| Issue 236: (Key Framework) Rewrite of Section 2 | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Sat, 3 Apr 2004 18:36:21 -0500 (EST) | |
Issue 236: Rewrite of Section 2
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 4/3/2004
Reference:
Document: Keying-01
Comment type: T/E
Priority: S
Section: 2
Rationale/Explanation of issue:
I've gone and rewritten Section 2 to improve the organization and
readability.
Change Section 2 to the following:
"2. EAP Key Hierarchy
2.1. Key Terminology
The EAP Key Hierarchy makes use of the following types of keys:
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length.
Extended Master Session Key (EMSK)
Additional keying material derived between the peer and server that
is exported by the EAP method. The EMSK is at least 64 octets in
length, and is never shared with a third party.
AAA-Key
A key derived by the peer and EAP server, used by the peer and
authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator, wrapped within the AAA-Token; it is therefore known
by the peer, authenticator and backend authentication server.
However, despite the name, the AAA-Key is computed regardless of
whether a backend authentication server is present. AAA-Key
derivation is discussed in Appendix E; in existing implementations
the MSK is used as the AAA-Key.
AAA-Token
Where a backend server is present, the AAA-Key and one or more
attributes is transported between the backend authentication server
and the authenticator within a package known as the AAA-Token. The
format and wrapping of the AAA-Token, which is intended to be
accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples include
RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].
Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the peer and
EAP server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716], it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it.
However, when it is generated it MUST be unpredictable.
Pairwise Master Key (PMK)
The AAA-Key is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
Encryption Key" (Enc-SEND-Key) (reception is defined from the point
of view of the authenticator). Within [IEEE80211i] Octets 0-31 of
the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK). In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the AAA-Key.
Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the
EAP conversation. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and authenticator. An
example TEK key hierarchy is described in Appendix C.
Transient Session Keys (TSKs)
Session keys used to protect data which are appropriate for the
ciphersuite negotiated between the EAP peer and authenticator. The
TSKs are derived from AAA-Key during the Secure Association
Protocol. In the case of [IEEE80211i] the Secure Association
Protocol consists of the 4-way handshake and group key derivation.
An example TSK derivation is provided in Appendix D.
2.2. Key Hierarchy
The EAP Key Hierarchy, illustrated in Figure 3 below, includes three
types of keys:
[1] Keys calculated locally by the EAP method but not exported,
such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV and
keys calculated from exported quantities: AAA-Key.
[3] Keys calculated by the Secure Association Protocol: TSKs.
In order to protect some or all of the EAP conversation, EAP methods
supporting key derivation typically negotiate a ciphersuite and
derive Transient EAP Keys (TEKs) to provide keys for that
ciphersuite. However, the TEKs are stored locally within the EAP
method and are not exported.
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.
On both the peer and EAP server, the exported MSK and EMSK are
utilized in order to calculate the AAA-Key. Where a backend
authentication server is present, the AAA-Key is transported from the
backend authentication server to the authenticator within the AAA-
Token, using the AAA protocol.
Once EAP authentication completes and is successful, the peer and
authenticator obtain the AAA-Key and the Secure Association Protocol
is run between the peer and authenticator in order to securely
negotiate the ciphersuite, derive fresh TSKs used to protect data,
and provide mutual proof of possession of the AAA-Key.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | | |
| | EAP Method Key | | |
| | Derivation | | |
| | | | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | |
| | | | | |
| | |
| V | | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| | | |
| MSK (64B) | EMSK (64B) | IV (64B) |
| | | Exported|
| | | by |
V V V EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method|
| AAA Key Derivation, | | Known | |
| Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
| ---+
| Transported |
| AAA-Key by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK | Ciphersuite |
| Derivation | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 3: EAP Key Hierarchy
When the authenticator acts as an endpoint of the EAP conversation
rather than a pass-through, EAP methods are implemented on the
authenticator as well as the peer. If the EAP method negotiated
between the EAP peer and authenticator supports mutual authentication
and key derivation, the EAP Master Session Key (MSK) and Extended
Master Session Key (EMSK) are derived on the EAP peer and
authenticator and exported by the EAP method. In this case, the MSK
and EMSK are known only to the peer and authenticator and no other
parties. The TEKs and TSKs also reside solely on the peer and
authenticator. This is illustrated in Figure 4. As demonstrated in
[I-D.ietf-roamops-cert], in this case it is still possible to support
roaming between providers, using certificate-based authentication.
Where a backend authentication server is utilized, the situation is
illustrated in Figure 5. Here the authenticator acts as a pass-
through between the EAP peer and a backend authentication server. In
this model, the authenticator delegates the access control decision
to the backend authentication server, which acts as a Key
Distribution Center (KDC). In this case, the authenticator
encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]
or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the
backend authentication server, which acts as the EAP server. Since
the authenticator acts as a pass-through, EAP methods reside only on
the peer and EAP server As a result, the TEKs, MSK and EMSK are
derived on the peer and EAP server.
On completion of EAP authentication, EAP methods on the peer and EAP
server export the Master Session Key (MSK) and Extended Master
Session Key (EMSK). The peer and EAP server then calculate the AAA-
Key from the MSK and EMSK, and the backend authentication server
sends an Access-Accept to the authenticator, providing the AAA-Key
within a protected package known as the AAA-Token.
The AAA-Key is then used by the peer and authenticator within the
Secure Association Protocol to derive Transient Session Keys (TSKs)
required for the negotiated ciphersuite. The TSKs are known only to
the peer and authenticator.
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| |===============| |
| |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator |
| | | |
| | Secure Assoc. | |
| peer |<------------->| (EAP |
| |===============| server) |
| | Link layer | |
| | (PPP,IEEE802) | |
| | | |
|MSK,EMSK | |MSK,EMSK |
| AAA-Key | | AAA-Key |
| (TSKs) | | (TSKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 4: Relationship between EAP peer and authenticator (acting as
an EAP server), where no backend authentication server is present.
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| |
| |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend |
| | | | | |
| | Secure Assoc. | | AAA-Key| |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
| | | | | |
|MSK,EMSK | | AAA-Key | |MSK,EMSK,|
| (TSKs) | | (TSKs) | | AAA-Key |
| | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 5: Pass-through relationship between EAP peer, authenticator
and backend authentication server.
2.3. Requirements for EMSK Usage
EAP reserves a portion of keying material, called the EMSK, for
extended uses. Keys derived from this key material may be used to
key applications on different devices and different processes
separate from the entity that receives the MSK.
If the keying material is used to provide keys for multiple
Applications or devices, it is desired that the keys will be
cryptographically separate. Cryptographic separation means that
knowledge of one key does not provide an easy way to determine
another key derived from the same key material. This is also known
as computationally independent.
This section provides guidelines for a mechanism which can be used
with existing and new EAP methods and applications to provide
cryptographic separation between keys derived for different
applications and devices. These derived keys are referred to in this
section as Application Master Session Keys or AMSK.
The EAP EMSK usage guidelines provide a means for generating multiple
application-specific master keys (AMSKs). These AMSKs are then used
to derive transient session keys (TSKs), which are used as actual
ciphering keys. This allows multiple applications to use keys
independently derived from the EAP method.
AMSK Key Derivation is discussed in Appendix F."
-
Issue 236: (Key Framework) Rewrite of Section 2 Bernard Aboba, April 3 2004
- Re: Issue 236: (Key Framework) Rewrite of Section 2 Florent Bersani, April 8 2004
Results generated by Tiger Technologies using MHonArc.