Subject: [eap] Re: issue 357: Channel Binding Definition

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 02 May 2006 07:11:09 -0700

As Yoshi has pointed out, it may be possible to handle channel bindings by 
mixing keys so that comparison may not be required.  How about this?

"Channel Binding

A mechanism for ensuring the correctness of channel properties (such as 
endpoint identifiers) provided to 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: Jari Arkko <[email-masked]>
Date: Mon, 08 May 2006 17:18:12 +0300

Re: do all the three parties have to be involved in
the binding? I believe that is essential for the
definition to say this.

Re: the data that is subject to channel binding. I think it is
clear that not all data known by the parties needs to be
bound. Traditionally, we've only talked about security
or billing related information, such as the NAS identity
and type and cost of service. A large number of other
parameters may be known by some of the parties, but
not relevant from a verification perspective.

Re: do all the parties share the same data? I tend to
agree with Vidya here that its sufficient to for the
verifier to check that the data it gets is correct. But
this issue is also related to policies of what the parties
want to be verified. If the server wants to verify FOO
but the client does not send it, we're not helping. This
leads me to think that the channel bindings, if we ever
get them deployed, are going to have use a well
standardized set of parameters or else we have a policy
management problem in our hands. But see below for
a process comment.

Process comment: Lets try to focus on the definition
of channel bindings rather than their implementation
in this discussion. EAP keying framework does not
define how to implement them, or whether to pick
solution 1, 2, or 3.

Suggested text:

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

Vidya: note that the "chosen set" may be different
in different situations, depending on what information
is available.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 May 2006 09:56:49 -0700

This looks good to me.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 08 May 2006 10:06:44 -0700

>agreed upon by the EAP peer,  authenticator and

This is confusing to me.  I was under the assumption that the peer 
and the server should agree that they have the same view of the 
authenticator (perhaps with the provision that the server may have a 
superset of the information than the peer has).  What does the 
authenticator need to agree on?  Does it matter?

regards,
Lakshminath

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 May 2006 18:39:05 -0700

>agreed upon by the EAP peer,  authenticator and

I'm ok with this.  Any objections?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 8 May 2006 23:39:43 -0400

I agree.  

Note that agreement just by EAP peer and server would not be
sufficient.  Authenticator's agreement by running SAP for proof of
possession of a key that is generated by the peer and server and
somehow bound to the chosen set of properties would be required.
Otherwise, it seems possible for an attacker to sit between the peer
and legitimate authenticator and do something wrong by spoofing some
of the properties of the legitimate authenticator.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 09 May 2006 00:58:21 -0700

>of the properties of the legitimate authenticator.

How?  The attacker won't have the key (MSK) to do something like 
that.  Perhaps you might explain the attack in detail. Thanks.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 09 May 2006 01:01:28 -0700

>I'm ok with this.  Any objections?

I am not sure about the authenticator involvement, have asked Jari 
that question and awaiting response.  It's about the EAP server and 
peer agreeing about the authenticator's identity and perhaps other 
things about the authenticator, no?

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 May 2006 08:34:48 -0400

> that.  Perhaps you might explain the attack in detail. Thanks.

In case there is no SAP between the peer and authenticator (e.g.,
wired 802.1X), the attacker does not need to have the key.  In that
case, agreement just by EAP peer and server is useless.  What I'd like
to mention is that Channel Binding makes sense only if keying meterial
exported by an EAP method is used by SAP.

Yoshihiro Ohba