[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed resolution to guidelines document
- To: 'radext mailing list' <firstname.lastname@example.org>
- Subject: Proposed resolution to guidelines document
- From: Alan DeKok <email@example.com>
- Date: Tue, 19 Jan 2010 14:24:48 +0100
- User-agent: Thunderbird 18.104.22.168 (Macintosh/20090812)
I have put a proposed draft on my web site. It *should* address the
(cough) minor comments discussed here:
1) delete unused definition of RADIUS proxy as pointed out by Avi
2) add missing line as pointed out by Avi
3) change text about "complex" types to "new" types.
4) move "Complex attributes and security" to the "Security" section
5) remove all text referencing "applications" from that section,
and change the text to "other, non-RADIUS systems". This makes
the text generic enough to apply to application layers, or to
the practice of storing RADIUS data in SQL tables
6) add text about modern systems:
Some systems permit complex attributes to be defined via a method
that is more capable than traditional RADIUS dictionaries. These
systems can reduce the security threat of new types significantly,
but they do not remove it entirely.
7) it doesn't address Joe's comments or Bernard's suggestion. That
text will come later.
I believe that this addresses *all* of controversial points. The
document no longer relies on traditional RADIUS dictionaries to motivate
its recommendations. It no longer discusses *any* processing model of
RADIUS, other than to say that systems other than RADIUS may use the
data produced by RADIUS.
All it says is "prefer simple types to complex ones, but allow complex
ones if everything else is worse". And it says that change has risk.
If this text is deemed to be not applicable to the majority of
"RADIUS" implementations, then I suggest that those systems are no
longer implementing RADIUS.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.