Issue 342: More NITs

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


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

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