Subject: Re: [Emu] Channel Binding Discussion at IETF 77

From: Yaron Sheffer <[email-masked]>
Date: Fri, 18 Jun 2010 13:31:53 +0300

Hi Sam,

I am glad you are taking a fresh look at this issue. Some comments:

- I think draft-ietf-emu-chbind is not as interesting, or potentially 
useful, as draft-clancy-emu-aaapay. In any case, both drafts should be 
looked at together.

- I think tunnel methods are more trouble than they're worth in this 
context. They create inter-layer security issues of their own. And most 
people tend to think of TLS+PKI when talking about tunnel methods, even 
though theoretically there may be alternatives.

- I support very much the need to standardize channel binding 
attributes. There are EAP methods today with a placeholder for such 
attributes (EAP-GPSK, EAP-EKE, probably more).

- In addition to attributes, I think (or rather, I'm afraid) we need to 
standardize/recommend a minimal set of such attributes for some use 
cases. For example, in a wi-fi setting you can expect to receive an IP 
address (MAC address?) and an SSID. I realize this can turn into a major 
rathole but without such recommendations, there are too many possible 
combinations.

Thanks,
	Yaron

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Jun 2010 15:29:07 -0400
> From: Sam Hartman<[email-masked]>
> Subject: [Emu] Channel Binding Discussion at IETF 77
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> Hi.  At IETF 77, I agreed to edit draft-ietf-emu-chbind.  Also, at that
> meeting, I sat down with Glen to understand his concerns with the
> document.  I'd like to write up my notes on that meeting and to discuss
> what I think the critical next steps are for the document.
>
>
> I presented two motivating examples, one of which is I think directly
> within the previous discussions of channel binding and one of which is
> my motivation for caring about the problem.
>
> Consider a corporation that has an internal network and that also has
> agreements with WIFI hotspots to provide its employees connectivity.
> Policy requires that people use a different set of firewall rules and
> VPN configuration when connecting at the WIFI hotspots than when
> connecting to the home network.  Typically clients determine which
> network is in use by the SSID.  They use the same EAP credentials in
> both cases.
>
> You can imagine  that the corporation would know the identities of its
> own access points.  In particular, a combination of configuration on the
> AAA servers and at the boundary firewall could mean that the AAA servers
> know whether a given request for access is coming from the corporate
> network or a WIFI hotspot.  Today, however, the corporate AAA
> infrastructure does not know what the client thinks it is connecting
> to.  If the client disclosed the SSID it sees then the corporation would
> be in a position to enforce the security policy.
>
> Glen agreed that channel binding could address this.  We'll come back to
> whether  it's a good idea in a bit.
>
> My motivation is related to the technology being developed by the
> Moonshot project (http://www.project-moonshot.org ).
> We'd like to use EAP as part of application authentication. With network
> access, there are a lot of situations where one network is much the same
> as another. However with application authentication the party you're
> talking to matters a lot, especially in federations with relatively
> liberal membership policies.  I might well be willing to send
> information to my company's ERP system that I should not send to a rogue
> machine at a competitor that is part of the same federation. I'd like to
> know the difference in who I'm talking to.
>
> Glen described several significant concerns about the way channel
> binding has been handled.
>
> First, there is the basic complexity concern.
> EAP has grown and evolved over the years, in many cases with design
> taking place after the fact. Adding a new facility has a high
> cost. However, there are some things in the current draft that make that
> cost even higher.
>
> I, and a few others have argued that all EAP methods should gain channel
> binding support. Glen points out that is a lot of work and argues it is
> unnecessary.
>
> Glen is also concerned that each EAP method will handle channel binding
> differently.His assumption is that each method would have a different
> set of channel binding attributes that it carried, a different mechanism
> for carrying them, and different names/numbers for the attributes. So,
> rather than just supporting channel binding in some deployment of EAP,
> you would need to tie it to a particular method or small set of
> methods. He acknowledged that we could have some standardized way of
> dealing with new EAP methods but points out that we have a lot of
> existing methods.
>
> Glen and I had a long discussion about channel binding in EAP vs channel
> binding as part of the secure association protocol.
> That was a very useful discussion.
>
> The interesting question is what  favors one approach vs another.
>
> Channel binding always requires changing the client and the home AAA
> server/EAP server.
>
> Using a SAP requires:
> 1) changing all the NASes
> 2) Specifying an extension to each lower layer that may be used
> 3) Specifying AAA transport for this extension.
>
> [As an aside, Glen proposed a mechanism for doing this at the AAA layer
> that should get written up somewhere. I thought it was quite clever and
> easier than any attempt to do this I had seen before. Of course I'm a
> relative novice when it comes to AAA.]
>
> Using channel binding inside EAP requires:
>
> 1) Changing/specifying channel binging for the EAP methods in use.
>
> For most of the applications I care about (with the exception of the EAP
> for non-network-access use case), avoiding having to change the NAS is a
> huge advantage.
> Also, from where I sit, not having to update the link layers is a big
> deal.
> However, the conversation was really useful because I now understand
> situations in which both of those assumptions about complexity of change
> would be different.
>
> So, here are some ideas going forward for areas I'd like to improve the
> draft:
>
> 1) The introduction does discuss use cases.  However I don't think it
> does a particularly good job of describing concrete use cases; I'd like
> to provide some explicit examples.
>
> 2) The draft doesn't currently motivate the secure association protocol
> version of channel binding.  I will admit that my reaction when I read
> that section of the draft was roughly "that's a stupid idea there to
> placate people who don't think we can do this in EAP."  At this point I
> feel I understand the use case well enough to describe it and would like
> to attempt doing so.
>
> 3) It's not actually true that you need to cover all EAP methods in
> order to use channel binding inside EAP.  In particular, if you have a
> tunneled configuration, only one of the methods needs to support channel
> binding.  There are complexities here: you either need cryptographic
> binding or you need the channel binding to be part of the method that
> provides authentication of the client to the server.  Still, it seems
> like this is an area where we should explicitly consider what's going on
> and see if we can use tunnel methods to reduce cases where we need to
> implement channel bindings.
>
> 4) It seems clear to me that we want one namespace of channel binding
> attributes that we carry in EAP methods and secure association
> protocols.  The current draft implies that but doesn't really give
> concrete mappings for how that will be carried in existing EAP methods.
> It's my understanding that there has been work done in this space.  I
> think that we need to go through that work and make sure it is sound to
> address Glen's concern that we don't want the set of attributes to be
> method-specific, nor do we want applications consuming channel binding
> to need to pay attention to what their method supports.  Some methods
> will support channel binding; some will not.  However for those that do,
> we want a consistent interface provided to the lower layer.
>
>
> There may be other open issues with the document.  I have not inherited
> any such list if there is one.
>
> I'd appreciate comments from the WG and chairs on this proposed
> approach.
>
> --Sam
>
>