Subject: [eap] Review of draft-arkko-eap-service-identity-auth-02.txt

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 May 2005 23:10:03 -0700 (PDT)

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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 May 2005 10:54:00 +0300

Hi Bernard,

>how they work or what the implications are.
I would agree with at least the former part. I think this was also
apparent in the discussion we had recently on thist list under
the Basic Facts thread.

>them.  This seems like a topic that might be worth covering in the EAP Key
Yes.

>that it attempts to make Channel Bindings implementable.
Yes. There seems to be some support in various methods for
it, but at least I have gotten the perception that such support
was not fully baked and likely not implemented. I guess part
of the reason for the draft was that, but the other part was that
we wanted to avoid a situation where we start to lose the various
independence properties of EAP, e.g., one method would only
define the parameters for channel bindings in one L2 but not
for others.

>comparison.   This is how PEAPv2 appears to work, for example.
This is indeed possible, and I believe we the authors of this
draft are willing to consider either direction. In fact, an earlier
revision sent the information on both directions, allowing both
parties to perform the check. But the arguments you give above
do make sense to me.

In the Basic Facts thread Yoshihiro and myself talked also about
this issue. One of the questions that was posed was why some
particular node is set in a special role in this verification, and I'm
not sure I can answer that fully yet.

>implications, because there may be incentives for the peer to falsify
Yes.

I think we may need to understand the implications from
the point of view of the different players. Many of the
folks working on this technology look at things from the
point of view of the providers; I at least confess I often
focus too much on it.

>record of the mismatch, but also can deny access, preventing the peer from
Yes, this seems to be an issue.

What I'd like to understand better is whether there's a similar
issue the other way around. If the peer does not have the
information, will there be some case where the server can
claim something that the peer can't verify? For instance, could
the server claim that there's a mismatch?

>expressed in the form of AAA attributes, rather than a new format.
This is a good idea. There seems to be two parts in this: the
format and the availability of AAA attributes. We may also
have a situation where there's a legitimate need for information
that is presently not available as an AAA attribute.

>require EAP methods to change once new Channel Bindings are defined.  This
This is very important, agreed.

>transmit them from peer to server.
Right. We realized this in our recent list discussion. Our -02
is the first step into this direction, but probably not yet
sufficient.

>EAP attribute list and if so, whether these attributes MUST match.
Yes, it does sound good. Need to think about this for a while
though.

>peer to server
Right.

>me that PEAPv2 Channel Binding verification can actually work as
Another issue with PEAPv2 is that if we ever get to an RFC
about channel bindings, I would at least not like that RFC
to contain modifications to protocols that are not available
as RFCs. This would probably imply cutting the PEAPv2 part
out of the draft and doing it separately.

But lets first agree on what the right direction of information
is.

>clear that the proposed approach can be approved.
This is an issue. Any thoughts on how it could be solved?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 May 2005 09:59:51 -0700 (PDT)

> was not fully baked and likely not implemented.

I think that's fair.  Part of the problem is figuring out how to implement
Channel Bindings without having to constantly update the method
specification for new parameters.  For example, suppose a new lower layer
supports a NAS-Identifier attribute; you'd want the EAP method to
automatically support that attribute and for the AAA server to be
able to verify it, all without a code update.

> I guess part

Right.  I think this is part of the update problem.

> not sure I can answer that fully yet.

I think that security may be part of the answer.  The AAA server obtains
its Channel Binding parameters within the AAA protocol, and therefore they
are integrity protected.  Also, if proxies are doing the recommended
checks along the path the parameters have been sanity checked.

On the other hand, the peer may have obtained parameters from the lower
layer with no security, so they could have been forged.  For example,
parameters obtained in an 802.11 Beacon or Probe Response can have been
sent by an attacker.  So I think that the peer and server are in different
positions with respect to confidence in the information they receive.

> point of view of the providers; I at least confess I often

One of the reasons for the interest in Channel Bindings is the potential
for fraud.  For example, a point of attachment can attract peers
via advertisement of misleading Channel Bindings, then provide different
information to the AAA server.

One attack that has gotten some publicity is the "Evil Twin" attack where
a rogue AP impersonates a popular SSID and attracts peers to attach to it.
It then spoofs popular web sites, potentially obtaining personal financial
information.

In a roaming environment, such an attack can succeed, even where EAP
methods supporting mutual authentication and strong encryption are used,
as long as the rogue AP can reach the home AAA server via some roaming path.
For example, one operator can masquerade as another operator to the user,
convincing them to attach and then charge the user for roaming to another
network.

In this scenario, the interest of the user and home server are probably
aligned: they want to prevent fraud.  The interest of the local operator
or downstream proxy may not be aligned with the peer and server depending
on whether they are in cahoots with the attacker.

> the server claim that there's a mismatch?

Yes, the server can claim there is a mismatch.  If the peer doesn't obtain
the server parameters, it can't verify if this is true or not.  This seems
like it could be an issue if only for debugging purposes: the AAA server
could be set up incorrectly, requiring an attribute that the peer doesn't
send.

> that is presently not available as an AAA attribute.

Since the AAA server can only verify the information sent by the EAP peer
against that it receives from the NAS, it would appear that this would
reuqire creating a new AAA attribute.  Something like a country code
appears to be a reasonable for that, IMHO.

> is the first step into this direction, but probably not yet

One question is where the verification policy resides.  If it is on the
server, then the server can decide what attributes are required to be
present and which ones must match, without additional information from the
peer.  However, if the peer gets a say in this then maybe its opinions
need to be expressed.

> This is an issue. Any thoughts on how it could be solved?

I have only bad ideas, unfortunately.  EAP-TLS doesn't open a data channel
after TLS authentication completes.  This has been a source of frustration
when trying to extend it. The only (bad) idea I have is potentially to use
attribute certificates, and send the blobs that way.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap