Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA KeyCaching effectively prohibited?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 18 Jan 2006 17:43:28 -0500

Hi Kapil,

Thanks for the explanation. I actually happened to read D0.09 before
people sent me D1.0. Yes, I agree with your assessments below. However
two points:

1) Reading D0.09 I was not sure if the authenticator had to be in R0KH.
At least D0.09 was fuzzy on whether the authenticator is in R0KH or
R1KH. It seems that they had made that clear in D1.0. so I give up on
802.11r example. So based on what you are saying R0KH is an
authenticator and not "a trusted man-in-the middle"). 

2) The question for the EAP group, is: is it absolutely necessary to
send the MSK to the authenticator. I think in RFC 3748 that was an
optional thing. Here we follow on that and make it mandatory? We are
also saying authenticator and AAA client has the same identifier
(logically same) because MSK is carried over AAA protocol (AAA req.) and
because EAP needs to stay mode independent (EAP req.). I see this as a
restriction, why can't we allow MSK to go a key holder that is simply a
AAA client.
If during the initial authentication, the authenticator/ AAA client that
interacts with the peer indicates the ID of this key holder as an entity
that covers that whole domain (I believe it is called mobility domain in
802.11r), then sure we have a trusted man-in-the middle. Ok, 11r does
not have that because R0KH is the authenticator, but

Now the question is whether 802.11r handles R0KH handovers?

Thanks,

Madjid

-----Original Message-----
From: Sood, Kapil [mailto:[email-masked]] 
Sent: Saturday, January 14, 2006 11:43 AM
To: Nakhjiri Madjid-MNAKHJI1; Renwei Li; Jari Arkko; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA
KeyCaching effectively prohibited?

11r does not have a 'trusted' man-in-the-middle.  11r still bases its
security model on that the AAA Key (MSK) gets delivered to the
authorized Authenticator only.  This is the authenticator through which
the STA performed the full EAP authentication.  This is called R0 Key
holder (R0KH) in 11r draft.  R0KH derives the PMK-R0 from the MSK with
domain specific parameters binding.

R0KH also derives multiple PMK-R1 keys (11r key hierarchy) from the
PMK-R0, for distribution to other authenticators (called R1 key holders)
within the same administrative domain (called mobility domain in 11r).
A local trusted party (say, MDC - Mobility Domain Controller) helps
establish mutual authentication between these authenticators (key
holders in 11r) and derives mutual Key Encryption Keys (KEKs).  These
KEKs will be used for secure delivery of PMK-R1 keys from R0KH to R1KHs.
AAA server may not have any knowledge of this key hierarchy (by design),
and distribution.

Best Regards,
 
Kapil.
503.264.3759
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Thursday, January 12, 2006 5:11 PM
> To: Renwei Li; Jari Arkko; Bernard Aboba
> Cc: [email-masked]; [email-masked]
> Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA
KeyCaching effectively
> prohibited?
> 
> Not really sure what you mean by creating a scenario.  This is a real 
> life deployment. 11r has defined key holders.
> And what is wrong with trusted man in the middles?
> 
> -----Original Message-----
> From: Renwei Li [mailto:[email-masked]]
> Sent: Wednesday, January 11, 2006 7:00 PM
> To: Nakhjiri Madjid-MNAKHJI1; Jari Arkko; Bernard Aboba
> Cc: [email-masked]; [email-masked]
> Subject: Re: [eap] sending keys to authenticator?: was: Issue: AAA Key

> Caching effectively prohibited?
> 
> If we do so, we are effectively creating a scenario 
> (Authenticated-)Man-in-the-Middle? Sounds familiar?
> 
> Regards,
> 
> Renwei
> 
> 
> >-----Original Message-----
> >From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> >Sent: Wednesday, January 11, 2006 07:13 PM
> >To: 'Jari Arkko', 'Bernard Aboba'
> >Cc: [email-masked], [email-masked]
> >Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA
Key
> Caching	effectively prohibited?
> >
> >Question: Does EAP keying allow sending keys to an entity other than 
> >the initial authenticator, e.g. another AAA client or a key holder?
> >Or Does the EAP keying framework that prohibits keys being sent to an

> >entity other than the initial authenticator?
> >
> >
> >Thanks,
> >
> >Madjid
> >
> >-----Original Message-----
> >From: Jari Arkko [mailto:[email-masked]]
> >Sent: Saturday, November 05, 2005 6:34 PM
> >To: Bernard Aboba
> >Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked]
> >Subject: Re: [eap] RE: Issue: AAA Key Caching effectively prohibited?
> >
> >Bernard Aboba wrote:
> >
> >> Under Joe's proposal, an AMSK created during the original exchange 
> >> can
> >
> >> be cached in the AAA server.  One way that "Key Request" could work

> >> would be for the EAP peer to request that a key be sent to the new 
> >> authenticator.  It would make this request by contacting the new 
> >> authenticator, which would generate a AAA request. The EAP peer
would
> 
> >> mutually authenticate to the AAA server, demonstrate possession of 
> >> the
> >
> >> cached AMSK, and then request that a key derived from that AMSK be
> >> sent to the new EAP authenticator.   Via the AAA request the new
EAP
> >> authenticator would mutually authenticate to the AAA Server.
> >>
> >> So we have:
> >>
> >> a. Authentication of parties:  EAP peer- AAA server;  EAP 
> >> authenticator - EAP server;  EAP peer-authenticator (through a 
> >> subsequent SAP exchange)
> >>
> >> b. Freshness.  Presumably the EAP peer - AAA server exchange
includes
> 
> >> nonces exchanged by both parties to ensure freshness of the derived

> >> keys.  Also the SAP exchange would include a nonce exchange.
> >>
> >> c. "Channel binding":  The EAP peer requests that a key be sent via

> >> the entity that it wants the key sent to.  The new authenticator 
> >> identifies itself to the AAA server, allowing the EAP peer and AAA 
> >> server to verify that it is telling the same information to both
the
> >> AAA server and EAP peer.
> >
> >I like this. What do we need to make this possible in the keying 
> >framework?
> >
> >- Say EMSK is kept in method layer
> >
> >- Possibly say that EMSK can be deleted after AAA has made
> >  its declaration of what application keys its going to need
> >  (assuming we always know what applications are authorized
> >  a priori - but I think that's a good assumption).
> >
> >- Clarify the caching and parent death rules for AMSks.
> >
> >--Jari
> >
> >
> >_________________________________________________________________
> >To unsubscribe or modify your subscription options, please visit:
> >http://lists.frascone.com/mailman/listinfo/eap
> >
> >Arhives: http://lists.frascone.com/pipermail/eap
> >
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Clint Chaplin <[email-masked]>
Date: Thu, 19 Jan 2006 10:52:33 -0800

"Now the question is whether 802.11r handles R0KH handovers?"

Strictly speaking, 802.11r will require the transmission of keying
material from an R0KH to an R1KH.  Obviously, there are some security
requirements on this transmission, and we are putting there
requirements into the next version of the draft.

Actually specifying/ddeveloping such a handover mechanism is outside
the scope of  IEEE 802.11 TGr; we can only touch PHY and MAC. 
However, there is an engineerin team that has been formed to develop
such a mechanism, with the goal of creating an RFC.

--
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Jan 2006 18:26:18 -0800

>requirements into the next version of the draft.

IEEE 802.11rD1.0 supports a variety of handover techniques. 

These include "over the air" and "over the DS" modes.  The "over the DS"
mode allows the PTK to be established over the DS, and also enables the
PMK/PTK lifetime to be established as well as synchronization of key scope,
so it is more complete than IEEE 802.11i pre-authentication.  

As I understand it, a STA roaming within the Mobility Domain can expect
"fast BSS transition" services to be operative, but the quality of those
services may vary.  For example, if the handover is being done between TAPs
utilizing the same R1KH-ID (NAS-ID), then the PMK-R1 is likely to be
available on the TAP and handover is likely to be very fast. 

If a transition is within the MD but between different R1KH-IDs (but the
same R0KH-ID) then it is possible that the PMK-R1 has already been "pushed"
so that handover will be very fast.  However, it is also possible that the
PMK-R1 will need to be "pulled" in which case extra delays will result.

If a transition is within the MD but between different R0KH-IDs, then EAP
authentication will be needed.  However, I don't think this case really
makes much sense since a Mobility Domain is by definition the set of TAPs
within which handover is possible without EAP authentication.  That would
lead me to think that all TAPs within an MD should have the same R0KH-ID.
But perhaps this is a misunderstanding/wishfull thinking.  I am sure that
Clint will correct any portion of the above that is
mistaken/misguided/confused/insane.  
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: Clint Chaplin <[email-masked]>
Date: Sun, 22 Jan 2006 19:03:00 -0800

The current draft of IEEE 802.11r allows the use of multiple R0KH,
each of which can (and should!) have a different R0KH-ID.

I can think of at least one architecture where this might be
desirable: LWAPP style arcitecture where each switch had it's own
R0KH.