eap Mailing List: RE: Re: EAP Key Binding

[Walker, Jesse (jesse.walker]

Hi Bernard,

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com]
> Sent: Sunday, April 17, 2005 8:20 AM
> To: Walker, Jesse
> Cc: eap [at] frascone.com; Paul Funk; Henry Ptasinski; Steve Emeott; Russ
> Housley; Nancy Winget; dstanley [at] agere.com
> Subject: RE: [eap] Re: EAP Key Binding
> 
> > To honor this requirement, the identity
> > delivered to the NAS is not necessarily the authenticated identity
> > directly, but rather a function of the authenticated identity,
something
> > derived from the authenticated identity that can be made public
without
> > violating the EAP Peer's privacy.
> 
> The key management framework defines the Peer and Server identities
> utilized by existing methods.  We can mention that this information
needs
> to be passed up along with the Key Name and exported keys.  On the
peer
> side this information can be passed down to the lower layer to
> do the required computation.  On the AAA server side, the required
> computation can be sent to the NAS in an attribute.
> 
> The question in my mind is whether this is an existing attribute (e.g.
> User-Name), a proposed attribute (CUI), or something new altogether.
> If the function of the peerID includes the Challenge it could qualify
> for inclusion in the CUI attribute which is supposed to not allow
> tracking.  I don't think User-Name will work since some AAA servers
> might just send the peer-ID with no hiding.  However, I'm not sure if
> the content of CUI can be constrained this way.
> 
> > You may respond that some sort of multi-factor authentication may be
> > used, and that several identities will be asserted during
> > authentication. Fine. Let's define some standard way to concatenate
them
> > and compute a function of them. And that is the right thing to do,
too,
> > because all of the identities collectively are what the Server
verified
> > by EAP authentication.
> 
> I think that it is sufficient to require the EAP method to define and
pass
> up the peer-ID.  Whatever the method passes up is what is included in
the
> computation.
[Walker, Jesse] This is fine.
> 
> > This realization is
> > an important step forward in the conversation, and I don't remember
it
> > being made before.
> 
> Actually, it was discussed in the EAP WG 18 months ago as part of the
> channel binding issue.  However at the time there was no request from
IEEE
> 802.11 for that functionality.
[Walker, Jesse] Thanks for this information. I think we don't care how
the binding happens, as long as it happens.

> > [Walker, Jesse] If you recall, I prepared a requirements document
> > 11-04-1498 that we discussed at the November 2004 IEEE 802 meeting
in
> > San Antonio. At the time you indicated you did not think it was
> > necessary for IEEE to forward such a document to IETF.
> 
> My understanding was that IEEE 802.11 did not vote to approve the
> requirements document, so that it had no official status.
[Walker, Jesse] Right. How I recollect the discussion was that you did
not think we needed to create an official response, so I did not ask for
a vote.

> > For the record,
> > now are you asking 802.11 to update and adopt this or some similar
> > document as requirements and then forward the result to IETF?
> 
> Yes, if there is consensus on such a set of requirements that would be
> helpful.  Note that I'm not just talking about requirements for the
802.11
> handshake;  I'm talking about 802.11 requirements for the system
(which
> would include any functionality required from EAP or AAA).
[Walker, Jesse] Thank you. With this direction I will work with my
colleagues in 802.11 to reach a consensus on requirements and have it
forwarded to IETF.