RE: review of draft-zorn-radius-pkmv1-04.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I believe the intent was "related to RADIUS security". The guidelines
> document could be updated to address this.

The rationale behind the original exemption was that security required
changes on both the RADIUS client and server.  Therefore the RADIUS
server would need a code change anyway, regardless of whether the
attributes were complex or simple.   That rationale applies not just
to "RADIUS security" but also to authentication mechanisms, many of
which were previously implemented with complex attributes (e.g. CHAP).
So I'm not clear that we're talking about a "loophole" here.

> encapsulation using RFC 2548 MPPE-Key attributes...

I was unclear about how this is supposed to work.  Is the idea to apply
the MPPE-Key encryption mechanism to the attribute specified
in the draft, or is the idea to actually use the MPPE-Key attributes
themselves?  If the former, more detail should be provided.  If the latter,
is it necessary to define two attribute formats or would it be simpler to
go with one?  If the RFC 2548 MPPE-Key attributes are used, is the format
the same as that defined in RFC 2548 (just a wrapped key) or is the wrapping
applied to a complex attribute? 

> a four octet Integer should be used instead of a two octet data type
> (which doesn't exist in RADIUS)

As I recall, the security exemption didn't apply to creation of new RADIUS
data types, correct?


_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]