Subject: RE: [eap] EAP-Keying draft issues

From: "Walker, Jesse" <[email-masked]>
Date: Thu, 7 Oct 2004 21:35:43 -0700

Alper,

Has this be made mandatory for all EAP methods that do keying? I do not
believe so. The lack of mandatory binding is the issue.

-- Jesse

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Thursday, October 07, 2004 3:22 PM
To: Walker, Jesse; [email-masked]
Subject: RE: [eap] EAP-Keying draft issues

Hi Jesse,

>    d. Key derivation must use the authenticated identities of the
> parties
>       that are intended to consume the keys. The existing EAP, 802.1X,
> and
>       802.11i architectures provide no way to deliver the
authenticated
>       identity of the AP to the STA nor the STA to the AP, so this
> implies
>       a deployment constraint: the authenticated identities in the
4-Way
>       Handshake must be the MAC addresses of the two parties. This is
>       certainly not compatible with the advice the keying draft gives,
>       and it is incompatible with the way people deploy EAP, 802.1X,
and
>       802.11i. I think this is a problem for the keying draft.

> Concern (d) I think gets to the heart of a much more fundamental
> problem. This is that the draft does not address the central issue
that
> motivated it. Keying is a three-party problem, and no three-party
> solution has been offered or even hinted at, and no process to lead to
a
> three-party construction seems to have been erected, enunciated, or
even
> envisioned. Section 5.3 waves its hands at the issue, but elsewhere
the
> document coexists at best uncomfortably with the issues raised by
having
> three parties in the equation. The document seems like a mish-mash of
> requirements mixed together with rationales why we have to keep on
doing
> things the way we have always done them before.

Could this be solved by the EAP lower layer design? 

PANA-Bind exchange (which carries the EAP Success) carries device
identifiers of the PANA client and enforcement point(s). The message is
integrity protected as well. This provides identification of the
consumers of the keys (if I got the NIST problem right....).

The latest PANA spec is here:
http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06c.txt

Alper

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Fri, 08 Oct 2004 14:33:41 -0700

Hi Jesse,

The binding I'm referring to is solely between the authenticator (NAS,
PAA) and peer (PaC). That's where PANA runs. It allows binding the
authorized session to identifiers that are used with secure association
and eventually data packets. 

That's different than binding the authenticated identities of the
authenticator and peer (via AAA) to the session. I'm under the
impression that both are required though.

Alper

> From: Walker, Jesse [mailto:[email-masked]]
> Sent: Thursday, October 07, 2004 9:36 PM
> To: Alper Yegin; [email-masked]