| Key derivation and the principle of equivalence | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Wed, 11 May 2005 22:54:45 -0400 (EDT) | |
At various points during the development of RFC 3748, we talked about the
"Principle of Equivalence" - that EAP methods operate the same way,
regardless of whether the authenticator is in "pass-through" mode or not.
One of the consequences of the Principle of Equivalence is that EAP key
management should be explainable without using terms that suggest that the
AAA server is required. Terms such as "AAA-Key" are somewhat confusing
because they suggest that EAP requires a AAA server in order to do key
derivation.
So as an experiment, I have collected the material in the Key Management
framework document that relates directly to EAP (not lower layers) and
rewritten it without introducing AAA. The text follows. If this
explanation seems more clear, this approach can be incorporated
into the Key Management framework. Comments welcome.
---------------------------------------------------------------------------
EAP Key Hierarchy
EAP, defined in [RFC3748] is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported.
The EAP Key Hierarchy, illustrated in Figure 1, has at the root the
long term credential utilized by the selected EAP method. If
authentication is based on a pre-shared key, the parties store the
EAP method to be used and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to
decide whether access to some service should be granted. The peer
stores information necessary to choose which secret to use for which
service.
If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access
to some service should be granted. The peer stores information
necessary to choose which certificate to use for which service.
Based on the long term credential established between the peer and
the server, EAP derives two types of keys:
[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| Peer-ID, | | Exported|
| Server-ID, | MSK (64+B) | IV (64B) by |
| Method-ID, | EMSK (64+B) | EAP |
| Key-Lifetime | | Method |
V V V V
Figure 1: EAP Key Hierarchy
EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known the Key-Lifetime. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange.
Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in
the EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method
authenticates the peer identity, that identity is exported by the
method as the Peer-ID. A suitable EAP peer name may not always be
available. Where an EAP method does not define a method-specific
peer identity, the Peer-ID is the null string. The Peer-ID for
existing EAP methods is defined in Appendix E.
Server-ID
Where the EAP method authenticates the server identity, that
identity is exported by the method as the Server-ID. A suitable
EAP server name may not always be available. Where an EAP method
does not define a method-specific peer identity, the Server-ID is
the null string. The Server-ID for existing EAP methods is
defined in Appendix E.
Method-ID
EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-
ID uniquely identifies an EAP session of a given Type between an
EAP peer and server. The Method-ID is typically constructed from
nonces or counters used within the EAP method exchange. The
Method-ID for existing EAP methods is defined in Appendix E.
Session-ID
The Session-ID uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-ID) and server (as identified by
the Server-ID). The EAP Session-ID consists of the concatenation
of the Expanded EAP Type Code (including the Type, Vendor-ID and
Vendor-Type fields defined in [RFC3748] Section 5.7) and the
Method-ID.
Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these
methods. As a result, it is NOT RECOMMENDED to use this approach as
the sole way to determine key lifetimes.
As illustrated in Figure 2, keying material and parameters exported
by EAP methods are passed down to the EAP peer or authenticator
layers, which passes them to the EAP layer. Keying material and
related parameters MUST NOT be cached by the EAP peer or
authenticator layers, or the EAP layer. Based on the Method-ID
exported by the EAP method, the EAP layer forms the EAP Session-ID by
concatenating the EAP Expanded Type with the Method-ID. Together
with the MSK, EMSK, IV, Peer-ID, Server-ID, and Key-Lifetime, the EAP
layer passes the Session-ID down to the lower layer.
The Method-ID is exported by EAP methods rather than the Session-ID
so as to prevent EAP methods from writing into each other's Session-
ID space. Lower layers MAY cache keying material and related
parameters. Lower Layer behavior is discussed in more detail in
Section TBD.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| EAP method |
| |
| MSK, EMSK, IV, Peer-ID, |
| Server-ID, Method-ID, |
| Key-Lifetime |
| |
| V |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+
| ! |
| EAP ! Peer or Authenticator |
| ! layer |
| ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+
| ! |
| EAP ! layer |
| ! |
| ! Session-ID = |
| ! Expanded-Type || |
| ! Method-ID |
| ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+
| ! |
| Lower ! layer |
| ! |
| V |
| MSK, EMSK, IV, Peer-ID, |
| Server-ID, Session-ID, |
| Key-Lifetime |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flow of EAP keying material
Key Naming
The naming of keys within the EAP key hierarchy is based on the EAP
Session-ID.
MSK Name
This key is created between the EAP peer and EAP server, and can
be referred to using the string "MSK:", concatenated with the EAP
Session-ID.
EMSK Name
The EMSK can be referred to using the string "EMSK:", concatenated
with the EAP Session-ID.
IV Name
Use of the IV is deprecated. However, if necessary the IV can be
referred to using the string "IV:" concatenated with the EAP
Session-ID.
PMK Name
This document does not specify a naming scheme for the PMK. The
PMK is only identified by the key from which it is derived.
Note: IEEE 802.11i names the PMKID for the purposes of being able
to refer to it in the Secure Association protocol; this naming is
based on a hash of the PMK itself as well as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]).
TEKs
The TEKs may or may not be named. Their naming is specified in the
EAP method.
EAP Invariants
Certain basic characteristics, known as the "EAP Invariants" hold
true for EAP implementations on all media:
Mode independence
Media independence
Method independence
Ciphersuite independence
Mode Independence
EAP as defined in [RFC3748] is a two party protocol spoken between
the EAP peer and server. A fundamental property of EAP is that the
conversation between the EAP peer and server is unaffected by whether
the EAP authenticator is operating in "pass-through" mode.
The principle of Mode Independence extends to the operation of EAP
methods, including key derivation. EAP methods operate identically
regardless of whether the authenticator is operating as a pass-
through or not; this also applies to the derivation of keying
material.
Since EAP is a protocol spoken between two parties, the completion of
an EAP method results in the derivation of keying material on the EAP
peer and server. Since the EAP peer is unaware of whether the EAP
authenticator is operating in "pass-through" mode or not, key
derivation is unaffected by this, and the parameters exported by EAP
methods (MSK, EMSK, IV, Method-ID, Peer-ID, Server-ID, Key-Lifetime)
are similarly unaffected.
Within EAP, the primary function of the AAA protocol is to maintain
the principle of Mode Independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the
authenticator mode of operation.
Media Independence
One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE
802.11 wireless LANs [IEEE-802.11i].
In order to maintain media independence, it is necessary for EAP to
avoid inclusion of media-specific elements. For example, EAP methods
cannot be assumed to have knowledge of the lower layer over which
they are transported, and cannot utilize identifiers associated with
a particular usage environment (e.g. MAC addresses).
The need for media independence has also motivated the development of
the three phase exchange. Since discovery is typically media-
specific, this function is handled outside of EAP, rather than being
incorporated within it. Similarly, the Secure Association Protocol
often contains media dependencies such as negotiation of media-
specific ciphersuites or session parameters, and as a result this
functionality also cannot be incorporated within EAP.
Note that media independence may be retained within EAP methods that
support channel binding or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to
use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence. To
support channel binding, an EAP method can pass binding parameters to
the AAA server in the form of an opaque blob, and receive
confirmation of whether the parameters match, without requiring
media-specific knowledge.
Method Independence
By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code.
As a result, as noted in [RFC3748], authenticators must by default be
capable of supporting any EAP method. Since the Discovery and Secure
Association exchanges are also method independent, an authenticator
can carry out the three phase exchange without having an EAP method
in common with the peer.
This is useful where there is no single EAP method that is both
mandatory-to-implement and offers acceptable security for the media
in use. For example, the [RFC3748] mandatory-to-implement EAP method
(MD5-Challenge) does not provide dictionary attack resistance, mutual
authentication or key derivation, and as a result is not appropriate
for use in wireless LAN authentication [RFC4017]. However, despite
this it is possible for the peer and authenticator to interoperate as
long as a suitable EAP method is supported on the EAP server.
Ciphersuite Independence
While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator out-of-band of EAP. Since
ciphersuite negotiation is assumed to occur out-of-band, there is no
need for ciphersuite negotiation within EAP. Since ciphersuite
negotiation occurs outside of EAP, EAP methods generate keying
material that is ciphersuite-independent.
For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way
handshake exchange after EAP authentication has completed.
Advantages of ciphersuite-independence include:
Reduced update requirements
If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the
authenticator.
Reduced EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase method complexity
and result in duplicated effort.
Simplified configuration
The ciphersuite is negotiated between the peer and authenticator
out-of-band of EAP. The backend authentication server is neither a
party to this negotiation, nor is it an intermediary in the data
flow between the EAP peer and authenticator. The backend
authentication server may not have knowledge of the ciphersuites
and negotiation policies implemented by the peer and authenticator,
or be aware of the ciphersuite negotiated between them. This
simplifies the configuration of the backend authentication server.
For example, since ECP negotiation occurs after authentication,
when run over PPP, the EAP peer, authenticator and backend
authentication server may not anticipate the negotiated ciphersuite
and therefore this information cannot be provided to the EAP
method.
Appendix E - Key Names and Scope in Existing Methods
This appendix specifies Method-ID, Peer-ID, Server-ID and Key-
Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a
definition of the Method-ID Peer-ID, and Server-ID (could be the
empty string) and MAY also define Key-Lifetime (assumed to not be
exported if not described).
EAP-Identity
The EAP-Identity method does not derive keys, and therefore does not
define the Key-Lifetime or Method-ID. The Peer-ID exported by the
Identity method is determined by the octets included within the EAP-
Response/Identity. The Server-ID is the empty string (zero length).
EAP-Notification
The EAP-Notification method does not derive keys and therefore does
not define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID
are the empty string (zero length).
EAP-GTC
The EAP-GTC method does not derive keys and therefore does not define
the Key-Lifetime and Method-ID. The Peer-ID and Server-ID are the
empty string.
EAP-OTP
The EAP-OTP method does not derive keys and therefore does not define
the Key-Lifetime and Method-ID. The Peer-ID and Server-ID are the
empty string.
EAP-TLS
The EAP-TLS Method-Id is the concatenation of the peer and server
nonces.
The Peer-ID and Server-ID are the contents of the altSubjectName in
the peer and server certificates.
EAP-TLS does not negotiate a Key-Lifetime.
EAP-AKA
The EAP-AKA Method-Id is the contents of the RAND field from the
AT_RAND attribute, followed by the contents of the AUTN field in the
AT_AUTN attribute.
The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The Server-
ID is an empty string. EAP-AKA does not negotiate a key lifetime.
EAP-SIM
The Method-Id is the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the NONCE_MT field in the
AT_NONCE_MT attribute.
The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The Server-
ID is an empty string. EAP-SIM does not negotiate a key lifetime.
-
Key derivation and the principle of equivalence Bernard Aboba, May 11 2005
-
Re: Key derivation and the principle of equivalence Jari Arkko, May 12 2005
- Re: Key derivation and the principle of equivalence Bernard Aboba, May 12 2005
-
Re: Key derivation and the principle of equivalence Bernard Aboba, May 15 2005
- Re: Key derivation and the principle of equivalence Yoshihiro Ohba, May 16 2005
-
Re: Key derivation and the principle of equivalence Jari Arkko, May 12 2005
Results generated by Tiger Technologies using MHonArc.