Subject: Re: [Emu] GPSK issue - KDF Data

From: "[email-masked]" <[email-masked]>
Date: Wed, 4 Oct 2006 23:24:44 +0000 (UTC)

One small problem, how does an EAP peer see the identity of the other 
parties?
Dave.

----Original Message----
From: [email-masked]
Date: Oct 4, 2006 14:01 
To: "Hannes Tschofenig"<[email-masked]>, "Bernard Aboba"
<[email-masked]>
Cc: <[email-masked]>
Subj: Re: [Emu] GPSK issue - KDF Data

Agree with Hannes on this.

Lakshminath

At 10:29 AM 10/4/2006, Hannes Tschofenig wrote:
>For channel bindings you don't need to incorporate something into 
>the KDF. Checking whether the identities seen by the three parties is 
enough.
>
>Ciao
>Hannes
>
>PS: Btw, what is the status of the channel binding work? Totally 
stalled?
>
>Bernard Aboba schrieb:
>>>this aspect refers to the ability to put arbitrary data exchanged 
>>>between the end points into the key derivation function.
>>>
>>>It is therefore not about the nonces, identities etc. that is 
>>>typically incorporated into the key derivation function.
>>>
>>>Why would someone want todo this? I don't think it is useful.
>>Channel Bindings?
>>
>
>
>_______________________________________________
>Emu mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 04 Oct 2006 16:36:14 -0700

Hi Dave,

I was tersely agreeing to Hannes's note on CB not needing to 
incorporate anything into KDF and Identity checking is sufficient.

To your question on the EAP peer knowing the identities of the other 
parties, the server's id would be available through the method and I 
would assume the authenticator's id would be available through the 
EAP lower layer.

Or, did I totally misunderstand your question?

regards,
Lakshminath

---

From: "Ray Bell" <[email-masked]>
Date: Wed, 4 Oct 2006 16:47:15 -0700

Do you mean mutual authentication between the peers?

Ray

----Original Message----
From: [email-masked]
Date: Oct 4, 2006 14:01 
To: "Hannes Tschofenig"<[email-masked]>, "Bernard Aboba"

Lakshminath

enough.
stalled?

---

From: David Mitton <[email-masked]>
Date: Wed, 04 Oct 2006 21:39:53 -0400

Lakshminath,

         The devil is in the details.

As I see it EAP doesn't provide a way for an 802.11 supplicant to 
know it's authenticator's ID.

I'd like to be proven wrong, but I am skeptical of claims based on assumptions.

Dave.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 4 Oct 2006 19:28:47 -0700

Hi Dave, 

> As I see it EAP doesn't provide a way for an 802.11 
> supplicant to know it's authenticator's ID.
> 

True that EAP does not provide a mechanism for the peer to know it's
authenticator's ID. The authenticator ID is meant to be known to the
peer via the lower layer. For instance, this could be one of the
following - MAC address of the AP, BSSID of the AP, or something else
that may be advertised in the beacon or sent in a Probe Response. The
AAA client provides a NAS ID to the backend server. 

Channel Bindings is meant to provide a means for the peer to verify that
the entity claiming to be the authenticator is the same as the entity
the server thinks is the authenticator as well. 

All this is irrespective of whether CB is realized by putting some
arbitrary information into the key derivation or by authenticated
matching of authenticator identities by peer and server. 

Having said that, I agree with Hannes and Lakshminath that we don't need
to add data to the KDF to realize channel binding. Identity matching via
authenticated exchange of information is sufficient. 

Regards,
Vidya

> >would assume the authenticator's id would be available 
> through the EAP 
> >lower layer.
> >
> >> >the KDF. Checking whether the identities seen by the 
> three parties 
> >> >is
> >>enough.
> >> >
> >> >Ciao
> >> >Hannes
> >> >