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

[Jari Arkko (jari.arkko]

Hi Bernard,

Thanks for your review! Some comments inline:

> 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.
>  
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.

> 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.
>  
Yes.

> 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.
>  
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.

> 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.
>  
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.

> 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.
>  
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.

> 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.
>  
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?

> 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.
>  
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.

> 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
>  
This is very important, agreed.

> 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.
>  
Right. We realized this in our recent list discussion. Our -02
is the first step into this direction, but probably not yet
sufficient.

> 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.
>  
Yes, it does sound good. Need to think about this for a while
though.

> 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
>  
Right.

> 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.
>  
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.

> 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.
This is an issue. Any thoughts on how it could be solved?

--Jari