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
|