| RE: issue: key separation (review of eap-keying-08 by matsnaslund) | <– Date –> <– Thread –> |
From: Bernard Aboba (bernard_aboba hotmail.com)
|
|
| Date: Wed, 30 Nov 2005 23:03:13 -0800 (PST) | |
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.
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 <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
-
issue: key separation (review of eap-keying-08 by mats naslund) Jari Arkko, November 30 2005
- RE: issue: key separation (review of eap-keying-08 by matsnaslund) Bernard Aboba, November 30 2005
Results generated by Tiger Technologies using MHonArc.