eap Mailing List: Issue 175: Rewrite of Section 7.10 and 7.13

[Bernard Aboba (aboba]

Issue 175: Rewrite of Sections 7.10 and 7.13
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 9/11/2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-September/001658.html
Document: EAP-05
Comment type: T
Priority: S
Section: 7.10, 7.13
Rationale/Explanation of issue:

These sections need to be updated to avoid conflict with the Key Framework
Document.

Change Section 7.10 to:

"7.10 Key derivation

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.

The MSK and EMSK are not 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 EAP method is also responsible for the derivation of
Transient EAP Keys (TEKs) used for protection of the EAP conversation
itself.

EAP methods provide the MSK and EMSK and not Transient Session
Keys so as to allow EAP methods to be ciphersuite and media
independent. 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.

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.)

This specification does not provide detailed guidance on how EAP
methods are to derive the MSK, EMSK and TEKs, or how the TSKs are to
be derived from the AAA-Key. Key derivation is an art that is best
practiced by professionals; rather than inventing new key derivation
algorithms, reuse of existing algorithms such as those specified in
IKE [RFC2409], or TLS [RFC2246] is recommended.

Further details on EAP Key Derivation are provided within [KEYFRAME]."

Change Section 7.13 to:

"7.13 Separation of authenticator and backend authentication server

It is possible for the EAP peer and authenticator to mutually
authenticate, and derive a AAA-Key for a ciphersuite
used to protect subsequent data traffic. This does not present an
issue on the peer, since the peer and EAP client reside on the same
machine; all that is required is for the client to derive the AAA-Key
from the MSK and EMSK exported by the EAP method, and
to subsequently pass a Transient Session Key (TSK) to the ciphersuite
module.

However, in the case where the authenticator and authentication
server reside on different machines, there are several implications
for security.

[a] Authentication will occur between the peer and the authentication
server, not between the peer and the authenticator. This means
that it is not possible for the peer to validate the identity of
the authenticator that it is speaking to, using EAP alone.

[b] As discussed in [RFC3579], the authenticator is dependent on the
AAA protocol in order to know the outcome of an authentication
conversation, and does not look at the encapsulated EAP packet
(if one is present) to determine the outcome. In practice this
means that the AAA protocol spoken between the authenticator and
authentication server MUST support per-packet authentication,
integrity and replay protection.

[c] Where EAP is used over lower layers which are not physically
secure, subsequent to completion of the EAP conversation, a
subsequent secure association protocol SHOULD be run between the peer and
authentication in order to mutually authenticate the peer and
authenticator; guarantee liveness of the TSKs; provide protected
ciphersuite and capabilities negotiation; and provide for
synchronized key usage.

[d] A AAA-Key derived from the MSK and/or EMSK negotiated between
the peer and authentication server MAY be transmitted to the
authenticator. Therefore a mechanism needs to be provided to transmit the
AAA-Key from the authentication server to the authenticator that needs
it. The specification of the AAA-key derivation, transport and wrapping
mechanisms is outside the scope of this document. Further details on AAA
Key Derivation are provided within [KEYFRAME]."