Subject: [eap] Issue 349: Yet more NITs

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 12 Apr 2006 18:25:00 -0700

Issue 349: Yet more NITs
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: April 12, 2006
Reference:
Document: Keying-11
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Move from Section 5 to Section 1.2:

" The terms "Cryptographic binding", "Cryptographic separation",
  "Key strength" and "Mutual authentication" are
defined in [RFC3748] and are used with the same
meaning in this document."

In Section 1.2 change "frequently" to "also frequently"

Add the following definition of "Secure Association Protocol":

An exchange that occurs between the EAP peer and authenticator
in order to manage the creation and deletion of unicast and
multicast security associations.

In Section 2.1, change:

"directly from the MSK, as described in [RFC2716]. This method
is NOT RECOMMENDED, since were PPP to support caching, this
could result in stale TSKs.  As a result, once the PPP session"

To:

"directly from the MSK, as described in [RFC2716].  This method
is NOT RECOMMENDED, since if PPP were to support caching, this
could result in TSK reuse.  As a result, once the PPP session"

In Section 2.2, change:

"  This specification does not impose constraints on the architecture of
   the EAP authenticator or peer.  Any of the authenticator
   architectures described in [RFC4118] can be used.  For example, it is
   possible for multiple base stations and a "controller" (e.g. WLAN
   switch) to comprise a single EAP authenticator.  In such a situation,
   the "base station identity" is irrelevant to the EAP method
   conversation, except perhaps as an opaque blob to be used in Channel
   Bindings.  Many base stations can share the same authenticator
   identity.  As a result, lower layers need to identify EAP peers and
   authenticators unambiguously, without incorporating implicit
   assumptions about peer and authenticator architectures."

To:

"  This specification does not impose constraints on the architecture of
   the EAP authenticator or peer.  Any of the authenticator
   architectures described in [RFC4118] can be used.  As a result, lower
   layers need to identify EAP peers and authenticators unambiguously,
   without incorporating implicit assumptions about peer and
   authenticator architectures.

   For example, it is possible for multiple base stations and a
   "controller" (e.g. WLAN switch) to comprise a single EAP
   authenticator.  In such a situation, the "base station identity" is
   irrelevant to the EAP method conversation, except perhaps as an
   opaque blob to be used in Channel Bindings.  Many base stations can
   share the same authenticator identity."

In Section 2.2.1, change:

"   The EAP method conversation is between the EAP peer and server, as
   identified by the Peer-ID and Server-ID.  The authenticator identity,
   if considered at all by the EAP method, is treated as an opaque blob
   for the purposes of Channel bindings.  However, the Secure
   Association Protocol conversation is between the peer and the
   authenticator, and therefore the authenticator and peer identities
   are relevant to that exchange, and define the scope of use of the EAP
   keying material passed down to the lower layer."

To:

"  The EAP method conversation is between the EAP peer and server, as
   identified by the Peer-ID and Server-ID.  The authenticator identity,
   if considered at all by the EAP method, is treated as an opaque blob
   for the purposes of Channel Bindings (see Section 5.12).  However,
   the Secure Association Protocol conversation is between the peer and
   the authenticator, and therefore the authenticator and peer
   identities are relevant to that exchange, and define the scope of use
   of the EAP keying material passed down to the lower layer."

There is redundancy between Section 2.2.1 and Section 5.5, which says:

"  In order to enable key binding and authorization of all parties, it
   is RECOMMENDED that the parties use a set of identities that are
   consistent between the conversation phases."

In Section 2.2.1, Change:

"In order to ensure that lower layer identifies are securely verified by all 
parties, it is recommended that lower layers:"

To:

"In order to ensure that lower layer identities are securely verified by all 
parties, it is RECOMMENDED that the parties use a set of identities that are 
consistent between the conversation phases.
This can be achieved by:"

Delete the above paragraph from Section 5.5.

In Section 2.2.2 change:

" "virtual authenticators",  the EAP peer and authenticator may not be able 
to
agree on the scope of the EAP keying material, creating
a security vulnerability.  For"

To:

" "virtual authenticators", a number of security
vulnerabilities may arise if the peer and authenticator
are not correctly identified.  For "

Change:

"Several measures are recommended to address these issues:"

To:

"in order to address these issues:"

In Section 3, change:

"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."

To:

"key derivation, but does not provide for the management of exported or 
derived keys."'

In Section 3.1, delete:

"As shown in Figure 3, both the peer and authenticator may have more
than one physical or virtual port, and as a result SHOULD identify
themselves in a manner that is independent of their attached ports."

This is redundant because Section 2.2.1 already states:

"    Since an authenticator may have multiple ports, the authenticator
     identifier used within the Secure Association Protocol exchange
     SHOULD be distinct from any port identifier (e.g. MAC address).
     Similarly, where a peer may have multiple ports, and sharing of EAP
     keying material and parameters between peer ports of the same link
     type is allowed, the peer identifier used within the Secure
     Association Protocol exchange SHOULD also be distinct from any port
     identifier."

In Section 3.1 [b], add: "Identity verification is discussed in Section 
2.2.1."

Change:

"Use of the key naming mechanism described in this document is RECOMMENDED."

to

"Use of the key naming mechanism described in Section 1.4.1 is RECOMMENDED."

In Section 3.1 [g] Change:

"Key resynchronization."

To:

"Key state resynchronization"

In Section 3.1 [j], add:

"See [RFC3748] Section 2.4 for more discussion."

In Section 3.4, change:

"re-key TEKs during a conversation."

To:

"re-key TEKs during an EAP conversation."

There is redundancy between Section 3.5 and Section 5.7, which states:

"    As described in [RFC3580] Section 3.17, When sent in an Access-
     Accept along with a Termination-Action value of RADIUS-Request, the
     Session-Timeout attribute specifies the maximum number of seconds
     of service provided prior to re-authentication.  [IEEE-802.11i]
     also utilizes the Session-Timeout attribute to limit the maximum
     time that EAP keying material may be cached."

In Section 3.5, change:

"     On the authenticator,  where EAP is used for authentication, the
     Session-Timeout value represents the maximum session time prior to
     re-authentication, as described in [RFC3580].  Where EAP is used
     for pre-authentication, the session may not start until some future
     time, or may never occur.  Nevertheless, the Session-Timeout value
     represents the maximum time after which transported EAP keying
     material, and all keys calculated from it, will have expired on the
     authenticator.  If the session subsequently starts, re-
     authentication will be initiated once the Session-Time has expired.
     If the session never started, or started and ended, by default keys
     transported by AAA and all keys calculated from them will be
     expired by the authenticator prior to the future time indicated by
     Session-Timeout.  Note that in future additional attributes may be
     specified to control the lifetime of cached keys; these attributes
     may modify the meaning of the Session-Timeout attribute in specific
     circumstances."

To:

"    On the authenticator,  where EAP is used for authentication, the
     Session-Timeout attribute represents the maximum session time prior
     to re-authentication.  As described in [RFC3580] Section 3.17, when
     sent in an Access-Accept along with a Termination-Action value of
     RADIUS-Request, the Session-Timeout attribute specifies the maximum
     number of seconds of service provided prior to re-authentication.

     Where EAP is used for pre-authentication, the session may not start
     until some future time, or may never occur.  Nevertheless, the
     Session-Timeout value represents the maximum time after which
     transported EAP keying material, and all keys calculated from it,
     will have expired on the authenticator.  If the session
     subsequently starts, re-authentication will be initiated once the
     Session-Time has expired. If the session never started, or started
     and ended, by default keys transported by AAA and all keys
     calculated from them will be expired by the authenticator prior to
     the future time indicated by Session-Timeout; this feature is
     utilized by [IEEE-802.11i].  Note that in future additional
     attributes may be specified to control the lifetime of cached keys;
     these attributes may modify the meaning of the Session-Timeout
     attribute in specific circumstances."

Delete the above paragraph from Section 5.7.

Combine sections 5.1 and 5.

In Section 5, Move [2] to [10] and renumber the other threats.

Add the following additional bullets:
[8] An attacker may attempt a man-in-the-middle attack in order to gain 
access
to the network.
[9] An attacker may launch a denial of service attack against the EAP
peer, authenticator or backend authentication server.

In Section 5.11, change:

"see [I-D.arkko-eap-service-identity-auth]."

To:

"see the discussion in Section 1.4 as well as 
[I-D.arkko-eap-service-identity-auth]."

Add the following non-normative reference:
[RFC4372]
Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
Chargeable User Identity", RFC 4372, January 2006.

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

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