RE: Thoughts on Issue 325

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Alan said:


"  Pretty much, yes.  Or attributes that encode complex types with
"length" fields that are 16 bits, or are 8-bits of "count of 32-bit
words".  Both can result in the encoded data claiming to be "larger"
than the encapsulating attribute, and lead to overflows."

[BA] Yes, these are the kind of issues that have resulted in widely
publicized exploits against many different RADIUS servers. 

Alan said:

"  I'm not sure we can have an exhaustive checklist.

  Good design is a balance.  Solutions are often a compromise between
two equally ugly alternatives."

[BA] Yes.  However, the question is whether we provide enough info to
enable the reader to understand that balance.  

Alan said:

"  Some of that was due to a desire to be (somewhat) compatible with
existing deployments of an I-D that had not passed review."

[BA] My understanding is that the major change from the draft to
RFC 5090 was chopping up a single string attribute into 20 pieces. 
Some of the individual attributes make sense to me because they
are the kind of thing that might be used in policy logic
(such as the realm).  However, RFC 5090 is about 
authentication, so that the Design Guidelines document would
also appear to offer the possibility to have left the string
intact. 

Overall, RFC 5090 is not viewed very favorably within the
SIP or HTTP communities, and as far as I know, it is much
less widely implemented than the draft which it purported
to "improve".  

So the question in my mind is how this particular case could
should have been handled, and whether that is reflected in
the document. 




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