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

[Avi Lior <avi@bridgewatersystems.com>]

Bernard,

While this debate is interesting its not addressing the issue.
We are not trying to create a new fundemental type!  We agree
That this would break RADIUS.

Sterman draft and my prepaid draft are not introducing any new 
fundemental type. We are introducing a new Attribute of
Type String.

Given that, that this is only to be decoded at the RADIUS 
server for which the Attribute is intended (and not by proxies) 
then how does this break existing RADIUS Server?  

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       | String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD for Digest-Attributes.

   Length

      >= 5

   String

      The  String  field  is 3 or more octets and contains one or
      more subattributes. Format of a subattribute is  shown  be¡
      low. The fields are transmitted from left to right.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      |     Sub-Type  |  Sub-Length   | Sub-Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

       .........................



> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: February 14, 2004 10:27 AM
> To: Alan DeKok
> Cc: radiusext@ops.ietf.org
> Subject: Re: FW: HTTP digest and RADIUS; new version of the 
> Sterman draft 
> 
> 
> > The single largest reason for defining sub-types is not to make our 
> > life easier when writing new I-D's for RADIUS.  It's to give other 
> > people a standard way of extending RADIUS, and thus to make 
> our life 
> > easier when we have to implement their modifications to the 
> protocol.
> 
> One of the basic design principles of RADIUS is that adding a 
> new attributes does not require code changes on the server.  
> To maintain this principle while adding sub-types is 
> extremely difficult because:
> 
> a.  RADIUS attributes are of limited length.  In Diameter, 
> attributes can be much larger, which allowed us to introduce 
> "Grouped" AVPs. However, "Grouped" attributes are permitted 
> in RFC 2865 only within attribute 26, Vendor-Specific, but 
> they are of limited utility since in RADIUS an attribute can 
> only be 253 octets in length.
> 
> b. AAA protocols have chosen not to introduce a data 
> definition language such as the SMI.  This was debated in the 
> AAA WG, but it was decided that this would introduce a level 
> of complexity that was not warranted.  In any case, now that 
> Diameter has chosen grouped AVPs, introduction of a data type 
> definition language in RADIUS would introduce compatibility issues.
> 
> Given the constraints implied by a) and b), the traditional 
> approach in RADIUS has been to introduce "tagged" attributes 
> that fit within existing data types.  For example, RFC 2867 
> and 2868 utilize tags within 4-octet integers, so that no new 
> data types are required.
> 
> Another potential approach would be to add additional 
> fundamental types, such as 128-bit IPv6 addresses.  While 
> code changes would be required, they would presumably only 
> need to be done once, and the basic RADIUS design principle 
> would be upheld.
> 
> 
> --
> 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/>
> 

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