eap Mailing List: issue: key separation (review of eap-keying-08 by mats naslund)

[Jari Arkko (jari.arkko]

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?