Subject: RE: [eap] issue: aaa-key confusion (review of eap-keying-08 bymatsnaslund)

From: "Salowey, Joe" <[email-masked]>
Date: Sun, 4 Dec 2005 21:43:21 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2005 10:04 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [eap] issue: aaa-key confusion (review of 
> eap-keying-08 bymatsnaslund)
> 
> Since existing EAP lower layers only make use of the MSK, the 
> MSK must be transported from the server to  authenticator in 
> order to provide for mode independence. Currently it is not 
> necessary to transport other keys, since existing lower 
> layers don't use them. However, it does not necessarily 
> follow that only the MSK can be transported.
> 
> So yes, the MSK must be transported as a consequence of mode 
> independence. 
> And yes, AAA-Key = MSK, but this is a tautology, not a 
> consequence of any principle.  I think it is more correct to 
> say that "all keys which are required by the lower layer need 
> to be transported  from the server to the authenticator", and 
> leave the term "AAA-Key" out of it.
> 

[Joe] I don't really like the name AAA-key either, but it is somewhat descriptive of the keys that are sent to the authenticator. The AAA-Key=MSK does not have to be true in all cases in order to support mode independence.  The lower layer just needs to define things in such that the key is derived the same way regardless of the back end architecture.  We should have a section in the document which describes what the lower layer needs to define, and how to derive the keys that are sent to the authenticator (AAA-KEY?) should be part of this. 

> 
> 
> >From: Jari Arkko <[email-masked]>
> >To: [email-masked]
> >CC: "Mats Näslund (KI/EAB)" <[email-masked]>
> >Subject: [eap] issue: aaa-key confusion (review of eap-keying-08 by
> >matsnaslund)
> >Date: Thu, 01 Dec 2005 07:29:31 +0200
> >
> >Submitter name: Mats Naslund
> >Submitter email address: [email-masked]
> >Reference: (this email)
> >Document: Keying Framework
> >Comment type: T
> >Priority: 1
> >Section: multiple
> >Rationale/Explanation of issue:
> >
> >AAA-Key
> >     A key derived by the peer and EAP server, used by the peer and
> >     authenticator in the derivation of Transient Session 
> Keys (TSKs).
> >     Where a backend authentication server is present, the AAA-Key is
> >     transported from the backend authentication server to the
> >     authenticator.  In existing usage, the AAA-Key is always derived
> >     from the MSK and so can be referred to using the MSK 
> name.  AAA-Key
> >     = MSK(0,63).
> >
> >MN: Isn't it the case that we MUST
> >have AAAk = MSK for mode independence?? Why does it only say "in 
> >existing usage..."
> >
> >The purpose of the PMK is a bit unclear to me...
> >
> >   Within EAP, the primary function of the AAA protocol is 
> to maintain
> >   the principle of Mode Independence, so that as far as the 
> EAP peer is
> >   concerned, its conversation with the EAP authenticator, and all
> >   consequences of that conversation, are identical, 
> regardless of the
> >   authenticator mode of operation.
> >
> >MN: Doesn't this imply that AAAk MUST be equal to MSK?
> >
> >   An additional step (phase 1b) is required in deployments which
> >   include a backend authentication server, in order to 
> transport keying
> >   material from the backend authentication server to the 
> authenticator.
> >   In order to obey the principle of Mode Independence, 
> where a backend
> >   server is present AAA Key transport needs to provide the 
> exported EAP
> >   keying material and/or derived keys required for derivation of the
> >   TSKs.  Since existing TSK derivation techniques depend 
> solely on the
> >   MSK, in existing AAA implementations, this is the only keying
> >   material replicated in the AAA key transport phase 1b.
> >
> >MN: again does this imply that MSK = AAAk? How else get mode 
> independence?
> >
> >_________________________________________________________________
> >To unsubscribe or modify your subscription options, please visit:
> >http://lists.frascone.com/mailman/listinfo/eap
> >
> >Arhives: http://lists.frascone.com/pipermail/eap
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap