| Re: Rewrite of Section 2 of the EAP Key Management Framework | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Wed, 21 Sep 2005 14:57:17 -0400 (EDT) | |
Oops... sent an old version. Here is the proposed rewrite:
-------------------------------------------------------------------------
2. Lower Layer Operation
2.1. Overview
Where EAP key derivation is supported, the conversation typically
takes place in three phases:
Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication
1b: AAA Key Transport (optional)
Phase 2: Secure Association Establishment
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)
Of these phases, Phase 0, 1b and Phase 2 are handled by a lower
layer. In the discovery phase (phase 0), peers locate
authenticators and discover their capabilities. For example, a peer
may locate an authenticator providing access to a particular network,
or a peer may locate an authenticator behind a bridge with which it
desires to establish a Secure Association.
The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase always includes EAP
authentication (phase 1a). Where the chosen EAP method supports key
derivation, in phase 1a EAP keying material is derived on both the
peer and the EAP server. This keying material may be used for
multiple purposes, including protection of the EAP conversation and
subsequent data exchanges.
An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence, where a backend
server is present AAA Key transport needs to replicate the exported
EAP keying material and/or derived keys required for derivation of
the TSKs. Since existing TSK derivation techniques depend solely on
the MSK, in existing AAA implementations, this is the only keying
material replicated in the AAA key transport phase 1b.
A Secure Association exchange (phase 2) then occurs between the peer
and authenticator in order to manage the creation and deletion of
unicast (phase 2a) and multicast (phase 2b) security associations
between the peer and authenticator. The conversation between the
parties is shown in Figure 3.
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
Figure 3: Conversation Overview
2.2. Discovery Phase
In the discovery phase (phase 0), the EAP peer and authenticator
locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on the lower layer
over which EAP runs. Since authenticator discovery is handled
outside of EAP, there is no need to provide this functionality within
EAP.
For example, where EAP runs over PPP, the EAP peer might be
configured with a phone book providing phone numbers of
authenticators and associated capabilities such as supported rates,
authentication protocols or ciphersuites. In contrast, PPPoE
[RFC2516] provides support for a Discovery Stage to allow a peer to
identify the Ethernet MAC address of one or more authenticators and
establish a PPPoE SESSION_ID.
IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing the
peer (known as the station or STA) to determine the MAC address and
capabilities of one or more authenticators (known as Access Point or
APs).
2.3. Authentication Phase
Once the peer and authenticator discover each other, they exchange
EAP packets. Typically, the peer desires access to the network, and
the authenticators provide that access. In such a situation, access
to the network can be provided by any authenticator attaching to the
desired network, and the EAP peer is typically willing to send data
traffic through any authenticator that can demonstrate that it is
authorized to provide access to the desired network.
An EAP authenticator may handle the authentication locally, or it may
act as a pass-through to a backend authentication server. In the
latter case the EAP exchange occurs between the EAP peer and a
backend authenticator server, with the authenticator forwarding EAP
packets between the two. The entity which terminates EAP
authentication with the peer is known as the EAP server. Where pass-
through is supported, the backend authentication server functions as
the EAP server; where authentication occurs locally, the EAP server
is the authenticator. Where a backend authentication server is
present, at the successful completion of an authentication exchange,
EAP keying material is transported to the authenticator (phase 1b).
EAP may also be used when it is desired for two network devices (e.g.
two switches or routers) to authenticate each other, or where two
peers desire to authenticate each other and set up a secure
association suitable for protecting data traffic.
Some EAP methods exist which only support one-way authentication;
however, EAP methods deriving keys are required to support mutual
authentication. In either case, it can be assumed that the parties
do not utilize the link to exchange data traffic unless their
authentication requirements have been met. For example, a peer
completing mutual authentication with an EAP server will not send
data traffic over the link until the EAP server has authenticated
successfully to the peer, and a Secure Association has been
negotiated.
Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers
may act as authenticators and authenticatees at the same time.
Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre-
establish EAP security associations in order to decrease handoff or
roaming latency.
2.4. Secure Association Phase
The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport
(phase 1b).
Secure Association Protocols typically include the following
features:
[1] Generation of fresh unicast and multicast transient session keys.
[2] Integrity and replay protection. This ensures that the Secure
Association Protocol messages cannot be forged, modified or
replayed.
[3] Secure capabilities negotiation. This enables security-relevant
parameters such as cryptographic algorithms to be securely
negotiated.
[4] Key naming. In order to avoid confusion in the case where an EAP
peer has more than one set of exported EAP parameters applicable to
establishment of a phase 2 security association with an
authenticator, the secure Association protocol needs to identify
the keying material for use in the Secure Association Protocol
exchange.
[5] Key management. This enables security associations to be created
and deleted, and for key state to be kept synchronized between the
peer and authenticator.
[6] Mutual proof of possession of EAP keying material between the peer
and authenticator. This enables the EAP peer and authenticator to
confirm authorization.
Aspects of the Secure Association Protocol are discussed in more
detail in Section 4.
2.5. Layering
In completion of EAP authentication, EAP methods on the peer and EAP
server export the Master Session Key (MSK), Extended Master Session
Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
ID and Key-Lifetime. As illustrated in Figure 4, 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 (including Channel Bindings) 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.
2.6. Key Usage
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 and
MUST NOT be used within another lower layer.
The exception to this rule is AAA. As illustrated in Figure 5, the
AAA client provides transported EAP keying material and parameters to
the EAP authenticator lower layer. In order to prevent the
compromise of transported EAP keying material and parameters, the AAA
client and EAP authenticator MUST be co-resident.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| EAP method |
| |
| MSK, EMSK, IV, Channel |
| Peer-ID, Server-ID, Bindings |
| Method-ID, |
| Key-Lifetime |
| |
| V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! Peer or Authenticator ! ! |
| ! layer ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer ! ! |
| ! ! ! |
| V V ^ |
| MSK, EMSK, IV, Channel Result |
| Peer-ID, Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Flow of EAP parameters
Peer Pass-through Authenticator Authentication
Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | V |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | | | |EAP !Auth.|
| ! | | | | | | ! |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | | | | | ! |
|EAP !layer| | EAP layer| EAP layer | |EAP !layer|
| ! | | | | | ! |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | | | | | ! |
| ! | | +-----------+ | | ! |
| ! | | ! | ! | | ! |
|Lower!layer| | Lower!layer| AAA ^ /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
| V | | V | ! | | ! |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! !
! !
+---------<-------+
AAA Protocol
Figure 5: Flow of EAP Keying Material and Parameters
2.6.1. Caching
If explicitly permitted within the lower layer specification, lower
layers MAY cache exported EAP keying material and related parameters,
including Channel Bindings. So as to enable interoperability, new
EAP lower layer specifications MUST describe EAP key caching
behavior. The caching behavior of existing EAP lower layers is as
follows:
PPP PPP, defined in [RFC1661] does not support caching of EAP key
material or parameters. Therefore EAP keying material passed down
to the lower layer is assumed to be lost and cannot be recovered.
IKEv2
IKEv2, defined in [IKEv2] only uses EAP keying material for
authentication purposes and not key derivation. As a result, IKEv2
does not cache EAP keying material or parameters, nor does it
utilize the Key-Lifetime to determine the lifetime of IPsec SAs.
As result, once IKEv2 authentication completes it is assumed that
EAP keying material and parameters are discarded.
IEEE 802.11i
IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
Peer-ID, Server-ID, Session-ID, or Key-Lifetime. More details are
about the structure of the cache are available in [IEEE-802.11i].
IEEE 802.1X-2004
IEEE 802.1X, defined in [IEEE-802.1X] does not support caching of
EAP keying material or parameters.
AAA Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
EAP [RFC4207] do not support caching of EAP keying material or
parameters. Regardless of whether a given AAA implementation
supports caching, keying material transported by AAA MUST be
discarded by the AAA server once it is sent.
2.7. Lower Layer Naming
Within the lower layer, the EAP peer and authenticator typically
utilize lower layer names to identify each other and define the scope
of cached keying material. However EAP methods treat lower layer
peer and authenticator identities as opaque blobs and do not
interpret them. For example, EAP peers cannot compare the lower
layer authenticator identifier with the Server-ID provided by the EAP
method, since these two identifiers will not be the same where pass-
through authentication is implemented.
For the purpose of identifying the authenticator to the peer, it is
RECOMMENDED that the NAS-Identifier attribute be provided by the
authenticator to the peer, and that if AAA is enabled, that the
authenticator/AAA client include the NAS-Identifer attribute within
the Access-Request sent to the AAA server. In order to ensure
against forgery, it is RECOMMENDED that the peer and authenticator
securely verify the authenticator identity, such as via the Secure
Association Protocol.
For the purpose of identifying the peer to the authenticator, the EAP
Peer-ID provided within the EAP method is recommended. Where the
authenticator acts as a pass-through, the AAA server may include the
Peer-ID in an Access-Accept if requested to do so by the
authenticator/AAA client. Alternatively, the peer may provide the
authenticator with the Peer-ID via the lower layer, such as within
the Secure Association Protocol.
2.8. Lower Layer Key Hierarchy
Based on the EAP keying material and parameters provided to it, the
lower layer may derive two other types of keys:
[3] Keying material calculated from exported EAP keying material
[4] Session keys calculated or transported by the Secure Association
Protocol: TSKs.
In order to satisfy the principle of Mode Independence, a lower layer
MUST only base the derivation of sesson keys on exported EAP
parameters guaranteed to be present on the peer and authenticator.
This implies that the Transient Sesion Keys (TSKs), known only to the
peer and authenticator, may only depend on exported EAP parameters
replicated by AAA from the EAP server to the authenticator.
TSKs MUST be cryptographically separate from each other. Similarly,
TEKs MUST be cryptographically separate from each other. In
addition, the TSKs MUST be cryptographically separate from the TEKs.
In existing usage, the only exported EAP parameter that is replicated
by AAA as the result of a successful EAP authentication is the MSK.
In existing usage, the AAA-Key is always derived from the MSK and so
can be referred to using the MSK name. AAA-Key = MSK(0,63).
The exported EAP parameters replicated from the EAP server to the
peer have a scope defined by the EAP peer name (if securely provided
to the authenticator), and the authenticator name (if securely
provided to the peer).
In order to avoid confusion in the case where an EAP peer has more
than one set of exported EAP parameters applicable to establishment
of a phase 2 security association with an authenticator, the secure
Association protocol needs to identify the keying material for use in
the Secure Association Protocol exchange.
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 7. 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 8. 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 [RFC4072], 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | Local to |
| | EAP |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| MSK (64B) | EMSK (64B) | IV (64B) Exported|
| | | by |
| | | EAP |
| V V v
| ---+
| AAA-Key Transported |
| by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK Derivation | Lower layer |
| [AAA-Key Cache] | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 6: Complete Key Hierarchy
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| |===============| |
| |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator |
| | | |
| | Secure Assoc. | |
| peer |<------------->| (EAP |
| |===============| server) |
| | Link layer | |
| | (PPP,IEEE802) | |
| | | |
|MSK,EMSK | |MSK,EMSK |
| (TSKs) | | (TSKs) |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 7: 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 |
| | | |AAA-Key/| |
| | Secure Assoc. | | Name | |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
| | | | | |
|MSK,EMSK | | MSK | |MSK,EMSK |
| (TSKs) | | (TSKs) | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 8: Pass-through relationship between EAP peer, authenticator
and backend authentication server.
-
Rewrite of Section 2 of the EAP Key Management Framework Bernard Aboba, September 20 2005
- Re: Rewrite of Section 2 of the EAP Key Management Framework Bernard Aboba, September 21 2005
- Re: Re: Rewrite of Section 2 of the EAP Key Management Framework Jari Arkko, October 19 2005
-
RE: Re: Rewrite of Section 2 of the EAP Key Management Framework Salowey, Joe, October 6 2005
- Re: Re: Rewrite of Section 2 of the EAP Key Management Framework Jari Arkko, October 19 2005
- RE: Re: Rewrite of Section 2 of the EAP Key Management Framework Salowey, Joe, October 7 2005
Results generated by Tiger Technologies using MHonArc.