eap Mailing List: Issue 342: More NITs

[Bernard Aboba (bernard_aboba]

Issue 342: More NITs
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: March 23, 2006
Reference:
Document: Keying-10
Comment type: E
Priority: S
Section: 3, 3.5, 4
Rationale/Explanation of issue:

Section 3 is somewhat confusing.

Section 3.5 is poorly written.

Section 4 is not clear about what mechanisms are being referred to in the 
last sentence.

Change Section 3 from:

"3.  Key Management

  EAP as defined in [RFC3748] supports key derivation, but not key
  management.  While EAP methods may derive keying material, EAP does
  not 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 re-key.  Although EAP
  methods may support "fast reconnect" as defined in [RFC3748] Section
  7.2.1, re-key of exported keys cannot occur without re-
  authentication.  In order to provide method independence, key
  management of exported or derived keys SHOULD NOT be provided within
  EAP methods."

To:

"3. Key Management

EAP as defined in [RFC3748] supports key derivation, but not key
management. While EAP methods may derive keying material, EAP does
not provide for the management of exported or derived keys. Although
EAP methods may support "fast reconnect" as defined in [RFC3748]
Section 7.2.1, EAP does not support re-key of exported keys without
re-authentication. Existing EAP methods do not export the Key-
Lifetime parameter; in the interest of method independence, key
management of exported or derived keys SHOULD NOT be provided within
EAP methods."

Change Section 3.5 from:

"3.5.  Key cache synchronization

  Issues arise when attempting to synchronize the key cache on the peer
  and authenticator.  Lifetime negotiation alone cannot guarantee key
  cache synchronization.

  One problem is that the AAA protocol cannot guarantee synchronization
  of key lifetimes between the peer and authenticator.  Where the
  Secure Association Protocol is not run immediately after EAP
  authentication, the exported and calculated key lifetimes will not be
  known by the peer during the hiatus.  Where EAP pre-authentication
  occurs, this can leave the peer uncertain whether a subsequent
  attempt to use the exported keys will prove successful.

  However, even where the Secure Association Protocol is run
  immediately after EAP, it is still possible for the authenticator to
  reclaim resources if the created key state is not immediately
  utilized.

  The lower layer may utilize Discovery mechanisms to assist in this.
  For example, the authenticator manages the key cache by deleting the
  oldest key first (LIFO), the relative creation time of the last key
  to be deleted could be advertised with the Discovery phase, enabling
  the peer to determine whether a given key had been expired from the
  authenticator key cache prematurely."

To:

"3.5. Key cache synchronization

Issues arise when attempting to synchronize the key cache on the peer
and authenticator.

While the AAA protocol can enable the backend authentication server
to provide guidance on the lifetime of transported EAP keying
material to the authenticator, this does not address the problem of
key lifetime synchronization between the peer and authenticator.
Where the EAP method does not export the Key-Lifetime parameter, the
lifetime of the EAP keying material may not be defined until
completion of the Secure Association Protocol, if ever. This can
leave the peer uncertain how long the authenticator will maintain EAP
keying material within the key cache.

However, key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where the Secure Association Protocol is run
immediately after EAP and determines the lifetime of EAP keying
material, it is still possible for the authenticator to reclaim
resources.

The lower layer may utilize the Discovery phase 0 to improve key
cache synchronization. For example, if the authenticator manages the
key cache by deleting the oldest key first (LIFO), the relative
creation time of the last key to be deleted could be advertised
within the Discovery phase, enabling the peer to determine whether
keying material had been prematurely expired from the authenticator
key cache."

Change Section 4 from:

"4. Handoff Vulnerabilities

With EAP, a number of mechanisms are be utilized in order to reduce
the latency of handoff between authenticators. One such mechanism is
EAP pre-authentication, in which EAP is utilized to pre-establish EAP
keying material on an authenticator prior to arrival of the peer.
Another such mechanism is key caching, in which an EAP peer can re-
attach to an authenticator without having to re-authenticate using
EAP. Yet another mechanism is context transfer, such as is defined
in [IEEE-802.11F] (now deprecated) and [CTP]. These mechanisms
introduce new security vulnerabilities, as discussed in the sections
that follow."

To:

"4. Handoff Vulnerabilities

With EAP, several mechanisms are available to reduce the latency in
handoff between authenticators:

[1] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the peer.

[2] Key caching. This mechanism enables an EAP peer to re-attach to an
authenticator without requiring EAP re-authentication.

[3] Context transfer, such as is defined in [IEEE-802.11F] (now
deprecated) and [CTP].

The sections that follow discuss the security vulnerabilities introduced
by the above mechanisms.