eap Mailing List: Issue 344: Yet More Nits

[Bernard Aboba (bernard_aboba]

Issue 344: Yet More NITs
Submitter name: Bernard Aboba
Submitter email address: aboba at internaut.com
Date Submitted: March 30, 2006
Reference:
Document: Keying-10
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of issue:

In Section 1.3

Change:

"Phase 2: Secure Association Establishment"

To:

"Phase 2: Secure Association Protocol"

Change:

"   In order to obey the principle of Mode Independence, where a backend
   server is present, all keying material which is required by the lower
   layer needs to be transported from the EAP server to the
   authenticator.  Since existing TSK derivation techniques depend
   solely on the MSK, in existing implementations, this is the only
   keying material replicated in the AAA key transport phase 1b."

To:

"    In order to obey the principle of Mode Independence (see Section
    1.6.1), where a backend server is present, all keying material which
    is required by the lower layer needs to be transported from the EAP
    server to the authenticator.  Since existing TSK derivation and
    transport techniques depend solely on the MSK, in existing
    implementations, this is the only keying material replicated in the
    AAA key transport phase 1b."

In Section 1.3.1, add:

"A proof of the security of the IEEE 802.11i 4-way
handshake when used with EAP-TLS [RFC2716], is provided in [He]."

Move the following material from Section 1.3 to Section 1.5 and
change the text from:

"    The goal of the EAP conversation is to derive fresh session keys
    between the EAP peer and authenticator that are known only to those
    parties, and for both the EAP peer and authenticator to demonstrate
    that they are authorized to perform their roles either by each other
    or by a trusted third party (the backend authentication server).
    Authorization issues are discussed in Sections 5.8.

    Completion of an EAP method exchange (Phase 1a) supporting key
    derivation results in the derivation of EAP keying material (MSK,
    EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
    and server (identified by the Server-ID).  Both the EAP peer and EAP
    server know the exported keying material to be fresh.  Disclosure
    issues are discussed in Section 5.5; key freshness is discussed in
    Sections 3.3, 3.4 and 5.7.

    Completion of the AAA exchange (Phase 1b) results in the transport of
    EAP keying material from the EAP server (identified by the Server-ID)
    to the EAP authenticator (identified by the NAS-Identifier) without
    disclosure to any other party.  Both the EAP server and EAP
    authenticator know this keying material to be fresh.  Security
    properties of AAA protocols are discussed in Sections 5.2-5.8, and
    5.11.

    Completion of the Secure Association Protocol (Phase 2) results in
    the derivation of Transient Session Keys (TSKs) known only to the EAP
    peer (identified by the Peer-ID) and authenticator (identified by the
    NAS-Identifier).  Both the EAP peer and authenticator know the TSKs
    to be fresh.  Security properties of Secure Association Protocols are
    discussed in Section 3.1."

To:

"   The goal of the EAP conversation is to derive fresh session keys
   between the EAP peer and authenticator that are known only to those
   parties, and for both the EAP peer and authenticator to demonstrate
   that they are authorized to perform their roles either by each other
   or by a trusted third party (the backend authentication server).

   Completion of an EAP method exchange (Phase 1a) supporting key
   derivation results in the derivation of EAP keying material (MSK,
   EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
   and server (identified by the Server-ID).  Both the EAP peer and EAP
   server know the exported keying material to be fresh.  Key freshness
   is discussed in Sections 3.3, 3.4 and 5.7.

   Completion of the AAA exchange (Phase 1b) results in the transport of
   EAP keying material from the EAP server (identified by the Server-ID)
   to the EAP authenticator (identified by the NAS-Identifier) without
   disclosure to any other party.  Both the EAP server and EAP
   authenticator know this keying material to be fresh.  Disclosure
   issues are discussed in Section 5.6; security properties of AAA
   protocols are discussed in Sections 5.2-5.8, and 5.11.

   Completion of the Secure Association Protocol (Phase 2) results in
   the derivation or transport of Transient Session Keys (TSKs) known
   only to the EAP peer (identified by the Peer-ID) and authenticator
   (identified by the NAS-Identifier).  Both the EAP peer and
   authenticator know the TSKs to be fresh.  Both the EAP peer and
   authenticator demonstrate that they are authorized to perform their
   roles.  Authorization issues are discussed in Section 5.8 and 5.9;
   security properties of Secure Association Protocols are discussed in
   Section 3.1."

In Section 1.6.1, change "in order to support" to "to support"

Change: "However, one of the advantages of EAP is that it enables deployment 
of"

To:

"However, when utilized in "pass-through" mode, EAP enables deployment of"

In Section 1.6.2, change:

"    over PPP [RFC1661],  IEEE 802 wired networks [IEEE-802.1X], and IEEE
   802.11 wireless LANs [IEEE-802.11i]."

To:

"    over PPP [RFC1661],  IEEE 802 wired networks [IEEE-802.1X], and
   wireless networks such as 802.11 [IEEE-802.11i] and 802.16 
[IEEE-802.16e]."

In Section 2.3:

Change "Figure 5" to "Figure 3".

Change:

"To take an example from IKE, the difference between IKEv1 and IKEv2 is that 
in
IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is"

To:

"For example, a difference between IKEv1 and IKEv2 is that in IKEv1 SA 
lifetimes
were negotiated; in IKEv2, each end of the SA is"

Change:

"EAP does not support negotiation of key lifetimes, nor does it support 
re-key
without re-authentication."

To:

"EAP does not support re-key without re-authentication and existing EAP
methods do not support key lifetime negotiation."


Change:

"[RFC3748], does not support the negotiation of lifetimes for exported
keying material such as the MSK, EMSK and IV."

To:

"[RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV."

Change:

"material or keys derived from it is only utilized by a single"

To:

"material or keys derived from it are only utilized by a single"

In Section 5.8:

Change "a post-EAP handshake" to "a Secure Association Protocol"

In Section 5.11:

Change:

"Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator.

While AAA protocols such as RADIUS [RFC2865] or
Diameter [RFC3588] support mutual authentication
between the authenticator (known as the AAA client) and
the backend authentication server (known as the backend authentication 
server),
the security mechanisms vary according to the AAA protocol.

In RADIUS, the shared secret
used for authentication is determined by the source address
of the RADIUS packet.  As noted in [RFC3579] Section 4.3.7,
it is highly desirable that the source address be checked
against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.

When RADIUS requests are forwarded by a proxy,"

To:

"Both the RADIUS [RFC2865] and Diameter [RFC3588] protocols are potentially 
vulnerable to
impersonation by a rogue authenticator.
While both protocols
support mutual authentication
between the authenticator (known as the AAA client) and
the backend authentication server (known as the backend authentication 
server),
the security mechanisms vary.

In RADIUS, the shared secret
used for authentication is determined by the source address
of the RADIUS packet.  As noted in [RFC3579] Section 4.3.7,
it is highly desirable that the source address be checked
against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.

When RADIUS Access-Requests are forwarded by a proxy,"

Change:

"While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
RRs to be properly configured.  As a result, it appears that Diameter
is as vulnerable to this attack as RADIUS, if not more so.  To address
this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]."

To:

"While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A, AAAA and PTR
Resource Records (RRs) to be properly configured.  As a result, Diameter
is as vulnerable to this attack as RADIUS, if not more so.  To address
this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]."

In Section 5.12:

Change:

"[RFC3579] Section 4.3.7 describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect
Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 
[RFC2865] or
NAS-IPv6-Address [RFC3162] attributes via the AAA protocol).
However, it is possible for a pass-through authenticator acting as a
AAA client to provide correct information to the backend authentication 
server while
communicating misleading information to the EAP peer via the lower
layer.

For example, a compromised authenticator can
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via the lower layer, or for
a pass-through authenticator acting as a AAA client to provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol."

To:

"As described in the previous section, it is possible for a proxy
to detect a AAA client attempting
to impersonate another authenticator (such by sending incorrect
Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address 
[RFC2865] or
NAS-IPv6-Address [RFC3162] attributes via the AAA protocol).
However, it is possible for a pass-through authenticator acting as a
AAA client to provide correct information to the backend authentication 
server while
communicating misleading information to the EAP peer via the lower
layer.

For example, a compromised authenticator can
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via the lower layer.  Also,
a pass-through authenticator acting as a AAA client can provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol."

In Section 7.2, add the following reference:

[He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. Mitchell,
"A Modular Correctness Proof of TLS and IEEE 802.11i",
ACM Conference on Computer and Communications Security (CCS '05), November, 
2005.