Subject: [eap] Issue 344: Yet More Nits

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 30 Mar 2006 15:36:41 -0800

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.

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

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