Subject: Re: [eap] Proposed Resolution to Issue 357: Channel Binding Definition

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Jun 2006 22:19:07 -0700

Hi Bernard,
The proposed text by Jari went through some revisions as I recall, based
on some discussions on the list. Here is the latest on that text I
pulled out from one of Jari's email, subsequent to the discussions: 

"I'd be happy to restrict the definition to peer and server agreeing
that they have the same view of the channel properties claimed by the
authenticator.

(But part of the distinction may also be in the specific implementation
of the "agreement"; what we are looking for is that the values agree,
without specifying who sends the values and who verifies them.)"

Based on the above, how about the following definition? 

"Channel Binding

A secure mechanism for ensuring that a chosen set of channel properties
(such as authenticator identifiers and properties) are agreed upon by
the EAP peer and server." 

Vidya

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, June 03, 2006 6:41 PM
> To: [email-masked]
> Subject: [eap] Proposed Resolution to Issue 357: Channel 
> Binding Definition
> 
> The text of Issue 357 is enclosed below.  The proposed 
> resolution is to accept the definition proposed by Jari Arkko:
> 
> "Channel Binding
> 
> A secure mechanism for ensuring that a chosen set of channel 
> properties (such as endpoint identifiers) are agreed upon by 
> the EAP peer, authenticator and server."
> 
> --------------------------------------------------------------
> ----------------------------------
> Issue 357: Channel Binding Definition
> Submitter name: Vidya Narayanan
> Submitter email address: [email-masked] Date Submitted: 
> May 1, 2006
> Reference: http://lists.frascone.com/pipermail/eap/msg04227.html
> Document: KEYING-12
> Comment type: 'T'echnical
> Priority: '1' Should fix
> Section: 1.2
> Rationale/Explanation of issue:
> The document defines channel binding
> as a communication within an EAP method - this seems a bit 
> restrictive, given that channel binding information could be 
> carried out-of-band as well. The only requirement is that the 
> information be integrity protected between the peer and server.
> 
> Requested change:
> Change wording to:
> 
> "The communication of integrity-protected channel properties 
> such as endpoint identifiers which can be compared to values 
> communicated via out of band mechanisms (such as via a AAA or 
> lower layer protocol)."
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Jun 2006 11:07:21 -0400

> the EAP peer and server." 

After Jari's email, I created a thread "Channel Binding analysis" for
further discussion.  I still believe three party agreement is
essential for Channel Binding.  To me the two party agreement
mentioned above looks similar to issueing a Kerberos ticket that is
never verified by the consumers of the ticket.

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 07 Jun 2006 08:36:50 -0700

>never verified by the consumers of the ticket.

The text mentions authenticator identifiers and properties, which presumably 
were agreed upon by the authenticator that sent them (unless it's a 
forgery).   However, there are also properties which don't relate to the 
authenticator itself (such as Calling-Station-Id) but are transmitted by the 
authenticator (e.g. to the backend server).   Are there any cases where a 
property to be verified by Channel Bindings is *not* transmitted by the 
authenticator?  Would the following work?

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

I'm not sure what the definition of a "channel property" is in this case.  
One could argue for example that the Calling-Station-Id is not a property of 
the channel -- but its verification is still considered part of Channel 
Bindings.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Jun 2006 14:19:40 -0400

On Wed, Jun 07, 2006 at 08:36:50AM -0700, Bernard Aboba wrote:
> 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.

> However, there are also properties which don't relate to 
> the authenticator itself (such as Calling-Station-Id) but are transmitted 
> by the authenticator (e.g. to the backend server).   Are there any cases 
> where a property to be verified by Channel Bindings is *not* transmitted by 
> the authenticator?  Would the following work?
> 
> "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.  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.

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?

Yoshihiro Ohba

> One could argue for example that the Calling-Station-Id is not a property 
> of the channel -- but its verification is still considered part of Channel 
> Bindings.
> 
> 
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 07 Jun 2006 12:56:53 -0700

>Then I think this presumption should be explicitly described in the

Do you want to suggest text?

>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

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?

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 08 Jun 2006 10:44:54 -0400

> Do you want to suggest text?

How about:

" 
It is expected that the parameters are also agreed upon by the peer
and authenticator via the lower layer if the authenticator is the
valid entity that advertised the parameters.
"

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

This was discussed before.  My comment was that if the authenticator
needs to advertise the channel binding parameters.

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

The peer may be lying in this case, but the server will never know
whether authenticator or peer is lying unless the server is
preconfigured with the peer's Calling-Station-Id.

Yoshihiro Ohba