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

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 03 Jun 2006 18:40:58 -0700

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 7 Jun 2006 10:18:29 -0700

> 
> > > Based on the above, how about the following definition?
> > >
> > > "Channel Binding
> > >
> > > properties (such as authenticator identifiers and properties) are 
> > > agreed upon by 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.
> 
> 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?
> 

I cannot presently think of a property that needs verification and is
not transmitted by the authenticator. 

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

This definition works for me. 

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

The channel property definition is fuzzy to me as well. But, perhaps we
don't need more detail in the EAP keying document itself. A subsequent
channel binding document should get into more detail to clarify things
like this. 

Vidya