Subject: Re: [HOKEY] 3 party protocol and EAP-ER

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 21 Mar 2007 08:52:03 -0700 (PDT)

Hi Dan,

I have long harbored doubts about the use of 2-party EAP-ER in re-auth with a Hokey server that is different (and possibly in a different domain) from the EAP server with which the original full EAP method was done.  The protocol you outline, which is a modified version of the one in draft-ohba, looks like it will work without any additional messaging. This is great news, if indeed it can be shown to be secure even without the party B's nonce (Hokey server's).  We still have to work out at the lower layer probably, how the Peer will know the Hokey server's id, but other than that it something that can be overlayed with relative ease.
Count one happy camper....

Michaela

----- Original Message ----
From: Dan Harkins <[email-masked]>
To: [email-masked]
Sent: Wednesday, March 21, 2007 6:16:50 AM
Subject: [HOKEY] 3 party protocol and EAP-ER

Hi,

  At the end of the HOKEY meeting on Monday there seemed to be a feeling
that there were two camps with competing and incompatible proposals. I
believe that feeling is incorrect.

  I spoke with Vidya, Lakshminath, and Madjid (separately but the same
discussion) and they all agree that we are very close. I would like to
demonstrate how a 3 party key distribution can be performed in the
EAP-ER exchange.

  EAP-ER looks roughly like this (and apologies to the authors if I get
something wrong):

  |<--------------- EAP ------------------------------------------>|
                                       |<--------- AAA ----------->|

   Peer                          Authenticator                  Server

  peer-id, [counter]rki
          ----------------------->   peer-id, [counter]rki
                                          ------------------------->

                                                   [finish]rki, {key}foo
                                     <------------------------------
               [finish]rki
     <-----------------------------

The peer sends all his stuff as a new EAP code. That gets put into a
AAA request by the authenticator who sends it to the server in the
traditional fashion. The server sends his finished message, using another
new EAP code, as an EAP msg attribute and the key in something like the
aes-key-wrap attribute using a key from the security association that the
server already shares with the authenticator, denoted as 'foo').
Other attributes assigned to that key's context are not shown for
simplicity but are assumed to be there. The authenticator gets this EAP
msg and forwards it onto the peer in the traditional fashion.

  This is how EAP-ER performs a secure 3 party protocol (note that the
protocol might not be absolutely correct but any changes that may be
necessary to ensure its security should not impact this):

  peer-id, {peer-id, auth-id,
            counter}rke
     ------------------------------>
                                      {peer-id, auth-id}foo,
                                      {peer-id, auth-id, counter}rke
                                    ---------------------------------->

                                      {counter+1, peer-id, auth-id}rke,
                                      {key}foo
                                    <----------------------------------
                {counter+1, peer-id,
                 auth-id} rke
     <------------------------------

Same new EAP code in peer's message. Same new EAP code in server's
response. Same conversion of EAP message to AAA attribute and back
again. I have introduced only 1 new term and that is auth-id. I would
like to point out that auth-id is going to be known by the peer and
the server because they have to generate a key in the key hierarchy that
is bound to that identity. So auth-id is not used in EAP-ER today but
for HOKEY to work that identity must be known so my introduction of it
into this protocol should not cause anyone any heartburn.

  I don't describe the necessary behavior of the server but it should
be obvious and it isn't really germane to this demonstration.

  This exchange doesn't have the server nonce which I wanted in the
"modified Otway-Rees" but it was not absolutely critical. The reason it
cannot be in this protocol is that the authenticator doesn't speak EAP
and most likely the only packets/frames it is sending to and receiving
from the peer are an encapsulation of the EAP packet, e.g. 802.1x, such
that it can be transmitted. It can't add anything to the message without
breaking things.

  What this provides is identity confirmation by all parties involved.
When the protocol finishes all parties know it finished and if it
finishes successfully they will all agree on that point. It is not
possible for someone to convince one party that the protocol finished
in a different state than the others think and it is not possible for
one of the parties to lie about his or her identity assuming the keys
used-- rki/rke, foo-- are unique and bound to the identities being used
in the protocol (which is not an unreasonable assumption and is, in fact,
necessary for good crypto hygiene). The peer gives consent to the
exchange by contributing the necessary data to initiate the protocol.

  As I said, this might not be 100% correct (I want to refer to my
notes for the secure 3 party protocol) but differences should slip right
in to it without any substantial changes.

  Any issues with EAP-ER (the state machine weirdness where the response
to an identity request is not an identity response, the requirement that
the authenticator change, etc) are unaffected by this addition. All that
happened was that the key distribution was secured.

  Please take a look. If anyone thinks there are still 2 opposing camps
with differing proposals please let me know.

  And if you will indulge my channelling of Rodney King I'd like to
end by asking, "can't we all just get along?"

  thanks,

  Dan.

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

____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 21 Mar 2007 10:00:37 -0700

Michaela,

What are you saying?  If you are saying that the protocol specified in 
the EAP-ER draft has security issues, please outline them here.  It is 
not constructive to simply say that you have doubts.

Dan is merely illustrating that there aren't really two camps.  The two 
approaches are merely two different ways of doing things.  The two 
approaches may indeed have different properties.

I have analyzed EAP-ER and stand by its correctness.  Does it mean there 
is no possibility of vulnerabilities?  I have never said that.  But, if 
there are concerns, please explain them clearly.

I haven't analyzed the protocol Dan wrote up.  I shall do that soon and 
continue offline discussions with Dan to see if we can converge here.  I 
encourage others to do the same and list any properties of interest.

regards,
Lakshminath

M. Vanderveen wrote:
> Hi Dan,
>  
> I have long harbored doubts about the use of 2-party EAP-ER in re-auth 
> with a Hokey server that is different (and possibly in a different 
> domain) from the EAP server with which the original full EAP method was 
> done.  The protocol you outline, which is a modified version of the one 
> in draft-ohba, looks like it will work without any additional messaging. 
> This is great news, if indeed it can be shown to be secure even without 
> the party B's nonce (Hokey server's).  We still have to work out at the 
> lower layer probably, how the Peer will know the Hokey server's id, but 
> other than that it something that can be overlayed with relative ease.
> ------------------------------------------------------------------------
> Sucker-punch spam < 
> http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html> 
> with award-winning protection.
> Try the free Yahoo! Mail Beta. < 
> http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html>
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 21 Mar 2007 10:32:37 -0700 (PDT)

Laksminath,

  Relax, no one is calling your baby ugly.

  EAP-ER has channel binding issues that have been explained up down and
sideways. In addition, it is not possible to apply a 2 party model to
this. Glen always says that EAP is a 2 party protocol and that the
separation of the AS and NAS is not necessarily physical so it is a
2 party model. While I have issues with that statement I will, for the
purposes of making a different point, temporarily concede that issue.
The different point being that the other authenticator IS a different
physical entity. The NAS and AS may be "one" but there is now another
NAS. There are now 3 parties. You can't use a security model developed
for a 2 party protocol here.

  Dan.

P.S. I now recind my temporary concession of Glen's assertion of a 2
party model.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 21 Mar 2007 10:55:42 -0700

Dan,

I have sent another email responding to your first message.  Agreeing in 
general.

Regarding channel binding, yep I agree that is a problem to solve. 
Several solutions have been discussed on the EAP list on that topic and 
I am sure we can find common ground in HOKEY.

Anyway, let us enjoy the common ground before getting too deep into the 
next round of debates.

thanks,
Lakshminath

---

From: "Charles Clancy" <[email-masked]>
Date: Thu, 22 Mar 2007 04:12:14 -0400 (EDT)

> I am sure we can find common ground in HOKEY.

The problem statement draft currently includes a requirement to provide
channel bindings, so I don't think there's any argument that it's a
problem we intend to solve.

Glen and I are distilling the issues down into a couple key questions
regarding possible additions to the list of protocol requirements in the
problem statement, and will be sending them to the list in the next couple
days.  Hopefully this recent convergence will make the derived consensus
stronger.

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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sat, 24 Mar 2007 03:23:24 -0700

Hi Dan,
 
I have long harbored doubts about the use of 2-party EAP-ER in re-auth
with a Hokey server that is different (and possibly in a different
domain) from the EAP server with which the original full EAP method was
done.  The protocol you outline, which is a modified version of the one
in draft-ohba, looks like it will work without any additional messaging.
This is great news, if indeed it can be shown to be secure even without
the party B's nonce (Hokey server's).  We still have to work out at the
lower layer probably, how the Peer will know the Hokey server's id, but
other than that it something that can be overlayed with relative ease. 
Presumably the hokey server ID can be ascertained after network access
has been allowed, but not the (new) NAS ID.  I really hate to throw cold
water on this developing love-fest, but this is not a minor problem: I
know of no wireless systems - not WiFi, nor WiMax nor  ... that actually
advertises the NAS identity.  If you think that 802.11 for example is
going to be modified so our lovely 3-party protocol will work, well,
think again.  I, for one, have no desire wasting my time on work that is
undeployable, so if we actually want to use a 3-party protocol it had
better solve the problem of secure identity advertisement as well, with
no hand-waving about the EAP lower layer...
Count one happy camper....
 
Michaela

----- Original Message ----
From: Dan Harkins <[email-masked]>
To: [email-masked]
Sent: Wednesday, March 21, 2007 6:16:50 AM
Subject: [HOKEY] 3 party protocol and EAP-ER

Hi,

  peer-id, [counter]rki

                                                   [finish]rki, {key}foo

The peer sends all his stuff as a new EAP code. That gets put into a
AAA request by the authenticator who sends it to the server in the
traditional fashion. The server sends his finished message, using
another
new EAP code, as an EAP msg attribute and the key in something like the
aes-key-wrap attribute using a key from the security association that
the
server already shares with the authenticator, denoted as 'foo').
Other attributes assigned to that key's context are not shown for
simplicity but are assumed to be there. The authenticator gets this EAP
msg and forwards it onto the peer in the traditional fashion.

in the protocol (which is not an unreasonable assumption and is, in
fact,

  thanks,

  Dan.

________________________________

Sucker-punch spam
<http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/m
ailbeta/features_spam.html>  with award-winning protection.
Try the free Yahoo! Mail Beta.
<http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/m
ailbeta/features_spam.html> 
_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 26 Mar 2007 07:05:38 -0700 (PDT)

Glen,

  As I point out in my post below I'm not adding any new requirements
onto what was already there.

  Take a step back from the 3-party protocol for a second. The peer
and the HOKEY server are each going to be independently generating
keys in their key heirarchies. The HOKEY server will be distributing
keys out of its. For the purposes of key separation and key naming
something unique about each authenticator (each recipient of a key from
the HOKEY server) is going to be mixed into the key derivation function
to produce a key for that authenticator. Since the peer is going to be
independently deriving a key for that authenticator it's going to have
to know what that unique something is so it can produce the same key.
Right? So what is that unique something and how is it learned by the
peer? However that happens without the 3 party protocol it will
happen with the 3 party protocol.

  I share your desire to produce something that actually gets deployed
and your belief that 802.11 is not going to change just for little old
HOKEY. Being late to the HOKEY party I just naively assumed you guys had
already figured out how that unique something was going to be learned
by the peer. If you have then what's the big deal? If you haven't then
don't blame the 3 party protocol for introducing this issue.

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 26 Mar 2007 07:32:12 -0700

Dan Harkins <mailto:[email-masked]> allegedly scribbled on Monday,
March 26, 2007 7:06 AM:

> something unique about each authenticator (each recipient of a key
> from the HOKEY server) is going to be mixed into the key derivation
> function to produce a key for that authenticator. Since the peer is
> going to be independently deriving a key for that authenticator it's
> going to have to know what that unique something is so it can produce
> the same key. Right? So what is that unique something and how is it
> learned by the peer? 

If this takes place in the standard EAP fashion, the unique keys will be
generated as a by-product of the EAP-ER authentication, not derived out
of thin air.  So in this case, no authenticator ID is required to
generate unique keys; it would only be needed for the purposes of
"channel-binding" (I won't go again into my opinion of that ;-).

...

>   I share your desire to produce something that actually gets
> deployed and your belief that 802.11 is not going to change just for
> little old HOKEY. Being late to the HOKEY party I just naively
> assumed you guys had already figured out how that unique something
> was going to be learned by the peer. If you have then what's the big
> deal? If you haven't then don't blame the 3 party protocol for
> introducing this issue.    

I'm not blaming anything on anything, just pointing out that this issue
must be solved.  I'm sure that we can think of a way to do that but if
not then we better kiss "channel-binding" (at least in that form) good
bye...
  
...

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 26 Mar 2007 10:49:44 -0700 (PDT)

Glen,

  "standard EAP fashion"? This isn't a standard EAP method. What
are you imagining happens in EAP-ER that produces a key? While
we're on the subject how is a "domain" and a "usage" conveyed
such that the key hierarchies are the same or is there more EAP
magic that I'm not seeing?

  Dan.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 26 Mar 2007 11:27:14 -0700

Hi Glen, 

My brain is working overtime to make sense of your "love fest" reference. 

I remember in Dallas BoF, people told us: "4067 context transfer protocol is
used in many SDOs to pass keys between authenticators" and people thought
abiding Housley criteria of principle of least privilege had no point in
most SDOs, due to the prevailing trust models. So why did you not stop
there, if you worried about adoption in 802.11?

Yet here we are a year later with a real WG and our attempt to simply make
sure the protocol works properly is being referred to as a "love fest"?

I like to remind people that this group is within the security area, not
within operation area for a good reason.

If we are really worried about "existing standards, such as 802.11" adopting
whatever we cook up here, then we may want to consider their deployment
scenarios. Authenticator-handovers are only less than 5% of WiMAX handovers,
while the rest of 95% of handovers are between IP nodes that are below
authenticators. So for the sake of those ambitious, tech saavy people that
are going to look at the outcome of this group for the 5% of scenarios, we
might want to at least do something that works and people feel comfortable
with, and I don't know how we can achieve that without discussions?

As far as your statement on NAS ID, I respectfully like to point you to
WiMAX NWG R1 stage 2, and 802.11r D3+ specs: both WiMAX and 802.11r do
actually pass "NAS ID" to the peer. WiMAX does it in form of "anchor
Authenticator ID" and 802.11r does it in form of Mobility domain information
element (MDIE) that indicates mobility domain ID and it is passed as
beacons. If your "find" botton does not work, I can give you all the
instances. Now even if they did as you said and I am wrong:

The majority of the group thinks developing a key hierarchy to deal with
authenticator handovers is a good idea. Furthermore, it seems that creating
per-authenticator keys, by mixing authenticator ID is good thing. So how are
we going to communicate the authenticator ID to both sides?

We said multiple times, the 3-party thing is simply showing what parameters
can be carried over a generic roundtrip message between the peer and the
server, it IS NOT a new protocol proposal. It achieves exchange of
identities, while also achieves channel binding as well as peer consent if
needed. So what is wrong with additional security precautions that actually
do not cost anything extra.

As far as hand waving below EAP layer, I believe you asked me the question
in San Diego meeting and my answer was that yes, authenticator ID should be
broadcast to the peer, so that the peer can calculate the per-authenticator
keys as part of the hierarchy. How it is broadcast over the air is an SDO
matter.

Using the "love fest" style language: I "shot my trap" now and won't go on
with this thread,

Madjid

  _____  

From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Saturday, March 24, 2007 3:23 AM
To: M. Vanderveen
Cc: [email-masked]
Subject: RE: [HOKEY] 3 party protocol and EAP-ER

Hi Dan,

I have long harbored doubts about the use of 2-party EAP-ER in re-auth with
a Hokey server that is different (and possibly in a different domain) from
the EAP server with which the original full EAP method was done.  The
protocol you outline, which is a modified version of the one in draft-ohba,
looks like it will work without any additional messaging. This is great
news, if indeed it can be shown to be secure even without the party B's
nonce (Hokey server's).  We still have to work out at the lower layer
probably, how the Peer will know the Hokey server's id, but other than that
it something that can be overlayed with relative ease. 

Presumably the hokey server ID can be ascertained after network access has
been allowed, but not the (new) NAS ID.  I really hate to throw cold water
on this developing love-fest, but this is not a minor problem: I know of no
wireless systems - not WiFi, nor WiMax nor  ... that actually advertises the
NAS identity.  If you think that 802.11 for example is going to be modified
so our lovely 3-party protocol will work, well, think again.  I, for one,
have no desire wasting my time on work that is undeployable, so if we
actually want to use a 3-party protocol it had better solve the problem of
secure identity advertisement as well, with no hand-waving about the EAP
lower layer...

Michaela

----- Original Message ----
From: Dan Harkins <[email-masked]>
To: [email-masked]
Sent: Wednesday, March 21, 2007 6:16:50 AM
Subject: [HOKEY] 3 party protocol and EAP-ER

Hi,

  peer-id, [counter]rki

                                                   [finish]rki, {key}foo

  thanks,

  Dan.

 

  _____  

Sucker-punch
<http://us.rd.yahoo.com/evt=49981/*http:/advision.webevents.yahoo.com/mailbe
ta/features_spam.html>  spam with award-winning protection.
Try the free
<http://us.rd.yahoo.com/evt=49981/*http:/advision.webevents.yahoo.com/mailbe
ta/features_spam.html>  Yahoo! Mail Beta.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 26 Mar 2007 11:49:36 -0700 (PDT)

Madjid,

  I don't think any offense was intended and I don't think you should
take any. It's mildly humerous and somewhat descriptive given what has
obviously been a very contentious working group. Editorial asides detract
from the (very valid!) point you're trying to make.

  Dan.

On Mon, March 26, 2007 11:27 am, Madjid Nakhjiri wrote:
> with

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 26 Mar 2007 12:37:59 -0700

Hi Dan,

Appreciate the note. It is "mildly" humorous, but _hardly_ constructive.

Madjid

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Monday, March 26, 2007 11:50 AM
To: Madjid Nakhjiri
Cc: 'Glen Zorn '; 'M. Vanderveen'; [email-masked]; 'Sam Hartman';
[email-masked]

  Madjid,

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 26 Mar 2007 13:25:39 -0700

March 26, 2007 10:50 AM:

>   Glen,
> 
>   "standard EAP fashion"? This isn't a standard EAP method. 

the unique keys will be generated as a by-product of the EAP-ER
authentication

> What are
> you imagining happens in EAP-ER that produces a key? 

the unique keys will be generated as a by-product of the EAP-ER
authentication

> While we're on
> the subject how is a "domain" and a "usage" conveyed such that the
> key hierarchies are the same or is there more EAP magic that I'm not
> seeing?    

What is the usage of the MSK?  It's the same for this new key.  

>> Dan Harkins <mailto:[email-masked]> allegedly scribbled on
>> Monday, March 26, 2007 7:06 AM:
>> 
>>>   Glen,
>>> 
>>>   As I point out in my post below I'm not adding any new
>>> requirements onto what was already there. 
>>> 
>>> going to have to know what that unique something is so it can
>>> produce the same key. Right? So what is that unique something and
>>> how is it learned by the peer?
>> 
>> If this takes place in the standard EAP fashion, the unique keys will
>> be generated as a by-product of the EAP-ER authentication, not
>> derived out of thin air.  So in this case, no authenticator ID is
>> required to generate unique keys; it would only be needed for the
>> purposes of "channel-binding" (I won't go again into my opinion of
>> that ;-). 
>> 
>> ...
>> 
>> I'm not blaming anything on anything, just pointing out that this
>> issue must be solved.  I'm sure that we can think of a way to do that
>> but if not then we better kiss "channel-binding" (at least in that
>> form) good bye... 
>> 
>> ...

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 26 Mar 2007 14:01:05 -0700 (PDT)

Glen,

  Sigh. OK, I will be a bit more explicit.

> the unique keys will be generated as a by-product of the EAP-ER

What is the exact process in EAP-ER whose by-product is a key?

> What is the usage of the MSK?  It's the same for this new key.

If that's the case then there is no need for "usage"-specific keys!
Excellent. We've just simplified the overly complicated key hierarchy.

What about the "domain"?

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 26 Mar 2007 14:12:22 -0700

March 26, 2007 2:01 PM:

...

> What is the exact process in EAP-ER whose by-product is a key?

I think that it's given in section 5.1.5 of draft-vidya-eap-er-02.txt.

> Excellent. We've just simplified the overly complicated key hierarchy.

Ditto, I suppose.  I don't really want to talk about this any further,
though: if the WG wants to use a 3-party approach, so be it.  I didn't
think that requiring that that protocol itself be responsible for
securely communicating the data it needs was particularly onerous, but
apparently it was.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 26 Mar 2007 20:18:58 -0700

Hi Glen, 

My brain is working overtime to make sense of your "love fest"
reference.  

I really wouldn't put too much energy into it.

I remember in Dallas BoF, people told us: "4067 context transfer
protocol is used in many SDOs to pass keys between authenticators" and
people thought abiding Housley criteria of principle of least privilege
had no point in most SDOs, due to the prevailing trust models. So why
did you not stop there, if you worried about adoption in 802.11?

Yet here we are a year later with a real WG and our attempt to simply
make sure the protocol works properly is being referred to as a "love
fest"? 

OK, so "properly" is a matter of opinion.  My definition of "properly"
includes the ideas of deployability and the possibility of working in
the real world with as few dependencies on lower layers as possible.

If we are really worried about "existing standards, such as 802.11"
adopting whatever we cook up here, then we may want to consider their
deployment scenarios. Authenticator-handovers are only less than 5% of
WiMAX handovers, while the rest of 95% of handovers are between IP nodes
that are below authenticators. So for the sake of those ambitious, tech
saavy people that are going to look at the outcome of this group for the
5% of scenarios, we might want to at least do something that works and
people feel comfortable with, and I don't know how we can achieve that
without discussions?

I give up, what do _you_ think is going on here?  _I_ think that we're
having a discussion.  I'm sorry if you don't like the way it's going but
that doesn't mean that it's not a discussion.

Authenticator ID" 

I don't believe that the Anchor Authenticator ID is advertised to the
peer; I may be mistaken, though.

and 802.11r does it in form of Mobility domain information element
(MDIE) that indicates mobility domain ID and it is passed as beacons. If
your "find" botton does not work, I can give you all the instances. 

Actually, my "Find" button works just fine, thanks!  The latest draft of
802.11r I have is 4.0.  That document defines a "Mobility Domain" as "A
set of BSSs, within the same ESS, identified by a Mobility Domain
Identifier. The Mobility Domain is used when Fast BSS Transition is
enabled, and provides the following services to the STA: (1) use of Fast
BSS Transition procedures is possible between any two APs in the same
Mobility Domain using either direct communication or through the STA's
existing association with its current AP; and (2) a common key hierarchy
is accessible at all APs in the same Mobility Domain. APs in the same
Mobility Domain advertise the same Mobility Domain Identifier.", with
the Mobility Domain Identifier being a 48-bit number uniquely
identifying a Mobility Domain.  I admit that it's been a while since I
worked on 802.11 but unless the definitions of BSS, ESS and AP have
drastically changed recently that doesn't sound like a NAS ID to me.  Or
maybe I just don't know what a NAS is.

Now even if they did as you said and I am wrong:

The majority of the group thinks developing a key hierarchy to deal with
authenticator handovers is a good idea. 

Yup.

Furthermore, it seems 

to you (perfectly valid, but it doesn't follow from your last statement)

that creating per-authenticator keys, by mixing authenticator ID is good
thing. So how are we going to communicate the authenticator ID to both
sides?

Good question.  An even better one is "How can a NAS lie about its
identity if it's not telling you what its name is in the first place?".
Be that as it may, however, I think that the authenticator identity
might be securely communicated from the server to the peer in the last
message of the "3-party thing" (I was almost going to call it a
"protocol" ;-) instead of being included in the 1st message from the
peer.  

We said multiple times, the 3-party thing is simply showing what
parameters can be carried over a generic roundtrip message between the
peer and the server, it IS NOT a new protocol proposal. It achieves
exchange of identities, while also achieves channel binding as well as
peer consent if needed. So what is wrong with additional security
precautions that actually do not cost anything extra.

Nothing; my point was that it's not zero cost (& you seem positively
offended when I point this out).

As far as hand waving below EAP layer, I believe you asked me the
question in San Diego meeting and my answer was that yes, authenticator
ID should be broadcast to the peer, so that the peer can calculate the
per-authenticator keys as part of the hierarchy. How it is broadcast
over the air is an SDO matter.

For those who might be wondering what I mean by "hand waving", see the
last two sentences for a lovely example ;-).

Using the "love fest" style language: I "shot my trap" now and won't go
on with this thread,

Madjid

Hi Dan,

Michaela

----- Original Message ----
From: Dan Harkins <[email-masked]>
To: [email-masked]
Sent: Wednesday, March 21, 2007 6:16:50 AM
Subject: [HOKEY] 3 party protocol and EAP-ER

Hi,

  peer-id, [counter]rki

                                                   [finish]rki, {key}foo

  thanks,

  Dan.

 

Sucker-punch spam
<http://us.rd.yahoo.com/evt=49981/*http:/advision.webevents.yahoo.com/ma
ilbeta/features_spam.html>  with award-winning protection.
Try the free Yahoo! Mail Beta.
<http://us.rd.yahoo.com/evt=49981/*http:/advision.webevents.yahoo.com/ma
ilbeta/features_spam.html>