eap Mailing List: RE: EAP-Keying draft issues

[Alper Yegin (alper.yegin]

[sorry for coming back to this so late, I was away from office]

I see two levels of binding in here:

1- binding user name and NAS id to the authentication session. This is
where we need AAA server's attestation.
2- binding MAC addresses (or, some other device identifiers) to the
authentication session. This is where we can get away without having to
get an attestation from AAA server.

Eventually we need to bind the MAC addresses to the session. My point
is, we can get there in two steps too (not necessarily having to run the
MAC addresses via the AAA server).

Does this make sense?

Alper



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