ietf
[Top] [All Lists]

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

2006-11-17 15:24:24
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf