eap Mailing List: Issue 390: IDNITs

[Bernard Aboba (bernard_aboba]

Issue 390: IDNITs
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: February 3, 2007
Reference:
Document: KEYING-17
Comment type: Editorial
Priority: S
Section: Various
Rationale/Explanation of issue:

The revised IDNITs 2.0 script found some issues with -17, including:

a. Reference to obsoleted DNSSEC RFCs.
b. Use of []'s for bullet points, which were confused with references.

EAP-PSK has been published as RFC 4764.  There are missing references to RFC 
4301, 4346, and RFC 2716bis.

The term "Channel Binding" and "Channel Bindings" are used interchangeably.

The Abstract doesn't mention a system-level security analysis.

Proposed resolution is to change [] to () in all situations where a 
reference
is not being used.

Change "Channel Bindings" to "Channel Binding" (term used in RFC 3748) when
referring to the process of verification; use the term "Channel Binding 
parameters"
to refer to the elements being verified.

Add the following references:

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet 
Protocol",
RFC 4301, December 2005.

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.

[RFC4764] Bersani, F. and H. Tschofenig,
"The EAP-PSK Protocol: a Pre-Shared Key Extensible Authentication
Protocol (EAP) Method", RFC 4764, January 2007.

[RFC2716bis] Simon, D. and B. Aboba, "The EAP TLS Authentication Protocol",
draft-simon-emu-rfc2716bis-07.txt, Internet draft (work in progress),
January 2007.

Change the abstract to the following:

" The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document
specifies the EAP key hierarchy and provides a framework for the
transport and usage of keying material generated by EAP
authentication algorithms, known as "methods". It also provides a
system-level security analysis."

Change Section 1 to the following:

" The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access
in situations in which the Internet Protocol (IP) protocol is not
available. Originally developed for use with Point-to-Point Protocol
(PPP) [RFC1661], it has subsequently also been applied to IEEE 802
wired networks [IEEE-802.1X], IKEv2 [RFC4306] and wireless networks
such as [IEEE-802.11i] and [IEEE-802.16e].

EAP is a two-party protocol spoken between the EAP peer and server.
Within EAP, keying material is generated by EAP authentication
algorithms, known as "methods". Part of this keying material may be
used by EAP methods themselves and part of this material may be
exported. In addition to export of keying material, EAP methods may
also export associated parameters such as authenticated peer and
server identities and a unique EAP conversation identifier, and may
import and export lower layer parameters known as "Channel Binding
parameters", or simply "channel bindings".

This document specifies the EAP key hierarchy and provides a
framework for the transport and usage of keying material and
parameters generated by EAP methods. It also provides a system-level
security analysis."

Change the definition of Channel Binding to the following:

"Channel Binding
A secure mechanism for ensuring that a subset of the parameters
transmitted by the authenticator (such as authenticator identifiers
and properties) are agreed upon by the EAP peer and server. It is
expected that the parameters are also securely agreed upon by the
EAP peer and authenticator via the lower layer if the authenticator
advertised the parameters."

Change the section on Channel Binding to the following:

"Channel Binding

It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via out-
of-band mechanisms (such as via AAA or the lower layer).

Where EAP is used in pass-through mode, the EAP peer does not verify
the identity of the pass-through authenticator within the EAP
conversation. Within the Secure Association Protocol, the EAP peer
and authenticator only demonstrate mutual possession of the
transported EAP keying material; they do not mutually authenticate
(see Section 5.6). This creates a potential security vulnerability,
described in [RFC3748] Section 7.15.

As described in the previous section, it is possible for a AAA 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 backend authentication
server via the AAA protocol.

As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].

Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Typically the EAP
method imports Channel Binding parameters from the lower layer on the
peer, and transmits them securely to the EAP server, which exports
them to the lower layer or AAA layer. However, transport may occur
from EAP server to peer, or may be bi-directional. On the side of
the exchange (peer or server) where Channel Binding is verified, the
lower layer or AAA layer passes the result of the verification (TRUE
or FALSE) up to the EAP method. While the verification can be done
either by the peer or the server, typically only the server has the
knowledge to determine the correctness of the values, as opposed to
merely verifying their equality. For further discussion, see [I-
D.arkko-eap-service-identity-auth].

It is also possible to perform Channel Binding without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-channel-
binding]. In this approach the EAP method includes Channel Binding
parameters in the calculation of exported EAP keying material, making
it impossible for the peer and authenticator to complete the Secure
Association Protocol if there is a mismatch in the Channel Binding
parameters. However, this approach can only be applied where EAP
methods generating key material are used along with lower layers that
utilize the keying material. For example, this mechanism would not
enable verification of Channel Binding on wired IEEE 802 networks
using IEEE 802.1X."