[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Thoughts on Issue 325
" 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.
" 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.
" 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
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
So the question in my mind is how this particular case could
should have been handled, and whether that is reflected in
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.