Subject: [eap] issue: key separation (review of eap-keying-08 by mats naslund)

From: Jari Arkko <[email-masked]>
Date: Thu, 01 Dec 2005 07:32:41 +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:

   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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 30 Nov 2005 23:03:10 -0800

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.

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.

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 <[email-masked]>
>To: [email-masked]
>CC: "Mats Näslund (KI/EAB)" <[email-masked]>
>Subject: [eap] issue: key separation (review of eap-keying-08 by 
>matsnaslund)
>Date: Thu, 01 Dec 2005 07:32:41 +0200
>