RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

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

 



> Through the exchange of such identifiers one can bind the MSK to the
> identity of the authenticator. But.... this has issues, imho. RFC 3748 does
> not mandate such a feature on the EAP lower layers. 

RFC 3748 doesn't talk about this because it isn't an EAP issue -- EAP 
methods treat the authenticator identity as an opaque blob (e.g. channel 
bindings). 

> Not sure if any supports such a thing. 

IKEv2 and IEEE 802.11r both support binding of the authenticator identity 
to the transient session keys.   IEEE 802.11i only supported binding of a 
port identity (MAC address).  

> Rather than relying on another part of the architecture (phase 0 -- 
> discovery)

>From a security point of view, there is no reliance on phase 0 -- the 
binding needs to be handled securely in a post-EAP handshake. 

> All I'm trying to say is, EAP (RFC 3748) does not appear to support this
> particular rule from draft-housley-aaa-key-mgmt. Just an observation.

It is a correct observation because the rule doesn't apply to EAP.  It 
applies to the lower layers. 

> > So child keys often do persist longer than the parent key, and there is
> > no issue with this.  However, the maximum lifetime of the child keys
> > cannot be longer than the maximum lifetime of the parent.
> 
> This explains it very well. Thank you.

Is there an issue with the explanation in the document? 

_______________________________________________

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

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