Subject: [HOKEY] [Fwd: Re: WGLC for draft-ietf-hokey-emsk-hierarchy]

From: "Dan Harkins" <[email-masked]>
Date: Sat, 2 Feb 2008 18:22:38 -0800 (PST)

I forgot to add the mailing list when I sent these :-(

  Dan.

---------------------------- Original Message ----------------------------
Subject: Re: [HOKEY] WGLC for draft-ietf-hokey-emsk-hierarchy
From:    "Dan Harkins" <[email-masked]>
Date:    Fri, February 1, 2008 5:33 pm
To:      "Charles Clancy" <[email-masked]>
         [email-masked]
--------------------------------------------------------------------------

  Hi Charles, hi Glen,

  It was my understanding that we had consensus around the idea that
each time a peer went to a new domain he would do a full authentication
back to the home AAA server.

  If that understanding is correct then an issue I have I would like to
become part of the issues list for this document is to get rid of the
DSRK. All we need to do is define how the EMSK forms USRKs and give one
example of a USRK-- a HOKEY usage and therefore a HOKEY USRK. The
document can be cleaned up considerably then.

  Another issue I have is the use of HMAC-SHA-256 to name keys. We're
using an extremely strong cryptographic mixing function and then throwing
away 3/4 of its output to simply name a key. It's like using a rocket-
fueled dragster to drive down the street to a neighbor's house! The
other problem with such a technique is that it maps every single key
hierarchy to the same name-space (numbers between 1 and 2^64). This will
effectively prevent rational key management. It is impossible for keys
to be discovered using what would be normal queries like, "identify all
keys from EAP session <foo>" (which would be required if you wanted to
do something like delete an entire key hierarchy). Since all of the
identifying information has been randomized along with every other key
hierarchy the only way to do that is linear search. We should not be
precluding important and useful datastructures, like hash tables, from
being used in implementations of our protocols.

  I strongly recommend we merely concatenate the EAP Session-ID with
whatever identifying label was bound into the generation of the key
itself. So if "blah" is the label used in prf+() to derive a USRK from
the EMSK, then the name of this derived key would be the EAP Session-ID
that was used to derive the EMSK concatenated with "blah". Make sense?

  thanks,

  Dan.

On Fri, January 11, 2008 8:07 am, Charles Clancy wrote:
> HOKEY WG,
>
> With the latest rev of the EMSK document, I think we are ready for last
> call.  Please respond to the list with your reviews and comments by
> Friday, February 1.
>
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
>
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
>

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 02 Feb 2008 21:43:19 -0800

Thanks Dan.  Please see inline.

> To:      "Charles Clancy" <[email-masked]>

I had the opposite understanding.  After it was pointed out that the key 
hierarchy was not complex at all and the dispute was about 1 level vs. 2 
levels, the discussion died down.  I assumed that you were convinced 
that this is not an issue after all.  I am surprised to hear your 
observation now that there was consensus.  We are really talking about 1 
level of (optional) key derivation.

> document can be cleaned up considerably then.

The notion of visited domain keying (the terminology of VMSK was changed 
to DSRK based on WG discussion) is in the charter and there are 
deliverables associated with it.  Here are the excerpts for easy reference:

 From the Description:
"4) When wireless networks employ AAA infrastructures, the cross-domain
roaming is handled by inter-domain authentication via the "home"
AAA/EAP server.  Any authentication must pass through the home server,
which increases latency. Latency can be reduced by establishing a
trust relationship between the EAP peer and the visited domain's
AAA/EAP server.  This trust relationship would be brokered by the home
EAP/AAA server.  Efficient re-authentication for the EAP peer can be
supported locally within the visited domain."

 From the Deliverables section
"6) A specification for inter-EAP-authenticator roaming and re-
authentication in visited domains that is brokered using inter-domain
trust relationships to support efficient inter-domain roaming."

Goals and Milestones:

"Sep 2007	  	Submit Protocol and Keying Hierarchy for Visited Domain 
Handovers and Re-authentication draft to IESG"

No one is forced to use the DSRK.  If there is consensus on sending the 
USRK to the visited domain (it would at least be worthwhile to have a 
key that does not leave home at all and another that does), that can be 
introduced as an option.  Consider that when there are two or more 
usages, then instead of sending that many USRKs to the visited domain, 
the home domain could send one DSRK and have as many USRKs as necessary 
derived within the visited/local domain.  There is a clear optimization 
here.  That comes with just one extra level of key derivation.

Would it help if we clearly specified that DSRK derivation and use is 
optional?  Does that sound like a reasonable middle ground here?

> fueled dragster to drive down the street to a neighbor's house! 

 From the benchmarks I have seen SHA-256 takes twice as long as SHA-1, 
so we are really not talking about astronomical differences.  We use 
HMAC-SHA-256 to avoid mandating implementation of two algorithms.

>The

Sounds reasonable, but please read on.

> that was used to derive the EMSK concatenated with "blah". Make sense?

Yeah, this is what Joe had before to his credit, although it was not a 
concatenation, but a derivation.  Name derivation elsewhere is also done 
with keys, e.g., PMKID derivation in 11i.  Sure, for whatever reason 
IEEE uses 128-bit names; we thought we'll save some place and said that 
64-bit names are quite sufficient, so we throw away more.  :)

Anyway, then we noticed that there is the matter of exporting 
session-IDs and that's what led to the current mechanism.  We were told 
that one of the EAP RFCs/I-Ds does not allow that.

Thanks again for your review Dan.

best regards,
Lakshminath

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2008 07:54:29 +0100

Lakshminath Dondeti wrote:
> levels, the discussion died down.

  I agree with Dan.  I had commented on this issue, too, and I did not
see any counter-argument.  It has nothing to do with a key hierarchy, so
I'm not sure why you brought that up.

  Existing commercial roaming agreements are predicated on the home AAA
server being authoritative for all authentications.  If it authorizes
network access, it also agrees to pay the network operator at the edge
for network access.  If it does not authorize network access, any
attempt to obtain payment is fraudulent, and is ignored.

  Inter-domain eap re-authentication means that someone *other* than the
home AAA server will re-authorize the user.  This ERP server cannot be
in the same domain as the original, otherwise it would be intra-domain,
and not inter-domain.  This ERP server can only be one of the AAA proxies.

  The AAA proxies do not have this authority, based on current
commercial practices.  I do not see this behavior changing.

>  I assumed that you were convinced 

  No.  There are commercial issues involved that trump any technical
analysis.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 02 Feb 2008 23:07:44 -0800

I understand your argument of commercial issues, Alan.  In fact, it 
turns out the idea of visited domain key and usages thereof is rooted in 
commercial possibilities.   We have now the notion of usages and when 
there are multiple usages, the agreement between home and visited can be 
that here is a DSRK and you (the visited domain server) and the peer 
derive all the usage keys you want.  That is the motivation and that was 
the reason the charter talks about visited domain keying and that is 
what is supported by the DSRKs.

> I'm not sure why you brought that up.

I brought it up because Dan noted before "That being the case the
key hierarchy becomes an unnecessary complexity."

regards,
Lakshminath

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 3 Feb 2008 01:36:43 -0800

Lakshminath Dondeti <> scribbled on Sunday, February 03, 2008 2:08 PM:

> there are multiple usages, the agreement between home and visited can
> be that here is a DSRK and you (the visited domain server) and the
> peer derive all the usage keys you want.  That is the motivation and
> that was the reason the charter talks about visited domain keying and
> that is what is supported by the DSRKs.    

I suspect that at least some of the people in this conversation are
arguing about different things :-)  There was, in fact WG consensus that
the _initial_ authentication in any given domain must go to the home AAA
server; subsequent reauthentications can be routed to the local hokey
server.  By itself, however, this usage doesn't make an argument for a
domain-specific key (as Dan has pointed out); the argument for a DSRK is
based upon the ideas that Lakshminath has described above & are not
hokey-specific.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2008 14:09:22 +0100

Lakshminath Dondeti wrote:
> commercial possibilities.

  Perhaps I was unclear.  I was talking about network topology, not key
hierarchies.  Network topologies drive key hierarchies.  Commercial
requirements drive key hierarchies.

  AAA proxy servers do not have the ability to authenticate users on
their own.  Therefore, they do not need to possess, or to manage keys.

  A newly visited domain does not have the ability to authenticate users
on it's own.  As noted above, neither do AAA proxies.  The only entity
that does have the ability to authenticate the user is the home AAA server.

  To Dan's original point: I agree that this view of the network was the
consensus.  I don't understand how discussing key hierarchies addresses
the concerns that were raised.

  The various hokey documents derive all sorts of interesting key
hierarchies with little discussion of *why* this is done, or what
problem is being solved.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 03 Feb 2008 11:01:41 -0800

> based upon the ideas that Lakshminath has described above & are not
I am also getting the sense that we are talking about different things 
at the same time and that's why not seeing each other's point.  I think 
your summary is quite correct.  Thanks Glen for clearing it up.

The initial authentication in any given domain must go to the home.  The 
argument for the DSRK is for multiple usages to be managed locally 
within each domain.  (There are other arguments for other things, but 
simplifying and separating each of them might be more helpful in making 
progress).

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 03 Feb 2008 11:12:04 -0800

Hi Alan,

I may be missing something here, but the arguments you make are against 
our entire charter.  We are chartered to and have introduced the notion 
of visited domain key servers that terminate protocols within visited 
domain.  That is not something that exists today, I understand.  But, 
that is the vision in new networks being specified elsewhere.  Some 
efforts were made elsewhere to define MSK based key hierarchy in visited 
domains for reauthentication.  We agreed in this group to define an EMSK 
based key hierarchy (it took a lot of energy and effort to achieve that 
consensus, I might add).  You are right that key hierarchy alone is 
insufficient.  The keys are handed to visited domain servers.

Hope that clarifies.

regards,
Lakshminath

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2008 21:56:13 +0100

Lakshminath Dondeti wrote:
> our entire charter.

  I think you're missing much of my argument.  I am emphatically *not*
arguing against the charter.

>  We are chartered to and have introduced the notion
> domain.

  ... after an initial authentication.

  If there is no initial EAP authentication, then ERP cannot occur, right?

>  That is not something that exists today, I understand.  But,

  It's the same statement of a solution I've seen multiple times.

  I thought I had brought up concerns with the solution, and with the
assumed (but not defined) architecture.  What I've seen in response is
re-statements of the charter, and of the key hierarchy.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 03 Feb 2008 14:21:12 -0800

Alan, or someone else in the WG,

Please explain the disconnect then.

thanks,
Lakshminath

---

From: Stefan Winter <[email-masked]>
Date: Thu, 7 Feb 2008 11:25:45 +0100

Hi,

> simplifying and separating each of them might be more helpful in making

As a clarification: this means that inter-domain roaming is not speeded up at 
all by the ERP mechanisms? 
That is, only roaming between AAA servers/NASes that belong to the same 
administrative domain and which share a common ERP server can benefit from 
it? 
And further, DSRKs only generate added value when there is more than one 
application that needs keys which are tied to a given user?

Greetings,

Stefan Winter

-- 
Stefan WINTER

Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked]     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 08 Feb 2008 01:43:47 -0800

> all by the ERP mechanisms? 

It is.  Instead of an EAP authentication run, the peer only has to do 
ERP, which takes 1 RT, instead of 2+ or more.

regards,
Lakshminath

> ------------------------------------------------------------------------
>