Subject: RE: FW: [eap] Re: EAP key binding discussion

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Apr 2005 11:52:17 -0500

Hi Bernard,

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, April 27, 2005 11:50 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: FW: [eap] Re: EAP key binding discussion

> Sorry for the late response to this. I have written something up. It is
> more a problem statement than a solution proposal. Basically because I
> was not sure whether sending the AAA key to some place other than an
> authenticator is against EAP key management principals.

The Housley Criteria are described in RFC 4017 as well as the EAP Key
Management framework.

In particular, I would pay attention to the "Confidentiality" condition
(which prohibits disclosure of keys to parties outside the peer, server
and authenticator), 

Madjid>>what about disclosure of the keys between the authenticators??
I think EAP and its key management framework has not positioned itself well with respect to handovers and that is why the door for interpretations is being opened over and over.

the "mutual authentication" condition which requires
mutual authentication between all parties, 

Madjid>> "all parties"? Where is the mutual authentication between the NAS and AAA server enforced? RADIUS shared secret (SS)? If that is the case then you can have 
			SS1
		LKDC----------AAA server
			     	 /	 /
		long term__/	/SS2
		secret  /       /
		       peer---- NAS

and the "domino effect"
condition which prevents compromise of one party from affecting other
parties.

Madjid>> Sending the AAA-key to each authenticator and reusing it by other authenticator as part of secure association generation with the peer causes "domino effect", no?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Apr 2005 10:49:37 -0700 (PDT)

> What about disclosure of the keys between the authenticators??

Here is the requirement (from RFC 4017):

      Requirement: "Compromise of a single authenticator cannot
      compromise any other part of the system, including session keys
      and long-term secrets."

"any other part of the system" would seem to include other authenticators.

> I think EAP and its key management framework has not positioned itself
> well with respect to handovers and that is why the door for interpretations
> is being opened over and over.

I'd be interested in any data that you have collected on this.  Having
recently done some tests on handover times in WLAN switches, I was
surprised by how well the equipment performs.  For example, we have
measured handoffs of 25ms or less on a consistent basis with a number of
WLAN switch products.  These measurements were made on equipment implementing
RFC 3579, RFC 3748, and WPA2 (including pre-authentication).

I have collected published material on handoff times at the following
location:
http://www.drizzle.com/~aboba/IEEE/

> the "mutual authentication" condition which requires mutual
> authentication between all parties,

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Apr 2005 16:01:39 +0300

Hi Madjid

>I think EAP and its key management framework has not positioned itself well with respect to handovers and that is why the door for interpretations is being opened over and over.
It is true that the key management framework does not do good
enough job for handovers. We have the security requirements for
overall operation which also need to be followed here, but
specific formulas etc on the handovers are not baked yet. Part
of the reason for this is that we are lacking a specific fast handover
architecture, given that there are so many proposals. That's why
we have also split the document so that we can get the "existing
stuff" (e.g. 802.11) document out as soon as possible, and have
more time to complete the fancier handover key scenarios.

>
>Madjid>> "all parties"? Where is the mutual authentication between the NAS and AAA server enforced? RADIUS shared secret (SS)? If that
>
Yes.

> is the case then you can have 
>			SS1
>		LKDC----------AAA server
>			     	 /	 /
>		long term__/	/SS2
>		secret  /       /
>		       peer---- NAS
>
>
>
>and the "domino effect"
>Madjid>> Sending the AAA-key to each authenticator and reusing it by other authenticator as part of secure association generation with the peer causes "domino effect", no
>  
>
Yes, if the AAA-Key is same for all authenticators.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Apr 2005 11:55:23 -0700 (PDT)

> Yes, if the AAA-Key is same for all authenticators.

I think one issue is exactly what the definition of an "authenticator" is.

From the AAA perspective, an authenticator is defined by attributes such
as NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier.  One issue is
that a NAS may have more than one IP address (e.g. APs can be members of
multiple VLANs and will need an IP address on each VLAN).  So it seems
like NAS-Identifier is perhaps the best identifier to use for the purpose
of defining the NAS identity from the point of view of the EAP peer,
server and authenticator.

Assuming that the NAS advertises its NAS-Identifier to the peer, securely
confirms it in an exchange with the peer (such as in the Secure
Association Protocol) and sends this to the server, it is possible for the
EAP peer, server and authenticator to confirm that the NAS has accurately
represented its identity.  The peer and server can confirm that the NAS
has told them the same NAS-Identifier via Channel Bindings.

If the peer and server confirm the NAS-Identifier value told to them is
the same, then the peer can assume that the server has verified that the
NAS is not impersonating another NAS.  The key framework discusses how
this can be done -- it basically requires verification by the first hop
proxy.

Note that I believe it is outside the scope of the document to describe
what hardware configurations constitute a valid NAS.  That is, a large NAS
could involve multiple processors, could be a WLAN switch or a stand alone
AP, could come in a plastic box, a metal box or no box at all (wirewrap
board in the open air).  A single NAS could even be a cluster.

Obviously it is a good idea for the NAS to not leak keying material beyond
its boundaries.  But that leakage can occur via poor circuit design,
inadequate shielding, as well as security vulnerabilities within the AP
itself.  So I think it's out of scope to describe all the precautions that
should be taken.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap