Subject: [eap] Issue 342: More NITs

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 23 Mar 2006 16:46:06 -0800

Issue 342: More NITs
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap