eap Mailing List: Approach to channel bindings (Was; Re: [eap] Basic facts about EAP)

[Jari Arkko (jari.arkko]

Hi Yoshihiro,

>I don't really think that the peer and the AAA server need to be
>syncronized about the exact parameters (that's why opaque blob can be
>used for channel bindings), while I do think that the peer and the
>authenticator (NAS) need to be synchronized about them.  
>
>Also, I think that the peer and the authenticator need to be
>synchronized about the parameters even in the case of stand-alone
>authenticator (i.e., no AAA protocol) in order to avoid MiTM in
>between.  In this case, the EAP lower-layer is surely able to bind the
>AAA-Key to the parameters (binding based on using the parameters in
>the key derivation algorithm) without carrying the parameters in the
>EAP method.  I think we should use the same way of binding regardless
>of whether there is a pass-through authenticator or not.  Otherwise,
>if we use one channel binding method for the stand-alone authenticator
>case and another channel binding method for the backend authenticator
>case, it would not make the pass-through authenticator transparent to
>the EAP peer.
>  
>
I wonder if we are talking about the same thing here. I agree with
what you say is needed, but it seems like the above is more like the
secure capabilities negotiation requirement that we have placed on
the Secure Association Protocol.

As others have pointed out, the term channel binding may not be
the best choice. But at least the way it is defined in RFC 3748 and
the keying draft it seems to talk about an ability to match two
independent sources of information to each other:

Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Where discrepancies
are found, these SHOULD be logged; additional actions MAY also be
taken, such as denying access.

To me this implies that we can't get this type of channel binding
without exchanging information on all sides of the peer - auth - server
triangle.

But perhaps we are talking about who should make the final
check, is it the peer, authenticator, server, or all of them. I've
been assuming it would be either the peer or the server, or
possibly both of them. What you have said has lead me to
reconsider this a bit. Perhaps all of the parties have an interest
in making sure the others are not fooling them.

--Jari