eap Mailing List: RE: issue: key separation (review of eap-keying-08 bymatsnaslund)

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Wednesday, November 30, 2005 11:03 PM
> To: jari.arkko [at] piuha.net; eap [at] frascone.com
> Cc: mats.naslund [at] ericsson.com
> Subject: RE: [eap] issue: key separation (review of 
> eap-keying-08 bymatsnaslund)
> 
> The document is describing what is done today, which is that 
> the MSK is passed down to the lower layer.
> 
> One of the questions we have been discussing is whether the 
> EAP layer can provide for key separation. One problem is that 
> the EAP layer does not have a mechanism by which it can 
> negotiate the cryptographic algorithms with which to compute 
> the "separate keys".
> 
> EAP methods can negotiate ciphersuites, but this only applies 
> to the EAP conversation.
> There is no way for an EAP method to negotiate the f() used 
> to compute the lower layer keys. So if the EAP layer 
> specifies a KDF using a fixed algorithm (e.g. 
> SHA-1) and
> that algorithm is compromised, there is no way to fix it. 
> This seems short-sighted.
> 
[Joe] We have discussed previously the capability of an EAP method to specify 
or negotiate a KDF for an EMSK to AMSK derivation.  This could apply to other 
internal derivations as well.  This seems like it would be part of the 
ciphersuite agility for an EAP method. 

> Layers below EAP have a lot more flexibility -- and therefore 
> if "crypto-agility" is required, then negotiation of f() 
> needs to occur below EAP. Today there is no "middle layer" 
> between EAP and the lower layer, so the only way this can be 
> handled is in the lower layer.
> 
[Joe] EAP methods should have some crypto agility as well. 

> In terms of operation, there is no interaction between the 
> SAPs. The EAP keying material is used only by the lower layer 
> over which the EAP conversation occurred.
> 
> 
> >From: Jari Arkko <jari.arkko [at] piuha.net>
> >To: eap [at] frascone.com
> >CC: "Mats Näslund (KI/EAB)" <mats.naslund [at] ericsson.com>
> >Subject: [eap] issue: key separation (review of eap-keying-08 by 
> >matsnaslund)
> >Date: Thu, 01 Dec 2005 07:32:41 +0200
> >
> >Submitter name: Mats Naslund
> >Submitter email address: Mats.Naslund [at] ericsson.com
> >Reference: (this email)
> >Document: Keying Framework
> >Comment type: T
> >Priority: 1
> >Section: multiple
> >Rationale/Explanation of issue:
> >
> >   In order to preserve the security of keys derived within 
> EAP methods,
> >   lower layers other than AAA MUST NOT export keys passed 
> down by EAP
> >   methods.  This implies that EAP keying material or 
> parameters passed
> >   down to a lower layer are for the exclusive use of that 
> lower layer
> >   and MUST NOT be used within another lower layer.  This prevents
> >   compromise of one lower layer from compromising other applications
> >   using EAP keying parameters.
> >
> >MN: I guess this is "key separation"... But if this is a 
> MUST requirement,
> >why not here standardize a way to do it? I.e.
> >
> >    lower_layer_key = f(MSK, layer_ID).
> >
> >   In order to provide method independence, key
> >   management of exported or derived keys SHOULD NOT be 
> provided within
> >   EAP methods.
> >
> >MN: does this exclude that EAP can provide key separation?
> >
> >   Since neither EAP nor EAP methods provide key management 
> support, it
> >   is RECOMMENDED that key management facilities be provided 
> within the
> >   Secure Association Protocol.  This includes:
> >
> >MN: But if the MSK is always sent to the SA protocol, it really does
> >not help if the SA protocol does e.g. key separation. Compromise
> >of the "entity" hosting the SA protocol would still compromise the
> >MSK. I guess I am asking: is there a "middle layer" missing, between
> >EAP and the SA procotol that takes care of key separation?
> >
> >[a]  Entity Naming.  A basic feature of a Secure Association 
> Protocol is
> >     the explicit naming of the parties engaged in the exchange.
> >     Without explicit identification, the parties engaged in the
> >     exchange are not identified and the scope of the EAP keying
> >     parameters negotiated during the EAP exchange is undefined.  As
> >     shown in Figure 5, both the peer and authenticator may have more
> >     than one physical or virtual port, and as a result 
> SHOULD identify
> >     themselves in a manner that is independent of their 
> attached ports.
> >
> >
> >(snip)
> >
> >[j]  Bi-directional operation While some ciphersuites only require a
> >     single set of transient session keys to protect traffic in both
> >     directions, other ciphersuites require a unique set of transient
> >     session keys in each direction. The phase 2 Secure Association
> >     Protocol SHOULD provide for the derivation of unicast 
> and multicast
> >     keys in each direction, so as not to require two 
> separate phase 2
> >     exchanges in order to create a bi-directional phase 2 security
> >     association.
> >
> >MN: This part clarifies a lot. So, it seems there is a 
> "layer" missing...
> >It is said above that it is RECOMMENDED that the Secure Association
> >Protocol (SAP) supports all of this. But what about 
> interaction between
> >different SAPs? I.e. should there be a layer below EAP, but above SAP
> >that takes care of inter-access key separation? Or, where is 
> this done?
> >Or is cross-SAP usage prohibited?
> >
> >
> >_________________________________________________________________
> >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
>