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

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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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