eap Mailing List: Issue 349: Yet more NITs

[Bernard Aboba (bernard_aboba]

Issue 349: Yet more NITs
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
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.