eap Mailing List: RE: EAP-Keying draft issues

[Walker, Jesse (jesse.walker]

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:alper.yegin [at] samsung.com] 
Sent: Thursday, October 07, 2004 3:22 PM
To: Walker, Jesse; eap [at] frascone.com
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