Subject: [eap] Proposed resolution to Issue 176

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Sep 2003 12:21:48 -0700 (PDT)

Based on the discussion of Issue 176, I'd like to propose the following
potential resolution.

Add to Section 7.2.1:

Session independence
The demonstration that passive attacks (such as capture of the
EAP conversation) or active attacks (including compromise of the
MSK, EMSK, TSKs or TEKs) does not enable compromise of subsequent
or prior MSKs, EMSKs, TSKs or TEKs.

Add:

"Session indep.: N/A"

to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6

Change Section 7.10 to the following:

"It is possible for the peer and EAP server to mutually
authenticate and derive keys. In order to provide
keying material for use in a subsequently negotiated
ciphersuite, an EAP method supporting key derivation MUST
export a Master Session Key (MSK) of at least 64 octets,
and an Extended Master Session Key (EMSK) of at least 64
octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server.

The MSK and EMSK MUST NOT be used directly to protect data;
however, they are of sufficient size to enable derivation
of a AAA-Key subsequently used to derive Transient Session
Keys (TSKs) for use with the selected ciphersuite.
Each ciphersuite is responsible for specifying how to
derive the TSKs from the AAA-Key.

The AAA-Key is derived from the keying material exported by the
EAP method (MSK and EMSK). This derivation occurs on the AAA server.
In many existing protocols that use EAP, the AAA-Key and MSK
are equivalent, but more complicated mechanisms are possible
(see [KEYFRAME] for details).

EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases
where one party may not have a high quality random number generator. A
RECOMMENDED method is for each party to provide a nonce of at
least 128 bits, used in the derivation of the MSK and EMSK.

EAP methods export the MSK and EMSK and not Transient
Session Keys so as to allow EAP methods to be ciphersuite
and media independent. Keying material exported by EAP
methods MUST be independent of the ciphersuite negotiated
to protect data.

Depending on the lower layer, EAP methods may run
before or after ciphersuite negotiation, so that the
selected ciphersuite may not be known to the EAP method.
By providing keying material usable with any ciphersuite,
EAP methods can used with a wide range of ciphersuites and
media.

It is
RECOMMENDED that methods providing integrity protection of
EAP packets include coverage of all the EAP header fields,
including the Code, Identifier, Length, Type and Type-Data
fields.

In order to preserve algorithm independence, EAP methods
deriving keys SHOULD support (and document) the protected
negotiation of the ciphersuite used to protect the
EAP conversation between the peer and server. This is
distinct from the ciphersuite negotiated between the peer and
authenticator, used to protect data.

The strength of Transient Session Keys (TSKs) used to protect
data is ultimately dependent on the strength of keys generated
by the EAP method. If an EAP method cannot produce keying material of
sufficient strength, then the TSKs may be subject to brute force attack.
In order to enable deployments requiring strong keys, EAP methods
supporting key derivation SHOULD be capable of generating an
MSK and EMSK, each with an effective key strength of at least 128 bits.

Methods supporting key derivation MUST demonstrate
cryptographic separation between the MSK and
EMSK branches of the EAP key hierarchy. Without
violating a fundamental cryptographic assumption
(such as the non-invertibility of a one-way function)
an attacker recovering the MSK or EMSK MUST NOT
be able to recover the other quantity with a level
of effort less than brute force.

Non-overlapping substrings of the MSK MUST be
cryptographically separate from each other, as defined
in Section 7.2.1. That is, knowledge of one substring
MUST NOT help in recovering some other substring without
breaking some hard cryptographic assumption. This is required
because some existing ciphersuites form TSKs by simply
splitting the AAA-Key to pieces of appropriate length.
Likewise, non-overlapping substrings of the EMSK MUST
be cryptographically separate from each other, and
from substrings of the MSK.

The EMSK is reserved for future use and MUST remain on
the EAP peer and EAP server where it is derived; it
MUST NOT be transported to, or shared with, additional
parties, or used to derive any other keys. (This restriction
will be relaxed in a future document that specifies how the
EMSK can be used.)

Since EAP does not provide for explicit key lifetime
negotiation, EAP peers, authenticators and authentication
servers MUST be prepared for situations in which one or
parties discard key state which remains valid on another
party.

This specification does not provide detailed guidance
on how EAP methods derive the MSK and EMSK;
how the AAA-Key is derived from the MSK and/or EMSK;
or how the TSKs are be derived from the AAA-Key.

The development and validation of key derivation algorithms is difficult,
and as a result EAP methods SHOULD reuse well established and analyzed
mechanisms for key derivation (such as those specified in IKE [RFC2409] or
TLS [RFC2246]), rather than inventing new ones. EAP methods SHOULD also
utilize well established and analyzed mechanisms for MSK and EMSK
derivation.
Further details on EAP Key Derivation are provided within [KEYFRAME]."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap