ietf
[Top] [All Lists]

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

2006-11-19 15:23:45
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).

MSK is exported by the EAP method. So, I'd think the EAP method shall
provide the authenticator identity.

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).

I'm talking about MSK, not TSK. By the time EAP authentication is completed
successfully, there is an MSK but the EAP peer does not know the "identifier
of the parties to whom the session key is available."

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?

The I-D currently does not have any text describing this. So, it'd be useful
to include one. Russ had agreed with me, but I had a question about the
normative language. Your above text clarifies it all. Thanks.

Alper



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf