eap Mailing List: Re: Proposed Resolution to Issue 357: Channel Binding Definition

[Bernard Aboba (bernard_aboba]

> > The text mentions authenticator identifiers and properties, which
> > presumably were agreed upon by the authenticator that sent them (unless
> > it's a forgery).
>
> Then I think this presumption should be explicitly described in the
> draft.

Do you want to suggest text?

> > "A secure mechanism for ensuring that a subset of the parameters
> > transmitted by the authenticator (such as authenticator identifiers and
> > properties) are agreed upon by the EAP peer and server."
>
> Transmitted to whom?  I think not all parameters do not need to be
> transmitted to the server while all parameters need to be transmitted
> to the peer.

I was leaving it open.   Some things might be transmitted to the peer but 
not the server, or vice versa.  For example, the authenticator may send 
Calling-Station-Id to the AAA server, but it doesn't send it to the peer 
(the peer includes that in the source address).

> In fact, if the server has the pre-established knowledge
> about the parameters, the only information that needs to be sent from
> authenticator to the server is authenticator identity which can be
> used as the primary database look-up key to find out other parameters
> associated with the authenticator identity.

How can the peer use channel binding parameters which it never received?  So 
the authenticator needed to send it to the peer at least, no?

> Also I don't understand why peer's lower layer parameter such as
> Calling-Station-Id needs to be agreed by peer and server.  What is the
> actual threat without agreement?

The threat is that the authenticator could lie about the Calling-Station-Id. 
 The peer could then find out from the server that it got different 
information.