eap Mailing List: RE: EAP-Keying draft issues

[Walker, Jesse (jesse.walker]

What is needed is attestation from the AAA Server that this binding is
correct. It is the only party whom both the Peer and the NAS trust, so
is the only party that can provide the necessary attestation.

-----Original Message-----
From: Alper Yegin [mailto:alper.yegin [at] samsung.com] 
Sent: Friday, October 08, 2004 2:34 PM
To: Walker, Jesse; eap [at] frascone.com
Subject: RE: [eap] EAP-Keying draft issues

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





> -----Original Message-----
> From: Walker, Jesse [mailto:jesse.walker [at] intel.com]
> Sent: Thursday, October 07, 2004 9:36 PM
> To: Alper Yegin; eap [at] frascone.com
> Subject: RE: [eap] EAP-Keying draft issues
> 
> 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
> 
>