eap Mailing List: Review of draft-arkko-eap-service-identity-auth-02.txt

[Bernard Aboba (aboba]

Overall review

This document represents the first practical attempt to make use of
Channel Bindings.  However in going over the document, it would appear
that the assumptions made by the authors do not match the Channel Binding
model in EAP methods such as PEAPv2.

I think this implies that we may not have consensus on how Channel
Bindings are supposed to work, or even that we may not really understand
how they work or what the implications are.

It therefore seems to me that the EAP WG needs to discuss Channel Bindings
in more detail in order to figure out the correct model for implementing
them.  This seems like a topic that might be worth covering in the EAP Key
management framework.

Details

RFC 3748 Section 7.15 describes the basic concept of Channel Bindings, but
currently no published or approved EAP method uses this.  Part of the
reason for this is that there is some uncertainty about how to use Channel
Bindings.  This document is an important contribution to the discussion in
that it attempts to make Channel Bindings implementable.

As such, the document raises a number of fundamental issues about Channel
Bindings.

One of these is the direction of information flow.  One of the issues that
has been raised in EAP WG is whether Channel Bindings violates the
principle of EAP Media Independence.

In order to avoid having EAP methods depend on the underlying media,
Channel Bindings need to be treated as opaque blobs.  However, this is
easier said than done.

The basic idea of Channel Bindings it that the value of the Channel
Bindings communicated by the  NAS to the AAA server is compared to the
value sent by the NAS to the EAP peer.

One important question is what entity does the comparison.  One
perspective is that the AAA system verifies the Channel Binding attributes
along the path, so that by the time the attributes get to the AAA server
they can be considered definitive.  As noted in the document, this does
not happen by accident -- proxies have to be on guard against fraud,
checking packets received from the NAS before forwarding them.

However, assuming this is done, it would appear that the AAA server is in
the best position to do the comparison.  This present an argument for
having the peer send the Channel Bindings to the server for the
comparison.   This is how PEAPv2 appears to work, for example.

In this model, the server is able to verify the Channel Bindings and deny
access to the peer if there is a mismatch, in adddition to logging
discrepancies.

Note that the document appears to assume that the channel bindings are
exchanged from server to peer and checked on the peer.  In this model, the
peer has to protect itself, and the server cannot deny access because it
doesn't have the information to do so.  This has some security
implications, because there may be incentives for the peer to falsify
information.

For example, in this approach, the peer can claim that the channel
bindings sent by the server did not match those that it obtained from the
lower layer, yet the server cannot verify this.  This could allow a peer
to obtain access to the network, yet refuse to pay for it.  In the
peer->server model of verification the peer has to submit its Channel
Bindings to the server and if they don't match, the server not only has a
record of the mismatch, but also can deny access, preventing the peer from
committing fraud.

Another fundamental issue about Channel Bindings is the format by which
they are expressed.  The document notes a number of relevant parameters,
several of which (such as country code) are not currently expressed as AAA
attributes.  However, for Channel Bindings to be sent from the NAS to the
AAA server, they need to be expressed as AAA AVPs or attributes.
Therefore it would seem natural for the Channel Binding parameters to be
expressed in the form of AAA attributes, rather than a new format.

Also, there is the issue of the impact of adding new Channel Binding
AVPs/attributes.  In terms of maintenance, it seems important not to
require EAP methods to change once new Channel Bindings are defined.  This
has a number of implications.  One of these is that EAP methods probably
should not define their own Channel Binding format, but rather should
transmit Channel Bindings as opaque blobs containing AAA AVPs/attributes.
This way, EAP methods do not actually parse the Channel Bindings, just
transmit them from peer to server.

If EAP methods transmit Channel Bindings as opaque bundles of AAA
attributes, then the task of comparison on the AAA server becomes easier,
since essentially this involves comparing the bundle of AAA attributes
sent by the  NAS to the bundle that are received from the EAP peer.  This
requires policy to be configured on the AAA server in order to decide
whether the blobs match or not.  But presumably this can be as simple as
configuring whether a given attribute MUST be present in both the NAS and
EAP attribute list and if so, whether these attributes MUST match.

Another question is "how does the EAP peer obtain the blob to send to the
EAP server?"  In order to avoid having EAP methods handle the blobs, it
would appear that the Channel Bindings need to be formatted and passed to
the EAP method by the lower layer.  For example, a lower layer would
format parameters such as the SSID, STA and AP MAC addresses in AAA
attribute format (Calling-Station-ID, Called-Station-Id), then passing
this to the EAP peer in the format of a AAA attribute blob.  Essentially
then, the lower layer on the peer takes responsibility for generating the
Channel Binding blob and the AAA server takes responsibility for verifying
it;  the EAP method does nothing except transporting the opaque blob from
peer to server.

Method Modifications

In addition to discussing a potential operational model for Channel
Bindings, the document also discusses potential modifications to existing
EAP methods in order to support Channel Bindings.

In looking through the proposal, I found some issues.  As noted above, the
PEAPv2 Channel Bindings model appears to assume peer->server informtion;
the document suggests that the flow is bi-directional or perhaps
server->peer.  Due to the assumptions described above, it is not clear to
me that PEAPv2 Channel Binding verification can actually work as
described.

In terms of the EAP-TLS modification, this requires a TLS Client
extension.  Here the Channel Binding information flow does appear to be
peer -> server.  However, a TLS extension is required, and so far the TLS
WG appears to be reluctant to consider that kind of extension.  So I'm not
clear that the proposed approach can be approved.