Subject: RE: [eap] Re: EAP Key Binding

From: "Walker, Jesse" <[email-masked]>
Date: Mon, 18 Apr 2005 07:05:57 -0700

Hi Bernard,

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Sunday, April 17, 2005 8:20 AM
> To: Walker, Jesse
> Cc: [email-masked]; Paul Funk; Henry Ptasinski; Steve Emeott; Russ
> Housley; Nancy Winget; [email-masked]
> 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.

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

---

From: Dorothy Stanley <[email-masked]>
Date: Mon, 18 Apr 2005 10:01:18 -0500

In November, TGr was not ready to approve 04/1498.  I think tgr as a whole
had not spent enough time with  the doc,  and wasn't comfortable with the
content. A draft 04/1498 was enough for the EAP WG to start with, as a 
rather large "comment" on the
Keying Framework document. I agree it's time to discuss 04/1498 in TGr 
again.

A (final) 04/1498-compliant TGr solution will also address an 
outstanding liaison action item,  the
"authenticator identity issue", that was raised in CAPWAP discussions:

The centralized model encourages AC implementations to use one PMK for 
many different WTPs. 
This practice facilitates speedy transition by a station from one WTP to 
another
WTP that is connected to the same AC without establishing a separate PMK. 
However, this leaves the station in a difficult position.  The station 
cannot
distinguish between a compromised PMK and one that is intentionally 
being shared.
This issue must be resolved, but the resolution is beyond the scope of 
the CAPWAP working group.

Dorothy

Walker, Jesse wrote:

-- 
----------------
Dorothy Stanley
Agere Systems
2000 North Naperville Rd. 
Naperville, IL 60566
630-979-1572 (Phone, Fax)
630-222-6753 (Cell)

---

From: Alper Yegin <[email-masked]>
Date: Wed, 20 Apr 2005 13:20:19 -0700

The centralized model encourages AC implementations to use one
PMK 
	for many different WTPs. This practice facilitates speedy
transition 
	by a station from one WTP to another WTP that is connected to
the same 
	AC without establishing a separate PMK.  However, this leaves
the station 
	in a difficult position.  The station cannot distinguish between
a 
	compromised PMK and one that is intentionally being shared. This
issue must 
	be resolved, but the resolution is beyond the scope of the
CAPWAP working group.

So, the issue is about binding PMK to NAS ports (WTPs in this case).
Unless the NAS explicitly informs the host about the list of ports, how
can this be handled? I think this is an issue for the EAP lower layer to
handle.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Apr 2005 15:45:56 -0700 (PDT)

> The centralized model encourages AC implementations to use one PMK
>for many different WTPs. This practice facilitates speedy transition
>by a station from one WTP to another WTP that is connected to the same
>AC without establishing a separate PMK.  However, this leaves the station
>a compromised PMK and one that is intentionally being shared. This
> issue must be resolved, but the resolution is beyond the scope of the
> CAPWAP working group.

Not only is it beyond the scope of the CAPWAP WG, but it's beyond the EAP
WG scope, too.  For the purposes of EAP and AAA, the key is provided to a
given NAS, no matter how many ports it has.  The way to fix this is to
have the authenticator advertise the NAS-ID and confirm this securely
between the peer and authenticator in the Secure Association Protocol (and
perhaps between the EAP peer and server too, via channel bindings).  EAP
and AAA already enable this, so it's up to the lower layer to implement it
correctly.

> can this be handled? I think this is an issue for the EAP lower layer to

The NAS doesn't have to inform the host of the list of ports, it just has
to provide the host with the same NAS-ID that it provides to the AAA
server.  You are correct that it is a lower layer issue.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Wed, 20 Apr 2005 18:06:50 -0700

> server.  You are correct that it is a lower layer issue.

Dorothy can correct me if I'm wrong, but shared knowledge of NAS-ID does
not seem to solve the problem she is describing. Unless both the host
and the NAS agree on the list of ports (WTPs) associated/bound to the
PMK (or, its derivatives), host cannot distinguish between a legitimate
WTP and one that's using a compromised PMK (or, a derivative). In fact,
what I'm talking about is further binding that not only includes the NAS
ID but also the port IDs.

Alper