RE: FW: HTTP digest and RADIUS; new version of the Sterman draft

[Avi Lior <avi@bridgewatersystems.com>]

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com]
> Sent: Monday, February 16, 2004 2:47 AM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: RE: FW: HTTP digest and RADIUS; new version of the 
> Sterman draft
> 
> 
> Avi Lior writes...
> 
> > Why is that any different then encoding a string with AVP
> as in X.500
> > encoding "a=1 b=3".  If that type of encoding is acceptable
> so should
> the
> > other.
> 
> [DBN] It IS different, and I don't know if I can come up with
> any additional or different explanations of why, beyond what 
> I have already written on this topic.  But let me try:  You 
> could, given the length constraints of attributes, create an 
> attribute of base-type undistinguished octets (String) and 
> include within the attribute value field an entire IPv4 
> packet.  

We are talking about RADIUS here right?  RADIUS attributes are limited to
253 Octets.  I don't see the relevance of your comment at all.

> We have one explicit example of an
> encapsulated protocol -- the EAP-Message attribute -- and 
> that's fine because it is reasonable, necessary and explicit. 
> It is also fine because EAP messages are clearly out-of-scope 
> for RADIUS.  No RADIUS product would want to attempt to parse 
> them -- they are "foreign" entities.

This is the exact case for Prepaid application and for Sterman draft. As you
correctly point out, just like the EAP case the internal attributes in both
the sterman draft and the prepaid draft are there exclusively for the
endpoint application.

As I suggested a million emails ago on this topic -- this should be the
test.  If the internal attributes are of use solely by the endpoint
applications (EAP for example) then there is no need to expose them.  Infact
there are advantages to be gained in performance gains in the proxy chains.
 
> The example you give in support of what I still call
> sub-types is X.500 addresses.  I have previously used a 
> similar example of DNS FQDNs.  Each of these is a multi-part 
> data type.  The distinction is that they are NOT a compendium 
> of attributes that are within the scope of AAA, grouped 
> together.  They are, to a large extent, an opaque data type 
> that the RADIUS protocol engine itself does not attempt to 
> parse.  They are forwarded to external entities, such as name 
> resolution engines, that process them, and potentially return 
> some useful result.  

Exactly correct. Once again this passes the above test.
Note that like in EAP endpoint application or foreign entities, or external
entities may be colocated with the RADIUS server or external to the RADIUS
server.  They are not part of the base RADIUS engine.

In past emails what I said was: If the protocol designer is allowed a
choice, it would be preferable that they use TLV encoding inside STRINGS as
opposed to "a=1  b=2" encoding scheme because of the obvious benefits of
being more compact and easier to parse.


>The only exception to this, that I'm
> aware of, is the NAI usages, in which a RADIUS proxy may 
> parse the "realm" portion of an NAI to determine the next hop 
> server address.

This is the minimum routing requirement and much more complex then you
indicate but I get your point and I agree.

> > The point which is made over and over is that the attribute
> is to be
> > interrperted only by endpoints and these would have code beyond the
> > dictionary anyway to parse further.
> 
> [DBN] I fully understand that point, however I reject it.
> This is not quite the same situation as the EAPOL messages we 
> encapsulate in EAP-Message attributes. The items being 
> debated are clearly, IMHO, AAA attributes fully within the 
> scope of RADIUS and Diameter.  Therefore any attempt to 
> "group" them in a fashion opaque to the majority of RADIUS 
> product simply fragments the multi-vendor interoperability of 
> RADIUS. The argument that only the RADIUS clients and servers 
> from companies that are promoting these proposals need to be 
> able to "play", i.e. to be able to parse the attributes if 
> they wish, is antithetical to the architecture of RADIUS.  
> Any such "limited scope" attributes MUST, IMHO, be VSAs.  
> Otherwise we no longer have a single, interoperable RADIUS standard.

I couldn't disagree with you more. First of all, the above argument has
nothing to do with with grouping attributes (or the creation of stealthy
protocols as you call it).  Its equally valid for ordinary RADIUS
attributes.  If I flatten out my "stealthy" attributes that doesn't mean
that everyone will implment them and should implment them!!!

And it's too late.  RADIUS already has the concept of extensions that are
not globally available or implemted by all RADIUS servers.

First there a groups of applications that are optionally supported:
EAP, CHIBA 3576, TUNNELS (2868), IPv6, WLAN extensions (RFC 3580)

Second there are many attributes that are optionally supported:

Look at all the Appletalk attributes.....

Not every deployment needs Appletalk 'stuff' and not every RADIUS client
supports these attributes. The same is true of EAP and the same could be
said of HTTP Digest.

You develop these extensions to that RADIUS can serve a purpose in an ever
evolving landscape.  You do this at the IETF for the obvious reasons.  

Mr Nelson, I am looking forward to you standing up at the next AAA-WG
meeting and objecting to having Diameter based Applications on the same
grounds.
 
> -- Dave
> 
> 
> 
> 

--
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/>