Overview I have read this document and have found several major issues with it.
As a result,I don't think it is currently suitable for adoption of an EMU WG
work item. Issues: a. Mistatement of the 'Lying NAS' problem. The 'Lying
NAS' problem does not just concern the issue of whether the authenticatorgives
different information to the peer and the server; it also relates to the
ability of the server to verify that the information is actually correct. The
document does not refer to the necessity of first-hop verification of the
information provided by the authenticator, such as the mapping between
theNAS-Identification attributes and the source address. The need for
verification impacts the trust model in some major ways, sincenot only does the
authentication server need to trust that the authenticatorattributes have not
been modified along the path -- it also needs to trust thatthe first hop was
configured to check the validity of attributes that only it cancheck. For
example, it's not much help for the AAA Server to verify that the RSN
IEprovided to the STA is the same one it got from the AP if there is no way
ofverifying whether the AP actually was configured to emit that RSN IE. b.
Lack of applicability to the roaming case. The document states that Channel
Bindings only apply to the non-roaming case. I'm not sure why this restriction
is mentioned because the issue of verificationis present even within a single
domain. c. Discussion of 'fuzzy' comparisions. By their nature, Channel
Bindings may includeinformation that may be opaque to the AAA server, such as
the RSN IE. Given thatthe AAA server may not be capable of understanding the
contents of the attributes,I question whether the concept of 'fuzzy
comparisons' makes sense. Rather, I thinkwe need to assume that a AAA server
will probably only be capable of 'byte by byte'comparisons in most cases. This
is an important issue, because it affects the structureof data that needs to be
provided by the client, and avoid potential 'canonicalization'issues that could
greatly complicate the successful implementation of channel bindings. d.
Discussion of lower layer channel bindings. The document does not discuss the
potential use of channel bindings in lower layers suchas IEEE 802.11r. I think
that this is important since lower layers such as 11r do bind EAPkeying
material to lower layer parameters (such as the peer and authenticator MAC
address). Thus, lower layer channel bindings is an alternative that should be
discussed. e. Development of requirements. If this document is going to
include an evaluation ofalternative approaches, then it needs to clearly
articulate the requirements for such anevaluation. f. Clear distinction
between RFC 5056 and 3748 channel binding concepts. The currentdocument is not
as clear as it could be on this. The RFC 5056 channel binding conceptis closer
to that of 'cryptographic binding' than it is to EAP channel bindings. This
shouldbe made clear. g. Exploration of operations implications. There are a
number of barriers to successfulimplementation of channel bindings that need to
be explored, including: 1. Required configuration for first-hop AAA clients. 2.
Potential changes to drivers and AAA servers. 3. Potential impacts on
authentication reliability. h. Motivation. Why should we care about Channel
Bindings? Given the operational costsI'd suggest that the document needs to
make a case that there is a potentially serioussecurity vulnerability here.
Such a case probably involves some kind of financial fraudissue which is most
likely in a roaming situation - which is unfortunately a scenario that
thedocument rules out of scope. Some specific comments.
============================ Abstract This document defines how to implement
channel bindings for Extensible Authentication Protocol (EAP) methods. [BA]
I'd add a definition of the problem to the abstract goals. Section 1 A
well-documented problem with the current Extensible Authentication Protocol
(EAP) architecture [RFC3748] when used in pass-through authenticator mode is
the so-called 'lying NAS' problem. Here, a Network Access Server (NAS), or
pass-through authenticator, may authenticate to the backend AAA
infrastructure using one set of credentials, while representing contrary
information to EAP clients. [BA] The 'lying NAS' problem is not really about
credentials, since in RADIUS the identity of a RADIUS client is defined by its
IP address.Rather, the issue is providing different *information*
(e.g.Called-Station-Id, NAS-Identifier, etc.) to the peer and AAA server. A
concrete example of this may be an IEEE 802.11 access point with a security
association to a particular AAA server. While there may be some identity
tied to that security association, there's no reason the access point need
advertise the same identity to clients. [BA] The identity used in the AAA
server security association and theone advertised to clients do not necessary
have to agree, even if theNAS is not lying. In fact, it may include
whatever information in its beacons (to include different SSID or security
properties) it desires. This could lead to situations where, for example, a
client joins one network that's masquerading as another. [BA] The SSID is a
good example, but the 'security properties' (e.g. RSN IE)are not provided to
the AAA server. Therefore it isnot possible for a NAS to 'lie' to the AAA
server about the RSN IE itsent in a Beacon. Channel bindings [RFC5056] seek
to enforce a stronger security relationship between the three entities, by
allowing the client and server to compare their relative perception of the
authenticator's identity in a secure channel. [BA] RFC 5056 specifically
states that it does not apply to EAP, andthat the use of the term 'Channel
Bindings' is not the same as theone used in EAP. As a result, I'd recommend
deleting the aboveparagraph or clarifying the relationship. This document
defines how to use 'AAA Payloads' [I-D.clancy-emu-aaapay] within EAP methods
to implement channel bindings. Unlike [RFC5056], channel binding in EAP
context does not ensure binding different layers of a session but rather the
information advertized to client and authentication server by an
authenticator acting as pass-through device during an EAP session. [BA] You
might say that 'Channel Bindings' in RFC 5056 corresponds tothe term
'cryptographic binding' in EAP. It is preferable to use this idea, rather
than hashing identity information directly into keys, for a number of
reasons: o It allows for fuzzy comparisons of entity names, rather than
requiring absolute. This can facilitate deployment and debugging. [BA] Not
sure this is convincing because it's doubtful whether'fuzzy comparisons' are
implementable in the alternative approach either. Wouldn't this require the AAA
server to be able to parse the attributesand 'understand' them in some deep
manner? o Any EAP method that provides mutual authentication and key
derivation can easily add channel binding as proposed in this draft. On
the other hand, including identities into key derivations requires the
modification of EAP methods. For instance, many EAP methods specify how
MSK and other keying material is derived and adding channel binding by
adding identifiers would need to be specified for each method
individually. [BA] I think you are making assumptions about how the keys are
mixed inthat may not necessarily be valid. For example, couldn't the
mixingoccur in a lower layer rather than in the EAP method? A more validreason
would be that EAP methods need to be lower layer independent,whereas Channel
Bindings often are not -- so that mixing them intoEAP keying material could be
an issue. However, this argument wouldnot hold for mixing that occurs in a
lower layer. This practice isalready incorporated into lower layer
specifications such as IEEE 802.11r. o Client and authentication server may
communicate on different layers with the authenticator and thus receive
different identifiers that may belong to the same device. A server may be
able to recognize which different identifiers belong to the same
device (e.g. by performing a table look up). This scenario cannot be
solved by hashing identities into keys. [BA] I think what you're trying to say
here is that the set of channelbindings may vary between authenticator
implementations, no? 4. Trust Model [BA] I think that you need to include this
introduction earlier in thedocument. Channel bindings are always provided
between two communication endpoints, i.e. here between client and server, who
communicate through an authenticator in pass-trough mode (as illustrated in
Figure 1). Channel binding prevents attacks by rogue authenticators in
pass-trough mode (see Example Attacks). Clancy & Hoeper Expires
August 21, 2008 [Page 4]Internet-Draft
EAP-CHBIND February 2008
--------------------------------------------- -------- info1 |
------------- info2 ----------- | |EAP peer| <--------|
|Authenticator| ----------> |Auth.Server| | -------- |
------------- ----------- | | |
| | | |
Home Domain | | |
--------------------------------------------- |
| |
| | Channel binding |
|<---------------------------------------------------->|
Figure 1: Overview of Channel Binding [BA] There is an important piece missing
from this picture -- theneed of the first hop proxy to check the *correctness*
of the informationpassed by the authenticator. For example, only the first hop
can checkif the NAS-Identifier attribute actually corresponds to the source
IPaddress of the authenticator; downstream proxies or servers cannot checkthis,
since the information will have been 'laundered' by the time itreaches them.
During an EAP execution, an authenticator presents information info1 and
info2 to client and server, respectively. Such information can include the
authenticator's identifier/address and/or advertised network information
(such as offered services and billing information). To prevent attacks by
rogue authenticators, the server must be able to recognize any
inconsistencies in info1 and info2. Therefore, the client sends info1 to the
server and upon performing an inconsistency check, the server notifies the
client about the result. Only in case of a positive result, channel binding
is provided and the EAP session continues. Note that under some
circumstances, the client could be able to check for inconsistencies; however
the check is generally easier to implement on the server. The trust model for
channel binding consists of three parties, namely a client, an authentication
server and an authenticator in pass- through mode as illustrated in Figure 1.
In this trust model, client and authentication server are honest while the
authenticator is maliciously sending false information to client and/or
server. The three parties have the following trust relationships: o The
server trusts that the channel binding information received from the
client is the information that the client received from the authenticator
(i.e. info1) o The client trusts the channel binding result received from
the server o The server trusts the identifier received from the
authenticator [BA] The first hop cannot just trust the identifer received from
the authenticator -- it is *required* that it be able to verify it, based on
configuration. Note that the model includes all cases in which authenticator
and authentication server communicate over one or more intermediate nodes
as long as 1) these nodes only forward the messages (e.g. routers) and 2)
authenticator and server communicate using an end-to-end protocol (e.g.
AAA). However, roaming scenarios with proxies are out of the scope of this
document. [BA] Roaming scenarios are actually quite central to the problem
statementbecause almost all the severe security vulnerabilities relate to
roaming in some way. ______________________
EMAILING FOR THE GREATER GOOD
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
