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
authenticator
gives 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 the
NAS-Identification attributes and the source address.
The need for verification impacts the trust model in some major ways, since
not only does the authentication server need to trust that the authenticator
attributes have not been modified along the path -- it also needs to
trust that
the first hop was configured to check the validity of attributes that
only it can
check.
For example, it's not much help for the AAA Server to verify that the RSN IE
provided to the STA is the same one it got from the AP if there is no way of
verifying 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
verification
is present even within a single domain.
c. Discussion of 'fuzzy' comparisions. By their nature, Channel
Bindings may include
information that may be opaque to the AAA server, such as the RSN IE.
Given that
the 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 think
we 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 structure
of 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 such
as IEEE 802.11r. I think that this is important since lower layers such
as 11r do bind EAP
keying 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 of
alternative approaches, then it needs to clearly articulate the
requirements for such an
evaluation.
f. Clear distinction between RFC 5056 and 3748 channel binding
concepts. The current
document is not as clear as it could be on this. The RFC 5056 channel
binding concept
is closer to that of 'cryptographic binding' than it is to EAP channel
bindings. This should
be made clear.
g. Exploration of operations implications. There are a number of
barriers to successful
implementation 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 costs
I'd suggest that the document needs to make a case that there is a
potentially serious
security vulnerability here. Such a case probably involves some kind of
financial fraud
issue which is most likely in a roaming situation - which is
unfortunately a scenario that the
document 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 the
one advertised to clients do not necessary have to agree, even if the
NAS 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 is
not possible for a NAS to 'lie' to the AAA server about the RSN IE it
sent 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, and
that the use of the term 'Channel Bindings' is not the same as the
one used in EAP. As a result, I'd recommend deleting the above
paragraph 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 to
the 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 attributes
and '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 in
that may not necessarily be valid. For example, couldn't the mixing
occur in a lower layer rather than in the EAP method? A more valid
reason would be that EAP methods need to be lower layer independent,
whereas Channel Bindings often are not -- so that mixing them into
EAP keying material could be an issue. However, this argument would
not hold for mixing that occurs in a lower layer. This practice is
already 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 channel
bindings may vary between authenticator implementations, no?
4. Trust Model
[BA] I think that you need to include this introduction earlier in the
document.
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 -- the
need of the first hop proxy to check the *correctness* of the information
passed by the authenticator. For example, only the first hop can check
if the NAS-Identifier attribute actually corresponds to the source IP
address of the authenticator; downstream proxies or servers cannot check
this, since the information will have been 'laundered' by the time it
reaches 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 statement
because almost all the severe security vulnerabilities relate to roaming in
some way.
______________________
i <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
EMAILING FOR THE GREATER GOOD
------------------------------------------------------------------------
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
