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

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 May 2006 10:44:31 -0700

Hi Jari,

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

Agreed. 

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

True. Actually, there does seem to be a line of thinking where perhaps
channel binding capabilities can even be tied to the peer verifying
advertised capabilities of the authenticator with the AAA server. Of
course, it can be argued that it has nothing really to do with channel
binding (and I'd agree) - but, goes to prove again that this is an
opaque blob that may not be fully available at the peer. 

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

Fully agree with this. Let's define it for the EAP keying document and
continue to discuss solutions later for a separate document. 

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

Agree with the chosen set part. But, what is the authenticator agreeing
to? Isn't it just an agreement about the authenticator between the peer
and server? 

Vidya

> --Jari
> 
> 
> _________________________________________________________________
> 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: Jari Arkko <[email-masked]>
Date: Tue, 09 May 2006 13:46:56 +0300

Hi Vidya, Laksminath,

And you Laksminath wrote:

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

Good questions. 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.)

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 May 2006 10:02:43 -0400

> view of the channel properties claimed by the authenticator.

If the definition is only for agreement between the peer and server,
then it means we are allowing Channel Binding without running a SAP.
I think involvement of the authenticator's agreement via SAP is
needed.  I mean the authenticator needs to agree that, the
authenticator, not someone else, has sent the information to the peer.

Yoshihiro Ohba

---

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

>authenticator, not someone else, has sent the information to the peer.

Hmmm, let's see. The peer and the server agree, let's say through the 
EAP method, that they are talking to the same authenticator and the 
server sends the MSK (or for that matter, as Joe seems to imply, port 
open indication) to *that* authenticator.  So, I don't see why the 
authenticator needs any more verification.

Now without the SAP there are other problems, but they don't seem 
relevant to CB.  Perhaps I am missing something (you seem like you've 
explored this area quite a bit, please explain.  Thanks).

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 May 2006 15:00:37 -0400

> authenticator needs any more verification.

The problem here is that the authenticator that advertised the 
information may not be the one that receives the MSK.

> explored this area quite a bit, please explain.  Thanks).

Please see an example below.

[Peer]---[AA]---[LA]---[Server]
  |               |    |
  |    EAP method |    |
  |<------------------>|
  |               |MSK |
  |               |<---|

An attacker authenticator (AA) is acting as an authenticator for the
peer and and as a peer for the legitimate authenticator (LA), passing
through EAP messages between the peer and LA.  Both AA and LA
advertise the same LA's information XYZ.  The peer learns XYZ from AA.
The server have the XYZ for LA.  Server sends MSK to LA after creating
binding between XYZ and MSK by some means (i.e., key mixing or data
transfer).

If we stop here, the peer will think that AA has the MSK, which is not
true.  This looks like an open binding which might open up some
vulnerability to MiTM attack.  An additional verification, SAP, is
needed to close the binding by verifying proof of possession of the
MSK between the peer and authenticator.

Regards,
Yoshihiro Ohba

---

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

>[Peer]---[AA]---[LA]---[Server]

Yoshi,

You've just made a case for key generating EAP methods and the need 
for a SAP.  There is no dispute there.  But, my earlier point about 
without SAP, there are other problems is still true, no?  CB is not 
the only issue there.

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 May 2006 17:14:35 -0400

Lakshminath,

> without SAP, there are other problems is still true, no?  CB is not 

I agree that CB is not the only issue here, but CB is *an* issue.  The
SAP for CB does not necessarily generate a TSK.  In this case, the
role of the SAP is just to close the binding.  However, if you do CB
but don't generate TSK and use it for per-packet ciphering, then you
will surely have other issues.

Yoshihiro Ohba