eap Mailing List: Issue 288: Cleanup of Secure Association Section

[Bernard Aboba (aboba]

Issue 288: Cleanup of Secure Association Section
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 2/17/2005
Reference:
Document: KEY-04
Comment type: T
Priority: S
Section: 1.3.3
Rationale/Explanation of issue

There is text in several places relating to the Secure Association phase.

Here is a rewrite of Section 1.3.3 that combines and revises the text:

"1.3.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). EAP may be used in the following scenarios:

[a] Stationary peer. Where the peer is stationary it will establish
communications with one or more authenticators while remaining in
one location. In this scenario, EAP authentication typically
represents only a small fraction of the total session time, so that
it is acceptable for EAP authentication to occur each time the peer
wishes to access the network. In this scenario, the Secure
Association Protocol phase may be omitted.

[b] Mobile peer. Where the peer is mobile, it may move its point of
attachment from one authenticator to another, or between points of
attachment on a single authenticator. In this scenario, it is
often desirable to minimize the handoff latency, so that it is
desirable to avoid EAP authentication each time the peer changes
its point of attachment. In this scenario, caching of the AAA-Key
be supported on the EAP peer and authenticator. In this, a Secure
Assocation Protocol phase is required to allow EAP to be used
securely.

A Secure Association Protocol used with EAP typically supports the
following features:

[1] Generation of fresh transient session keys (TSKs). Where AAA-Key
caching is supported, the EAP peer may initiate a new session using
a AAA-Key that was used in a previous session. Were the TSKs to be
derived from a portion of the AAA-Key, this would result in reuse
of the session keys which could expose the underlying ciphersuite
to attack.

As a result, where AAA-Key caching is supported, the Secure
Association Protocol phase is REQUIRED, and MUST provide for
freshness of the TSKs. This is typically handled via the exchange
of nonces or counters, which are then mixed with the AAA-Key in
order to generate fresh unicast (phase 2a) and possibly multicast
(phase 2b) session keys. By not using the AAA-Key directly to
protect data, the Secure Association Protocol protects against
compromise of the AAA-Key.

[2] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the
scope of the transient session keys (TSKs) generated during the
exchange is undefined. As illustrated in Figure 1, both the peer
and NAS may have more than one physical or virtual port, so that
port identifiers are not recommended a naming mechanism.

[3] Secure capabilities negotiation. This includes the secure
negotiation of usage modes, session parameters (such as key
lifetimes), ciphersuites and required filters, including
confirmation of the capabilities discovered during phase 0. It is
RECOMMENDED that the Secure Association Protocol support secure
capabilities negotiation, in order to protect against spoofing
during the discovery phase, and to ensure agreement between the
peer and authenticator about how data is to be secured.

[4] Key management. EAP as defined in [RFC3748] supports key
derivation, but not key management. While EAP methods may derive
keying material, EAP does provide for the management of exported or
derived keys. For example, EAP does not support negotiation of the
key lifetime of exported or derived keys, nor does it support
rekey. Although EAP methods may support "fast reconnect" as
defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot
occur without reauthentication. In order to provide method
independence, key management of exported or derived keys SHOULD NOT
be provided within EAP methods.

Since neither EAP nor EAP methods provide key management support,
it is RECOMMENDED that key management facilities be provided within
the Secure Association Protocol. This includes key lifetime
management (such as via explicit key lifetime negotiation, or
seamless rekey), as well synchronization of the installation and
deletion of keys so as to enable recovery from partial or complete
loss of key state by the peer or authenticator. Since key
management requires a key naming scheme, Secure Association
Protocols supporting key management support MUST also support key
naming.

[5] Mutual proof of possession of the AAA-Key. The Secure Association
Protocol MUST demonstrate mutual proof of posession of the AAA-Key,
in order to show that both the peer and authenticator have been
authenticated and authorized by the backend authentication server.
Since mutual proof of possession is not the same as mutual
authentication, the peer cannot verify authenticator assertions
(including the authenticator identity) as a result of this
exchange."