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

From: "Dan Harkins" <[email-masked]>
Date: Tue, 30 Jan 2007 22:54:51 -0800 (PST)

Hi Saber,

  You 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!

  Dan.

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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 30 Jan 2007 23:39:33 -0800

Dan Harkins <mailto:[email-masked]> allegedly scribbled on Tuesday,
January 30, 2007 10:55 PM:

...

> propogate this flaw into HOKEY.  

/WG Chair hat off
Let's just think about this for a minute.  AFAIK, the only way a NAS can
"lie" is if the secret key of that NAS is compromised (meaning that the
secret key is either known or can be used to encrypt/decrypt messages by
an entity other than the authorized one), right?  How is this different
than a situation in which I compromise any secret key (e.g., your
password)?  If it is no different, than there is no solution: in secret
key cryptography, if the secret becomes non-secret, the game is over?
In that case, I would say that there is in fact no problem & no flaw
other than that inherent in secret key cryptography.  Once you cease to
trust the trusted entities in any system, you might as well just give up
and go home.
  
> 
>   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!  
> 
>   Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 31 Jan 2007 00:02:26 -0800 (PST)

Glen,

  A NAS can tell the AS it is one identity and assert a completely
different identity to the client. Without channel binding you cannot
detect this lie. The "misplaced trust in server" flaw entails an
authenticator who has a trusted relationship with the AAA server but
the misplaced trust is that the client thinks the server is doing some
checking that it is not capable of doing.

  How is this different then if you compromise my password? Well there
is no way for me to know whether my password has been compromised in
this case! Normally the only two entities that know my password are me
and some server. Period. Full stop. If anyone other than me and the server
than knows my password means that means my password has been compromised.

  If you add some 3rd entity into the mix and say that the server will
only give my password out to certain trusted people but it is incapable of
demonstrating to me that it is abiding by that restriction then I have
no way of knowing whether some random entity on the network that happens
to know my password is really authorized to hold my password or whether
my password has been obtained by some nefarious organization. If we have
a secure 3 party protocol then I am able to know whether that entity is
authorized to hold my password since I took part in the protocol to give
it my password. If I notice that some entity seems to have my password
and I have no record of ever consenting to give it my password then my
password has been compromised.

  It's not that the server holding my password is not trusted, it's that
there is nothing in the protocol to make sure that it will do The Right
Thing, or even that it _can_ do The Right Thing.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 31 Jan 2007 00:15:47 -0800 (PST)

Glen,

  Let me ask you a question. Why does a protocol like Kerberos exist?

  If Alice wants to talk to Bob and both Alice and Bob have a trust
relationship with Trent then why can't Trent just give some Bob-specific
key to Bob that is derived from a key hierarchy built from the secret
he shares with Alice? Then all Alice has to do is go to Bob and, voila!,
the key exists and no nasty tickets and time stamps etc are needed.

  Kerberos is quite a bit more involved though. Why is that? What problem
is it trying to solve that is not solved by Trent just sending a key to
Bob?

  Dan.

---

From: "Saber Zrelli" <[email-masked]>
Date: Wed, 31 Jan 2007 22:40:39 +0900 (JST)

Hi Dan,

Thank you for your comment,
see my answer below

> 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.

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.

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.

Best Regards,
Saber.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Jan 2007 11:10:37 -0500

> trust the trusted entities in any system, you might as well just give up

It depends on what the trusted entities are.  When we discuss
AAA-based key transport it appears that the trusted entities are
basically physical boxes which runs AAA and AAA-related applications
inside it.  In such environment, one can say that key distribution is
secured because the transport between the trusted boxes is secured.
On the other hand, if we view that the trusted entities are protocol
entities inside the box, we cannot rely on AAA protocol security any
more.  Each AAA-related application protocols would need to have its
own security.

We can argue essentially the same thing for AAA protocol security
itself.  RADIUS has its own protection mechanism while Diameter relies
on underlying transport security.  Which is securer?

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 31 Jan 2007 10:36:20 -0800

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Wednesday, January 31, 2007 12:02 AM:

> different identity to the client. 

AFAIK, the NAS asserts no identity whatsoever to the EAP client....

> Without channel binding you cannot
> the misplaced trust is that the client thinks the server is doing
> some checking that it is not capable of doing.     
> 
>   How is this different then if you compromise my password? Well
> there is no way for me to know whether my password has been
> compromised in this case! Normally the only two entities that know my
> password are me and some server. Period. Full stop. If anyone other
> than me and the server than knows my password means that means my
>   If you add some 3rd entity into the mix and say that the server
> will only give my password out to certain trusted people but it is
> incapable of demonstrating to me that it is abiding by that
> restriction then I have no way of knowing whether some random entity
> on the network that happens to know my password is really authorized
> to hold my password or whether my password has been obtained by some
> nefarious organization. If we have a secure 3 party protocol then I
> am able to know whether that entity is authorized to hold my password
> since I took part in the protocol to give it my password. 

A couple of problems: first, neither AAA nor EAP are 3-party protocols &
I don't think that AAA _can_ be transformed into a 3-party protocol &
still scale; second, your logic leads to a hall of mirrors, I think.
Once I prove to myself that the NAS is not lying, how do I prove that
the antenna, modem, etc. between myself & the NAS is not lying?  The
5ESS switching the circuit?  The PGA inside the NAS? 

> If I notice
> that some entity seems to have my password and I have no record of
> ever consenting to give it my password then my password has been
> compromised.

If you notice...
           
> 
>   It's not that the server holding my password is not trusted, it's
> that there is nothing in the protocol to make sure that it will do
> The Right Thing, or even that it _can_ do The Right Thing.  

And if the server is lying, too?

> 
>   Dan.
> 
>> Dan Harkins <mailto:[email-masked]> allegedly scribbled on
>> Tuesday, January 30, 2007 10:55 PM:
>> 
>> ...
>> 
>>> 
>>>   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.
>> 
>> /WG Chair hat off
>> Let's just think about this for a minute.  AFAIK, the only way a NAS
>> can "lie" is if the secret key of that NAS is compromised (meaning
>> that the secret key is either known or can be used to encrypt/decrypt
>> messages by an entity other than the authorized one), right?  How is
>> this different than a situation in which I compromise any secret key
>> (e.g., your password)?  If it is no different, than there is no
>> solution: in secret key cryptography, if the secret becomes
>> non-secret, the game is over? In that case, I would say that there
>> is in fact no problem & no flaw 
>> other than that inherent in secret key cryptography.  Once you cease
>> to trust the trusted entities in any system, you might as well just
>> give up and go home.
>> 
>>> 
>>>   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! 
>>> 
>>>   Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Jan 2007 13:59:59 -0500

Saber,

> 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? :)

> 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.

> basic role of this AAA protocol (transporting key between EAP server and

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.

Yoshihiro Ohba

---

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

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Wednesday, January 31, 2007 12:16 AM:

> relationship with Trent then why can't Trent just give some
> Bob-specific key to Bob that is derived from a key hierarchy built
> from the secret he shares with Alice? Then all Alice has to do is go
> to Bob and, voila!, the key exists and no nasty tickets and time
> stamps etc are needed.     
> 
>   Kerberos is quite a bit more involved though. Why is that? What
> problem is it trying to solve that is not solved by Trent just
> sending a key to Bob?  

A more relevant question, I think, is "Upon what does the security of
Kerberos depend?"  The answer, of course, is the secrecy of the Kerberos
master key in the KDC: if KDC is compromised, the game is over BTW, it's
not clear to me that any 3-party protocol is immune to the threat of
collusion).  Basically, it seems to me that you are saying that if the
basic trust model of AAA is violated then there is a problem.  I don't
deny that, but I would say that that is just a (not particularly useful)
truism that applies to _any_ system.

...

---

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

Glen,

> 5ESS switching the circuit?  The PGA inside the NAS?

  Right, EAP is not a 3-party protocol but after EAP is finished the
resulting MSK is given to some other entity. That makes it a 3 party
protocol. We're also talking about a mobile device (one), some HOKEY
server that builds a key hierarchy (two), and an authenticator to which
the mobile devices wants to handover and for which a specific key from
the hierarchy is derived (three). The key distribution protocol involving
those 3 parties is a 3 party protocol.

  The antenna, modem, etc do not hold keys so if they're lying about
something it has no impact on the discussion at hand.

>> ever consenting to give it my password then my password has been

  Yes, if some authenticator says he already has my key when I attempt
to do a handover to him.

> And if the server is lying, too?

  The identity of the server has already been authenticated. What's
he lying about?

  Dan.

---

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

Glen,

  Yes, of course if the KDC is compromised the game is over. But I'm
not talking about compromise of the KDC. 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.

  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 analagously 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.

  Dan.

---

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

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

...

> something it has no impact on the discussion at hand. 

As I understand the so-called "lying NAS" problem, the possession of
keys is basically irrelevant.  In fact, maybe you could help me out
here: suppose that it really is a problem (of which I'm obviously
skeptical ;-), what is the threat?

...

>   The identity of the server has already been authenticated. What's

OK, what is the NAS lying about?  What's the point of lying?  Where's
the threat?  Seriously!  I've asked those questions multiple times of
multiple god-like security folks & never gotten an answer other than
mumbling...

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 31 Jan 2007 15:53:01 -0800

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

> 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?

> 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.
  
> to just give a key to Bob and analogously it is not OK for the HOKEY

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.  The user authenticates to & optionally authenticates a
rather amorphous entity you might call the Network.   

>> Kerberos depend?"  The answer, of course, is the secrecy of the
>> Kerberos master key in the KDC: if KDC is compromised, the game is
>> over BTW, it's not clear to me that any 3-party protocol is immune to
>> the threat of collusion).  Basically, it seems to me that you are
>> saying that if the basic trust model of AAA is violated then there is
>> a problem.  I don't deny that, but I would say that that is just a
>> (not particularly useful) truism that applies to _any_ system.
>> 
>> ...

---

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

Glen,

  The possession of keys is very relevant to the lying NAS problem.
But I can't even mumble as good as the god-like security folks you
talk to so can I refer you to the Handbook of Applied Cryptography?
Section 12.9 which discusses classic protocol flaws. Number 4 is
"Misplaced Trust in Server". That's the lying NAS problem. It talks
about it in terms of the Otway-Rees protocol but the analogy should
be obvious.

  The threat is that a key can be given to someone to whom it should
not be given. The outcome of a key distribution protocol should be a
situation where all parties have a common knowledge of the key and the
identities of all the parties with whom the key is shared. It should
not be possible for an attacker to mislead the participants in the
protocol such that they do not reach that necessary outcome. If it is
possible then the protocol is flawed.

  But what is the threat of the flawed protocol you ask? Flaws are
exploited in attacks and even if it was not possible for me to envision
an attack that exploits this flaw that does not mean the flawed protocol
is acceptable.

  Let me try anyway with a threat. These are symmetric keys used as a
network access credential. If it was possible for a key to be given to
someone to whom it should not have been given then that person who
received the key can turn around and impersonate the client to the person
that key _should have_ been given to. Or he could just wait for the
client to attempt a HOKEY handoff to the authenticator that he impersonated
and then he'll probably be able (assuming the session key is derived from
some 4-way-like handshake using the EMSK derivative) to evesdrop on the
client's conversation, inject badness into that conversation, and basically
do nasty things.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 31 Jan 2007 17:11:48 -0800 (PST)

Glen,

> 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.

> 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? 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?

> 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.

>              The user authenticates to & optionally authenticates a

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.

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Jan 2007 20:15:07 -0500

> from one he shares with Alice.

If Alice and Bob trust each other, they should be able to create a key
without KDC.

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 31 Jan 2007 20:14:44 -0800

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

>> 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?
> 
> 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.
 
>>> 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.
> 
> 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!".

> 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).   

>>> 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?
 
> 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.
> 

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.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 31 Jan 2007 20:26:15 -0800

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.

....