[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RADIUS FIXES] Authorize Only / RADIUS layering criteria
Hi,
On Wed, Jul 27, 2005 at 04:19:23PM -0400, Alan DeKok wrote:
> "Nelson, David" <dnelson@enterasys.com> wrote:
> > The specific practice that I'm suggesting is undesirable is the
> > definition of new RADIUS attributes, and their basic semantic
> > descriptions, in RFCs defining the applications, rather than in
> > [companion] RADIUS extensions RFCs. That does not mean that the I-Ds
> > for such RADIUS extensions need to be work items for the RADEXT WG.
>
> That makes sense.
>
> To address Emile's view, let's take PEAP as an example. The RADIUS
> server gets these layers:
>
> ethernet
> IPv4
> UDP
> RADIUS
> EAP
> EAP-PEAP
> TLS'
> EAP'
> EAP-MSCHAPv2
>
> Those layers don't map 1-1 to the OSI 7 layer stack. I think what
> Emile is saying is is that if you pick a layer, everything "below" you
> is transport, and everything "above" you is application.
Exactly. Well said.
I also agree with David above to some extent, but would suggest the
following criteria on that.
Let's take the example of Class for simplicity, supposing for a moment
that it isn't already defined. The generic opaque attribute that SHOULD
be echoed by the NAS would be defined by a RADIUS extension RFC, and be
available for use in any application that requires an attribute with
those external semantics. The upgrade from SHOULD to MUST would
require an upgrade to the core RADIUS RFC.
The RADIUS extension RFC defining Class could suggest its use as a
billing item reference or similar uses. However, it should not enumerate
or limit future applications, or put constraints on its value, when not
required for its basic definition ('an attribute whose contents are
copied from access accept to subsequent accounting request').
If our 'new' Class attribute can be defined without reference to or
(partial) implementation of the applications that use it, or without
mentioning application specific constraints on its value (eg. must be a
valid domain name, or in UTF-8, or whatnot) that are not required for
the NAS to perform the essential task of echoing the value from access
accepts in accounting requests, no such reference or constraint should
be given in the definition of Class in our fictional RADIUS extension
RFC.
However, the use of Class to implement secure roaming to non-trusted
upstream providers would be subject of an application level RFC for
secure roaming, including the requirement that a cryptographically
strong RNG must be used to generate part of its contents, and so on.
I do agree with David that it would be a shame if both the body defining
secure roaming and the body thinking about billing items would each
reinvent some form of Class. I agree that our hypothetical Class should
be defined as a RADIUS extension and not on the application level,
especially if its semantics are likely to have more than one application
(even disregarding for a moment the fact that it requires a change at
the NAS at the code level for most NASes).
However, I think that if an application standardized by the IETF needs a
new non-vendor specific attribute number, but the attribute doesn't
require any special handling by clients, proxies or servers, no RADIUS
standards work should be required.
A good example would be Acct-Input-Gigawords. It's external semantics
(when and where it's sent) is identical to Acct-Input-Octets and it does
not change anything that already exists.
A good counterexample would be Message-Authenticator; the implementation
of that needs code changes to the core of a RADIUS server and client,
because you need access to the whole packet to calculate or verify the
signature contained in it. Others would be User-Password and
Tunnel-Password because they need decrypting and re-encrypting at each
proxy.
To address the MIB etc. point made elsewhere in this discussion: I do
think that the number space is orthogonal to standardization. If you do
standards work for a new application that already requires a specific
type of endpoint and the application does not affect the proxies in any
way, you should be allowed to request a number for a new attribute from
the main attribute space via IANA, without full fledged RADIUS standards
work. This is also very well laid down in RFC 2865 section 6.2.
If the allocation of new attributes from the non-VSA space without
RADIUS standards work would go against current IETF policy, then I'd
rather see a new VSA space with IETF as the vendor and the IANA as the
entity governing the number space to hold such simple new attributes,
than a fully fledged process to update RADIUS each time a new RADIUS
application is standardized by the IETF.
But as said, and I think I agree with David here: as soon as an
application requires new attributes that may have wider use, or
attributes with special external semantics that may be useful for other
applications as well, they should be defined in a RADIUS extension RFC
(but as generically as possible!), not solely in a RADIUS application
RFC, so as to protect RADIUS applications from reinventing their wheels
as much as possible.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>