Subject: Re: [HOKEY] EMSK Hierarchy Changes

From: Charles Clancy <[email-masked]>
Date: Thu, 01 Feb 2007 16:27:56 -0500

Madjid, Yoshi,

"Authorization Context" means what you're authorized to do with a key. 
"Authorization Scope" means who's authorized to use the key.  Re-auth 
means doing some sort of authentication that generates a new EMSK. 
Re-key means using your EMSK hierarchy to generate a key to access the 
network.

Based on the conversation, let me correct my original picture:

EMSK (*.*) -+- home (*.home) -----+- USRK (service1.home)
             |                     \- HRK (handoff.home)
             \- domainX (*.domainX) -+- USRK (service2.domainX)
                                     \- HRK (handoff.domainX)

Then the HRK hierarchy would look like:

HRK (handoff.domain) -+- rMSK (handoff/port-access.domain/AP1)
                       +- rMSK (handoff/port-access.domain/AP2)
                       \- rMSK (handoff/port-access.domain/AP3)

Here "handoff/port-access" is an authorization sub-context of "handoff" 
and "domain/APx" is an authorization sub-scope of "domain".

I'm suggesting that each domain have its own HRK.  This allows the 
hierarchy to look the same regardless of the domain.

Certainly Yoshi's approach would work too, where we don't have our first 
level of keys being domain-specific.  This alleviates the need to cache 
domain-specific top-level keys somewhere.  However it would require 
anyone implementing a domain-specific USRK to develop their own local 
key-caching infrastructure.

In whatever keying hierarchy we decide to use, I just want to make sure 
that we're not, for example, deriving a new EMSK from an HRK.  This 
would violate our key scoping and context requirements.

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

Madjid Nakhjiri wrote:
> Hi Charles,
> 
> First, coming from AAA world and being deep up to my knees on a Dime
> discussion on separation of identity authentication and service
> authorization, I am not sure what "authorization scope" means. To me
> authorization means being allowed to use a service and the related USRK. I
> thought we had a discussion on "scope" versus "context". At least
> "authorization context" would make better sense:) In a pure sense of
> "authorization", the way the key hierarchy is done now, the home domain
> gives complete authorization rights away to the visited domain (but only
> within that visited domain) and that was my initial concern on putting USRK
> below visited-EMSKs, mind you.
> 
> Continuing on that note, as far as re-auth, It all depends on what sort of
> re-authentications you are allowing in domain2. Intra-domain re-auths are
> possible (and btw they don't lead to new EMSKs as you are saying). I think
> intra-domain re-auth operations are ok based on the below hierarchy (you can
> use reauth.domain2 key), but inter-domain re-auths are not. Inter-domain
> re-auths (when you move out of domain 2), need to be done by contacting home
> domain (i.e. the domain for initial EAP and EMSK) and use a re-auth key
> (domainreauth.home) derived from either EMSK.home directly or from HRK.home,
> but not from domain2-emsk
> So either of the following should work
> 
> 
> 					/-HOKEY(HRK.home)
> EMSK (*.*) -+- home (*.home)----Home (domainreauth.home)--
>             +- domain1 (*.domain1)
>             \- domain2 (*.domain2) -+- USRK1 (service1.domain2)
>                                     +- USRK2 (service2.domain2)
>                                     \- HOKEY (reauth.domain2)
> 
> 
> EMSK (*.*) -+- home (*.home)------HOKEY (HRK.home)-HOKEY(domainreauth.home)
>             +- domain1 (*.domain1)
>             \- domain2 (*.domain2) -+- USRK1 (service1.domain2)
>                                     +- USRK2 (service2.domain2)
>                                     \- HOKEY (reauth.domain2)
> 
> 
> I am still puzzled by "rekey" key as "anything that results from EMSK".
> 
> Madjid
> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 3:41 PM
> To: [email-masked]
> Subject: Re: [HOKEY] EMSK Hierarchy Changes
> 
> I think the following might clarify what Yoshi's talking about...
> 
> It might be very useful to attach authorization scopes and context to
> everything in our EMSK keying hierarchy, that way we can make sure we're
> not extending a derived key past the scope/context of its parent.   I'm
> using the notation (X.Y), where X is the service (context) and Y is the
> domain (scope).
> 
> Also, I'm going to use "re-auth" to refer to a process that derives a new
> EMSK, and "re-key" for deriving anything that results from the EMSK.  The
> only way to extend the context/scope of your key is to be re-authorized
> from scratch, which would require talking to your home EAP server.  Keys
> derived via "re-key" have a scope/context equal to or smaller than their
> parent key.
> 
> Below are my interpretations:
> 
> Current EMSK draft:
> 
> EMSK (*.*) -+- USRK1 (service1.*)
>             +- USRK2 (service2.*)
>             \- HOKEY (rekey.*) -+- homeRoot (reauth.home)
>                                  +- visitedRoot1 (rekey.domain1)
>                                  \- visitedRoot2 (rekey.domain2)
> 
> Problem: Keys derived from any HOKEY process cannot be used for anything
> other than re-key within a specific domain, because of their scope and
> context.  This means that any USRK requests in visited domains would still
> have to travel to the home EAP server.
> 
> Proposed changes:
> 
> EMSK (*.*) -+- home (*.home)
>             +- domain1 (*.domain1)
>             \- domain2 (*.domain2) -+- USRK1 (service1.domain2)
>                                     +- USRK2 (service2.domain2)
>                                     \- HOKEY (reauth.domain2)
> 
> This approach solves the above problem, but would require the local
> domain's AAA server to cache keys for us.  The local HOKEY server would
> request a USRK from the local AAA server.  Requests for local USRKs could
> be handled by the local AAA server.
> 
> Yoshi, it seems to me that in order to have scope/context work, we need to
> make the proposed changes to the EMSK hierarchy.  Or, have I completely
> misunderstood your point?  If so, could you specify the problem using the
> above notation, including scope and context?
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 01 Feb 2007 17:32:15 -0500

Hi Charles,

Regarding per-domain root keys, I still have an issue.  In order to
re-key a domain-specific USRK, re-key of the per-domain root key is
needed, but how?  The only way to re-key a domain-specific USRK with
this hierarchy is to do re-auth to the home domain.  This looks very
odd.  Is that what people want to do?

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 01 Feb 2007 15:07:42 -0800

I like the key hierarchy proposed by Charles.  The per-domain root key 
approach has the advantage that a key can be handed out to say domainX 
with the scope of domainX and may be used within the domain as per the 
rules/guidelines in USRK derivation specification(s).

On Yoshi's note : "In order to
re-key a domain-specific USRK, re-key of the per-domain root key is
needed, but how? "

To re-key domain specific USRK, it is plausible to derive a new one from 
the domain key (LMSK is what we called it last or was it EMSK jr. ;) ). 
  There is no need really to rekey the domain key itself.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 01 Feb 2007 18:49:39 -0500

>  There is no need really to rekey the domain key itself.

- What is the re-key protocol?  

Another questions:

- Who is the key holder of the domain key?

- How to distribute the domain key?  It seems that there is
three-party key distribution issue here as well.

Regards,
Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 01 Feb 2007 17:16:16 -0800

Hi Charles,

I understood those as "context" and "scope" and was objecting to the use of
"authorization", and I guess that triggered Glen's: obfuscating introduction
of non-existence strong link....comment;)

I don't quite agree with your definitions of re-auth, re-key, please see
below.

I think we are making progress on the key hierarchy, but still not there
yet,  a few comments:

1) You added HRK, that is fine, and you added one HRK per domain, that is
fine too (if we are going based on SJ agreements) since HRK is just another
USRK. However, my point is still not addressed and that was when you move
from one domain to another domain, you need a new domain EMSK and that EMSK
MUST come from the initial EMSK that resides in home domain, thus you MUST
authenticate to the home domain. And if we are still in the spirit of hokey,
that authentication should be efficient (not using the word fast to avoid
wordsmithing). So we need a re-auth to the HOME DOMAIN, thus we need a key
to do that re-auth and therefore, I added a "domainreauth" key in my
suggested hierarchy. I wanted to call it "alldomainreauth" to indicate that
all inter-domain handovers go this way, but I have been accused of using
long key names before.
This means the home domain hierarchy has one extra key that the other
domains don't and this slight asymmetry is ok to me.

2) once again I point out the difference between re-auth (re-authentication
to the AAA server, for whatever reason) and handover keying (i.e the need
for generating keys for each authenticator), so I am not sure if a re-auth
key (what is now called rMSK) used for re-auth to AAA server within the
domain is the same as the per-authenticator key. I don't agree that reauth
means generating EMSKs. And as far as I recall getting new keys for access
to the network through new attachments (HANDOVER) was called handover keying
(name of WG), not rekeying. To me rekeying means, you have a key and it is
expiring or compromised and you need a new one instead.

3) did not know we could go to AP level? Weren't we supposed to stay at
authenticator level?

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Thursday, February 01, 2007 1:28 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Madjid, Yoshi,

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 01 Feb 2007 17:21:16 -0800

Aside from the terminology (use of term re-key) I agree: a re-auth with home
is needed.

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, February 01, 2007 2:32 PM
To: Charles Clancy
Cc: Madjid Nakhjiri; [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Hi Charles,

Yoshihiro Ohba

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 2 Feb 2007 15:35:36 -0500 (EST)

Yoshi,

I would assume that in practice lifetime(EMSK) = lifetime (Domain-Specific
Keys), thus there would never be a need to re-key the domain-specific
keys, and as you mention re-auth would always be required.

Certainly people could deploy something else, where the lifetime of the
domain keys is less.  If they complain about having to re-auth, then it's
their problem.

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

On Thu, February 1, 2007 5:32 pm, Yoshihiro Ohba wrote:
>> >intra-domain re-auth operations are ok based on the below hierarchy
>> (you
>> >can

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 2 Feb 2007 15:48:10 -0500 (EST)

> - What is the re-key protocol?

If the liftime is equal to the lifetime of the EMSK, you won't ever need
to re-key.  However, if you really wanted a rekey protocol, you could
perform the same AAA protocol that distributes the key in the first place.
 We'd need to define some AAA exchange for this, but we're going to need
to do that anyway.

> - Who is the key holder of the domain key?

A local AAA server.

> three-party key distribution issue here as well.

The home EAP server transports it over AAA to the local domain's AAA
server.  It's a 2-party transfer.  We'd use channel bindings to properly
support the 3-party model.

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 2 Feb 2007 15:55:44 -0500 (EST)

On Thu, February 1, 2007 8:16 pm, Madjid Nakhjiri wrote:
> Hi Charles,
>
> However, my point is still not addressed and that was when you move
> authenticate to the home domain.

In the picture, there's a key called "home" and a key called "domainX". 
Perhaps they shoudl have been named better.  These are domain-specific
root keys derived from the original EMSK.  They are scoped for per-domain
use.  These are the same keys we called "EMSK jr" at the interim.  They
reside on the AAA server for each domain, and are transported there using
AAA.

> And if we are still in the spirit of
> hokey,

I think that key is improperly scoped.  You can't use it to generate keys
for a different scope.  Using the domain-specific root keys, you can still
quickly rekey in a visited domain.  There is no need to talk to the home
EAP server, provided the domain-specific keys were pre-emptively
distributed.

> domain is the same as the per-authenticator key.

There would be peer keys derived from the HRK used to secure the re-key
operation between the peer and the HOKEY server in the visited domain. 
The rMSKs would be distributed to the authenticators.

> I don't agree that reauth

Ah, I agree that can be another interpretation of the terminology.  It
might be useful to call it "handover keying" instead of "re-keying". 
Maybe even "ho-keying". ;)

> 3) did not know we could go to AP level? Weren't we supposed to stay at

In my picture, AP == authenticator, which is certainly the case for 11i.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Feb 2007 16:44:18 -0500

Thank you for the clarification.

It does not make sense to require the AAA server in the local domain
to store a per-domain root key when authentication to move into the
local domain did not use the local AAA server at all (i.e., when the
authenticator in the local domain directly communicated with the AAA
server in the home domain).  Especially the mobile device needs to
know the identity of the local AAA server (in addition to the identity
of HOKEY server in the local domain) for handover keying to work.
This seems architectually an odd requirement.  I am still suspicious
about the need for per-domain root key.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 02 Feb 2007 13:45:49 -0800

Yoshi,

We cannot require an entity to hold a key it does not want!  So, no need 
to worry :).

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Feb 2007 16:50:42 -0500

> We cannot require an entity to hold a key it does not want!  So, no need 

I am so puzzled.  Then why do you need the key at all??

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 02 Feb 2007 13:52:56 -0800

Yoshi,

As I noted, if there is a local AAA server and it wants to support 
efficient re-authentication based on HOKEY protocols and the Peer wants 
to use that, it can (that is what we are chartered to do).  If a domain 
says it doesn't want to do that, we cannot force that domain and 
entities there in to hold any keys (we cannot force feed anyone).

HTH

Lakshminath

---

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

> entities there in to hold any keys (we cannot force feed anyone).

But the key hierarchy does not seem to be consistent with what you are
saying.  Regardless of whether there is a local AAA server, per-domain
key must be derived from EMSK, and the per-domain key is defined to be
held by a local AAA server.  I think this is a problem.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 02 Feb 2007 15:06:32 -0800

Yoshi,

If there is no local AAA server, it cannot hold a key :).  There is no 
derivation required either.  You may be confused here.  Let's drop this 
line of debate for now and we can discuss it when the text gets written.

thanks,
Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Mon, 05 Feb 2007 16:48:21 -0500

If there isn't a local AAA server, what defines it as a "domain" 
distinct from the home domain?  I don't see how authenticators 
communicating directly with a home AAA server would be capable of 
performing handoffs.

I CAN imagine a situation where you don't have a local EAP server, but I 
CANNOT imagine a situation where you don't have a local AAA server. 
Your HOKEY server's going to be talking AAA to *someone* to get its 
keying material, so it's going to be a AAA device on the local network. 
  It should be fairly simple to make it your local AAA server if you 
don't have one already.  In that case, domain-specific keys are cached 
at the AAA layer of the HOKEY server, and the ho-keys are passed up to 
the HOKEY server.

Graphically:

Local AAA Server:

AUTHENTICATOR  ---  LOCAL AAA  ---  HOME AAA
                \        |
                 \       |
                  -  HOKEY server

No Local AAA Server:

AUTHENTICATOR  ---  HOKEY server (implements AAA server) --- HOME AAA

I very much expect HOKEY servers will be implemented much like EAP 
servers -- logically separate from AAA servers, but physically the same 
device.

Not requiring a local AAA server for HOKEY would be like implementing an 
EAP server without requiring a AAA server to support it.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 5 Feb 2007 15:39:18 -0800 (PST)

Charles,

  Is it your contention that the 4 entities you draw graphically below
all share keys using a 2 party protocol? And that when we start adding
some more authenticators into the mix (the whole point of this group,
right?) it looks like this:

 AUTHENTICATOR  ---  LOCAL AAA  ---  HOME AAA
                 \        |
                  \       |
                   -  HOKEY server
                     /      |    \
                    /       |     \
                   /        |      \
            authenticator   |     authenticator
                            |
                       authenticator

and everything still fits into the "AAA model" (there's just 2 parties
involved)? Is that your vision? No 3 party protocols involved? If I'm
wrong can you point out what key distribution would involve 3 parties?

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 5 Feb 2007 15:48:51 -0800 (PST)

Hi Charles,

  I forgot to draw the client. Damn!

  AUTHENTICATOR  ---  LOCAL AAA  ---  HOME AAA
     |            \        |
     |             \       |
     |              -  HOKEY server
     |                /      |    \
     |               /       |     \
     |              /        |      \
     |(1)    authenticator   |     authenticator
     |       /               |           |
  client    /           authenticator    |
   | \  \__/(2)         /                |
   |  \________________/ (3)             |
    \                                    |
     \___________________________________/ (4)

Client starts at (1), then hands off to (2), then hands off to (3)
then hands off to (4). Any 3 party protocols involved in all this
key distribution, or is it all still the "AAA model"?

  Dan.

---

From: Charles Clancy <[email-masked]>
Date: Mon, 05 Feb 2007 19:15:12 -0500

Dan,

Very nice ASCII art.

First, I expect the HOKEY server and the local AAA server to be the same 
machine, so they wouldn't represent separate parties, much as the EAP 
server and AAA server aren't different parties in a normal EAP 
authentication.  Though, if we're giving keys specifically to AAA 
servers, we may want to revisit this.

Thus, we have the peer, authenticator, HOKEY server, and EAP server. 
They communicate using the following protocols:

peer       authenticator         HOKEY server       EAP server
   <-- L2 ---->    <----- AAA ------->   <------ AAA ----->
   <------------- EAP/HOKEY ----------->

I'd like to see channel bindings included hierarchically, for example 
the key distributed from the EAP server to the HOKEY server is already 
bound to the EAP server, HOKEY server, and peer (which reflects its 
scope).  The handoff key derived from that that's then send to the 
authenticator would be channel bound (binded?) to the peer.  The idea 
being that we cryptographically bind the key scope into the key 
derivation itself.  Then the eventual rMSK shared by the peer and 
authenticator would already be properly bound.  Thus in the end we get a 
4+ party authentication in the end.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 05 Feb 2007 16:14:13 -0800

I am confused about the position of the HOKEY server in the first 
diagram.  How does it communicate to the HOME AAA to get the necessary 
root key?  Via the authenticator?   That doesn't sound right!  Please 
clarify.

thanks,
Lakshminath

Charles Clancy wrote:
> CANNOT imagine a situation where you don't have a local AAA server. Your 
> HOKEY server's going to be talking AAA to *someone* to get its keying 
> material, so it's going to be a AAA device on the local network.  It 
> should be fairly simple to make it your local AAA server if you don't 
> have one already.  In that case, domain-specific keys are cached at the 
> AAA layer of the HOKEY server, and the ho-keys are passed up to the 
> HOKEY server.
> 
> Graphically:
> 
> Local AAA Server:
>

---

From: Charles Clancy <[email-masked]>
Date: Mon, 05 Feb 2007 19:26:57 -0500

The HOKEY server would be implemented right on top of AAA just like the 
EAP server is now.  It communicates with the home AAA server via the 
local AAA server.

Lakshminath Dondeti wrote:
>> I CAN imagine a situation where you don't have a local EAP server, but 
>> I CANNOT imagine a situation where you don't have a local AAA server. 
>> keying material, so it's going to be a AAA device on the local 
>> network.  It should be fairly simple to make it your local AAA server 
>> if you don't have one already.  In that case, domain-specific keys are 
>> cached at the AAA layer of the HOKEY server, and the ho-keys are 
>> passed up to the HOKEY server.
>>
>> Graphically:
>>
>> Local AAA Server:
>>
>> servers -- logically separate from AAA servers, but physically the 
>> same device.
>>
>> Not requiring a local AAA server for HOKEY would be like implementing 
>> an EAP server without requiring a AAA server to support it.
>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 05 Feb 2007 17:05:22 -0800

Never mind.  I was looking at the figure in the wrong type of email 
reader :).  Sorry!

Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 05 Feb 2007 22:05:40 -0800

Hi Charles, 

Sorry for the delay in responding and sorry for going through the emails in
chronological order:) I understand that once you give a domain its root key
(EMSK-jr or DSRK), the domain does not have to go to the home (ignoring the
scope debate for now) for dealing with internal matters. 

My point was how does the peer and the new domain get that EMSK-jr to begin
with? 
You have to the initial server that has the top EMSK to ask it to generate a
EMSK-jr for your new domain? Where is this initial server? At home off
course? No? I am not saying the new domain EMSK-jr has a home scope, but in
reality it is the home that hold the EMSK.
Now, unless you are assuming that the initial server creates all EMSK-jr for
perceivable domains right at the start proactively (which does not sound
practical to me), the EMSK-jr for each domain has to be generated per
request as the peer enters the new domains.

And yes, hokeying is more appropriate of rekeying in the context of
handovers. 
AP=authenticator may be accurate for 802.11 but is not in general. It is not
even the case in CAPWAP and it is not in WiMAX, so we need to decide whether
we can or cannot go below the authenticator. Are we now saying we can go
below authenticator by mapping BSs to authenticator ports? I didn't think we
could do channel binding based on port numbers? Can we?

Madjid

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 05 Feb 2007 22:28:51 -0800

I may be misunderstanding something in the picture below, but I am having a
hard time justifying all these entities, a home AAA server that implements a
logical EAP server (doing 3748 EAP server function) is good enough for me.
Unless by local AAA server, we mean a AAA server that serves a visited AAA
domain, Not sure why we need a separate "local AAA" and "hokey server" at
home?

If we care so much about logical separations, to me all we need is the
following

			AAA server-----EAP server
		Holds Any child		holds EMSK
			 Of EMSK

I don't know why we cannot just assume a AAA server can do hokey, just like
a lot of other things a AAA server does. People who go to AAA server for
Mobile IP don't spawn a Mobile IP server out of AAA server, why are we
spawning a "hokey server"? AAA vendors today bundle any RFC they like into
their servers.

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 1:48 PM
To: Yoshihiro Ohba
Cc: Lakshminath Dondeti; [email-masked]; Madjid Nakhjiri
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Graphically:

Local AAA Server:

No Local AAA Server:

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 05 Feb 2007 22:36:03 -0800

As I said, I think the home AAA server (that also implements the EAP server,
that holds EMSK), also implements hokey. So to me hokey server IS the AAA
server and since home AAA server and EAP server are the same, you don't need
AAA to talk between what you call hokey server and the EAP server. It should
be a local API. This come from the way USRKs are generated from EMSK.

A local AAA server will come in only when you are in visited domain.

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 4:15 PM
To: Dan Harkins
Cc: [email-masked]; Madjid Nakhjiri
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Dan,

Very nice ASCII art.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 05 Feb 2007 22:40:40 -0800

Wow Dan,

Nicest email I have seen in all my IETF years.
Stealing your nice art work, I see this as following:
local AAA server (which I like to call visited AAA server)
comes in only when the authenticator belongs to a visited domain.
There is no AAA between EAP server and home AAA.
Home AAA implements hokey logic and you have traditional AAA model between
the AAA server and the authenticators.

  AUTHENTICATOR  ---  home AAA  ---  EAP server
     |                HOKEY logic
     |                /      |    \
     |               /       |     \
     |              /        |      \
     |(1)    authenticator   |     authenticator
     |       /               |           |
  client    /           authenticator    |
   | \  \__/(2)         /                |
   |  \________________/ (3)             |
    \                                    |
     \___________________________________/ (4)

Madjid

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 3:49 PM
To: Dan Harkins
Cc: Charles Clancy; [email-masked]; Madjid Nakhjiri
Subject: Re: [HOKEY] EMSK Hierarchy Changes

  Hi Charles,

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Feb 2007 10:42:58 -0500

Hi Charles,

On Mon, Feb 05, 2007 at 04:48:21PM -0500, Charles Clancy wrote:
> distinct from the home domain?  

It can be the DNS domain name of the local domain that can give the
distinction.

> I don't see how authenticators 

I CAN imagine a situation where there is no EAP server or a AAA server
in the local domain but there is a HOKEY server.  Please see below.

> keying material, so it's going to be a AAA device on the local network. 

I don't think AAA is always needed for the HOKEY server to get its
keying material for handover keying.  For example, if we consider a
case in which a Kerberos-like 3-party key distribution protocol, there
is actually no need for key distribution from home AAA server to the
local HOKEY server at all.  Instead, the home AAA server can just
issue an inter-realm TGT to the mobile device at the time of initial
authentication, and then the mobile device can talk to the HOKEY
server using the TGT for further operations.  On the other hand, this
does not mean we must not use AAA.

In any case, I believe use of a 3-party key distribution mechanism
that DOES NOT rely on underlying transport security (such as AAA
transport security) is an important requirement.  A 3-party key
distribution mechanism that relies on underlying transport security
has a problem because there is *no cryptographic way* for any party
that involves in the key distribution to make sure the underlying
transport was actually secured.  MSK-branch of EAP keying has this
problem.  I don't think we should not inherit the same problem to
*handover keying* which does not have to be based on EAP or AAA, while
it may be a bit impractical to depart from EAP-keying for *re-auth*
which is based on EAP and AAA.

Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Tue, 06 Feb 2007 11:32:45 -0500

Yoshi,

I agree that if you're using a Kerberos-like approach, local AAA servers 
are not necessary.

It's difficult to design a re-key protocol without consideration of how 
the ho-key protocol will work.  In particular, if the ho-key protocol is 
going to be AAA-based, then I feel defining domain-specific root keys is 
appropriate.  If it's going to be Kerberos-based, then perhaps it's not.

My understanding of the consensus is that we're not considering 
Kerberos-based approaches.

---

From: Charles Clancy <[email-masked]>
Date: Tue, 06 Feb 2007 12:01:02 -0500

Madjid,

If a reactive approach is being used, I would expect the visited 
HOKEY/AAA server to request a DSRK during the initial ho-key (ho-auth?) 
in the visited domain.  Here's the scenario for a visited domain:

1. peer initiates handoff to visited domain
2. visited AAA server requests a DSRK from home EAP server
    DSRK = KDF(EMSK, scope=domainX, context=*, chbindID=AAAsvr.domainX)
3. EAP server sends DSKR to visited AAA server
4. visited HOKEY server requests HRK from visited AAA server (via API)
    HRK = KDF(DSRK, scope=domainX, context=hokey,
              chbindID=HOKEYsvr.domainX)
5. peers has knowledge of the domain and the chbindID for the AAA server
    and HOKEY server because it was advertised in the L2 beacons, so he
    can compute the DSRK and HRK
6. peer proves knowledge of HRK (or some child key) by doing some sort
    of packet exchange
7. peer and HOKEY server derive rMSK
    rMSK = KDF(HRK, scope=authenticator1.domainX,
               context=hokey/portaccess, chbindID=ap1.domainX)
8. HOKEY server distributes rMSK to the authenticator
9. peer and authenticator perform L2 key handshake to derive session
    keys

In the end, we've used a series of 2-party key agreement protocols to 
generate a keying hierarchy whose bottom-most keys are channel bound to 
every entity involved in their derivation and transport.

---

From: Charles Clancy <[email-masked]>
Date: Tue, 06 Feb 2007 12:05:05 -0500

By "local" I mean "visited".  I would expect that just as AAA and EAP 
servers are physically colocated, I would expect AAA and HOKEY servers 
to be physically colocated as well.

We're using AAA as a transport protocol, much like EAP does.  We can't 
just ignore it though, because some keys are AAA-specific and some are 
EAP-specific and some are HOKEY-specific.  Thus, to distinguish where 
keys should be delivered and to whom, it's necessary to include a 
logical AAA server that caches some keys.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 6 Feb 2007 11:57:20 -0800 (PST)

Hi Charles,

  This I see this as a problem: "we've used a series of 2-party key
agreement protocols to generate a keying hierarchy".

  In #2 below the visited AAA server requests a DSRK. I assume it is
going to say, "my chbindID=AAAsrv.domainX" and the home EAP server would
generate a DSRK and give it to the visited AAA server. What if that AAA
server was really "AAAsrv.domainY"? It tells the home AAA server it is
"AAAsrv.domainX" and gets a root key for a completely different domain.

  In #7 an rMSK is created based partially on "chbindID=ap1.domainX".
How does the authenticator communicate this identity-- ap1.domainX" to
the HOKEY server? What if its identity really was ap2.domainX and said,
"give me the rMSK for ap1.domainX". Would it get the rMSK for ap1.domainX?

  These are 3 party protocols-- client (Alice) wants to speak to
authenticator (Bob) and uses key shared with HOKEY server (Trent) to
facciliate this-- and you can't fudge them with a series of 2 party
protocols.

  I think that part of #1 MUST include the transmission of a tamper-proof
blob that binds the visited AAA server and/or HOKEY server to the
transaction. That blob is sent to the home AAA server. The protocol MUST
entail the home AAA server decrypting the blob and verifying that the
identity of the visited AAA server and/or HOKEY server inside the
tamper-proof blob (send by the client) is the same as the identity of the
visited AAA server and/or HOKEY server that is sending the blob which it
cannot tamper. The home AAA server MUST send a tamper-proof
acknowledgement
back to the client to let it know that the handshake completed.

  A similar handshake MUST take part in the distribution of the rMSK.
The client MUST send a tamper-proof blob to the local HOKEY server through
the authenticator in domainX which identifies that authenticator. The
HOKEY server MUST decrypt that blob and verify that the identity of the
authenticator inside the tamper-proof blob is the same as the identity
of tha authenticator sending the tamper-proof blob to it. It MUST also
send back an acknowledgment to the client to let it know the handshake
completed.

  Protocols such as Wide-Mouth Frog and Otway-Rees are examples of what
is needed to solve this problem. Neither is 100% applicable to HOKEY but
we can come up with something close to them that is.

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 06 Feb 2007 08:46:53 -0800

I have two words: "logical entity"

Oh more words:  Charles wrote this earlier "First, I expect the HOKEY 
server and the local AAA server to be the same machine,"

Does that alleviate your concerns?

Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Wed, 07 Feb 2007 07:59:20 -0500

> agreement protocols to generate a keying hierarchy".

Indeed.  I'm not quite so sure it's a problem though.

 > What if that AAA
 > ...
 > What if its identity really was ap2.domainX and said,

Every device from the authenticator through the home EAP server has a 
security association, and has an identity bound to that security 
association.  It prevents the layer below you from telling you a fake 
identity when it requests a key.

 > facciliate this-- and you can't fudge them with a series of 2 party

I don't agree.  You're proposing a series of 3-party protocols.  How is 
that fudging any less?

First of all, we have a hierarchy that delegates trust, and the ability 
to generate keying material.  Thus, the home EAP server really doesn't 
need to know the ID of the authenticator on the other side of the 
network.  (And looking at your proposal, I don't think you think the 
home EAP server should know the ID of the authenticator.)  Due to this, 
I think the approach of binding network-side identities into the key 
derivation works well.

As for the client, provided we can communicate all these identities to 
it, we solve the lying NAS (and lying HOKEY server (and lying visited 
AAA server))) problem.

With the approach I described, do you see any way a device could provide 
inconsistent identities?

I have no fundamental objection to a 3-party protocol.  But we have 5 
parties involved:

peer - authenticator(rMSK) - HOKEY(HRK) - AAA(DSRK) - EAP(EMSK)

I'm proposing 2-party key agreements:
   peer-authenticator
   authenticator-HOKEY
   HOKEY-AAA
   AAA-EAP

Based on your suggestion, I think you're saying we need the following 
multi-party key agreements:

a. peer-EAP (regular EAP)
b. peer-HOKEY-EAP (first ho-auth)
c. peer-authenticator-HOKEY

So in #1 (of my original proposal), the peer would actually need to send 
2 blobs, one to satisfy (b) and one to satisfy (c)?  The visited HOKEY 
server would keep (c) and pass (b) to the home EAP server?  Then 
whenever you did a handoff in the visited domain you would just need to 
do (c) again?

Thus, we're doing basically the same thing as I proposed, but involve 
the peer in every key agreement.  To properly implement your proposal, I 
think we'd need to actually do the following instead:

a. peer-EAP
b. peer-AAA-EAP
c. peer-HOKEY-AAA
d. peer-authenticator-HOKEY

Thus during #1 the peer would send blobs (b), (c), AND (d).  Then to do 
a handoff he'd just send (d).  That accounts for the DSRK in the keying 
hierarchy.

I think the biggest thing this does for us is allows the peer to 
authorize each key derivation and distribution to the next lowest layer 
of the hierarchy.  From a channel bindings / lying-device perspective, 
there is no security difference.

Is having the peer authorize distribution of keys is important?

... for reference ...

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 8 Feb 2007 14:04:35 -0800 (PST)

Hi Charles,

> Dan Harkins wrote:
[snip]
> identity when it requests a key.

  What is the identity bound to that security association and how does
is it relevant to another layer?

  For instance, let's say it's an IPsec SA. It is bound to an IP address.
How is that identity known to another layer? How does the IP address of
the wired port of an AP become known to a wireless client of that AP? It
doesn't! The AP is identified by the client by BSSID and by the AAA
server by IP address.

  Or it could be like a RADIUS client implementation where it assigns some
static secret to authenticate itself to the RADIUS server and protect
parts of certain messages. Again, that security association is bound to
something like an IP address. Through that security association you can
send "my identity is AP2.domainX" just as easily as "my identity is
AP1.domainX" and the message will be received and correctly processed.

  Of course you can make it so your implementation is not susceptible to
this sort of impersonation but then you're doing essentially what would
be required by a secure 3 party protocol. That being the case why not
just put that work into the key distribution protocol to ensure that it
is done securely always and everywhere?

> I don't agree.  You're proposing a series of 3-party protocols.  How is

  The 2 party protocol is being justified because the client is unaware
of whether the secret he knows is known by 1 other entity or 2 other
entities, thanks to the AAA model. Since it is possible that the secret
could only be known by one other person it is argued to be a 2 party
protocol, the 2 parties being the client and "EAP server".

  But when you get into the mode of distributing keys between 3 parties
where all three parties know there are 3 parties then you can't say
"AAA model" anymore.

  It's not a series of 3 party protocols. There is one involving the
initial EAP exchange which we are not tackling and have decided to not
debate in this forum anymore. Then there is a 3 party protocol of a
HOKEY server distributing keys to authenticators in the same domain and
a separate 3 party protocol where a HOKEY server one domain distributes
a key to a HOKEY server in another domain.

> I think the approach of binding network-side identities into the key

  Binding identities into the key derivation is necessary but not
sufficient. What is also needed is an assurance that the an entity is
not given the wrong key.

> it, we solve the lying NAS (and lying HOKEY server (and lying visited

  We can only solve that problem if we can ensure that AP2.domainX cannot
receive a key for AP1.domainX (and also ensure that HOKEY-SERVER.domainY
cannot receive a key for HOKEY-SERVER.domainZ). If the protocol cannot
prevent it (i.e. the secure solution depends on trusting the wisdom and
integrity of the guy writing the code or the vendor supplying the boxes)
then the protocol is broken.

> With the approach I described, do you see any way a device could provide

  I believe I described one above. If you feel I didn't ask again and I'll
try again.

> c. peer-authenticator-HOKEY

  I think (a) is outside of HOKEY. Also, after discussion with Glen at
the ad-hoc I'm a little confused about (b). Glen was saying that the
HOKEY server could just look like a proxy AAA server. (c) yes, that's
one. The other would be

  d. peer - HOKEY.x - HOKEY.home

where the HOKEY server in a different domain obtains a key to use for
all authenticators in his domain.

> whenever you did a handoff in the visited domain you would just need to

  These are, or should be, separate handshakes. For practicality it may
be necessary to piggy-back 2 of them on a single request-response (what
you say about 2 blobs being sent).

> d. peer-authenticator-HOKEY

  Yes, except, as I said I think (a) is out of scope, and depending on how
(b) is done it may or may not need to be solved by us.

> Is having the peer authorize distribution of keys is important?

  I believe there is a difference from a channel bindings point of view
because there is no binding if the HOKEY server is just gratuitously
giving out keys, or giving out keys intended for a particular identity
through a channel that is not authenticated by that particular identity.
There has to be a protocol such that each party agrees on the identity of
each other party. Just mixing identities into the keys does not do channel
binding.

  Yes, authorization of distributed keys is important too because it can
be used to alert the peer as to when the key heirarchy has been
compromised-- if AP2.domainX has a key for the peer and the peer did not
participate in a 3-party protocol involving AP2.domainX and
HOKEY-SERVER.domainX then he knows something stinks in keyland and should
immediately throw away the heirarchy.

  Dan.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 08 Feb 2007 14:32:09 -0800

Hi Charles,

Thanks for the breakdown. 
First, a couple of minor things, 
1) I would say chbindID needs to include both AAAsvr and peer, since channel
should be bound to two peers.
2) Similar point regarding scope, if scope meant who can use the key, I
thought it would be the server and the peer, not the entire domain (all
nodes in the domain?), just trying to be consistent, may be context would be
a pair (peer, AAAsvr.domainX) again?

Second, the major point: between your steps 1 and 2, you are assuming that
visited AAA server represents the peer in a key request from home EAP
server! This is where I was suggesting a re-auth key. The peer needs to
re-auth to the home server to be authorized for a handover to the visited
domain and for that it signs a request with re-auth key.

Also on your step 6, why does the peer need to prove knowledge of HRK (I am
assuming to visited AAA server?), The peer does not need to interact with
AAA server directly. The proof of possession can be done for a lower level
key with an entity that is in contact with the peer, i.e an authenticator or
a base station as part of an L2 handshake (where you also add anti-replay
measures). All parameters needed to derive higher level keys can be
transported in the signaling.

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 9:01 AM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Madjid,

---

From: Charles Clancy <[email-masked]>
Date: Fri, 09 Feb 2007 07:53:49 -0500

Dan,

Rather than respond to everything individually, let me just say that I'm 
beginning to be convinced.  I still think that, for example, defining 
and distributing consistent identities is just has hard in both models, 
but I can see it being harder to make an insecure implementation with a 
3-party approach.

For reference:

 >> a. peer-EAP (EMSK)
 >> b. peer-AAA (DSRK) - EAP (EMSK)
 >> c. peer-HOKEY (HRK) - AAA (DSRK)
 >> d. peer-authenticator (rMSK) - HOKEY (HRK)

Certainly (a) is out of scope.  (b) and (c) are outside the scope of 
ho-keying in general, but we need something defined in order to create a 
functional protocol.  HOKEY then defines (d).

 > d. peer - HOKEY.x - HOKEY.home

I don't think HOKEY.x needs to talk to or be bound to HOKEY.home. 
HOKEY.x needs to talk to EAP.home.  The HRK for "x" and "home" are 
cousin keys, and cryptographically independent.  The binding needs to 
come from the top, the EMSK.

I propose something like the following to solve (b) and (c):

globalBK = KDF(EMSK, "binding key"), context=binding, scope=*
domainBK = KDF(DSRK, "binding key"), context=binding, scope=domain

DSRKtkt = hash(globalBK, peer ID, home EAP ID, visited AAA ID)
HRKtkt = hash(domainBK, peer ID, visited AAA ID, HOKEY ID)

1. During the HOKEY reauth, the peer generates the DSRKtkt and HRKtkt
    and sents them to the HOKEY server.
2. HOKEY server would send a request to the [visited] AAA server (likely
    though some API) requesting an HRK and would include both the DSRKtkt
    and HRKtkt
3. AAA server would then request a DSRK from the EAP server, and
    would include the DSRKtkt
4. DSRK would then be distributed over AAA, and then the HRK could
    be generated and delivered to HOKEY.

This provides a HOKEY-independent way to secure the DSRK and HRK.  This 
would help ensure that the DSRK and HRK were only distributed to 
authorized parties.  Certainly HOKEY would perform something similar to 
satisfy (d) for the rMSK.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 09 Feb 2007 10:03:30 -0500

Hi Charles,

This would be a great step.

There may be several alternative ways for distributing keys in a
secure 3-party key distribution protocol, but I fully agree that it is
better to work on a 3-party key distribution protocol that is securer
than EAP keying.

In your proposed approach, HOKEY server should be able to send the
request directly to the home EAP server without using the local AAA
server.  I mean, local AAA server and DSRK should not be mandatory for
handover keying.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 09 Feb 2007 16:53:04 +0100

> Hi Charles,
Hi all,

Personally, I also think that considering a 3-party key distribution
protocol is a good way to proceed.

Best Regards.
>>>>> "give me the rMSK for ap1.domainX". Would it get the rMSK for
>>>>>           
>>>> ap1.domainX?
>>>>

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 09 Feb 2007 10:58:20 -0800

Well, if we are insisting on having a logically separate HOKEY server, then
both home and visited domain need to have a HOKEY server each, i.e. 

		Visted AAA server-------------Home AAA server
			|					|
		Visited HOKEY server		home HOKEY server.

And I suggested to get rid of term "local". When I am out of town, I am
visiting, I am not local, even if I stay for a month:)

Madjid

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 09 Feb 2007 11:01:17 -0800

I just responded to this with more than 2 words. Let me ask you this, does
your ISP charge you per words typed?? Most of ISPs have flat rate these
days:) 

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 8:47 AM
To: Madjid Nakhjiri
Cc: 'Charles Clancy'; [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Lakshminath

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 09 Feb 2007 11:27:16 -0800

Hi Dan, 

If I may jump in the middle here...

On your comment on #2, that is why I was asking for a generic re-auth key to
Home EAP server, the peer sends a request for a handover to a new visited
domain and signs it with that key. The visited domain server encapsulates
the request on AAA along with extra stuff (see below) and signs with its
security association with home AAA server.

Also during San Jose meeting I presented a channel binding solution that
verifies the identity of the middle entity (in DSRK case, visited AAA server
identity, in HRK case, the authenticator/AP identity). So here is the
solution (ME: middle entity)

Peer-------------ME-----------server
The peer and server share a key, say (Kps) and the ME entity and server
share a key, say (Kms).

If the downlink id (DID) of middle entity (shown to peer) is included in the
(peer request, MAC) and signed with Kps and the uplink ID of ME (shown to
server) is included the AAA(peer request, MAC), MAC signed with Kms.

The server checks both MACs, each with a different key and assures about
ME's identity.
After key generation at server and peer (just like EAP MSK/EMSK), the key
only needs to go to ME from server (using Kms)

Do you still see the issue you mentioned for 2 party protocols?

Madjid 

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 11:57 AM
To: Charles Clancy
Cc: Madjid Nakhjiri; [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

  Hi Charles,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 9 Feb 2007 12:21:55 -0800 (PST)

Hi Madjid,

  From a 10,000' perspective I'd say yes that's about right. But there
is quite a bit of detail needed to take care of things like interleaving
attacks, replay issues, and key confirmation. In an earlier email I
mentioned Otway-Rees. Check it out.

  Also, I think that a key notarization scheme can be used to solve this
problem as well. There are benefits and drawbacks to each.

  Dan.

>>> Sorry for the delay in responding and sorry for going through the
>>> emails
>>> in
>>> course? No? I am not saying the new domain EMSK-jr has a home scope,
>>> but
>>> in
>>> Now, unless you are assuming that the initial server creates all
>>> EMSK-jr
>>> for
>>> AP=authenticator may be accurate for 802.11 but is not in general. It
>>> is
>>> not
>>>> (name of WG), not rekeying. To me rekeying means, you have a key and
>>>> it
>>>> is

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 9 Feb 2007 16:19:05 -0800

I've tried to follow the discussion under the various threads and am a
bit confused at the moment, as to what the real problem is. I think this
is all pointing to the channel binding problem, as this thread
indicates. It primarily exists with today's MSK, because the key is not
bound to the authenticator in any way. It is implicitly already bound to
the peer, since it is derived as a result of verification of that
particular peer's credentials. However, with the DSRK (domain specific
root key), the key is going to be bound to a domain (or a server) by
derivation - 

DSRK = PRF (EMSK, "Domain name or server name") for example.

In other words, the domain information is already part of the key and
hence the key cannot be used in any other domain. 

Further, for derivation of the HRK, which is a USRK, it must use the
guidelines in draft-ietf-emsk-hierarchy, which means there is a service
label that identifies it as the HRK. For e.g.,

HRK = PRF (DSRK, "HOKEY Root Key") 

Since the DSRK is bound to the domain/server, so is the HRK
automatically bound to the same domain/server. The context is specified
by the label. 

Delivery of the DSRK independent of the HOKEY process is outside the
scope of the HOKEY charter as I see it. In order to perform re-auth
within a local domain, a DSRK must be available to that domain. Also, I
can't see why a key derived from the EAP hierarchy will be given to a
domain without an EAP/HOKEY exchange involving the peer. And, in the
extreme case of that, in fact, being needed for some real scenario,
something like the RADIUS keyreq draft can be used to fetch the key. In
such a case, it is feasible that a DSRK is given to a domain without
peer involvement - however, given that the key will only be usable for
its scope (domain) and context (for services within that domain), what
is the problem? I can't see how any security properties are lost there. 

I'm concerned that we are attempting to solve an already solved problem
here. 

Regards,
Vidya 

> Sent: Friday, February 09, 2007 12:22 PM
> To: Madjid Nakhjiri
> Cc: [email-masked]; 'Madjid Nakhjiri'
> Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK 
> Hierarchy Changes
> 
> 
>   Hi Madjid,
> 
>   From a 10,000' perspective I'd say yes that's about right. 
> But there is quite a bit of detail needed to take care of 
> things like interleaving attacks, replay issues, and key 
> confirmation. In an earlier email I mentioned Otway-Rees. 
> Check it out.
> 
>   Also, I think that a key notarization scheme can be used to 
> solve this problem as well. There are benefits and drawbacks to each.
> 
>   Dan.
> 
> > Hi Dan,
> >
> > On your comment on #2, that is why I was asking for a 
> generic re-auth 
> > key to Home EAP server, the peer sends a request for a 
> handover to a 
> > new visited domain and signs it with that key. The visited domain 
> > server encapsulates the request on AAA along with extra stuff (see 
> > below) and signs with its security association with home AAA server.
> >
> > Also during San Jose meeting I presented a channel binding solution 
> > that verifies the identity of the middle entity (in DSRK 
> case, visited 
> > AAA server identity, in HRK case, the authenticator/AP 
> identity). So 
> > here is the solution (ME: middle entity)
> >
> > The peer and server share a key, say (Kps) and the ME entity and 
> > server share a key, say (Kms).
> >
> > If the downlink id (DID) of middle entity (shown to peer) 
> is included 
> > in the (peer request, MAC) and signed with Kps and the 
> uplink ID of ME 
> > (shown to
> > The server checks both MACs, each with a different key and assures 
> > about ME's identity.
> > After key generation at server and peer (just like EAP 
> MSK/EMSK), the 
> > key only needs to go to ME from server (using Kms)
> >
> > going to say, "my chbindID=AAAsrv.domainX" and the home EAP server 
> > would generate a DSRK and give it to the visited AAA 
> server. What if 
> > that AAA server was really "AAAsrv.domainY"? It tells the home AAA 
> > server it is "AAAsrv.domainX" and gets a root key for a 
> completely different domain.
> >
> > the HOKEY server? What if its identity really was ap2.domainX and 
> > said, "give me the rMSK for ap1.domainX". Would it get the 
> rMSK for ap1.domainX?
> >
> >   I think that part of #1 MUST include the transmission of a 
> > tamper-proof blob that binds the visited AAA server and/or HOKEY 
> > server to the transaction. That blob is sent to the home 
> AAA server. 
> > The protocol MUST entail the home AAA server decrypting the 
> blob and 
> > verifying that the identity of the visited AAA server and/or HOKEY 
> > server inside the tamper-proof blob (send by the client) is 
> the same 
> > as the identity of the visited AAA server and/or HOKEY 
> server that is 
> > sending the blob which it cannot tamper. The home AAA 
> server MUST send 
> > a tamper-proof acknowledgement back to the client to let it 
> know that 
> > the handshake completed.
> >
> > The client MUST send a tamper-proof blob to the local HOKEY server 
> > through the authenticator in domainX which identifies that 
> > authenticator. The HOKEY server MUST decrypt that blob and 
> verify that 
> > the identity of the authenticator inside the tamper-proof 
> blob is the 
> > same as the identity of tha authenticator sending the tamper-proof 
> > blob to it. It MUST also send back an acknowledgment to the 
> client to 
> > let it know the handshake completed.
> >
> >   Protocols such as Wide-Mouth Frog and Otway-Rees are examples of 
> > what is needed to solve this problem. Neither is 100% applicable to 
> > HOKEY but we can come up with something close to them that is.
> >
> >   Dan.
> >
> >> Madjid,
> >>
> >> HOKEY/AAA server to request a DSRK during the initial ho-key 
> >> (ho-auth?) in the visited domain.  Here's the scenario for 
> a visited domain:
> >>
> >> 1. peer initiates handoff to visited domain 2. visited AAA server 
> >> requests a DSRK from home EAP server
> >>     DSRK = KDF(EMSK, scope=domainX, context=*, 
> >> chbindID=AAAsvr.domainX) 3. EAP server sends DSKR to visited AAA 
> >> server 4. visited HOKEY server requests HRK from visited 
> AAA server (via API)
> >>               chbindID=HOKEYsvr.domainX) 5. peers has knowledge of 
> >> the domain and the chbindID for the AAA server
> >>                context=hokey/portaccess, chbindID=ap1.domainX) 8. 
> >> HOKEY server distributes rMSK to the authenticator 9. peer and 
> >> authenticator perform L2 key handshake to derive session
> >>     keys
> >>
> >> generate a keying hierarchy whose bottom-most keys are 
> channel bound 
> >> to every entity involved in their derivation and transport.
> >>
> >> --
> >>> emails in chronological order:) I understand that once you give a 
> >>> domain its root key (EMSK-jr or DSRK), the domain does 
> not have to 
> >>> go to the home (ignoring the scope debate for now) for 
> dealing with 
> >>> internal matters.
> >>>
> >>> My point was how does the peer and the new domain get 
> that EMSK-jr 
> >>> to begin with?
> >>> You have to the initial server that has the top EMSK to ask it to 
> >>> generate a EMSK-jr for your new domain? Where is this initial 
> >>> server? At home off course? No? I am not saying the new domain 
> >>> EMSK-jr has a home scope, but in reality it is the home that hold 
> >>> the EMSK.
> >>> EMSK-jr for perceivable domains right at the start proactively 
> >>> (which does not sound practical to me), the EMSK-jr for 
> each domain 
> >>> has to be generated per request as the peer enters the 
> new domains.
> >>>
> >>> AP=authenticator may be accurate for 802.11 but is not in 
> general. 
> >>> It is not even the case in CAPWAP and it is not in WiMAX, 
> so we need 
> >>> to decide whether we can or cannot go below the 
> authenticator. Are 
> >>> we now saying we can go below authenticator by mapping BSs to 
> >>> authenticator ports? I didn't think we could do channel binding 
> >>> based on port numbers? Can we?
> >>>
> >>> Madjid
> >>>
> >>>
> >>>> from one domain to another domain, you need a new domain 
> EMSK and 
> >>>> that EMSK MUST come from the initial EMSK that resides in home 
> >>>> domain, thus you MUST authenticate to the home domain.
> >>>
> >>> Perhaps they shoudl have been named better.  These are 
> >>> domain-specific root keys derived from the original EMSK. 
>  They are 
> >>> scoped for per-domain use.  These are the same keys we 
> called "EMSK 
> >>> jr" at the interim.  They reside on the AAA server for 
> each domain, 
> >>> and are transported there using AAA.
> >>>
> >>>> And if we are still in the spirit of hokey, that authentication 
> >>>> should be efficient (not using the word fast to avoid 
> >>>> wordsmithing). So we need a re-auth to the HOME DOMAIN, thus we 
> >>>> need a key to do that re-auth and therefore, I added a 
> >>>> "domainreauth" key in my suggested hierarchy. I wanted 
> to call it 
> >>>> "alldomainreauth" to indicate that all inter-domain handovers go 
> >>>> this way, but I have been accused of using long key names before.
> >>>> This means the home domain hierarchy has one extra key that the 
> >>>> other domains don't and this slight asymmetry is ok to me.
> >>>
> >>> I think that key is improperly scoped.  You can't use it 
> to generate 
> >>> keys for a different scope.  Using the domain-specific root keys, 
> >>> you can still quickly rekey in a visited domain.  There 
> is no need 
> >>> to talk to the home EAP server, provided the domain-specific keys 
> >>> were pre-emptively distributed.
> >>>
> >>>> 2) once again I point out the difference between re-auth 
> >>>> (re-authentication to the AAA server, for whatever reason) and 
> >>>> handover keying (i.e the need for generating keys for each 
> >>>> authenticator), so I am not sure if a re-auth key (what is now 
> >>>> called rMSK) used for re-auth to AAA server within the domain is 
> >>>> the same as the per-authenticator key.
> >>>
> >>> There would be peer keys derived from the HRK used to secure the 
> >>> re-key operation between the peer and the HOKEY server in 
> the visited domain.
> >>>> means generating EMSKs. And as far as I recall getting 
> new keys for 
> >>>> access to the network through new attachments (HANDOVER) 
> was called 
> >>>> handover keying (name of WG), not rekeying. To me 
> rekeying means, 
> >>>> you have a key and it is expiring or compromised and you 
> need a new 
> >>>> one instead.
> >>>
> >>> Ah, I agree that can be another interpretation of the 
> terminology.  
> >>> It might be useful to call it "handover keying" instead 
> of "re-keying".
> >>>> 3) did not know we could go to AP level? Weren't we supposed to 
> >>>> stay at authenticator level?
> >>>
> >>> In my picture, AP == authenticator, which is certainly 
> the case for 
> >>> 11i.
> >>>
> >>

---

From: Charles Clancy <[email-masked]>
Date: Sun, 11 Feb 2007 23:42:09 -0500

Certainly you'd have a home and visited HOKEY server.  They would be 
logical portions of your home and visited AAA servers.

---

From: Charles Clancy <[email-masked]>
Date: Sun, 11 Feb 2007 23:44:04 -0500

Yoshi,

I'm not sure if making the DSRK optional is very easy to do.  It's
difficult to optionally have or not have a level in a keying hierarchy.
 If the visited HOKEY server is talking to the home EAP server via AAA,
it's going to be a AAA device anyway.  It seems to me we're already
requiring a visited AAA server by virtue of using the AAA protocol.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 11 Feb 2007 23:02:28 -0800

> Sent: Sunday, February 11, 2007 8:44 PM
> To: Yoshihiro Ohba
> I'm not sure if making the DSRK optional is very easy to do.  
> It's difficult to optionally have or not have a level in a 
> keying hierarchy.
>  If the visited HOKEY server is talking to the home EAP 
> server via AAA, it's going to be a AAA device anyway.  It 
> seems to me we're already requiring a visited AAA server by 
> virtue of using the AAA protocol.
> 

Actually, the term "AAA server" may be misleading to some, since it
might show some implications of accounting and such that are not
relevant here. What we really need is a device that does the server part
of the AAA transport, with no implication on what kind of authorization
or accounting that box may or may not do. 

In order to support localized re-authentication, such an entity is
needed and it needs to speak AAA, since we are running the protocol over
AAA. 

Vidya

> >> Rather than respond to everything individually, let me 
> just say that 
> >> I'm beginning to be convinced.  I still think that, for example, 
> >> defining and distributing consistent identities is just 
> has hard in 
> >> both models, but I can see it being harder to make an insecure 
> >> implementation with a 3-party approach.
> > 
> >> For reference:
> >>
> >> ho-keying in general, but we need something defined in order to 
> >> create a functional protocol.  HOKEY then defines (d).
> >>
> >> DSRKtkt = hash(globalBK, peer ID, home EAP ID, visited AAA 
> ID) HRKtkt 
> >> = hash(domainBK, peer ID, visited AAA ID, HOKEY ID)
> >>
> >> This provides a HOKEY-independent way to secure the DSRK and HRK.  
> >> This would help ensure that the DSRK and HRK were only 
> distributed to 
> >> authorized parties.  Certainly HOKEY would perform 
> something similar 
> >> to satisfy (d) for the rMSK.
> >>
> >> --
> >>>>> server was really "AAAsrv.domainY"? It tells the home 
> AAA server 
> >>>>> it is "AAAsrv.domainX" and gets a root key for a 
> "give me the 
> >>>>> rMSK for ap1.domainX". Would it get the rMSK for
> >>>> ap1.domainX?
> >>>>
> >>>> Every device from the authenticator through the home EAP 
> server has 
> >>>> a security association, and has an identity bound to 
> that security 
> >>>> association.  It prevents the layer below you from telling you a 
> >>>> fake identity when it requests a key.
> >>>  What is the identity bound to that security association and how 
> >>> does is it relevant to another layer?
> >>>
> >>> How is that identity known to another layer? How does the 
> IP address 
> >>> of the wired port of an AP become known to a wireless 
> client of that 
> >>> AP? It doesn't! The AP is identified by the client by 
> BSSID and by 
> >>> the AAA server by IP address.
> >>>
> >>>  Or it could be like a RADIUS client implementation where 
> it assigns 
> >>> some static secret to authenticate itself to the RADIUS 
> server and 
> >>> protect parts of certain messages. Again, that security 
> association 
> >>> is bound to something like an IP address. Through that security 
> >>> association you can send "my identity is AP2.domainX" 
> just as easily 
> >>> as "my identity is AP1.domainX" and the message will be 
> received and correctly processed.
> >>>
> >>>  Of course you can make it so your implementation is not 
> susceptible 
> >>> to this sort of impersonation but then you're doing 
> essentially what 
> >>> would be required by a secure 3 party protocol. That 
> being the case 
> >>> why not just put that work into the key distribution protocol to 
> >>> ensure that it is done securely always and everywhere?
> >>>
> >>>>> authenticator (Bob) and uses key shared with HOKEY 
> server (Trent) 
> >>>>> to facciliate this-- and you can't fudge them with a 
> series of 2 
> >>>>> party protocols.
> >>>> I don't agree.  You're proposing a series of 3-party protocols.  
> >>>> How is that fudging any less?
> >>>  The 2 party protocol is being justified because the client is 
> >>> unaware of whether the secret he knows is known by 1 
> other entity or 
> >>> 2 other entities, thanks to the AAA model. Since it is 
> possible that 
> >>> the secret could only be known by one other person it is 
> argued to 
> >>> be a 2 party protocol, the 2 parties being the client and 
> "EAP server".
> >>>
> >>>  But when you get into the mode of distributing keys between 3 
> >>> parties where all three parties know there are 3 parties then you 
> >>> can't say "AAA model" anymore.
> >>>
> >>> initial EAP exchange which we are not tackling and have 
> decided to 
> >>> not debate in this forum anymore. Then there is a 3 party 
> protocol 
> >>> of a HOKEY server distributing keys to authenticators in the same 
> >>> domain and a separate 3 party protocol where a HOKEY server one 
> >>> domain distributes a key to a HOKEY server in another domain.
> >>>
> >>>> First of all, we have a hierarchy that delegates trust, and the 
> >>>> ability to generate keying material.  Thus, the home EAP server 
> >>>> really doesn't need to know the ID of the authenticator on the 
> >>>> other side of the network.  (And looking at your 
> proposal, I don't 
> >>>> think you think the home EAP server should know the ID of the 
> >>>> authenticator.)  Due to this, I think the approach of binding 
> >>>> network-side identities into the key derivation works well.
> >>> sufficient. What is also needed is an assurance that the 
> an entity 
> >>> is not given the wrong key.
> >>>
> >>>> As for the client, provided we can communicate all these 
> identities 
> >>>> to it, we solve the lying NAS (and lying HOKEY server (and lying 
> >>>> visited AAA server))) problem.
> >>>  We can only solve that problem if we can ensure that AP2.domainX 
> >>> cannot receive a key for AP1.domainX (and also ensure that 
> >>> HOKEY-SERVER.domainY cannot receive a key for 
> HOKEY-SERVER.domainZ). 
> >>> If the protocol cannot prevent it (i.e. the secure 
> solution depends 
> >>> on trusting the wisdom and integrity of the guy writing 
> the code or 
> >>> the vendor supplying the boxes) then the protocol is broken.
> >>>
> >>>> With the approach I described, do you see any way a device could 
> >>>> provide inconsistent identities?
> >>>  I believe I described one above. If you feel I didn't 
> ask again and 
> >>> I'll try again.
> >>>
> >>>> I have no fundamental objection to a 3-party protocol.  
> But we have 
> >>>> 5 parties involved:
> >>>>
> >>>> Based on your suggestion, I think you're saying we need the 
> >>>> following multi-party key agreements:
> >>>>
> >>>  I think (a) is outside of HOKEY. Also, after discussion 
> with Glen 
> >>> at the ad-hoc I'm a little confused about (b). Glen was 
> saying that 
> >>> the HOKEY server could just look like a proxy AAA server. 
> (c) yes, 
> >>> that's one. The other would be
> >>>
> >>> where the HOKEY server in a different domain obtains a key to use 
> >>> for all authenticators in his domain.
> >>>
> >>>> So in #1 (of my original proposal), the peer would 
> actually need to 
> >>>> send
> >>>> 2 blobs, one to satisfy (b) and one to satisfy (c)?  The visited 
> >>>> HOKEY server would keep (c) and pass (b) to the home EAP 
> server?  
> >>>> Then whenever you did a handoff in the visited domain you would 
> >>>> just need to do (c) again?
> >>>  These are, or should be, separate handshakes. For 
> practicality it 
> >>> may be necessary to piggy-back 2 of them on a single 
> >>> request-response (what you say about 2 blobs being sent).
> >>>
> >>>> Thus, we're doing basically the same thing as I proposed, but 
> >>>> involve the peer in every key agreement.  To properly implement 
> >>>> your proposal, I think we'd need to actually do the 
> following instead:
> >>>>
> >>>> a. peer-EAP
> >>>> b. peer-AAA-EAP
> >>>> c. peer-HOKEY-AAA
> >>>  Yes, except, as I said I think (a) is out of scope, and 
> depending 
> >>> on how
> >>>> Thus during #1 the peer would send blobs (b), (c), AND 
> (d).  Then 
> >>>> to do a handoff he'd just send (d).  That accounts for 
> the DSRK in 
> >>>> the keying hierarchy.
> >>>>
> >>>> authorize each key derivation and distribution to the 
> next lowest 
> >>>> layer of the hierarchy.  From a channel bindings / lying-device 
> >>>> perspective, there is no security difference.
> >>>>
> >>>  I believe there is a difference from a channel bindings point of 
> >>> view because there is no binding if the HOKEY server is just 
> >>> gratuitously giving out keys, or giving out keys intended for a 
> >>> particular identity through a channel that is not 
> authenticated by that particular identity.
> >>> There has to be a protocol such that each party agrees on the 
> >>> identity of each other party. Just mixing identities into 
> the keys 
> >>> does not do channel binding.
> >>>
> >>>  Yes, authorization of distributed keys is important too 
> because it 
> >>> can be used to alert the peer as to when the key 
> heirarchy has been
> >>> compromised-- if AP2.domainX has a key for the peer and 
> the peer did 
> >>> not participate in a 3-party protocol involving AP2.domainX and 
> >>> HOKEY-SERVER.domainX then he knows something stinks in 
> keyland and 
> >>> should immediately throw away the heirarchy.
> >>>
> >>>  Dan.
> >>>
> >>>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 12 Feb 2007 03:35:36 -0800

Narayanan, Vidya <mailto:[email-masked]> allegedly scribbled on
Sunday, February 11, 2007 11:02 PM:

>> It's difficult to optionally have or not have a level in a keying
>>  hierarchy. If the visited HOKEY server is talking to the home EAP
>> server via AAA, it's going to be a AAA device anyway.  It seems to
>> me we're already requiring a visited AAA server by virtue of using
>> the AAA protocol. 
>> 
> 
> relevant here. 

Actually, I think that it is incorrect from an architectural standpoint.
I'm not a big fan of fuzzy thinking (as opposed to fuzzy logic :-) & a
AAA server w/a hokey server seems to me to be just that.  Note that I
don't care where the hokey server physically sits; it may even be
_implemented_ as a DLL in a AAA server.  I think that it's _much_ harder
to make those kind of implementation decisions if you don't have a clear
idea of what, exactly, you are implementing; in the worst case lazy
assumptions like "it's just part of a AAA server" can lead to nasty bugs
that can't be fixed w/o either bizarre hacks or redesigning the whole
system.  A sterling example of this is the popular error that equates an
EAP server and a AAA server.

> What we really need is a device that does the server
> part of the AAA transport, with no implication on what kind of
> authorization or accounting that box may or may not do.    
> 
> needed and it needs to speak AAA, since we are running the protocol
> over AAA.  

Hmm, a hokey server might reasonably include the functionality of a AAA
proxy...
 
...

---

From: Charles Clancy <[email-masked]>
Date: Mon, 12 Feb 2007 08:28:24 -0500

My interpretation of the discussion is that we should do precisely as 
you describe, except that the RADIUS keyreq packet contain a value MIC'd 
by an authentication key derived directly from the EMSK (like the 
rIK/rMSK relationship in EAP-ER), and that MIC'd value should contain 
the channel binding info.  That way it channel bindings can be 
explicitly validated prior to key distribution.

I believe the two approaches to be virtually equivalent from a security 
perspective.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Feb 2007 09:08:32 -0500

Why can't a HOKEY server for handover keying be co-located with a AAA
client not a AAA server?  DSRK may be required for re-auth in visited
domains but it's not required for handover keying.  IMO, making the
DSRK optional can be easily done by just having separate architectures
for re-auth and handover keying and defining DSRK only in re-auth
arch.  To me, re-auth and handover keying are two different usages and
it does not make sense to have a single architecture for different
usages.

Yoshihiiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 12 Feb 2007 07:30:23 -0800

Charles Clancy <mailto:[email-masked]> allegedly scribbled on Monday,
February 12, 2007 5:28 AM:

> you describe, except that the RADIUS keyreq packet contain a value
> MIC'd by an authentication key derived directly from the EMSK (like
> the rIK/rMSK relationship in EAP-ER), and that MIC'd value should
> contain the channel binding info.  That way it channel bindings can
> be explicitly validated prior to key distribution. 

This assumes a request for a key.  I had assumed that all keys would be
delivered at the same time (e.g., in the RADIUS Access-Accept).  A
separate key request would increase the latency of the reauthentication
considerably, wouldn't it?

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Feb 2007 11:06:34 -0500

> EAP server and a AAA server.

I agree on this.  I further think that why HOKEY server needs to
depend on domain structure of "AAA" at all.  Regardless of whether a
HOKEY server is in the home AAA domain or in a visited domain, EAP
server just needs to send out a key to the HOKEY server, no?  Having
said that I am still suspicious about the need for DSRK...

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 12 Feb 2007 08:31:52 -0800

> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Monday, February 12, 2007 3:36 AM
> To: Narayanan, Vidya; Charles Clancy; Yoshihiro Ohba
> Narayanan, Vidya <mailto:[email-masked]> allegedly 
> scribbled on Sunday, February 11, 2007 11:02 PM:
> 
> >> Yoshi,
> >> 
> seems to me 
> >> we're already requiring a visited AAA server by virtue of 
> using the 
> >> AAA protocol.
> >> 
> > 
> I'm not a big fan of fuzzy thinking (as opposed to fuzzy 
> logic :-) & a AAA server w/a hokey server seems to me to be 
> just that.  Note that I don't care where the hokey server 
> physically sits; it may even be _implemented_ as a DLL in a 
> AAA server.  I think that it's _much_ harder to make those 
> kind of implementation decisions if you don't have a clear 
> idea of what, exactly, you are implementing; in the worst 
> case lazy assumptions like "it's just part of a AAA server" 
> can lead to nasty bugs that can't be fixed w/o either bizarre 
> hacks or redesigning the whole system.  A sterling example of 
> this is the popular error that equates an EAP server and a AAA server.
> 
> > What we really need is a device that does the server part 
> of the AAA 
> > transport, with no implication on what kind of
> Hmm, a hokey server might reasonably include the 
> functionality of a AAA proxy...
>  

Agreed.

---

From: <[email-masked]>
Date: Mon, 12 Feb 2007 11:01:40 -0600

Colleagues,

The mention of latency is refreshing. While we need excellent security,
we must also make it possible for seamless mobility to be achieved. We
can't count on MBB with huge handover time budgets to hide long SA setup
times.

Best Regards,
Michael G. Williams 

-----Original Message-----
From: ext Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 7:30 AM
To: Charles Clancy; Narayanan, Vidya
Cc: [email-masked]; Madjid Nakhjiri
Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

Charles Clancy <mailto:[email-masked]> allegedly scribbled on Monday,
February 12, 2007 5:28 AM:

> contain the channel binding info.  That way it channel bindings can be

...

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Feb 2007 10:45:38 -0800 (PST)

Hi Vidya

[snip]
>                                                          And, in the

  In the RADIUS keyreq draft the requestor sends either a NAS IP address
or a NAS Identifier to request the key. What prevents a key requestor from
inserting any NAS Identifier in that request? HOKEY-server.verison.net
requests a key and puts HOKEY-server.sprint.net as the NAS Identifier.
Does it get the key? If not where in the keyreq draft does it indicate
that this request would fail?

  The keyreq draft specifies using the keywrap draft (which is dead,
problem right there) and the keywrap draft defines 2 new secrets but it
doesn't say how those secrets are established, only that they SHOULD
(should've been a MUST) be cryptographically separate from the shared
secret. That shared secret is based on the IP address of the UDP packet
that encapsulates the RADIUS request and that has nothing to do with a
NAS Identifier.

> I'm concerned that we are attempting to solve an already solved problem

  We are not doing that. We are solving a new problem that is created by
the desire to distribute a secret known by 2 people to a 3rd person.
The method of transport-- using the RADIUS keyreq draft-- is not a
solution to that problem.

  Dan.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 12 Feb 2007 12:42:45 -0800

Well, the key derivation expressions are a bit more complicated that what
you show here, there are party identities involved, so if you are mixing an
identity in the derivation, the identity need to be exchanged in a trustable
manner, and not every entity fetches the keys.

If we were happy with the existing MSK treatment, we would not be here..

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, February 09, 2007 4:19 PM
To: Dan Harkins; Madjid Nakhjiri
Cc: [email-masked]; Madjid Nakhjiri
Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

Regards,
Vidya

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 12 Feb 2007 12:45:57 -0800

The peer has to derive the keys as well, so the peer needs certain info as
well. It is the other intermediaries that fetch the keys.

And yes, we need to analyze what is to be exchanged and then how that
exchange an be piggybacked on existing signaling to avoid latency addtions.

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 7:30 AM
To: Charles Clancy; Narayanan, Vidya
Cc: [email-masked]; Madjid Nakhjiri
Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

...

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 12 Feb 2007 12:49:58 -0800

Hi Dan,

I agree that at some point we need the parachute to get down to 0 foot
without crash landing:)

However, my "channel binding tuple" included "other info", so you can stick
other things in there if you want (say for replay). I am not sure what an
"interleaving attack is". What do you mean from key notarization?

Got to check Otway-Rees, wide mouth frog..

Madjid

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Friday, February 09, 2007 12:22 PM
To: Madjid Nakhjiri
Cc: 'Dan Harkins'; 'Charles Clancy'; [email-masked]; 'Madjid Nakhjiri'
Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

  Hi Madjid,

  Dan.

>>> generate a
>>>> (re-authentication

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 12 Feb 2007 13:14:56 -0800

Ha???

This seems like a local brewery, new varieties of servers popping up
everyday!!!

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Sunday, February 11, 2007 11:02 PM
To: Charles Clancy; Yoshihiro Ohba
Cc: [email-masked]; Madjid Nakhjiri
Subject: RE: [HOKEY] EMSK Hierarchy Changes

Vidya

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 12 Feb 2007 13:16:18 -0800

agree..

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 3:36 AM
To: Narayanan, Vidya; Charles Clancy; Yoshihiro Ohba
Cc: [email-masked]; Madjid Nakhjiri
Subject: RE: [HOKEY] EMSK Hierarchy Changes

 
...

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 12 Feb 2007 13:18:30 -0800

Hi Dan, 

> Sent: Monday, February 12, 2007 10:46 AM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Madjid Nakhjiri; [email-masked]
> > something like the RADIUS keyreq draft can be used to fetch 
> the key. 
> > In such a case, it is feasible that a DSRK is given to a domain 
> > without peer involvement - however, given that the key will only be 
> > usable for its scope (domain) and context (for services within that 
> > domain), what is the problem? I can't see how any security 
> properties are lost there.
> 
>   In the RADIUS keyreq draft the requestor sends either a NAS 
> IP address or a NAS Identifier to request the key. What 
> prevents a key requestor from inserting any NAS Identifier in 
> that request? HOKEY-server.verison.net requests a key and 
> puts HOKEY-server.sprint.net as the NAS Identifier.
> Does it get the key? If not where in the keyreq draft does it 
> indicate that this request would fail?
> 

If the SA with which the AAA exchange is protected between the NAS and
the server is incapable of detecting a false ID, it is AAA that is
broken. We are not attempting to fix such broken AAA implementations
here. For instance, the commonly talked about problem with channel
bindings is the case where the NAS provides ID1 to the peer, while its
real ID is ID2. Hence, the server with which it has an SA thinks it is
handing a key out to ID2, while the peer thinks a key was handed out to
ID1. If the AAA SA is not tied appropriately to ID2, the NAS would get
away with claiming it is ID1. This is clearly unacceptable. 

A request coming from verizon.net must be identified as such at the AAA
server by means of appropriate AAA routing and SAs. Forgetting HOKEY for
a moment, for several other important reasons (such as accounting, for
instance), the AAA server better be able to associate an SA with the
correct NAS with no ambiguity. If not, there are bigger problems. 

>   The keyreq draft specifies using the keywrap draft (which 
> is dead, problem right there) and the keywrap draft defines 2 
> new secrets but it doesn't say how those secrets are 
> established, only that they SHOULD (should've been a MUST) be 
> cryptographically separate from the shared secret. That 
> shared secret is based on the IP address of the UDP packet 
> that encapsulates the RADIUS request and that has nothing to 
> do with a NAS Identifier.
> 
> > I'm concerned that we are attempting to solve an already solved 
> > problem here.
> 
>   We are not doing that. We are solving a new problem that is 
> created by the desire to distribute a secret known by 2 
> people to a 3rd person.
> The method of transport-- using the RADIUS keyreq draft-- is 
> not a solution to that problem.
> 

Understood. And, I wasn't saying that the method of transport is the
solution there. I was in fact, showing how the inclusion of the
appropriate identities in the key derivation already solves the problem
sufficiently. This is true even if the key is distributed without peer
involvement, which is the point I was trying to make with the transport
comment. 

Hope that helps. 

Regards,
Vidya

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 12 Feb 2007 13:19:47 -0800

I for one don't want to see us generating a myriad of hierarchies. Even
though I am not particularly a fan of this whole DSRK thing, since I think
the home AAA server relinquishing too much control, I will still follow the
consensus. Also, I don't think you can have optional things at the top of
the hierarchy. In the leaves and branches, it might be ok, but not at the
top..

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 6:09 AM
To: Charles Clancy
Cc: Yoshihiro Ohba; Dan Harkins; [email-masked]; Madjid Nakhjiri
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Yoshihiiro Ohba

> >> satisfy (d) for the rMSK.
ability
> >>>  We can only solve that problem if we can ensure that AP2.domainX
cannot
> >>>> With the approach I described, do you see any way a device could
provide
> >>>> 2 blobs, one to satisfy (b) and one to satisfy (c)?  The visited
HOKEY

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Feb 2007 13:45:57 -0800 (PST)

Hi Vidya,

[snip]
> broken.

  Then every RADIUS implementation is broken in this respect. The shared
secret that a RADIUS server uses is based on the IP address of the UDP
packet that encapsulates the RADIUS request. Any kind of "security
association" you create around that shared secret is going to be
indexed off an IP address and an IP address is not the same as a NAS
identifier. Since they're not the same detecting this "false ID" is
not possible.

>          We are not attempting to fix such broken AAA implementations

  Exactly! :-) It is clearly unacceptable. We fix this with a secure
3 party protocol.

> involvement, which is the point I was trying to make with the transport

  The inclusion of the identities provides for key separation and limits
exposure of the hierarchy. Since there is nothing that stops a NAS from
requesting a different NAS's key there is no secure binding of key to
identity. As I mentioned to Charles, mixing the identity into the key is
necessary but not sufficient.

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Feb 2007 18:25:21 -0500

>From the discussion, I am sensing that we could have a cleaner key
hierarchy, architecture and signaling if define them without mixing
them with AAA stuff.

But if we have DSRK in the key hierarchy (at the top or in the middle
it does not matter), we are actually introducing AAA domain structure,
which would introduce corresponding AAA entities such as AAA servers
in the architecture and signaling to be consistent, which is the
dilemma we are faced with DSRK, as far as I understand.

In my personal opion, from HOKEY perspective, AAA is just a transport
of HOKEY signaling, and AAA domain structure is just one form of how
we distribute HOKEY servers.  We can still use AAA for signaling even
if key hierarchy, architecture and signaling do not discuss AAA at all
at high-level.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 12 Feb 2007 17:10:52 -0800

Hi Dan, 
Let me start with a disclaimer that I think fixing AAA issues is out of
scope of this WG. If we really believe there are as serious issues as
not being able to validate the real entity from which a request was
received, that needs to be addressed in a more generic form at a
different place. That said, I'm not convinced there is a real problem
here. 

> Sent: Monday, February 12, 2007 1:46 PM
> To: Narayanan, Vidya
>   Then every RADIUS implementation is broken in this respect. 
> The shared secret that a RADIUS server uses is based on the 
> IP address of the UDP packet that encapsulates the RADIUS 
> request. Any kind of "security association" you create around 
> that shared secret is going to be indexed off an IP address 
> and an IP address is not the same as a NAS identifier. Since 
> they're not the same detecting this "false ID" is not possible.
> 

You may be right in that the RADIUS *implementations* are not doing what
needs to be done. However, if this whole AAA thing is so broken, no kind
of confirmation from the peer is going to help either. If a NAS is
capable of lying about its ID to the backend, it is also capable of
lying to the peer. So, if an ISP1.net NAS portrays itself successfully
as an ISP2.net NAS both to the peer and the server, the peer's
authorization is also going to be for ISP2.net - the whole premise
behind channel binding working is that the backend can detect that the
NAS lied to the peer, based on the SA it has with the NAS and actually
tell the peer that the NAS is lying via an SA it has directly with the
peer. So, if the backend SA is not properly tied to the NAS, nothing
works! 

For instance, a session ID is exchanged at the time of the
authentication exchange and the same session ID is used for accounting
later. If a NAS got away with pretending as ISP2.net, it would be
billing as ISP2.net, which is not in the best interest of ISP1.net
either! So, claiming that this whole thing is broken, given that this
all functions today, seems to be misleading. 

> > handing a key out to ID2, while the peer thinks a key was 
> handed out 
> > to ID1. If the AAA SA is not tied appropriately to ID2, the 
> NAS would 
> > get away with claiming it is ID1. This is clearly unacceptable.
> 

As I've explained above, modifying a AAA key management protocol into a
3-party model is not going to fix anything if the NAS can lie in both
directions and get away with it. The NAS-lying-to-the-peer and the
peer-lying-to-the-NAS problems exist since there is no direct SA between
the NAS and the peer. That is what the server is there for, since it is
supposed to have an independent trust relationship with both parties.
The NAS-lying-to-the-backend problem is a new one that you seem to be
bringing up and I'm saying a lot would be broken today if that were
true. And, if that were true, we need to immediately deprecate AAA at
the IETF, but, that's a different discussion :) The bottomline as I see
it is to ensure that the key transport protocol has the necessary
security properties. If that hasn't been made clear for other protocols
that use AAA, we should make sure it is clear in the context of new ones
we are designing. 

Vidya

> > A request coming from verizon.net must be identified as such at the 
> > AAA server by means of appropriate AAA routing and SAs. Forgetting 
> > HOKEY for a moment, for several other important reasons (such as 
> > accounting, for instance), the AAA server better be able to 
> associate 
> > an SA with the correct NAS with no ambiguity. If not, there 
> are bigger problems.
> >
> >> problem right there) and the keywrap draft defines 2 new 
> secrets but 
> >> it doesn't say how those secrets are established, only that they 
> >> SHOULD (should've been a MUST) be cryptographically 
> separate from the 
> >> shared secret. That shared secret is based on the IP 
> address of the 
> >> UDP packet that encapsulates the RADIUS request and that 
> has nothing 
> >> to do with a NAS Identifier.
> >>
> >>   We are not doing that. We are solving a new problem that 
> is created 
> >> by the desire to distribute a secret known by 2 people to a 3rd 
> >> person.
> > appropriate identities in the key derivation already solves the 
> > problem sufficiently. This is true even if the key is distributed 
> > without peer involvement, which is the point I was trying 
> to make with 
> > the transport comment.
> 
>   The inclusion of the identities provides for key separation 
> and limits exposure of the hierarchy. Since there is nothing 
> that stops a NAS from requesting a different NAS's key there 
> is no secure binding of key to identity. As I mentioned to 
> Charles, mixing the identity into the key is necessary but 
> not sufficient.
> 
>   Dan.
> 
> 
> 
> 
> 
>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 12 Feb 2007 23:10:48 -0800

Dan Harkins <mailto:[email-masked]> allegedly scribbled on Monday,
February 12, 2007 10:46 AM:

...

>   We are not doing that. We are solving a new problem that is created

That's the problem _you_ are trying to solve.  Presumably you have a
favorite screwdriver & are willing to beat this nail with it all day
long.

> solution to that problem. 

Very true, but only because no key request is necessary.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Feb 2007 23:45:49 -0800 (PST)

Glen,

  I don't have a favorite screwdriver. If you have a hammer that solves
the problem then great but if you insist on building a structure without
using either one then someone's gonna huff and puff and blow it down.

  You have argued that the "AAA model" hides the distinctuion between a
NAS that uses its own internal database to perform EAP and a separate
NAS and EAP server from the client and therefore it's a 2 party protocol.
Can you please explain how this "AAA model" works when it is obvious to
the client that 3 people know the secret?

  Talk about favorite screwdrivers! Sheesh. "AAA model", it's a floorwax,
it's a dessert topping....

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 13 Feb 2007 09:49:16 -0800 (PST)

Hi Vidya,

  As I have mentioned numerous times already in this thread I'm not
suggesting we "fix AAA issues".

[snip]
> of confirmation from the peer is going to help either.

  On the contrary, it prevents the NAS from representing itself to the
peer as one identity and to the AAA server as another.

>                                                        If a NAS is

  What you're arguing for is to bind the SA that the AAA server uses for
communication with the NAS to the NAS Identifier. That is great!

  That will make sure that the identity the NAS presents to the AAA server
is the one it authenticated as. So now what is needed is a way to ensure
that that identity is the one being represented to the peer.

> either!

  You seem to be forgetting that this is a _symmetric_ credential that the
peer uses for network access. If ISP2.net obtained the key that the peer
should be using when talking to ISP1.net that allows ISP2.net to
impersonate the peer to ISP1.net. If and when the peer attempted to
legitimately connect to ISP1.net it would allow ISP2.net to decrypt all
its traffic, inject bogus traffic into the flow, and do all sorts of
nastiness.

  Accounting is the least of the worries.

>          So, claiming that this whole thing is broken, given that this

  This doesn't function today because none of this exists today! We don't
go building key heirarchies and distribute keys all over the place. If we
did then HOKEY wouldn't be necessary.

  What we do today requires a reauthentication each time. As I mentioned
earlier in this thread, the damage that can be done is very contained.
The damage will not be contained if we use the same 2 party protocol when
distributing keys across domains or to authenticators in a domain.

[snip]
> directions and get away with it.

  No, what you did above was argue for MORE verification.

  Preventing the NAS from presenting a different identity to the peer and
AAA server would be a good thing (if it's lying in both directions exposure
is much easier) but now you seem to be saying that if we can't prevent it
from lying to both about the same identity then we should allow it to
lie to either one? How bizarre!

"If we can't have both a belt AND suspenders then we should have neither"

>                                  The NAS-lying-to-the-peer and the

  And how to you propose to use the server to prevent this lying?

> the IETF, but, that's a different discussion :)

  Again, as I've mentioned previously in this thread channel binding takes
care of the problem today.

>                                                 The bottomline as I see

  Yes, ensuring that key transport is secure is the bottom line because
if you can't ensure that the all bets are off. But merely assuring that
the transport is correct does not ensure that the correct thing is being
sent over that secure transport. And if you don't ensure that then it
doesn't matter whether the transport is secure or not!

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 13 Feb 2007 11:52:15 -0800

[snip]

> > You may be right in that the RADIUS *implementations* are not doing 
> > what needs to be done. However, if this whole AAA thing is 
> so broken, 
> > no kind of confirmation from the peer is going to help either.
> 
>   On the contrary, it prevents the NAS from representing 
> itself to the peer as one identity and to the AAA server as another.
> 

It is not sufficient to simply detect an identity mismatch - it is
necessary to detect lying. And, lying cannot be detected here unless
there is a third party that *trusts both parties and is trusted by
both*. That third party here is the server. And, trust here means that
the server must be capable of detecting wrong IDs and misinformation.
Otherwise, there is no trust in the context we are talking about here. 

>   What you're arguing for is to bind the SA that the AAA 
> server uses for communication with the NAS to the NAS 
> Identifier. That is great!
> 

Yes. If you believe this is broken today, we need to work on fixing it
at the AAA level, not in HOKEY. 

>   That will make sure that the identity the NAS presents to 
> the AAA server is the one it authenticated as. So now what is 
> needed is a way to ensure that that identity is the one being 
> represented to the peer.
> 
>   You seem to be forgetting that this is a _symmetric_ 
> credential that the peer uses for network access. If ISP2.net 
> obtained the key that the peer should be using when talking 
> to ISP1.net that allows ISP2.net to impersonate the peer to 
> ISP1.net. If and when the peer attempted to legitimately 
> connect to ISP1.net it would allow ISP2.net to decrypt all 
> its traffic, inject bogus traffic into the flow, and do all 
> sorts of nastiness.
> 

The goal of network access is NOT confidentiality. If a node is worried
about confidentiality of data, it better be using end-to-end protection
on that data. And, I repeat - if the server cannot trust the NAS, there
is nothing you can do to make this work. 

>   Accounting is the least of the worries.

The closest problem tied to access control in some networks is
accounting. Especially since you used SPs as an example, it is very much
relevant. 

>   This doesn't function today because none of this exists 
> today! We don't go building key heirarchies and distribute 
> keys all over the place. If we did then HOKEY wouldn't be necessary.
> 

I'm puzzled by this! Of course this exists today! EAP, in the
pass-through authenticator model, has the exact same problem. It doesn't
matter if you have one entity in the middle or a dozen entities in the
middle to which keys are being handed over - it is the exact same
problem! The AAA-based model of brokering trust is widely deployed, even
outside of EAP. And, with the deployment of EAP, this has only
increased. 

>   What we do today requires a reauthentication each time. As 
> I mentioned earlier in this thread, the damage that can be 
> done is very contained.
> The damage will not be contained if we use the same 2 party 
> protocol when distributing keys across domains or to 
> authenticators in a domain.
> 
> [snip]
> > As I've explained above, modifying a AAA key management 
> protocol into 
> > a 3-party model is not going to fix anything if the NAS can lie in 
> > both directions and get away with it.
> 
>   Preventing the NAS from presenting a different identity to 
> the peer and AAA server would be a good thing (if it's lying 
> in both directions exposure is much easier) but now you seem 
> to be saying that if we can't prevent it from lying to both 
> about the same identity then we should allow it to lie to 
> either one? How bizarre!
> 

No, this is NOT what I'm saying. I'm only saying that if you believe
there are issues with AAA security and how it ties the SA to the
identity of the NAS, that needs to be worked out outside of the HOKEY
space. HOKEY is modeled very much like the pass-through authenticator
model of EAP - if there is a problem here, the same problem applies to
regular EAP as well. I don't believe that HOKEY is introducing a
problem. Whether the key hierarchy just comprised of the MSK and EMSK,
with the MSK being handed to the NAS or it comprises of additional DSRKs
being handed to the HOKEY/Local AAA servers, the problem is the same.
You seem to think AAA security is broken - I suggest you write a draft,
describing the issue and how you think it needs to be fixed and take it
up with RADEXT and DIME. As I said, broken AAA security has broader
implications than just HOKEY. 

> > peer-lying-to-the-NAS problems exist since there is no direct SA 
> > between the NAS and the peer. That is what the server is there for, 
> > since it is supposed to have an independent trust 
> relationship with both parties.
> 

The key is in the fact that the server is meant to have an *independent*
*trust relationship* with both entities - that *trust* must ensure that
it can detect lying entities. For instance, if the peer lied about its
identity, it's credentials won't match and hence, it would be denied
access. Similarly, the AAA SA must detect a misrepesented NAS Identity.
Now, in the model with AAA proxies, that trust is hop-by-hop. And, that
has been an acceptable security model for the users of AAA. Diameter
provides the option of true end-to-end trust relationships even in the
presence of proxies. So, that's already addressing that shortcoming of
RADIUS. 

>   Again, as I've mentioned previously in this thread channel 
> binding takes care of the problem today.
> 

No, it doesn't. First of all, there is no channel binding today. There
have been a number of attempts to work on this theoretical problem, but,
there has never been any incentive to do so. The topic has been
discussed every now and then on the EAP mailing list for at least a few
years now. Every time the question on "who thinks this is a real problem
to solve" has been asked, there has practically been silence. Hence the
reason it has remained unsolved thus far. This is not to say that it
shouldn't be solved for EAP now - the MSK is not bound to any identities
and hence, it would be good to have a way to solve it (the new GPSK EAP
method defined in EMU allows the exchange of protected opaque payloads
between the peer and server that can be used for this purpose). However,
for what we are doing here in HOKEY, if we bound the identities to the
keys appropriately, this is not needed. 

> >                                                 The bottomline as I 
> > see it is to ensure that the key transport protocol has the 
> necessary 
> > security properties. If that hasn't been made clear for other 
> > protocols that use AAA, we should make sure it is clear in 
> the context 
> > of new ones we are designing.
> 
>   Yes, ensuring that key transport is secure is the bottom 
> line because if you can't ensure that the all bets are off. 
> But merely assuring that the transport is correct does not 
> ensure that the correct thing is being sent over that secure 
> transport. And if you don't ensure that then it doesn't 
> matter whether the transport is secure or not!
> 

As I said above, it would be good to see a draft on this sent to the AAA
WGs. We still need to make progress in HOKEY with the EAP-based
approach, which also means using AAA as the transport. 

Vidya

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 13 Feb 2007 13:24:25 -0800 (PST)

Hi Vidya,

  You seem to be simultaneously arguing that something is broken and
needs to get fixed (elsewhere) and that we can use that broken thing
in HOKEY because it's used today.

> Otherwise, there is no trust in the context we are talking about here.

  What aspect of identity lying is not detected by an identity mismatch?

  Yes, it's necessary to detect lying. Yes, the 3rd party is the server.
And yes, the server must be capable of detecting wrong IDs and
misinformation. That is EXACTLY WHAT I'M ARGUING FOR!!!!

  You are not proposing anything that allows the server (the 3rd party
that trusts both parties and is trusted by both) to detect this lying!

  I am proposing that we implement a secure 3 party protocol to detect
this lying.

> at the AAA level, not in HOKEY.

  If I believe? You said "if the backend SA is not properly tied to the
NAS, nothing works." You accept that the backend SA is not properly tied
to the NAS, and therefore "nothing works". Since this technique of key
distribution doesn't work according to you why do you want to use it in
HOKEY?

> is nothing you can do to make this work.

  Confidentiality? I just gave you an example of impersonation and
causing bogus traffic to appear authentic. Surely those are things that
network access is supposed to prevent. Please don't get hung up on
"decrypt all its traffic", that's just one of the many nasty things that
is possible.

> outside of EAP. And, with the deployment of EAP, this has only

  If "widely deployed" equaled secure then we would still be using WEP.

  You're puzzled? I'm puzzled because here you're arguing that this is
widely deployed and "it doesn't matter" whether you expose a secret to 1
person or a dozen people. You imply that it is OK to use this with HOKEY.
But above you said "the server must be capable of detecting wrong IDs and
misinformation" while admitting that, today, it is not capable of such a
feat.

  So what's puzzling is how you can say that something must to be done,
that it is not being done, and that it's not a problem.

> implications than just HOKEY.

  If I believe? You have previously admitted that there is a problem.

  HOKEY is not the same as the pass-through authenticator model. In that
model the peer cannot detect that a AAA server even exists. It is a 2
party protocol from the peer's perspective. HOKEY will give a key that the
peer knows is only known by 1 other entity to a 3rd entity and that is
not a 2 party protocol.

> presence of proxies. So, that's already addressing that shortcoming of

  You say "that *trust* must ensure that it can detect lying entities"
yet you don't say how that will be accomplished. "the AAA SA must detect
a misrepresented NAS Identity." Please explain _exactly_ what part of the
protocol ensures that an SA based on an IP address detects a misrepresented
NAS Identity.

> keys appropriately, this is not needed.

  To quote Glen, "just because you say so?"

  As I have mentioned repeatedly, the problem of a pass-through
authenticator lying about its identity is a contained problem. While
I can't speak for the EAP mailing list (and neither can you) it can be
inferred that people don't want to address it because it is contained.
It surely wouldn't be the first time a standards body has decided not to
address a problem because the problem is relatively contained.

  But when you leave the pass-through model you are no longer containing
the problem. You are not in the pass-through model because the peer is
not speaking a 2 party authentication protocol to a server through this
new authenticator. The new authenticator is just getting a key derived
from an exchange that happened elsewhere.

> approach, which also means using AAA as the transport.

  You admit there's a problem, you say the problem needs to be fixed
(elsewhere), and you say we need to go forward using the problematic model.
That just doesn't make sense.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 13 Feb 2007 13:46:24 -0800 (PST)

Hi Madjid,

  By key notarization I mean a scheme in which the key-encrypting key
is comprised of two parts, one part supplied by the key distributior
and the other provided by the peer. So the recipient of the key can't
unwrap it until it gets both halves to generate the key-decrypting key.
The key halves would bind the identities of the parties involved in
the protocol.

  This type of scheme would allow for a "push model" where keys can be
gratuitously distributed to authenticators as opposed to a "pull model"
where the authenticator doesn't get the key until the peer attempts to
connect to it.

  Dan.

>> On your comment on #2, that is why I was asking for a generic re-auth
>> key
>> to
>> tamper-proof
>> through
>>>> chronological order:) I understand that once you give a domain its
>>>> root
>>>> key
>>>> (EMSK-jr or DSRK), the domain does not have to go to the home
>>>> (ignoring
>>>> the
>>>>> from one domain to another domain, you need a new domain EMSK and
>>>>> that
>>>>> EMSK
>>>>> wordsmithing). So we need a re-auth to the HOME DOMAIN, thus we need
>>>>> a
>>>>> key
>>>>> suggested hierarchy. I wanted to call it "alldomainreauth" to
>>>>> indicate
>>>>> that
>>>> re-key

---

From: <[email-masked]>
Date: Tue, 13 Feb 2007 16:02:09 -0600

It's kinda like having DNA from three parents. Kinky. Twisted.

A push model sounds useful, but would still need to be triggered by
something.

Michael

-----Original Message-----
From: ext Dan Harkins [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 1:46 PM
To: Madjid Nakhjiri
Cc: [email-masked]; 'Madjid Nakhjiri'
Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

  Hi Madjid,

  By key notarization I mean a scheme in which the key-encrypting key is
comprised of two parts, one part supplied by the key distributior and
the other provided by the peer. So the recipient of the key can't unwrap
it until it gets both halves to generate the key-decrypting key.
The key halves would bind the identities of the parties involved in the
protocol.

  Dan.

> without crash landing:)
>
> However, my "channel binding tuple" included "other info", so you can 
> stick other things in there if you want (say for replay). I am not 
> sure what an "interleaving attack is". What do you mean from key 
> notarization?
>

> is quite a bit of detail needed to take care of things like 
> interleaving attacks, replay issues, and key confirmation. In an 
> earlier email I mentioned Otway-Rees. Check it out.
>
>   Also, I think that a key notarization scheme can be used to solve 
> this problem as well. There are benefits and drawbacks to each.
>
>   Dan.
>
>> Hi Dan,
>>

>> key to Home EAP server, the peer sends a request for a handover to a 
>> that verifies the identity of the middle entity (in DSRK case, 
>> visited AAA server identity, in HRK case, the authenticator/AP 
>> identity). So here is the solution (ME: middle entity)
>>
>> If the downlink id (DID) of middle entity (shown to peer) is included

>> in the (peer request, MAC) and signed with Kps and the uplink ID of 
>> ME (shown to
>> After key generation at server and peer (just like EAP MSK/EMSK), the

>> would generate a DSRK and give it to the visited AAA server. What if 
>> server it is "AAAsrv.domainX" and gets a root key for a completely
different domain.
>> How does the authenticator communicate this identity-- ap1.domainX" 
>> to the HOKEY server? What if its identity really was ap2.domainX and 
>> said, "give me the rMSK for ap1.domainX". Would it get the rMSK for 
>> ap1.domainX?
>>
>> server to the transaction. That blob is sent to the home AAA server. 
>> The protocol MUST entail the home AAA server decrypting the blob and 
>> server inside the tamper-proof blob (send by the client) is the same 
>> as the identity of the visited AAA server and/or HOKEY server that is

>> sending the blob which it cannot tamper. The home AAA server MUST 
>> send a tamper-proof acknowledgement back to the client to let it know

>> that the handshake completed.
>>
>> authenticator. The HOKEY server MUST decrypt that blob and verify 
>> that the identity of the authenticator inside the tamper-proof blob 
>> is the same as the identity of tha authenticator sending the 
>> tamper-proof blob to it. It MUST also send back an acknowledgment to 
>> the client to let it know the handshake completed.
>>
>>> (ho-auth?) in the visited domain.  Here's the scenario for a visited
domain:
>>> server 4. visited HOKEY server requests HRK from visited AAA server
(via API)
>>> In the end, we've used a series of 2-party key agreement protocols 
>>> to generate a keying hierarchy whose bottom-most keys are channel 
>>> bound to every entity involved in their derivation and transport.
>>>
>>> --
>>>> domain its root key (EMSK-jr or DSRK), the domain does not have to 
>>>> go to the home (ignoring the scope debate for now) for dealing with

>>>> internal matters.
>>>>
>>>> My point was how does the peer and the new domain get that EMSK-jr 
>>>> to begin with?
>>>> (which does not sound practical to me), the EMSK-jr for each domain

>>>> has to be generated per request as the peer enters the new domains.
>>>>

>>>> handovers.
>>>> AP=authenticator may be accurate for 802.11 but is not in general. 
>>>> It is not even the case in CAPWAP and it is not in WiMAX, so we 
>>>> need to decide whether we can or cannot go below the authenticator.

>>>> Are we now saying we can go below authenticator by mapping BSs to 
>>>>> However, my point is still not addressed and that was when you 
>>>>> move from one domain to another domain, you need a new domain EMSK

>>>>> and that EMSK MUST come from the initial EMSK that resides in home

>>>> domain-specific root keys derived from the original EMSK.  They are

>>>> scoped for per-domain use.  These are the same keys we called "EMSK

>>>> jr" at the interim.
>>>> They
>>>> reside on the AAA server for each domain, and are transported there

>>>> using AAA.
>>>>> "domainreauth" key in my suggested hierarchy. I wanted to call it 
>>>> I think that key is improperly scoped.  You can't use it to 
>>>> generate keys for a different scope.  Using the domain-specific 
>>>> root keys, you can still quickly rekey in a visited domain.  There 
>>>> is no need to talk to the home EAP server, provided the 
>>>> domain-specific keys were pre-emptively distributed.
>>>>
>>>> re-key operation between the peer and the HOKEY server in the 
>>>> visited domain.
>>>>> means generating EMSKs. And as far as I recall getting new keys 
>>>>> for access to the network through new attachments (HANDOVER) was 
>>>>> called handover keying (name of WG), not rekeying. To me rekeying 
>>>>> means, you have a key and it is expiring or compromised and you 
>>>>> need a new one instead.
>>>>
>>>> Ah, I agree that can be another interpretation of the terminology.

>>>> It might be useful to call it "handover keying" instead of
"re-keying".
>>>> In my picture, AP == authenticator, which is certainly the case for

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 13 Feb 2007 14:53:01 -0800

Hi Dan,
May be this was not clear in all my emails - I DON'T believe there is a
problem. I am willing to accept that *you believe* there is a problem
and am asking that you write a draft explaining the problem and how you
see it being solved. If such a draft convinces the community of the
problem, that should then be fixing AAA in a broader sense. 

While we both believe that the backend needs to be able to detect lying
identities, there is clearly a disconnect between what we both are
saying in terms of whether or not this is broken today. I agreed that
RADIUS *implementations* may not be done correctly today. However, this
is clearly feasible in Diameter. Let's take this example. 

Consider Diameter deployed with TLS. Diameter provides the option of
directly creating a TLS session with the NAS, even in the presence of
proxies. The IDs used in the TLS exchange may be FQDNs, for instance. If
the NAS ID is appropriately used in creating the TLS session, the ID is
effectively bound to that TLS session. There isn't a problem here. 

OTOH, you refuse to accept that a proper deployment of AAA could, in
fact, possess the security properties we need here. We don't build specs
for broken *implementations*. If the AAA specs are broken in a way that
will prevent that from having the necessary security properties
irrespective of how it is deployed, that is a separate issue. You seem
to be mixing the two. There is definitely a means to deploy this stuff
correctly. If that guidance is not clear, we should make that clear.
But, using something else for HOKEY just because some of it is deployed
incorrectly is not making sense to me. 

Vidya

> Sent: Tuesday, February 13, 2007 1:24 PM
> To: Narayanan, Vidya
> Subject: RE: AAA Issues (RE: [HOKEY] Channel binding/ lying 
> MITM: EMSK Hierarchy Changes)
> 
> 
>   Hi Vidya,
> 
>   You seem to be simultaneously arguing that something is 
> broken and needs to get fixed (elsewhere) and that we can use 
> that broken thing in HOKEY because it's used today.
> 
> >>   On the contrary, it prevents the NAS from representing itself to 
> >> the peer as one identity and to the AAA server as another.
> >>
> >
> And yes, the server must be capable of detecting wrong IDs 
> and misinformation. That is EXACTLY WHAT I'M ARGUING FOR!!!!
> 
>   You are not proposing anything that allows the server (the 
> 3rd party that trusts both parties and is trusted by both) to 
> detect this lying!
> 
>   I am proposing that we implement a secure 3 party protocol 
> to detect this lying.
> 
> >> >                                                        
> If a NAS is 
> server uses 
> >> for communication with the NAS to the NAS Identifier. That 
> is great!
> >>
> >
> >> >                                                 The 
> bottomline as I

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 13 Feb 2007 16:10:39 -0800 (PST)

Hi Vidya,

  So if you use DIAMETER, and you deploy it with TLS, and if you enroll
all NASs in some certification authority where their NAS Id is part of
the DN in a certificate then you can have SAs based on NAS Ids. And
then, even though it's not part of any standard I can find, you could
ensure that the NAS Id presented in a key request is the same as the
NAS Id that is bound to the SA. Wonderful. That's what you are requiring
to allow a server to detect a NAS lying about its identity?

  I accept that a deployment (however unlikely and contrived) could
possess some of the right security properties. In fact, I said that much
in this thread already (to Charles).

  You are asserting that if it is possible to come up with a single
instance of a compliant protocol operating securely then the protocol
is secure. I am asserting that if it is possible to come up with a single
instance of a compliant protocol operating insecurely then the protocol
is insecure.

  Your standard is flimsy and I submit that no security protocol should
be developed using it. Key distribution entails a security protocol.

  One property that a key distribution protocol MUST have is that it
MUST NOT be possible to distribute the wrong key. A protocol that cannot
guarantee that is not suitable. And "guarantee" doesn't mean that you
merely need to find a single instance of it working correctly. What it
means is that you cannot find a single instance of it working incorrectly.

  For the purposes of HOKEY I don't care whether the AAA specs are
broken in some respect. I just care whether HOKEY is going to use them
in a broken manner.

  What I don't understand is what your opposition to requiring correct
behavior in HOKEY is? If you believe that certain behavior is correct
then you should not be opposed to requiring that behavior as part of key
distribution in HOKEY.

  Dan.

>> NAS-lying-to-the-peer and the

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 13 Feb 2007 17:34:58 -0800

Hi Yoshi,

Initially the idea was to use EMSK to generate use specific keys (USRK), one
for each use case. So handover root key (HRK) would be one key off EMSK and
for instance you would have a MIP-USRK dealing with Mobile IP.

As I argued in SJ, you can have one USRK at the top in the home domain and
then derive USRKs for visited domains from that top level USRK.

			EMSK
		     /  |  \
		    /   |   \
		   /    |    \
	      USRK1 USRK2  USRK3
	      /  \
           /    \
Domain2USRK     Domain 3USRK

This way the service model is preserved and service level agreements between
the operators can be honored easily.

The DSRK (domain root specific keys) as they are named to introduced to deal
with the fact that people want one key per domain to deal with everything
between heaven and earth within the domain.

Having seen all the discussion on the list, I am starting to think that we
should deal with visited domain with less priority and I am starting to see
the argument about symmetrical key hierarchy fade away, since the
re-authentication key with home EAP server seems to be dangling in the air..

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 3:25 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; 'Charles Clancy'; 'Dan Harkins'; [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Yoshihiro Ohba

> > >> ho-keying in general, but we need something defined in order to
create

> > >> This provides a HOKEY-independent way to secure the DSRK and HRK.
This
> > >>>>> server was really "AAAsrv.domainY"? It tells the home AAA server
it
> > >>>> association.  It prevents the layer below you from telling you a
fake
> > >>>  What is the identity bound to that security association and how
does
> > >>> the wired port of an AP become known to a wireless client of that
AP?
> It
How
> > >>>  The 2 party protocol is being justified because the client is
unaware
> > >>>  But when you get into the mode of distributing keys between 3
parties
following
for
> > >>>> whenever you did a handoff in the visited domain you would just
need
> > >>>> Thus, we're doing basically the same thing as I proposed, but
involve
> > >>>  Yes, except, as I said I think (a) is out of scope, and depending
on
> how
> > >>>> Thus during #1 the peer would send blobs (b), (c), AND (d).  Then
to
> do
view
> > >>> There has to be a protocol such that each party agrees on the
identity
> of

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 13 Feb 2007 17:59:27 -0800

Hi Dan,

Thanks for the clarification. Key encrypting keys sounds like a key
distribution based on wrapping/ transport. What about a key derivation
technique, where no wrapping involved?  The two parties still exchange
parameters/ key halves but arrive at the final key themselves without the
need for key wrapping?

I would put EAP EMSK in that category. The keys below EMSK such as Handover
root key (HRK) and authenticator keys (we called them ADMSKs) would be
derived also based on a parameter exchange but not as a result of a key
wrap.

Also it seems that not every level of key hierarchy has all the security
measures, such as anti-replay measure inbuilt. For instance, HRK and ADMSK
derived just based on use of Identities and scope, etc, but no nonce
exchange. Only at the link level, there may be nonce exchanges to avoid
replays. I am not sure if this has huge security implications, but it
certainly avoids the need for real time exchanges during derivation of each
level of the hierarchy.

If you require a real time exchange for each level of hierarchy, then yes,
you cannot have proactive keying and you also have to have one exchange per
level of key hierarchy and that would make the latency horrendous. No?

R,

Madjid 

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 1:46 PM
To: Madjid Nakhjiri
Cc: [email-masked]; 'Madjid Nakhjiri'
Subject: RE: [HOKEY] Channel binding/ lying MITM: EMSK Hierarchy Changes

  Hi Madjid,

  Dan.

> stick
>>>> using

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 13 Feb 2007 18:40:00 -0800

Hi Dan,
Perhaps at this point, we should baseline where we are and continue the
rest of the discussion in the context of the protocol design. 

I agree that it MUST NOT be feasible for an entity to obtain a key that
is not meant for it. I am also saying that it is feasible to ensure that
via a correct deployment of AAA. And, perhaps this is something the
HOKEY protocol document (or its AAA counterpart document) must elaborate
on, as to how to achieve this property via AAA transport. However, I
disagree with your take that we should abandon AAA and use something
else. If a particular AAA deployment finds the risk of using RADIUS with
hop-by-hop security acceptable, that's their problem. 

Embarking on a path of using something other than AAA will ensure that
this protocol doesn't get used anywhere and it is simply not needed. We
are trying to solve real problems and make EAP usable in a secure
fashion in an enviroment where handoff latency is a huge deal. As a
tradeoff for latency, we see designs that context transfer the EAP MSK
in practice across different entities, opening up the possibility for
domino effect. We are trying to provide a secure, low latency
alternative to such designs. 

Since we agree on the security properties required and we agree that
Diameter can provide the necessary properties, we should agree to use
that and move on with the design now.  

Vidya

> Sent: Tuesday, February 13, 2007 4:11 PM
> To: Narayanan, Vidya
>   So if you use DIAMETER, and you deploy it with TLS, and if 
> you enroll all NASs in some certification authority where 
> their NAS Id is part of the DN in a certificate then you can 
> have SAs based on NAS Ids. And then, even though it's not 
> part of any standard I can find, you could ensure that the 
> NAS Id presented in a key request is the same as the NAS Id 
> that is bound to the SA. Wonderful. That's what you are 
> requiring to allow a server to detect a NAS lying about its identity?
> 
>   I accept that a deployment (however unlikely and contrived) 
> could possess some of the right security properties. In fact, 
> I said that much in this thread already (to Charles).
> 
>   You are asserting that if it is possible to come up with a 
> single instance of a compliant protocol operating securely 
> then the protocol is secure. I am asserting that if it is 
> possible to come up with a single instance of a compliant 
> protocol operating insecurely then the protocol is insecure.
> 
>   Your standard is flimsy and I submit that no security 
> protocol should be developed using it. Key distribution 
> entails a security protocol.
> 
>   One property that a key distribution protocol MUST have is 
> that it MUST NOT be possible to distribute the wrong key. A 
> protocol that cannot guarantee that is not suitable. And 
> "guarantee" doesn't mean that you merely need to find a 
> single instance of it working correctly. What it means is 
> that you cannot find a single instance of it working incorrectly.
> 
>   For the purposes of HOKEY I don't care whether the AAA 
> specs are broken in some respect. I just care whether HOKEY 
> is going to use them in a broken manner.
> 
>   What I don't understand is what your opposition to 
> requiring correct behavior in HOKEY is? If you believe that 
> certain behavior is correct then you should not be opposed to 
> requiring that behavior as part of key distribution in HOKEY.
> 
>   Dan.
> 
> > Hi Dan,
> > May be this was not clear in all my emails - I DON'T 
> believe there is 
> > a problem. I am willing to accept that *you believe* there is a 
> > problem and am asking that you write a draft explaining the problem 
> > and how you see it being solved. If such a draft convinces the 
> > community of the problem, that should then be fixing AAA in 
> a broader sense.
> >
> > While we both believe that the backend needs to be able to detect 
> > lying identities, there is clearly a disconnect between 
> what we both 
> > are saying in terms of whether or not this is broken today. 
> I agreed 
> > that RADIUS *implementations* may not be done correctly today. 
> > However, this is clearly feasible in Diameter. Let's take 
> this example.
> >
> > proxies. The IDs used in the TLS exchange may be FQDNs, for 
> instance. 
> > If the NAS ID is appropriately used in creating the TLS 
> session, the 
> > ID is effectively bound to that TLS session. There isn't a 
> problem here.
> >
> > fact, possess the security properties we need here. We don't build 
> > specs for broken *implementations*. If the AAA specs are 
> broken in a 
> > way that will prevent that from having the necessary security 
> > properties irrespective of how it is deployed, that is a separate 
> > issue. You seem to be mixing the two. There is definitely a 
> means to 
> > deploy this stuff correctly. If that guidance is not clear, 
> we should make that clear.
> > But, using something else for HOKEY just because some of it is 
> > deployed incorrectly is not making sense to me.
> >
> > Vidya
> >
> broken and 
> >>   You are not proposing anything that allows the server (the 3rd 
> >> party that trusts both parties and is trusted by both) to 
> detect this 
> >> lying!
> >>
> >>   I am proposing that we implement a secure 3 party protocol to 
> >> detect this lying.
> >>
> >> >> >
> >> If a NAS is
> >>   If I believe? You said "if the backend SA is not 
> properly tied to 
> >> the NAS, nothing works." You accept that the backend SA is not 
> >> properly tied to the NAS, and therefore "nothing works". 
> Since this 
> >> technique of key distribution doesn't work according to you why do 
> >> you want to use it in HOKEY?
> >>
> >> >>   That will make sure that the identity the NAS presents to the 
> >> >> AAA server is the one it authenticated as. So now what 
> is needed 
> >> >> is a way to ensure that that identity is the one being 
> represented 
> >> >> to the peer.
> >> >>
> >> >> > later. If a NAS got away with pretending as ISP2.net, 
> it would 
> >> >> > be billing as ISP2.net, which is not in the best interest
> >> of ISP1.net
> >> >> > either!
> >> >>
> credential 
> >> >> that the peer uses for network access. If ISP2.net obtained the 
> >> >> key that the peer should be using when talking to ISP1.net that 
> >> >> allows ISP2.net to impersonate the peer to ISP1.net. If 
> and when 
> >> >> the peer attempted to legitimately connect to ISP1.net it would 
> >> >> allow ISP2.net to decrypt all its traffic, inject bogus traffic 
> >> >> into the flow, and do all sorts of nastiness.
> >> >>
> >> >
> >> causing bogus traffic to appear authentic. Surely those are things 
> >> that network access is supposed to prevent. Please don't 
> get hung up 
> >> on "decrypt all its traffic", that's just one of the many nasty 
> >> things that is possible.
> >>
> >> >>   This doesn't function today because none of this 
> exists today! 
> >> >> We don't go building key heirarchies and distribute 
> keys all over 
> >> >> the place. If we did then HOKEY wouldn't be
> >> necessary.
> >> >>
> >> >
> >>   You're puzzled? I'm puzzled because here you're arguing 
> that this 
> >> is widely deployed and "it doesn't matter" whether you expose a 
> >> secret to 1 person or a dozen people. You imply that it is 
> OK to use 
> >> this with HOKEY.
> >> But above you said "the server must be capable of 
> detecting wrong IDs 
> >> and misinformation" while admitting that, today, it is not 
> capable of 
> >> such a feat.
> >>
> >>   So what's puzzling is how you can say that something must to be 
> >> done, that it is not being done, and that it's not a problem.
> >>
> >> >>   What we do today requires a reauthentication each time. As I 
> >> >> mentioned earlier in this thread, the damage that can 
> be done is 
> >> >> very contained.
> >> >>   Preventing the NAS from presenting a different 
> identity to the 
> >> >> peer and AAA server would be a good thing (if it's 
> lying in both 
> >> >> directions exposure is much easier) but now you seem to 
> be saying 
> >> >> that if we can't prevent it from lying to both about the same 
> >> >> identity then we should allow it to lie to either one? How 
> >> >> bizarre!
> >> >>
> >> >> "If we can't have both a belt AND suspenders then we 
> should have 
> >> >> neither"
> >> >>
> >> >
> >> > No, this is NOT what I'm saying. I'm only saying that if you 
> >> > believe there are issues with AAA security and how it 
> ties the SA 
> >> > to the identity of the NAS, that needs to be worked out 
> outside of
> >> the HOKEY
> >>   HOKEY is not the same as the pass-through authenticator 
> model. In 
> >> that model the peer cannot detect that a AAA server even 
> exists. It 
> >> is a 2 party protocol from the peer's perspective. HOKEY 
> will give a 
> >> key that the peer knows is only known by 1 other entity to a 3rd 
> >> entity and that is not a 2 party protocol.
> >>
> >> >> >                                  The
> >> > identity, it's credentials won't match and hence, it would be 
> >> > denied access. Similarly, the AAA SA must detect a misrepesented
> >> NAS Identity.
> >> > has been an acceptable security model for the users of AAA. 
> >> > Diameter provides the option of true end-to-end trust 
> relationships
> >> even in the
> >> yet you don't say how that will be accomplished. "the AAA SA must 
> >> detect a misrepresented NAS Identity." Please explain 
> _exactly_ what 
> >> part of the protocol ensures that an SA based on an IP address 
> >> detects a misrepresented NAS Identity.
> >>
> >> > reason it has remained unsolved thus far. This is not to 
> say that 
> >> > it shouldn't be solved for EAP now - the MSK is not bound to
> >> any identities
> >> I can't speak for the EAP mailing list (and neither can 
> you) it can 
> >> be inferred that people don't want to address it because 
> it is contained.
> >> It surely wouldn't be the first time a standards body has 
> decided not 
> >> to address a problem because the problem is relatively contained.
> >>
> >>   But when you leave the pass-through model you are no longer 
> >> containing the problem. You are not in the pass-through 
> model because 
> >> the peer is not speaking a 2 party authentication protocol to a 
> >> server through this new authenticator. The new 
> authenticator is just 
> >> getting a key derived from an exchange that happened elsewhere.
> >>
> >> >> >                                                 The
> >> bottomline as I
> >> >>   Yes, ensuring that key transport is secure is the bottom line 
> >> >> because if you can't ensure that the all bets are off.
> >> >> But merely assuring that the transport is correct does 
> not ensure 
> >> >> that the correct thing is being sent over that secure 
> transport. 
> >> >> And if you don't ensure that then it doesn't matter whether the 
> >> >> transport is secure or not!
> >> >>
> >> >
> >> (elsewhere), and you say we need to go forward using the 
> problematic 
> >> model.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Feb 2007 00:30:35 -0500

> then derive USRKs for visited domains from that top level USRK.

This (the original key hierarchy) is what I have been mentioning!  I
believe this is most flexible enough to support all scenarios being
discussed.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Feb 2007 01:26:34 -0500

Vidya,

It just does not sound reasonable to me to stick with a key
distribution model whose security properties depend on transport
security or a particular deployment.  What is wrong with designing a
key distribution protocol that is supposed to securely work with any
transport and any deployment if some people are willing to work on it?

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 13 Feb 2007 22:50:27 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on

> transport and any deployment if some people are willing to work on

/WG Chair Hat OFF

That's a great idea, but I haven't heard of one of those in these
discussions.  In particular, I have no idea how any of Dan's 3-party
suggestions could work as-as in the presence of AAA proxies (I assume
that you are categorizing AAA as a "transport").  That is certainly a
popular deployment.

/WG Chair Hat ON

Nothing wrong with it, but it sounds like that's a different WG to me.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Feb 2007 11:21:29 -0500

Hi Glen,

> that you are categorizing AAA as a "transport").  That is certainly a

It must work over any transport including AAA even if there are a
number of AAA proxies among the entities of the key distribution
protocol or even if EAP server and AAA server are implemented in
separate boxes using some other protocol in between.  AAA protocols
basically need to define some attributes to carry the key distribution
protocol message and that's it.  From key distribution perspective, I
believe categorizing AAA just as a "pipe" is a key to get everything
right.

> Nothing wrong with it, but it sounds like that's a different WG to me.

I believe that's part of deliverable (5) of the charter:

"
  (5) A protocol specification for secure and timely distribution of
  cryptographic keys to support roaming and handover.  Use of AAA
  protocols is preferred, and if used, should leverage existing work
  if possible (such as RADEXT WG work on RFC 3576bis and RADIUS
  cryptographic algorithm agility). However, if AAA protocols cannot
  meet the objectives, other protocols for reactive or proactive
  distribution or retrieval of keys by the proper entities is
  permitted.
"

Yoshihiro Ohba

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 14 Feb 2007 10:08:37 -0800 (PST)

Hi Vidya,

  I don't agree that Diameter can provide the necessary security
properties. I said, "I accept that a deployment (however unlikely and
contrived) could possess some of the right security properties." Some.

  And furthermore, I don't think it's right to pursue a protocol which
can only be done securely in highly contrived deployment because it's
not going to be deployed like that, it will be deployed the easiest way
possible. I'm not putting a fork in AAA but by itself I don't think
it's enough.

  I'll repeat that if an implementation of a protocol is both compliant
and "broken" (to quote you) then the protocol is not suitable.

  You admit that certain behavior is required to be secure. Surely you
will insist in doing that behavior (so as not to be "broken"). So why
don't you want to do that necessary work as part of the key distribution
protocol instead of as undocumented additions to a particular deployment
of the protocol? You're going to be doing it anyway.

  Dan.