| Rewrite of Section 2 of the EAP Key Management Framework | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Wed, 21 Sep 2005 02:59:08 -0400 (EDT) | |
Here is a proposed rewrite of Section 2 of the EAP Key Management
Framework document to improve clarity and clarify issues relating to lower
layer key usage. Comments/edits welcome.
--------------------------------------------------------------------
2. Lower Layer Operation
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 4.
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 4: Conversation Overview
2.1. 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.2. 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.3. 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.4. Lower Layer Key Hierarchy
On 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. From these exported parameters two other types
of keys may be derived:
[3] Keying material calculated from exported quantities
[4] Session keys calculated or transported by the Secure Association
Protocol: TSKs.
In order to satisfy the principle of Mode Independence, a lower layer
may 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 6. 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 7. 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| 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 5: 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 6: 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 7: Pass-through relationship between EAP peer, authenticator
and backend authentication server.
2.5. Authenticator and Peer Naming
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). Absent an explicit binding step within the
Secure Association Protocol, the replicated exported EAP parameters
are not bound to a specific peer or authenticator port.
Within the lower layer, EAP peer and authenticator identification
enables the lower layer to define the scope of the exported EAP
parameters passed down to the lower layer. For the purpose of
identifying the authenticator to the peer, the value of the NAS-
Identifier attribute is recommended. The authenticator may include
the NAS-Identifier attribute to the AAA server in an Access-Request,
and the authenticator may provide the NAS-Identifier to the EAP peer.
Mechanisms for this include use of the EAP-Request/Identity
(unsecured) or a lower layer mechanism (such as the 802.11
Beacon/Probe Response). Where the NAS-Identifier is provided by the
authenticator to the peer a secure mechanism is RECOMMENDED.
For the purpose of identifying the peer to the authenticator, the EAP
peer identifier provided within the EAP method is recommended. It
cannot be assumed that the authenticator is aware of the EAP peer
name used within the method. Therefore alternatives mechanisms need
to be used to provide the EAP peer name to the authenticator. For
example, the AAA server may include the EAP peer name in the User-
Name attribute of the Access-Accept or the peer may provide the
authenticator with its name via a lower layer mechanism.
Absent an explicit binding step within the Secure Association
Protocol, the replicated exported EAP parameters are not bound to a
specific peer or authenticator port.
-
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: Rewrite of Section 2 of the EAP Key Management Framework Bernard Aboba, September 21 2005
Results generated by Tiger Technologies using MHonArc.