Subject: RE: [HOKEY] HOKEY re-key architecture

From: "Dan Harkins" <[email-masked]>
Date: Wed, 31 Jan 2007 21:27:16 -0800 (PST)

Glen,

> Dan Harkins <mailto:[email-masked]> allegedly scribbled on
> Wednesday, January 31, 2007 5:12 PM:
>
>>   Glen,
>>
>>>>   Yes, of course if the KDC is compromised the game is over. But I'm
>>>> not talking about compromise of the KDC.
>>>
>>> But your postulation of a "lying NAS" assumes that the fundamental
>>> AAA trust model has been broken.  How is that different than
>>> assuming that the KDC is compromised, therefore Kerberos is broken?
>>
>>   No it doesn't! It merely observes that there is no binding of the
>> identity to whom the MSK is given by the AAA server. And therefore
>> it's possible to "lie" about who you are to the AAA server and get
>> something you're not supposed to get.
>
> No, it's not.  The NAS does authenticate itself to the AAA server, at
> least in any relevant usage & the user authenticates to the AAA server,
> as well.

The lying NAS problem assumes that the NAS has authenticated itself to
the AAA server. The issue is under what identity?

Let's say that Bob authenticates himself to Trent using IKE main mode with
a pre-shared key. That identity is an IP address. That's great. It's
secure for what it's purpose is, sending integrity protected, source
authenticated and optionally encrypted data. That's it though.

After Alice authenticates to Trent, Trent is supposed to send a key to
Bob so Alice can talk to him. Let's just say it's one of those key
hierarchies where the identity that Bob presents is mixed into the key.
What is that identity? It can't be the IP address that he's authenticated
himself to Trent with because that's not known by Alice since she's
speaking to him out of some other interface. So it's some other identity
that is common and can (not to say it is today in every deployment, but
it can) be known by both parties.

The common identity that Bob presents is supposed to be "Bob", not "Bill".
But he presents "Bill" as the identity to mix into the key to Trent and
Trent dutifully produces a key for "Bill" and sends it to Bob.

Since there is nothing in the protocol that requires that Bob authenticate
with an identity that is meaningful to the purpose of key distribution
and there is nothing in the protocol that enables Trent to check the
identity he is presenting is really something he should be presenting
there is a flaw.

That doesn't mean that Bob didn't authenticate himself to Trent. He did.
But so what? If you authenticate yourself to a corporate server and so
does a co-worker,if the co-worker was able to obtain a key that should
only be known by you wouldn't that be a problem? Of course it would! It
wouldn't mean that the co-worker didn't authenticate or that you didn't
authenticate. It would mean the protocol which gave him the key was broken.

>>>> I'm talking about the
>>>> requirements on key distribution. In Kerberos the KDC supplies
>>>> session keys for Alice and Bob to speak together. If it was OK for
>>>> the KDC to just send Bob a key derived from one he shares with Alice
>>>> then there would be no need for Kerberos. But it's not OK to do
>>>> that, even if the transport of the key from KDC to Bob was secure.
>>>
>>> That's because Alice & Bob don't (necessarily) trust each other -
>>> that is part of the Kerberos trust model.  If you violate that model
>>> (i.e., by assuming that Alice and Bob _do_ trust each other (as well
>>> as the KDC)) then it _is_ just fine for the KDC to just send Bob a
>>> key derived from one he shares with Alice.
>>
>> So in your mind the mobile device trusts any other device that claims
>> to be offering access to the network?
>
> I didn't say that.  What I said was that the (potential) distrust
> between Alice & Bob is part of the Kerberos trust model, which basically
> says that no one trusts anyone but the Kerberos server.  That is not the
> AAA trust model.  You might not like the AAA model, but that does mean
> that you can break it, then say "Look, it's broken!".

Alice trusts Trent, mobile device trusts AAA server; and Bob trusts Trent,
authenticator trusts AAA server. They are analagous.

But why does Alice trust Bob now? If the AAA model is that Alice trusts
Bob then how did they get that trust relationship and furthermore if they
have it they why do they need Trent (i.e. the AAA server)?

>> Why is that? Why does Alice
>> (the mobile device) trust Bob (the authenticator to whom she wants to
>> do a handoff)? How is that trust established?
>
> Dan, I'm sure you already know this, but it's for the same reason that a
> Kerberized rcmd client trusts a Kerberized rcmd server: the rcmd server
> displays knowledge of a quantity that the client also knows but the rcmd
> server could only have learned from a mutually trusted party (the AAA
> server).

But Alice only trusts Bob after going through the secure 3 party protocol
named Kerberos. You're suggesting that Alice trusts Bob and no secure
3 party protocol is necessary.

>>
>>>>   A primary objective of Kerberos is authentication of Alice to Bob.
>>>> Mere possession of a key does not prove possession. So there is some
>>>> handshaking and proof of identity involved. It is not OK for the KDC
>>>> to just give a key to Bob and analogously it is not OK for the HOKEY
>>>> server to just give a key from the mobile device's key hierarchy to
>>>> the new authenticator. This is a 3 party protocol and we need to
>>>> make it secure.
>>>
>>> One more time: it is not a three-party protocol.  In fact, it's
>>> barely a 2-party protocol, since the user typically has no idea what
>>> the identity of the local AAA server might be (possible exceptions
>>> being when using PK cert-based EAP methods), let alone the identity
>>> of the NAS s/he is talking to.
>>
>> Yes, it's 3 parties. The mobile device, the AAA server and the entity
>> to whom the MSK is given. In the HOKEY case it's the mobile device,
>> the HOKEY server, and the authenticator to whom the mobile device
>> wants to do a handoff.
>
> OK, fine.  Let's just say that there are three parties.  How do you
> propose that the mobile authenticate anybody here?  How many keys does
> it get to carry around?

It carries around 1 key hierarchy based off the EMSK. Depending on
where it does handoffs or roams it might be a couple of keys or it might
be some expansive hierarchy, but it's still off the same root key. That
will not be different whether you securely distribute keys or whether you
just fling them around willy-nilly.

But the mobile device must be an active participant in the key
distribution from Trent/HOKEY server to Bob/authenticator. It has to
consent to Bob holding the key. That is done with a secure 3 party protocol,
it's not done with some massive key database.

The mobile device doesn't trust the authenticator it wants to do a handoff
to. So it uses a common trust point-- the HOKEY server aka Trent-- to
distribute a key and allow it to authenticate the authenticator aka Bob
at the same time.

>>
>>>              The user authenticates to & optionally authenticates a
>>> rather amorphous entity you might call the Network.
>>
>> Ahh, "the Network". And everything in "the Network" is secure and we
>> can all rest assured that nothing bad is happening in there. Not
>> everyone subscribes to that "crunchy on the outside, gooey on the
>> inside" model, especially when the outside isn't very crunchy at all.
>>
>> If patently insecure or flawed protocols are being used in "the
>> Network"
>> then it is not secure. There is no cryptographic boundary (from a
>> FIPS-140
>> point-of-view) for "the Network" so you can't treat it like a single
>> entity.
>
> I really think that the only flaw is in the logic that created the
> "lying NAS problem" out of basically thin air.  The AAA trust model says
> that the AAA server trusts its clients.  The "lying NAS" construct
> assumes just the opposite, then claims that the original model is broken
> because _it_ is broken.

  Created out of thin air? You previously said that you spoke to numerous
god-like security experts who all said the same thing although not in a
way to convince you. So if this "lying NAS problem" was created out of
thin air that means there is a massive conspiracy of god-like security
experts (and their lackeys like me) to force some unnecessary scheme on
you. That's not a credible stand for you to take.

  Dan.

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

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 31 Jan 2007 21:38:14 -0800 (PST)

Glen,

  Nobody's proposing that devices carry around multi-gigabyte databases
of keys. That's the whole point of the secure 3 party protocol! There
are no more keys required whether you do this right or whether you do
this wrong.

  If you do it right there is a handshake between the mobile device,
the new authenticator and the HOKEY server whereby the new authenticator
comes into possession of a key he can use to give the mobile device
network access. That handshake satisfies basic security requirements for
a key establishment protocol.

  If you do it wrong you just let the HOKEY server give the keys out
to whoever it wants under an unspecified scheme. That satisfies no
security requirements. It might be possible to implement such a broken
protocol in a way that could have legitimate security claims but that
requires us to trust the implementation and that is never right.

  Dan.

> Glen Zorn (gwz) <> allegedly scribbled on Wednesday, January 31, 2007
> 8:15 PM:
>
> ...
>
>>>
>>> can all rest assured that nothing bad is happening in there.
>
> I didn't say that, either.  I asked you to tell me what a threat, any
> threat, was from a lying NAS (a NAS that tells the AAA server its real
> identity (because it must) but tells its client something else (even
> though it actually doesn't claim _any_ identity to the client, but let's
> just ignore that inconvenient matter as well) and you gave a reference
> to an entirely different (& irrelevant) problem.  Just show me an actual
> threat, some real or potential danger that arises from this capability &
> I'll gladly back the requirement that clients carry a key for every
> access device on the planet in a very handy multi-gigabyte database.
>
> ....
>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 31 Jan 2007 23:04:17 -0800

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Wednesday, January 31, 2007 9:27 PM:

...

>   Created out of thin air? You previously said that you spoke to
> numerous god-like security experts who all said the same thing
> although not in a way to convince you. 

Actually, I said that they say that this thing exists, but not one could
say what the threat was nor how it could actually  exist in the face of
the AAA trust model I've described.  I'll just note that you haven't,
either; you have brought up all kinds of interesting things (for
example, the NAS stealing the MSK so it could eavesdrop on traffic after
a hand-over -- I've to wonder why, since 802.11i part of its _job_ is to
decrypt the airlink traffic & forward it (functionally identical to
eavesdropping).  Frankly, I'm getting the same answers I usually get
when trying to get a straight answer about this supposed problem: "What,
exactly, is the threat, you ask?  Uhhhh LOOK OVER THERE, A UFO!" & the
sound of "godlike security expert" feet disappearing in the distance...

> So if this "lying NAS problem"
> was created out of thin air that means there is a massive conspiracy
> of god-like security experts (and their lackeys like me) to force
> some unnecessary scheme on you. 

No; it could be that those "god-like security experts" (note the quotes,
signifying sarcasm) don't understand the model or just don't like it.
If you reject the AAA trust model, the problem is real; if not, the
problem disappears like vapor.  It sounds to me like you are really
interested in rejecting the AAA trust model; that's fine, but you'd
better be replacing it with another that scales and works as well in the
real world.  (Is that the sound of feet disappearing in the distance
that I hear? ;-)

> That's not a credible stand for you
> to take.      
> 
>   Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 31 Jan 2007 23:28:41 -0800 (PST)

Glen,

  The problem does not disappear if you believe in the AAA trust model.
In the AAA trust model the AAA server trusts the authenticator through
some out-of-band mechanism and it trusts the mobile device through an
EAP authentication. The mobile device does not trust the authenticator.

  And that is _exactly the same_ as a KDC that trusts Alice through
some out-of-band mechanism and trusts Bob through some out-of-band
mechanism. Just replace one "out-of-band" with EAP and you have the
identical case. You have a trusted third party known as either the AAA
server or the KDC and you have two entities that trust that third party
but don't (yet) trust each other.

  So getting back to my original question, since the two cases are the
same, why do we need Kerberos? According to you, the AAA trust model
implies that the AAA server can just send a key to the authenticator
(it's "authenticated" after all) and everything is hunky-dory. So why
can't the KDC just send Bob a key for Alice and be done with it (since
the KDC has an authenticated relationship with Bob)? Why bother with the
handshaking? Surely there must be some problem that Kereros is solving.
What is it?

  Dan.

P.S. the issue I was bringing up is relevant to 802.11i but more so to
802.11r. If some entity can obtain a key that it should not have then it
can use that key to impersonate the client. It's a symmetric key. A
demonstration of its possession by the client "authenticates". it If you
cannot cryptographically prove who knows the key then you have no basis
for assuming that some random entity that has it is, in fact, the client
that established it in the first place.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 31 Jan 2007 23:29:00 -0800

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Wednesday, January 31, 2007 9:38 PM:

...

> the new authenticator and the HOKEY server whereby the new
> authenticator comes into possession of a key he can use to give the
> mobile device network access. That handshake satisfies basic security
> requirements for a key establishment protocol. 

Strange, that's exactly what AAA & H(okey)EAP do, except that the new
authenticator gets no key at all except in the case where link
encryption is supported.
  
> security requirements. It might be possible to implement such a
> broken protocol in a way that could have legitimate security claims
> but that requires us to trust the implementation and that is never
> right.

Dan, nobody's suggesting that, either. I'm certainly not suggesting that
the Hokey server distribute authentication keys any more than an EAP
server would distribute passwords.  The only keys that I, at least, am
talking about distributing are the moral equivalent of the .11i MSK.
AFAIK, that key can only be used for traffic encryption.  So, tell me
again what threat is present in the "lying NAS" problem.  The key can't
be used to eavesdrop on any traffic except that which passes through the
access point anyway.  The key can't be used to impersonate anyone since
it isn't used for user authentication.  It can't be used by the access
point to forge traffic from the mobile (except to itself!) because only
the access point & mobile use it for traffic protection.  Assuming a
non-braindead derivation process, it should not be computationally
feasible to backtrack from the distributed key to its progenitor.  I'm
really trying here, Dan, but I can't see it.
      
,,,

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 1 Feb 2007 08:39:50 -0800 (PST)

Hi Artur,

  You say there's no difference between if there's a AAA server or if
the NAS uses it's local database. But there's a big difference from a
security of view because in the former there are 3 parties and a key
is given by the AAA server to the NAS that's not using its local database.

  Thanks for the historical background. The day that folks decided to
move the local NAS database out to some central server they broke the
2 party model that you and Glen are fastidiously sticking to. Perhaps
there is no logical difference and a mobile device won't be able to
distinguish between the two but there is a very big difference from a
security point of view because now a key is being taken out of one
entity and given to another entity. (If this was still a 2 party protocol
then Glen would not have to write I-Ds about wrapping keys as RADIUS
attributes, there should be no need to wrap a key if it's a 2 party
protocol).

  You can't draw a rational cryptographic boundary around a AAA server
and all wireless access points in a network, for example, and say that's
an amorphous entity called "the Network" that mobile devices authenticate
to. That just doesn't work. You can draw a "logical boundary" anywhere
you want to simplify discussion but it doesn't change the fact (yes, the
fact) that there are 3 parties involved when the NAS doesn't have or
doesn't use its local database.

  Perhaps that is why people "scurry" away to paraphrase Glen. Because
they just cannot suspend reality or equate a logical dotted line drawn
to simplify things and a cryptographic boundary.

  Since this is the HOKEY working group let me return to the other 3
party protocol, the one we should be dealing with.

  There is an authenticator who has never seen the mobile device yet and
who does not have a key for it. Furthermore it is desirable to not do a
full EAP authentication to this new authenticator. HOKEY is supposed to
come up with a way that the new authenticator gets a key to use to provide
network access for the mobile device. From whom does it get that key?

  Please tell me that _this_ key distribution scheme involving, one,
a mobile device, two, a new authenticator, and three, some server that
holds they keys to distribute, is not the "classical AAA" model and
is therefore not a 2 party protocol. Or are you drawing a logical line
around 2 of those entities and saying "same amorphous blob"?

  Dan.

> hi Dan, Glen
> Sorry, Dan, but I can't agree at this point. The AAA has never been
> supposed to be a trusted third party, and as a matter of fact, it is
> not.
>
> There is a major difference between Kerberos-like models (true 3
> party architectures) and AAA like models (classical 2 party
> architectures, where one party is implemented as a distributed sub-
> architecture).
>
> The big difference is: in Kerberos, every user knows there is a KDC,
> every user has an explicit preestablished security association with
> the KDC *and* every user is obliged to ask the KDC to hand out the
> keys for any new connection to any other user. The KDC and all users
> have explicit, distinct identities, which every communicating party
> is aware of at any moment.
>
> While I understand that at the first glance it looks confusingly
> similar to what happens in AAA, the used mechanisms, reflected in the
> common identification requirements, are radically different. In the
> whole AAA model, there is and can be (by design) no difference of
> where there is an AAA server or whether the NAS simply uses its
> internal data base.
>
> That is the whole problem behind it and you will never get Glen to
> see what you see, if you do not get to see this first :-) There is a
> historical background: one day, some folks decided to move the local
> NAS databases out to some central server (it was handier to
> administer in that way) and called the comm protocol TACACS and
> RADIUS, later. Logically though everything remained the same - in
> particular, it did not change a thing for the user: the server
> identity, the NAS identity etc. are not communicated to the user (for
> that very special reason), except for some special cases (e.g. with
> certain EAP methods, as Glen mentioned).
>
> That is what Glen means by an "amorph entity which you might call
> network": from the user perspective there is and can be no difference
> of whether it is one NAS with a local user list or multiple NASes
> sharing one list which happens to be on the server or why not a whole
> P2P grid sharing the user list. That is why the AAA model assumes
> trust between its entities: all AAA parties are one entity, their
> distinction in server/client/agent/manager/etc is purely internal, on
> a subentity basis.
>
> Just think about it: afaik CHAP (early AAA classic, EAP neighbor,
> still widely used) requires that AAA simply hands out user-password
> and user-name to the requesting NAS. just like that - like a common
> data base.
>
> Now, that's the AAA model. Neither me nor Glen (if I am correct) are
> saying that it is perfect or sufficient. But it is like that, it is
> very much NOT like Kerberos.
>
>
>
> artur
>

---

From: Saber Zrelli <[email-masked]>
Date: Fri, 2 Feb 2007 01:53:05 +0900

Hi Yoshihiro,

* On Wed, 31 Jan 07 at 13:59, Yoshihiro Ohba wrote:
> > >> IMHO the key distribution from HOS to HAN is not an issue since
> > >> the secure transport of keys from HOS to HAN is already deployed and
> > >> widely used, (precisely, it corresponds to the transport of key over AAA
> > >> protocol from EAP server to AN). A re-key over EAP protocol could build
> > >> upon that.
> > >
> > >   I don't think the AAA protocol from EAP server to authenticator is
> > > secure at all! It is merely providing a key. Out of the 6 enumerated
> > > requirements I listed in my previous email (which was not exhaustive)
> > > I don't think that protocol satisfies any of them. Perhaps it might
> > > satisfy the confidentiality requirement depending on how the key is
> > > wrapped, but that's about all.
> > >
> > >   There is a "misplaced trust in server" protocol flaw that exists in
> > > the current AAA protocol to distribute a key from an EAP server to an
> > > authenticator (also known as the "Lying NAS" problem). We cannot
> > > propogate this flaw into HOKEY.
> > >
> > >   Security requirements exist on the key distribution protocol itself and
> > > they cannot simply be satisfied by securing the transport of the protocol.
> > > For instance, you can't just make an IPsec tunnel between authenticator
> > > and EAP server and say it solves your key distribution protocol problems!
> > >
> > 
> > I am not sure to understand the issues, consequences and what is the
> > problem with the AAA protocol between EAP server and the NAS for conveying
> > keys.
> > 
> > But this is what I think:
> > 
> > The AAA protocol from EAP server to authenticator may be not secure at all.
> > But still, it is deployed everywhere and It seems to me that I will be
> > there forever until one day maybe people decide to fix it.
> 
> Aren't we (HOKEY WG members) the people who can decide to fix it if it
> is wrong? :)

I don't really know :) I think that we can trust existing protocols
unless there is a clear concern.

> 
> > 
> > More importantly, the integrity of the re-key protocol relies on the
> > integrity of the EAP framework, including the AAA protocol for carrying
> > key from EAP server to AP ( I'm I wrong ?) thus re-key is as weak as this
> > AAA protocol anyway. You can be fooled during EAP authentication phase by
> > a bad NAS, then use a VERY secure re-key handshake, it wont make it better
> > I think.
> > 
> > Therefore, I estimate that the re-key protocol could use the AAA protocol
> > between the EAP server and the NAS for delivering keys.
> 
> It appears that you are discussing security of MSK branch.  Since
> re-key protocol is going to rely on EMSK branch which is not exposed
> to AP unlike MSK, re-key protocol is based on the *securer* part of
> the EAP keying framework.  It is also possible to obsolete MSK-branch
> if it is not doing the right thing.

I guess what I wanted to say is that, the proper execution of re-key may
rely on the security of the initial authentication.

For example, imagine a STA arriving at a new realm, does initial EAP
authentication, but the MSK is disclosed somehow. The attacker may
impersonate the NAS based on the corrupted MSK, then provide fake IP,
DNS, time ..

If Kerberos is used for example, as a basis for re-key, the STA will
participate in re-key exchanges using previously obtained forged DNS
and time services. re-key in such circumstances may not work (because
Kerberos relies on time and DNS) and but the failure that caused the
diclosure of MSK will not be propagated.

Thus, if we assume that MSK might be corrupted we have to exclude many
solutions including Kerberos. Such assumption is not necessary IMHO.

> > 
> > If this AAA protocol is updated one day, that wont hurt re-key since the
> > basic role of this AAA protocol (transporting key between EAP server and
> > NAS) would be the same.
> 
> What are exact requirements for any three-party key distribution
> protocol?  Does AAA protocol satisfy the requirements?  These are
> basic questions we need to answer first.

I completely agree.

Regards,
Saber.

---

From: Artur Hecker <[email-masked]>
Date: Thu, 1 Feb 2007 18:35:21 +0100

Hello Dan

> is given by the AAA server to the NAS that's not using its local  

well, technically there isn't as long as we are using the same model.  
imagine you have a user whom you are dealing with. imagine further  
that the user actually simply discloses everything he gets to another  
user. you, as a network, see the user identity you authenticated. you  
obviously do not know what happens next.

that is how the stuff currently works with AAA, in spite of EAP etc.  
what the server does, can always be done *in the same manner* at the  
NAS. worse that that: it is so by design.

what i'm saying is: the only identity the user is dealing with, is a  
virtual one. be it at the server, on the nas or in the cloud between  
them: that does not matter according to the current model.

now, throw away the model and i'm all yours.

> 2 party model that you and Glen are fastidiously sticking to. Perhaps

please avoid suggesting things i've never said :-) i'am not sticking  
to anything; i personally do not care a dime. ah common': i hate the  
whole client-server paradigm altogether.

but imo there is one very important thing to understand: why do you  
think security in terms of physical devices? an identity can very  
well be attributed to something that does not physically exist: a  
program, a flow, an ip packet. why do you try to break it down to  
supposedly tangible, physical entities such as AAA server or NAS? why  
can't it be say a P2P grid spawn over something else?

the security and its understanding have to be attached to the used  
model. as the guys distributed the *NAS* function, they did so  
"within the NAS". the NAS entity became virtual ... and distributed -  
all that within the same NAS. its behaviour to the outer world is the  
same: the new virtual NAS talks to the possibly physical mobile node:  
2 party model. to be able to do so, the AAA trust model says that as  
two parts of the same, the server and nas trust each other. in other  
words - they collaborate.

you doubt that and want to change it: fine; i can think of 100  
reasons to do so. but clearly, that's not really AAA.

if you ask me, to do so, we will need:

- identification and distinction of NASs, users and servers (along  
with respective DOI)
- awareness of server presence for all parties - NAS, users ("i have  
to address the server S first, then i'll see if this NAS is rogue")
	- and possibly other servers - for multi domain (but i shut up)
- state machines and protocols that respect these new phases.

> entity and given to another entity. (If this was still a 2 party  

see above, you seem to think security in terms of physical devices,  
which is strange to me.

> attributes, there should be no need to wrap a key if it's a 2 party

he would and he did, but for a different reason: it is part of the  
new NAS implementation and completely transparent for the user in all  
cases. how the NAS is implemented is out of scope - to periphrase Led  
Zeppelin "The protocol remains the same".

> doesn't use its local database.

no, you can't say that the only "relevant" entities are physical  
ones. actually, i would dare saying quite the opposite: what actually  
matters for security are virtual entities - programms, flows, more so  
than grey metal boxes.

now, good thing: you are right to steer back to hokey; however, for  
the moment i do not intend to comment. i'll rather wait for yoshi and  
charles to settle it down.

artur

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 1 Feb 2007 12:06:13 -0800 (PST)

Hi Artur,

> obviously do not know what happens next.

  Yes, I imagine such a situation. Everything is just disclosed to another
user. And that's the problem. You've taken a 2 party protocol, EAP, and
disclosed the secret to a 3rd party. The security considerations of the
2 party protocol have just been changed.

  The act of "disclosing everything" changes things. In one case-- NAS
uses local database-- there is no "disclosure of everything". In another
case-- NAS uses external database in AAA server-- there is "disclosure
of everything."  Those are two different things whether the client knows
about it or not. The security considerations of these two very different
situations are very different regardless of the fact that the AAA model
makes the client unable to distinguish between the two.

[snip]
> Zeppelin "The protocol remains the same".

  You're completely missing my point. If this was some amorphous blob
and it was OK from a security perspective to "simply disclose everything
to another user" in that amorphous blob ("the Network") then wrapping
the security sensitive parts of that everything would not be necessary
and that I-D would not be necessary. The fact that it is necessary to
cryptographically wrap a key when sending it from a AAA server to a NAS
underscores my point that this is a 3rd entity that the secret is being
disclosed to!

  I know exactly why that I-D was written. It's to protect data a secret
known only be 2 people when given to a 3rd. The fact that the client is
not aware that this secret is being given to a 3rd person does not change
the fact that it is being given to a 3rd person.

> matters for security are virtual entities - programms, flows, more so

  I never said that grey metal boxes are the only relevant entities
to consider. I said that you can't draw a rational cryptographic boundary
around an entire network. And since you can't it is not OK to just
"disclose everything" to entities in that network.

  When you have 3 parties involved in a key establishment protocol you
can't treat it like it's a 2 party key establishment protocol! You're
trying to draw a cryptographic boundary around two entities in a network
(by saying that it's OK to "disclose everything") while simultaneously
admitting it's necessary to secure communications between them. Those
are two incompatible positions.

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 1 Feb 2007 15:07:11 -0800

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Wednesday, January 31, 2007 11:49 PM:

>>> mobile device network access. That handshake satisfies basic
>>> security requirements for a key establishment protocol.
>> 
>   Really? And what handshake is that which involves the mobile
> device, the new authenticator and the HOKEY server? 

/WG Chair hat OFF
I would like to see as little deviation as possible from the existing
EAP model, in which the peer authenticates to the authenticator.  For
reasons of convenience & to enhance scaling properties, the EAP
authenticator is often split over 2 or more physical locations; some
people have (erroneously, IMO) interpreted the physical split (e.g.,
into "pass-through authenticator" & "EAP server") as the creation of new
"parties" to the EAP protocol.  However, EAP is & always has been a two
party protocol, the parties being the peer & authenticator, _regardless
of any physical separation_ of portions of the parties.  The
authenticator may be fragmented however one wishes as long as a couple
of requirements are met: 1) the operation of the protocol viewed as a
black box remains the same & 2) the links (if any) connecting the
various pieces of the authenticator remain as secure as if all those
pieces were co-located.  In this case, it should be fairly obvious that
there is no need for the kind of handshake you are talking about because
it requires the spurious introduction of a third party.

> And if the
> authenticator gets no key at all then what's the point of
> HandOverKEYing? Handover keying sans the key sounds like a solved
> problem to me. 

/WG Chair hat ON
Not necessarily: one of the deliverable in our charter is 
"A protocol specification for media-independent, low-latency
re-authentication.  The protocol specification must support handovers 
between EAP authenticators.  This protocol specification is expected 
to employ a re-authentication branch in the key hierarchy."
So the derivation of _authentication_ keys in support of fast(er)
hand-offs would seem to have some utility.

>> Dan, nobody's suggesting that, either. I'm certainly not suggesting
>> that the Hokey server distribute authentication keys any more than an
>> EAP server would distribute passwords.  The only keys that I, at
>> least, am talking about distributing are the moral equivalent of the
>> .11i MSK. AFAIK, that key can only be used for traffic encryption. 
>> So, tell me 
>> again what threat is present in the "lying NAS" problem.  The key
>> can't be used to eavesdrop on any traffic except that which passes
>> through the access point anyway.  The key can't be used to
>> impersonate 
>> anyone since it isn't used for user authentication.  It can't be used
>> by the access point to forge traffic from the mobile (except to
>> itself!) because only the access point & mobile use it for traffic
>> protection.  Assuming a non-braindead derivation process, it should
>> not be computationally feasible to backtrack from the distributed key
>> to its progenitor.  I'm really trying here, Dan, but I can't see it.
> 
>   Well who, in your view, gives out the keys in this key hierarchy?
> Somehow these keys have to be send out to the places that the mobile
> device is going to do a handover to. 

/WG Chair hat ON
This question seems to presuppose a particular kind of support for
predictive handover, which I don't think we have decided upon yet.

> How is that done? What's the
> protocol?  

If we decide that distributing user authentication keys is a good idea
(I don't think that it is, when we have the option of not doing so) or
absolutely necessary for latency reduction, etc. AND we decided to toss
or hopelessly mutilate the EAP model, then some key establishment method
that protects against impersonation by the authenticator might be
necessary.  However, I don't think that that has been decided yet.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 1 Feb 2007 16:04:11 -0800 (PST)

Glen,

> it requires the spurious introduction of a third party.

  I don't know where you came up with those requirements. The "black box"
one boils down to "trust us, you don't have to worry about what we're
doing in here". As I have been trying to explain to Artur, you can't
draw a cryptographic boundary around a AAA server and all APs in a
network. It's not an amorphous blob from a security point of view
because inside that blob it is not all trusted. The fact that we need
I-Ds to wrap keys when transiting that amorphous blob underscores this
fact.

  I am not asserting that this 3rd party is a party to the EAP protocol.
EAP is a 2 party protocol. But the act of sending a secret known to 2
parties to a 3rd party is not part of that 2 party protocol. EAP is done.

  Furthermore, it can never be "as secure as if all those pieces were
co-located" because you're involving a 3rd party. A secret known by 2
people and only 2 people is necessarily going to be better than a secret
known by 3 people.

  Also, if you don't have the identity of that 3rd party involved in the
key distribution then you really don't know _exactly_ who you're giving
the key to. That cannot be dubbed secure.

  Your model is 2 party; reality is 3 party. I think reality is something
that we cannot ignore.

  I frankly don't really care about fixing EAP. Channel binding can take
care of that. And given that the EAP peer reauthenticates at each new
authenticator the damage is pretty tightly controlled. But I don't think
this protocol flaw (classic flaw number 4 from the Handbook of Applied
Cryptography, by the way) should be propogated throughout that amorphous
blob you're talking about. HOKEY is going to be creating a key hierarchy
and sending keys from that hierarchy to umpteen different entities.

  Whatever model you're insisting that is applicable to the EAP peer,
the EAP server and the authenticator is definitely not applicable to
the HOKEY peer, the HOKEY server, and every single authenticator that
the peer may wish to obtain network access from. No way. You can't call
that "2 party".

  Dan.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 1 Feb 2007 18:53:46 -0800

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Thursday, February 01, 2007 4:04 PM:

>> into "pass-through authenticator" & "EAP server") as the creation of
>> new "parties" to the EAP protocol.  However, EAP is & always has been
>> a two party protocol, the parties being the peer & authenticator,
>> _regardless of any physical separation_ of portions of the parties.
>> The authenticator may be fragmented however one wishes as long as a
>> couple of requirements are met: 1) the operation of the protocol
>> viewed as a black box remains the same & 2) the links (if any)
>> connecting the various pieces of the authenticator remain as secure
>> as 
>> if all those pieces were co-located.  In this case, it should be
>> fairly obvious that there is no need for the kind of handshake you
>> are talking about because it requires the spurious introduction of a
>> third party. 
> 
>   I don't know where you came up with those requirements. 

Dan, I didn't state any requirements, I just described how EAP works
(maybe you don't like how it works -- too bad) & stating my preference
for sticking with that model as it has been fairly well proven.

> The "black> box" > one boils down to "trust us, you don't have to
worry about what we're
> I-Ds to wrap keys when transiting that amorphous blob underscores
> this fact.    

You're confusing the view from the outside with the view from the
inside, I think.
  
> people and only 2 people is necessarily going to be better than a
> secret known by 3 people.   
> 
>   Also, if you don't have the identity of that 3rd party involved in
> the key distribution then you really don't know _exactly_ who you're
> giving the key to. That cannot be dubbed secure.  

The key is being transferred from the HOKEY server to the HOKEY client.
Are you saying that they don't know each other?  If not, I have know
idea what you _are_ talking about...

> 
>   Your model is 2 party; reality is 3 party. I think reality is
> something that we cannot ignore.

One more time: how many parties are there in an ATM transaction?  From
whose POV?  Do you insist that the both the ATM and the bank's central
computer authenticate themselves to you before you'll take the money?
Is the transaction not secure because of that?  Is that "reality"
3-party from _your_ POV?
 
> 
>   I frankly don't really care about fixing EAP. Channel binding can
> take care of that. And given that the EAP peer reauthenticates at
> each new authenticator the damage is pretty tightly controlled. But I
> don't think this protocol flaw (classic flaw number 4 from the
> Handbook of Applied Cryptography, by the way) should be propogated
> throughout that amorphous blob you're talking about. 

You know, I don't have a copy of that book handy.  When I get home, I'll
take a look.

> HOKEY is going
> to be creating a key hierarchy and sending keys from that hierarchy
> to umpteen different entities.       
> 
> the peer may wish to obtain network access from. No way. You can't
> call that "2 party".    

Only because you say so?

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 1 Feb 2007 23:54:27 -0800 (PST)

Glen,

> for sticking with that model as it has been fairly well proven.

  No you're not describing how EAP works. EAP is a 2 party protocol and
it's over when both parties have finished the exchange. Then something
else happens. The key that the 2 parties share is the given to a
3rd party.

> You're confusing the view from the outside with the view from the

  The "outside" vs. "inside" dichotomy you're talking about is artificial.
There is the reality of 3 parties knowing a secret. You want to wave
your hands over 2 of those parties and say "pay no attention to the man
behind the curtain! Nothing to worry about here! Move along! We have a
model that's only 2 parties!"

  If the NAS and AAA server were actually one party from a cryptographic
point of view it would not be necessary to wrap keys when sending them
from AAA server to NAS. But it is necessary. So they are not the same
entity.

> idea what you _are_ talking about...

  Wait, we're not talking about HOKEY we're talking about EAP. But as long
as you're changing the subject what is the identity of the authenticator
that the HOKEY server sends a key to? The HOKEY client has to know that
identity so it can generate the right branch of the key hierarchy. How
does the authenticator communicate that identity to the HOKEY server and
the HOKEY peer? It obviously has to be the same identity. But what if the
authenticator sends a different identity to the HOKEY server when he asks
for the key? Is there some protocol that would detect that? What protocol
would that be?

> Is the transaction not secure because of that?  Is that "reality"

  Horrible example. I don't authenticate my bank during an ATM transaction.
Maybe I should though because people have set up phoney ATMs and
extracted account information and PIN numbers. Seems like a flawed
protocol if that can happen. Is this the model you are proposing for
HOKEY? I sure hope not.

>> the peer may wish to obtain network access from. No way. You can't

  I'm getting tired of making statments in these exchanges because they
result in questions like that. So let me ask you a question and I hope
you will answer it:

  Do you think the same AAA model that governs the EAP peer and EAP server
will govern the HOKEY peer and HOKEY server? Can you explain why that
might be?

  Another question: since there's a HOKEY peer, a HOKEY server, and an
authenticator how can you claim there are only 2 parties?

  Dan.

---

From: Artur Hecker <[email-masked]>
Date: Thu, 1 Feb 2007 16:57:12 +0100

hi Dan, Glen

artur

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Feb 2007 09:52:48 -0500

Glen,

> it requires the spurious introduction of a third party.

You seem to assume Alice (mobile device) trust Bob (NAS and the AAA
infrastructure altogether) each other.  This trust model does not work
when the link between Alice and Bob is *wireless*.  We need to clearly
separate Bob into trusted part (AAA infrastructure which is Trent) and
untrusted part (NAS which is new Bob) and form a three-party model to
make it work.  Am I missing something?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Feb 2007 10:04:01 -0500

> Is the transaction not secure because of that?  Is that "reality"

Again this is based on the model in which Alice (customer) trust Bob
(ATM machine and the entire banking system) and the link between Alice
is Bob is physically secured.  This model does not work in wireless
enviroment.  Think about a scenario where the touch pad of the ATM
machine is broken and somehow replaced with wireless interface and you
need to send you card number and PIN using Bluetooth or WLAN or RFID
or whatever wireless technology.  Do you still trust the ATM machine?

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 2 Feb 2007 13:55:43 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Friday, February 02, 2007 6:53 AM:

...

> infrastructure altogether) each other.  This trust model does not
> work when the link between Alice and Bob is *wireless*.  

Interesting.  In that case, somebody should inform 802.11 immediately!

> We need to
> clearly separate Bob into trusted part (AAA infrastructure which is
> Trent) and untrusted part (NAS which is new Bob) and form a
> three-party model to make it work.  Am I missing something?     
> 
> Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 2 Feb 2007 14:05:47 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Friday, February 02, 2007 7:04 AM:

>> One more time: how many parties are there in an ATM transaction? 
>> From whose POV?  Do you insist that the both the ATM and the bank's
>> central computer authenticate themselves to you before you'll take
>> the money? Is the transaction not secure because of that?  Is that
>> "reality" 3-party from _your_ POV?
> 
> (ATM machine and the entire banking system) and the link between
> Alice is Bob is physically secured.  

I'm sorry, but you' (& Dan) seem to be painstakingly avoiding answering
my rather simple questions...

> This model does not work in
> wireless enviroment.  Think about a scenario where the touch pad of
> the ATM machine is broken and somehow replaced with wireless
> interface and you need to send you card number and PIN using
> Bluetooth or WLAN or RFID or whatever wireless technology.  Do you
> still trust the ATM machine?   

Presupposing that a change in media does not imply a change in the
attitude of banks toward money, I would suppose so.  In fact, I was
awarded a couple of patents a few years ago which were used by ATT to
implement wireless credit card verification & ATM machines using CDPD.
Apparently the link was secure enough for both the banks that bought the
machines & the people using them.