Subject: [HOKEY] Issue: EAP ERX use of MSK

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 11:45:02 -0700

Hi,

I see that ERP uses the result of initial EAP and the MSK for creation of
TSK initially and then get its own signaling started.

I think we should avoid using MSK all together, by kick starting root key
derivations right away. 

The way to signal this is pretty easy IMO (this should answer Vidya's
question in the other email on doing start messaging too):

When sending EAP Success and the MSK, the server can simply add a life time
of zero for the key, so that authenticator knows it needs to start ERX
process based on EMSK right away..

Madjid

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 15:03:15 -0700

Madjid,

Thanks for your comments.  Please see inline.

On 7/20/2007 11:45 AM, Madjid Nakhjiri wrote:
> Hi,
> 
> I see that ERP uses the result of initial EAP and the MSK for creation 
> of TSK initially and then get its own signaling started.

ERP does not "use the result of initial EAP and the MSK for creation of 
TSK."  Please point us to the text that contributed to your 
misunderstanding of ERP; we shall edit it immediately.  ERP has nothing 
to do with the creation of the initial TSK.  The peer and the 
authenticator use the result of the initial EAP exchange, the MSK, to 
create a TSK.

ERP also does not "get its own signaling started."  Either the peer or 
as Charles requested the authenticator may initiate ERP.

> 
> I think we should avoid using MSK all together, by kick starting root 
> key derivations right away.
> 

This is a bad idea.  The goal is to make things more efficient, not less.

regards,
Lakshminath

> When sending EAP Success and the MSK, the server can simply add a life 
> time of zero for the key, so that authenticator knows it needs to start 
> ERX process based on EMSK right away..
> 
>  
> 
> Madjid
> 
> 
> ------------------------------------------------------------------------
>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 15:09:14 -0700

Hi Lakshminath,

"3.  ERP Overview

   Figure 1 shows the protocol exchange.  The first time the peer
   attaches to an authenticator, it performs a full EAP exchange with
   the EAP server; as a result an MSK is distributed to the
   authenticator.  The MSK is then used by the authenticator and the
   peer to generate TSKs as needed.  At the time of the initial EAP
   exchange, the peer and the server derive a Re-authentication Root Key
   (rRK)...."

R,

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 3:03 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Issue: EAP ERX use of MSK

Madjid,

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 15:16:50 -0700

I am not sure I understand.  Where does it say what you said?

Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 15:31:27 -0700

>    as a result an MSK is distributed to the
>    peer to generate TSKs as needed.  

Not sure how else to read the doc..

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 3:17 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Issue: EAP ERX use of MSK

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 16:45:17 -0700

Madjid,

Please read my email and the I-D carefully before responding.  You are 
just not making sense at all.

best,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 20 Jul 2007 16:57:51 -0700

You know I have seen all kinds of responses, this one takes the cake.
At two instances, both in 3.1 and 5.1, you are stating that the first
authenticator gets MSK, and EMSK based keys kick in only at the second
authenticator.
 5.1 is even more clearer than that and I am saying it should not. If this
is still not clear, may be we move to another language, or is there
something I am missing.

Madjid

5.1.  ERP Bootstrapping

   The first time the peer attaches to an authenticator, it performs a
   full EAP exchange, which results in the MSK being distributed to the
   authenticator.  The MSK is then used by the authenticator as defined
   by specific lower layers.  At the time of the initial EAP exchange,
   the peer and the server also derive an EMSK.  Next, the peer and the
   server derive the rRK and the rIK as soon as the EMSK is available
   with the anticipation that ERP may be used by the peer if it plans to
   move to a new authenticator.

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 4:45 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Issue: EAP ERX use of MSK

Madjid,

best,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 18:25:15 -0700

There are two points to the exchange.  The first point is clear: you are 
proposing to throw away the MSK and I am saying there is no need to make 
things more inefficient.

On the other, the TSK reference simply describes current behavior; the 
ERP exchange has nothing to do with the TSK generation after the initial 
EAP exchange.

best,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 00:06:10 -0400

> I think we should avoid using MSK all together, by kick starting root key

I support Madjid's idea on kick starting root key derivation right
away.  However, I don't think use of zero lifetime for MSK is the
right solution to do it.  I rather suggest use of EAP-EXT method to do
it in initial EAP.  With use of EAP-EXT, ERP can be bootstrapped
within initial EAP, eliminating the need for ERP bootstrapping within
ERP which requires an ugly change to lower layers to keep using TSKs
generated from MSK after bootstrapping ERP, as described in Section
5.1.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 21:30:51 -0700

Yoshi,

You make a good point.  That part of the ERP bootstrapping probably 
needs work.  Any suggestions to the text itself?  I was thinking when I 
reread it that the lower layers I am aware of will start TSK derivation 
after the new MSK arrives.  Perhaps that will eliminate all the issues.

When we wrote that text, we were thinking of avoiding forcing the lower 
layer key exchange protocol unnecessarily.  That may not be as much a 
burden when it is run in a non-critical path.

Just thinking out loud here.

thanks,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 01:15:38 -0400

Lakshminath,

> after the new MSK arrives.  Perhaps that will eliminate all the issues.

I can think of lower-layer implementation which is robust against
re-authentication DoS attack in that until authorization lifetime for
initial auth is going to expire, an attacker can't start a
re-authentication ending up with a failure to just kick out the
connected peer.  The problem here is that ERP bootstrapping won't work
with such an implementation or ERP bootstrapping opens up
re-authentication DoS attack without such an implementation, both are
not desirable.

So my suggestion is to remove ERP bootstrapping feature from eap-erx
(this will make the document simpler), and use EAP-EXT method for
bootstrapping ERP instead.  I can work with you necessarly changes for
EAP-EXT method if you like it, but I guess you somehow don't like it.

Regards,
Yoshihiro Ohba

> >>time

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 22:42:22 -0700

Hi Yoshi,

Thanks for your notes.

> re-authentication DoS attack without such an implementation, both are

I am not sure I fully parsed the above properly, but let me restate so 
we are on the same page about the attack you are describing.  After full 
authentication, a malicious entity sends a bogus EAP Initiate Reauth 
message.  The authenticator of course passes it on and the server 
verifies the message and determines in the best case for the attacker 
that the integrity checksum is wrong.  The server returns an 
Access-Reject containing EAP Finish Reauth with the result flag set to 
failure.  The authenticator must behave as follows in that situation: if 
the MSK/rMSK lifetime has expired, it closes the connection with the 
peer.  If the MSK/rMSK is still valid, it should continue as if nothing 
has happened.

This would apply with or without the bootstrapping flag turned on.

I don't think that behavior is specified in the current version of the 
draft; we did a scan of the error behavior before the last revision, but 
it appears we have not captured all scenarios.

Or, did I completely misunderstand what you were saying.  If so, 
apologies; please try again.  Thanks in advance.

> EAP-EXT method if you like it, but I guess you somehow don't like it.

My understanding of the EAP-EXT method is that it is a wrapper around 
existing methods that do not generate EMSKs.  My recollection is that 
you were proposing it for that case.  Has it now been updated to include 
other scenarios?

The way I look at it is that if a method implementation does not support 
EMSK generation, well that method implementation should start being 
compliant with the RFCs.

If instead, you are suggesting that ERP bootstrapping is hopelessly 
broken and you have simple ideas for an alternative mechanism, I am 
definitely open to considering it provided that you can convince me that 
it is indeed broken.  I am sorry if I had given a different impression 
earlier.

I will be in Chicago tomorrow evening and we can discuss this topic at 
your convenience either before or after the HOKEY meeting.

best wishes,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 02:23:06 -0400

> peer.  If the MSK/rMSK is still valid, it should continue as if nothing 

Regardless of if the MSK/rMSK is still valid, it should close the
connection with the peer if the server returns an Access-Reject.
Otherwise, we will get into a lot of troubles with existing AAA
deployment.

> you were proposing it for that case.  Has it now been updated to include 

EAP-EXT method can be used regardless of whether methods generate
EMSKs or not.  When EMSKs are generated from methods, they are just
unused for that scenarios.  The MSKs generated from methods are always
used for generating EMSK in EAP-EXT instead.

> EMSK generation, well that method implementation should start being 

EAP-EXT is not just for EMSK generation.  It can be also used for
bootstrapping other features within initial EAP authentication,
including channel binding for MSK.

> it is indeed broken.  I am sorry if I had given a different impression 

I am not suggesting to have an alternate mechanism for ERP
bootstrapping within ERP.  In my analysis (if not wrong), ERP
bootstrapping within ERP is broken *and* not fixable unless ERP is
bootstrapped within initial EAP auth.

> your convenience either before or after the HOKEY meeting.

After the HOKEY meeting is most convinent for me.  

See you in Chicago,
Yoshihiro Ohba

> >>>>of

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 23:42:01 -0700

Actually, let us consider this:

Malicious Entity (ME) to Authenticator: EAPoL-Start
Authenticator to ME: EAP Request/Identity
ME to Authenticator: EAP Response/Identity (of a victim)
               Authenticator to Server: RADIUS Access-Request(EAP 
Response/Identity)
               Server to Authenticator: RADIUS 
Access-Challenge(Method-Message-1)
Authenticator to ME: EAP Request/Method-Message-1
ME to Authenticator: EAP Response/Method-Message-2
              Authenticator to Server: RADIUS 
Access-Request(Method-Message-2)
....
              Server to Authenticator: RADIUS Access-Reject(EAP Failure)

Doesn't the DoS attack exist today?  How is ERP different (other than 
requiring less work -- which is an unfortunate side effect of being 
efficient in the first place -- on the part of the malicious entity)?

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 02:48:15 -0400

> Malicious Entity (ME) to Authenticator: EAPoL-Start

A lower-layer implementation could discard EAPoL-Start if it were not
received, after successful initial EAP auth.  This is what I mentioned
about "robust lower-layer implementation" in a previous email.

Yoshihiro Ohab

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 20 Jul 2007 23:52:18 -0700

Hmmm, not sure I understand.

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 03:09:05 -0400

Oh, the first sentence should read:

"A lower-layer implementation could discard EAPoL-Start *as* if it
were not received, after successful initial EAP auth. "

This means that EAPoL-Start after successful initial EAP auth can be
filtered out for a while (e.g., until authorization life time is going
to be expired) to be robust against re-auth DoS attack.

Yoshihiro Ohba

On Fri, Jul 20, 2007 at 11:52:18PM -0700, Lakshminath Dondeti wrote:
> >>>>>>needs work.  Any suggestions to the text itself?  I was thinking when 
> >>>>>>I reread it that the lower layers I am aware of will start TSK 
> >>>>>>derivation after the new MSK arrives.  Perhaps that will eliminate 
> >>>>>>all the issues.
> >>>>we are on the same page about the attack you are describing.  After 
> >>>>full authentication, a malicious entity sends a bogus EAP Initiate 
> >>>>Reauth message.  The authenticator of course passes it on and the 
> >>>>server verifies the message and determines in the best case for the 
> >>>>attacker that the integrity checksum is wrong.  The server returns an 
> >>>>failure.  The authenticator must behave as follows in that situation: 
> >>>>if the MSK/rMSK lifetime has expired, it closes the connection with the 
> >>>>draft; we did a scan of the error behavior before the last revision, 
> >>>>but it appears we have not captured all scenarios.
> >>>>
> >>>>you were proposing it for that case.  Has it now been updated to 
> >>>>include other scenarios?
> >>>>The way I look at it is that if a method implementation does not 
> >>>>support EMSK generation, well that method implementation should start 
> >>>>being compliant with the RFCs.
> >>>>definitely open to considering it provided that you can convince me 
> >>>>that it is indeed broken.  I am sorry if I had given a different 
> >>>>impression earlier.
> >>>>>>When we wrote that text, we were thinking of avoiding forcing the 
> >>>>>>lower layer key exchange protocol unnecessarily.  That may not be as 
> >>>>>>much a burden when it is run in a non-critical path.
> >>>>>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 21 Jul 2007 00:25:08 -0700

Thanks for the clarification.  I guess it is late at night, and I am in 
the middle of some brainless administrative work, so I couldn't fill in 
the gap there.

So, whereas the AAA side of things may be slightly more problematic, one 
could argue that the lower-layer part of the authenticator SHALL ignore 
Access-Reject in the context of ERP (the Authenticator would know 
whether the exchange is EAP or ERP) until the lifetime expires to 
mitigate the DoS attack.  :)

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 03:52:20 -0400

> mitigate the DoS attack.  :)

I am taking your suggested mitigation just as a late-night joke that
screws up whole existing EAP/AAA deployment.

Yoshihiro Ohba

> >>>>>>>>needs work.  Any suggestions to the text itself?  I was thinking 
> >>>>>>>>when I reread it that the lower layers I am aware of will start TSK 
> >>>>>>I am not sure I fully parsed the above properly, but let me restate 
> >>>>>>so we are on the same page about the attack you are describing.  
> >>>>>>After full authentication, a malicious entity sends a bogus EAP 
> >>>>>>Initiate Reauth message.  The authenticator of course passes it on 
> >>>>>>and the server verifies the message and determines in the best case 
> >>>>>>for the attacker that the integrity checksum is wrong.  The server 
> >>>>>>returns an Access-Reject containing EAP Finish Reauth with the result 
> >>>>>>flag set to failure.  The authenticator must behave as follows in 
> >>>>>>that situation: if the MSK/rMSK lifetime has expired, it closes the 
> >>>>>>connection with the peer.  If the MSK/rMSK is still valid, it should 
> >>>>>>continue as if nothing has happened.
> >>>>>>I don't think that behavior is specified in the current version of 
> >>>>>>the draft; we did a scan of the error behavior before the last 
> >>>>>>revision, but it appears we have not captured all scenarios.
> >>>>>>
> >>>>>>I will be in Chicago tomorrow evening and we can discuss this topic 
> >>>>>>at your convenience either before or after the HOKEY meeting.
> >>>>>>>>lower layer key exchange protocol unnecessarily.  That may not be 
> >>>>>>>>as much a burden when it is run in a non-critical path.
> >>>>>>>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 21 Jul 2007 08:39:21 -0700

Sure :).  Although, I would be curious about exactly does it screw up 
existing anything.  Would it disrupt existing operation?  I'd think not! 
  When the ERP code is added to Authenticators, there will be a patch 
and that patch can take care of something like this.  I am even thinking 
that the "hack-factor" of this is pretty low.

Anyway, let's talk more face to face.  My flight leaves in a couple of 
hours from now.

best,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 21 Jul 2007 08:42:17 -0700

One additional issue here.  What if the peer lost state and is trying to 
send legitimate EAPoL-Start messages?  The authenticator would keep 
dropping them and unintentionally deny service.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 12:55:04 -0400

> dropping them and unintentionally deny service.

If the peer lost state due to, e.g., out of radio coverage, then lower
layer should be able to detect it and delete all state associated with
the peer.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Jul 2007 13:23:26 -0400

> that the "hack-factor" of this is pretty low.

It seems you are not just joking.  Then I strongly disagree with your
thinking.  When the AAA server rejects the access, the AAA server and
AAA client delete all associated state that was created for the
network access client during initial authentication, and the AAA
client sends all outstanding accounting records if any, to accounting
server.  This way, per-network-access-client state synchronization is
maintained among AAA nodes.  Since not only lower layer behavior but
also all those AAA behavior need to be changed (and I have no idea on
how the AAA behavior can be changed), the "hack-factor" is too big to
be adopted in real deployment.

Yoshihiro Ohba

> >>>>>>>>>>You make a good point.  That part of the ERP bootstrapping 
> >>>>>>>>>>probably needs work.  Any suggestions to the text itself?  I was 
> >>>>>>>>>>thinking when I reread it that the lower layers I am aware of 
> >>>>>>>>>>will start TSK derivation after the new MSK arrives.  Perhaps 
> >>>>>>>>>>that will eliminate all the issues.
> >>>>>>>>returns an Access-Reject containing EAP Finish Reauth with the 
> >>>>>>>>result flag set to failure.  The authenticator must behave as 
> >>>>>>>>follows in that situation: if the MSK/rMSK lifetime has expired, it 
> >>>>>>>>closes the connection with the peer.  If the MSK/rMSK is still 
> >>>>>>>>valid, it should continue as if nothing has happened.
> >>>>>>>>My understanding of the EAP-EXT method is that it is a wrapper 
> >>>>>>>>around existing methods that do not generate EMSKs.  My 
> >>>>>>>>recollection is that you were proposing it for that case.  Has it 
> >>>>>>>>now been updated to include other scenarios?
> >>>>>>>>support EMSK generation, well that method implementation should 
> >>>>>>>>start being compliant with the RFCs.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 22 Jul 2007 14:28:59 -0700

Going out of radio coverage is just one example, but for whatever reason 
the peer may lose state and should be able to use EAPoL-start to redo 
the EAP authentication.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 22 Jul 2007 14:35:44 -0700

This is becoming an important topic in my head.  Perhaps I am making an 
obvious mistake, but if Access-Reject tears down a perfectly good 
connection (when the subscription of the peer is still valid and the 
previously distributed MSK and the associated lifetime are still valid), 
we may have a problem.  There is a DoS attack there with full EAP 
authentication (I don't consider the work around of lower layers 
discarding EAPoL-start or equivalent until the authenticator thinks the 
session has expired as robust) or reauthentication.

best,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 22 Jul 2007 17:43:46 -0400

> the peer may lose state and should be able to use EAPoL-start to redo 

Sure.  But in that case, the authenticator also would lose its state
based on detection of lower layer disconnection, whatever the reason
for disconnection.  After that, EAPoL-start should always be processed
No problem here.  

On the contrary, in the case of ERP bootstrapping, the authenticator
*has* a state for the peer, and accepting EAPoL-start immediately
after successful initial EAP auth will lead to re-auth DoS attack, as
I explained in previous emails.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 22 Jul 2007 14:46:05 -0700

> for disconnection.  After that, EAPoL-start should always be processed

But, why do you assume that the state loss has to do with lower layer 
disconnection?

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 22 Jul 2007 18:06:39 -0400

On Sun, Jul 22, 2007 at 02:35:44PM -0700, Lakshminath Dondeti wrote:
> we may have a problem.  

ERP bootstrapping is the cause of the problem.  The rest of the AAA
system is just doing the right thing.  I already suggested a remedy
for it.

> There is a DoS attack there with full EAP 

Another workaround would be to add a flag to EAPoL-start to indicate
this EAP is for ERP bootstrapping.  I am sure no one will take that
idea :)

Yoshihiro Ohba

> >>>>So, whereas the AAA side of things may be slightly more problematic, 
> >>>>one could argue that the lower-layer part of the authenticator SHALL 
> >>>>ignore Access-Reject in the context of ERP (the Authenticator would 
> >>>>know whether the exchange is EAP or ERP) until the lifetime expires to 
> >>>>>>>>Doesn't the DoS attack exist today?  How is ERP different (other 
> >>>>>>>>than requiring less work -- which is an unfortunate side effect of 
> >>>>>>>>being efficient in the first place -- on the part of the malicious 
> >>>>>>>>entity)?
> >>>>>>>>
> >>>>>>>>regards,
> >>>>>>>>Lakshminath
> >>>>>>>>
> >>>>>>>>>>>>probably needs work.  Any suggestions to the text itself?  I 
> >>>>>>>>>>>>was thinking when I reread it that the lower layers I am aware 
> >>>>>>>>>>>>of will start TSK derivation after the new MSK arrives.  
> >>>>>>>>>>>>Perhaps that will eliminate all the issues.
> >>>>>>>>>>I am not sure I fully parsed the above properly, but let me 
> >>>>>>>>>>restate so we are on the same page about the attack you are 
> >>>>>>>>>>describing.  After full authentication, a malicious entity sends 
> >>>>>>>>>>a bogus EAP Initiate Reauth message.  The authenticator of course 
> >>>>>>>>>>passes it on and the server verifies the message and determines 
> >>>>>>>>>>in the best case for the attacker that the integrity checksum is 
> >>>>>>>>>>wrong.  The server returns an Access-Reject containing EAP Finish 
> >>>>>>>>>>Reauth with the result flag set to failure.  The authenticator 
> >>>>>>>>>>must behave as follows in that situation: if the MSK/rMSK 
> >>>>>>>>>>lifetime has expired, it closes the connection with the peer.  If 
> >>>>>>>>>>the MSK/rMSK is still valid, it should continue as if nothing has 
> >>>>>>>>>>happened.
> >>>>>>>>>>I don't think that behavior is specified in the current version 
> >>>>>>>>>>of the draft; we did a scan of the error behavior before the last 
> >>>>>>>>>>If instead, you are suggesting that ERP bootstrapping is 
> >>>>>>>>>>hopelessly broken and you have simple ideas for an alternative 
> >>>>>>>>>>mechanism, I am definitely open to considering it provided that 
> >>>>>>>>>>you can convince me that it is indeed broken.  I am sorry if I 
> >>>>>>>>>>had given a different impression earlier.
> >>>>>>>>>>I will be in Chicago tomorrow evening and we can discuss this 
> >>>>>>>>>>topic at your convenience either before or after the HOKEY 
> >>>>>>>>>>meeting.
> >>>>>>>>>>>>When we wrote that text, we were thinking of avoiding forcing 
> >>>>>>>>>>>>the lower layer key exchange protocol unnecessarily.  That may 
> >>>>>>>>>>>>not be as much a burden when it is run in a non-critical path.
> >>>>>>>>>>>>

---

From: Charles Clancy <[email-masked]>
Date: Mon, 23 Jul 2007 01:32:04 +0100

Captured as issue 15 ... sort of.  I think Yoshi's comments are a little 
broader than Madjid's original issue.

Are we talking about explicit bootstrapping, where a re-auth is executed 
immediately after an initial EAP auth?  I assume this doesn't apply to 
implicit bootstrapping?

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc

Madjid Nakhjiri wrote:
> The way to signal this is pretty easy IMO (this should answer Vidya’s

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 23 Jul 2007 01:35:38 -0400

On Sun, Jul 22, 2007 at 02:46:05PM -0700, Lakshminath Dondeti wrote:
(snip)
> But, why do you assume that the state loss has to do with lower layer 

It has to, because the state is associated with lower-layer.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 23 Jul 2007 04:57:13 -0700

Ok, I think there is some confusion here about the EAP lower layer and 
link layer; at least I had been using it to mean both things.  I am 
contending that the link doesn't have to be terminated.

More on this at the meeting today.  Hopefully we can get on the same 
page there.

best,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 23 Jul 2007 11:41:44 -0700

Hi,

TSKs are generated based on the key that is delivered to the authenticator,
so I am responding to what you state as a first point: 

I suggest you take a look 802.16e spec for the MSK based key hierarchy.
When adopting HOKEY key hierarchy for future link layers, I don't think
people would like to have two parallel key hierarchies depending on whether
it is the first or second authenticator.

So the point on inefficiency is actually goes back to developing a spec that
has two parallel hierarchy, not just an additional roundtrip during initial
network access, simply because we don't want to deal with a little of
inconvenience of fixing the current design.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 6:25 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Issue: EAP ERX use of MSK

best,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 24 Jul 2007 08:01:22 -0700

Madjid,

It is the same hierarchy, starts at the LTC+EAP Method :).

The "MSK" for an authenticator comes from various sources in that 
hierarchy:  MSK, EMSK->USRK->MSK, EMSK->DSRK->DSUSRK->MSK.  Given that, 
trying to get rid of the MSK has no basis.  The design is not broken; no 
fixing necessary.

regards,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 24 Jul 2007 09:11:35 -0700

Obviously my message is not getting through. I suggest you take a look at
802.16e spec.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 8:01 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Issue: EAP ERX use of MSK

Madjid,

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 24 Jul 2007 09:22:45 -0700

Which section, page?  By the way, you may find my name among the 
hundreds of people who were part of that effort.

best,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 24 Jul 2007 11:41:51 -0700

Well, then you don't need the page and section number. You should be able to
find exactly where to find it or know the section number by heart! 

The key hierarchy encompasses both EAP and RSA. The EAP branch only includes
MSK delivered to authenticator.
Your solution of delivering an MSK to the initial authenticator and then
another key (called rMSK or whatever) for the second authenticator (after
handover) is just bad and calling it efficient is simply absurd. I am sorry
I am loosing patience about the way discussions on technical constructive
comments/ suggestions on WG document are carried out. 

I thought the purpose of this work to take a top-down big picture approach
at the EAP (at least that was part of the initial marketing), not create a
spec that requires people to create two branch in the hierarchy, just
because the protocol does not have a clean bootstrapping of the
authenticator keys, following the EAP authentication.

What I am saying is finish EAP, but do not deploy MSK at the authenticator
for TSKs, not sure why an effort that is taking "a top down approach" does
not want to create a spec that people in SDOs actually want to use for their
link layers for the sake of getting a draft out two weeks sooner..

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 9:23 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] Issue: EAP ERX use of MSK

best,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 24 Jul 2007 12:29:56 -0700

Charles, Glen,

Unfortunately, this discussion seems to be going nowhere (perhaps Madjid 
and I agree on that).  If others in the WG think that there is a reason 
to throw away the MSK from the initial authentication, I would like to 
hear a case for it.  Using the MSK is status quo and so the burden is on 
the people who want to make the argument to throw a perfectly good key 
away.  Thoughts?

Yoshi and I had an offline chat on the DoS attack thread and I hope to 
talk to him again later in the work and come to a common understanding 
of the problem, and hopefully come to a consensus way forward.

best,
Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 24 Jul 2007 14:58:33 -0700

Well, if you don't want to continue the discussion that is another thing,
but my issue still remains.

 the way I interpret it, your justification of use of MSK by simply calling
it "efficient" is not adequate given the burden of specifying and
implementing two key hierarchies before and after handover/
re-authentication in a link layer SDO.

If you feel MSK is a perfectly good key, well it was a good key until we
started passing it around, but joking aside, then may be we should go
revisit why we are using EMSK instead MSK if MSK is a perfectly a good key??
Is that what you are suggesting?

And status quo??? Should I even respond? Doing EAPV2 on signaling, while
using MSK for status quo?

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 12:30 PM
To: Charles Clancy; Glen Zorn (gwz)
Cc: [email-masked]
Subject: Re: [HOKEY] Issue: EAP ERX use of MSK

Charles, Glen,

best,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Jul 2007 15:11:35 -0700

I'm completely lost on where this discussion is going.  One of the
fundamental principles I've been applying to the work in HOKEY is that
we are not re-defining or modifying any existing EAP behavior here.
This basically points to the fact that the MSK will be passed to the
lower layer as done today in EAP and we don't mess with it.  If the peer
stays at the same authenticator and performs ERP (bootstrapping or
regular exchange) via that same authenticator, an rMSK will be available
to it at the end of that exchange.  The lower layer, based on its
policies may choose to use it immediately or not - the MSK may still be
considered valid and be used or once a new key is available, the lower
layer may switch to using the new key.  

So, I have a hard time understanding how we have any room to propose
modifying the MSK use or behavior at this point.  And, as to the
symmetry in the branch of the key hierarchy from which the key delivered
to the authenticator comes, it is totally irrelevant to the
authenticator.  So, I don't understand that either.  

I don't think discussing modifications to MSK use here is going to be
useful for anything.  

Vidya

> From: Madjid Nakhjiri [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 11:42 AM
> To: Dondeti, Lakshminath
> Cc: [email-masked]
> Subject: RE: [HOKEY] Issue: EAP ERX use of MSK
> 
> Well, then you don't need the page and section number. You 
> should be able to find exactly where to find it or know the 
> section number by heart! 
> 
> The key hierarchy encompasses both EAP and RSA. The EAP 
> branch only includes MSK delivered to authenticator.
> Your solution of delivering an MSK to the initial 
> authenticator and then another key (called rMSK or whatever) 
> for the second authenticator (after
> handover) is just bad and calling it efficient is simply 
> absurd. I am sorry I am loosing patience about the way 
> discussions on technical constructive comments/ suggestions 
> on WG document are carried out. 
> 
> I thought the purpose of this work to take a top-down big 
> picture approach at the EAP (at least that was part of the 
> initial marketing), not create a spec that requires people to 
> create two branch in the hierarchy, just because the protocol 
> does not have a clean bootstrapping of the authenticator 
> keys, following the EAP authentication.
> 
> What I am saying is finish EAP, but do not deploy MSK at the 
> authenticator for TSKs, not sure why an effort that is taking 
> "a top down approach" does not want to create a spec that 
> people in SDOs actually want to use for their link layers for 
> the sake of getting a draft out two weeks sooner..
> 
> 
> Which section, page?  By the way, you may find my name among 
> the hundreds of people who were part of that effort.
> 
> best,
> Lakshminath
> 
> > Obviously my message is not getting through. I suggest you 
> take a look 
> > at 802.16e spec.
> > 
> > Madjid
> > 
> > hierarchy:  MSK, EMSK->USRK->MSK, EMSK->DSRK->DSUSRK->MSK.  Given 
> > that, trying to get rid of the MSK has no basis.  The design is not 
> > broken; no fixing necessary.
> > 
> > regards,
> > Lakshminath
> > 
> >> When adopting HOKEY key hierarchy for future link layers, I don't 
> >> think people would like to have two parallel key hierarchies 
> >> depending on
> > whether
> >> So the point on inefficiency is actually goes back to developing a 
> >> spec
> > that
> >> There are two points to the exchange.  The first point is 
> clear: you 
> >> are proposing to throw away the MSK and I am saying there 
> is no need 
> >> to make things more inefficient.
> >>
> >> On the other, the TSK reference simply describes current behavior; 
> >> the ERP exchange has nothing to do with the TSK generation 
> after the 
> >> initial EAP exchange.
> >>
> >> best,
> >> Lakshminath
> >>
> >>> At two instances, both in 3.1 and 5.1, you are stating that the 
> >>> first authenticator gets MSK, and EMSK based keys kick in only at 
> >>> the second authenticator.
> >>>  5.1 is even more clearer than that and I am saying it 
> should not. 
> >>> If
> > this
> >>> Please read my email and the I-D carefully before 
> responding.  You 
> >>> are just not making sense at all.
> >>>
> >>> best,
> >>> Lakshminath
> >>>
> >>>>>    exchange, the peer and the server derive a Re-authentication 
> >>>>> Root
> > Key
> >>>>>    (rRK)...."
> >>>>>
> >>>>>
> >>>>> R,
> >>>>>
> >>>>> Madjid
> >>>>>
> >>>>> ERP does not "use the result of initial EAP and the MSK for 
> >>>>> creation
> of
> > 
> >>>>> authenticator use the result of the initial EAP 
> exchange, the MSK, 
> >>>>> to create a TSK.
> >>>>>
> >>>>>> I think we should avoid using MSK all together, by 
> kick starting 
> >>>>>> root
> 
> >>>>> This is a bad idea.  The goal is to make things more efficient, 
> >>>>> not
> >> less.
> >>>>> regards,
> >>>>> Lakshminath
> >>>>>
> >>>>>> When sending EAP Success and the MSK, the server can 
> simply add a
> life
> > 
> >>>>>> time of zero for the key, so that authenticator knows 
> it needs to
> > start

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 25 Jul 2007 09:44:56 -0700

Sorry to hear that. The GPS tracking device is right in the thread in this
email. At the bottom, the authors say multiple times that the draft is NOT
saying MSK is sent to the first authenticator, then you moved into a desire
for status quo and saying your fundamental principle is to not change EAP
behavior?? I did not think keeping EAP behavior means forcing a client into
a re-authentication to get the key it needs to install to secure its link?

Again, the message is simple: use one key hierarchy for all authenticators.
As I recall, while I was leading the BoF work we had a debate on whether to
base the hierarchy on MSK or EMSK and we even called it "consensus" to use
EMSK. Should we revisit that now?

I just gave you guys a simple solution of sending MSK down with zero life
time as a trigger to start EMSK-based derivation and keying signaling, good
or bad suggestion, may be we should work on the engineering rather debating?

I don't think anywhere in 3748 it is mentioned YOU MUST send MSK to
authenticator and use it for TSK. They actually talk about AAA key! 
3748 says

Master Session Key (MSK)
      Keying material that is derived between the EAP peer and server
      and exported by the EAP method.  The MSK is at least 64 octets in
      length.  In existing implementations, a AAA server acting as an
      EAP server transports the MSK to the authenticator.

The MSK and EMSK MUST NOT be used directly to protect data; however,
   they are of sufficient size to enable derivation of a AAA-Key
   subsequently used to derive Transient Session Keys (TSKs) for use
   with the selected ciphersuite.  Each ciphersuite is responsible for
   specifying how to derive the TSKs from the AAA-Key.

Further, the IETF never defined anything below MSK, that is the job of the
SDOs, at least it has been so far, so that is moot.

I don't know what symmetry you are talking about.

And BTW as far as the fundamental principle of not changing EAP, how does
that jive with changing EAP state machine??  

Madjid

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 3:12 PM
To: Madjid Nakhjiri; Dondeti, Lakshminath
Cc: [email-masked]
Subject: RE: [HOKEY] Issue: EAP ERX use of MSK

Vidya

---

From: Charles Clancy <[email-masked]>
Date: Wed, 25 Jul 2007 16:29:58 -0400

Using the EMSK as the hierarchy root doesn't necessarily affect the 
initial EAP authentication.  By leaving the first EAP authentication 
unchanged, we allow for legacy clients.  If a client doesn't want to (or 
can't) do HOKEY, it doesn't have to initiate the bootstrap.

If the network has some way of knowing the client supports HOKEY, then 
perhaps we can optimize away the bootstrap, but I think this would 
require using a specialized EAP method during the initial 
authentication, such as EAP-EXT.

---

From: <[email-masked]>
Date: Wed, 25 Jul 2007 23:49:40 +0300

Inline pl. 

Preeti

>From: ext Charles Clancy [mailto:[email-masked]] 
>Sent: 25 July, 2007 23:30
>To: Madjid Nakhjiri
>Cc: [email-masked]
>Using the EMSK as the hierarchy root doesn't necessarily 
>affect the initial EAP authentication.  By leaving the first 
>EAP authentication unchanged, we allow for legacy clients.  If 
>a client doesn't want to (or

Perhaps derivation of EMSK may not affect the initial authentication,
but sustainability of EMSK will very much depend on  MSK/PMK lifetime
decided during initial authentication. Hence operation of EMSK very much
influenced by the initial EAP authentication. So although it is feasible
for authenticator to have two different heirarchy the management of
states of the two different statemachine may bring some complexity.     

>
>If the network has some way of knowing the client supports 
>HOKEY, then perhaps we can optimize away the bootstrap, but I 
>think this would require using a specialized EAP method during 
>the initial authentication, such as EAP-EXT.
>
>--
>>>>> has two parallel hierarchy, not just an additional 
>roundtrip during
>>>> initial

---

From: Charles Clancy <[email-masked]>
Date: Wed, 25 Jul 2007 16:58:33 -0400

> states of the two different statemachine may bring some complexity.     

The authenticator needs to handle two different types of hierarchies 
because it may have two different types of clients -- legacy and 
HOKEY-enabled.  An initial authentication would result in a legacy 
hierarchy, and would be replaced with the HOKEY hierarchy after the 
bootstrap was performed.  I don't see any additional complexity over 
what the authenticator would already need to provide to support 
different types of clients.

I don't see a problem with limiting the lifetime of the MSK -- however 
the EAP server needs to know whether the client supports HOKEY, so it 
knows whether to give the MSK a short, or a normal lifetime.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc
adjunct professor, electrical engineering, university of maryland

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 26 Jul 2007 11:24:34 -0700

The way it looks like currently even a HOKEY client has to install two key
hierarchies before and after handover. My issue was not about two different
kind of clients. That is a separate but very valid issue.