Subject: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard

From: "Dan Harkins" <[email-masked]>
Date: Fri, 1 Feb 2008 17:16:42 -0800 (PST)

Hello,

  I believe this is a well organized and complete document. On
numerous occasions while reviewing it I made a mental question
regarding something only to have the question answered in a
subsequent paragraph.

  I do have several comments though:

 1. this protocol can be used in the presence of AAA proxies. Due
    to the nature of AAA proxies a peer or authenticator may not
    even know whether they are part of the communication chain.
    Therefore, from the view of a security threat their presence
    must be assumed by the peer and authenticator.

    The Domain referred to in section 2 (part of the EMSK key
    hierarchy draft) specifically allows for proxies as part of
    the distributed system of computers that define the Domain.

    This brings up many significant issues that are not addressed
    in this draft.

    - It cannot be claimed that a key is being bound to its
      context when the context cannot even be scoped. (Section 6)

    - The domino effect is not prevented because compromise of a
      proxy will compromise keying material on (other) authenticators.

    - A pairwise key is being given by one of the entities that share
      it, e.g. the server, to a 3rd entity, e.g. a proxy, without the
      consent of the other peer that shares the key, e.g. the peer.
      This brings up security considerations that are not discussed.

    - During discussions at a HOKEY meeting and on the list the rationale
      that justified proxies was that the peer is more concerned about
      receiving network access (which is confirmed in the ERP document
      when it says, "The primary purpose [of ERP] is network access
      control.") than about specifically authenticating "the network".
      Provided that service is obtained with no surprises in the bill at
      the end of the month the rationale was that the peer didn't care
      if the key was distributed to proxies if it was necessary to
      continue to provide network access. Which is a reasonable rationale.
      But it needs to be mentioned in this document. It has a unique
      threat model that is not discussed anywhere.

    - The aforementioned rationale begs the question of why have
      "Domain Specific Keys". If the peer doesn't care whether proxies
      have a key, potentially for a different domain, then it doesn't
      care about key separation between domains. This is significant
      added complexity for no benefit.

    - RFC4962 REQUIRES things-- bind key to its context, prevent the
      domino effect-- that ERP cannot support. ERP is a AAA key
      management protocol though and falls under the scope of RFC4962.
      There needs to be justification for why ERP is not meeting the
      mandatory requirements of RFC4962.

  I think all of these issues need addressing before advancement of this
  Internet-Draft.

 2. Inter-Domain ERP

  It is this reviewers recollection that consensus was reached in HOKEY
  to require a peer to reauthenticate back to the home AAA server every
  time it attached to a POP in different domain.

  Therefore, I wonder why a "Domain-Specific" key, the DSRK, and all it's
  progeny-- DS-rIK, DS-rRK, DSUSRK, etc.-- continue to be used by this
  protocol. A "HOKEY-KEY", a USRK, should be derived from the EMSK
  and that is the key given, through proxies if need be, to the ER
  server in the visited domain. If the peer goes to a different domain
  then it does a full reauthentication resulting in a _new_ USRK, that
  has no relation to the previous USRK, being given to the ER server
  in the new domain. Again, it was my understanding that the group
  already reached consensus on this matter.

 3. HMAC-SHA256 as a key naming technique

  SHA-256 is a computationally intensive operation; HMAC-SHA256 doubly
  so. There should, therefore, be some justification to use such a
  strong cryptographic mixing function if all one wants to do is
  "uniquely name a key". EAP methods export a Session-ID. An rIK can
  be named by the concatenation of Session-ID and "rIK". Similarly for
  the rMSK, rRK and the other keys being generated in ERP.

  This has the added benefit of allowing for key management to quickly
  identify keys based on common queries-- all the keys for a specific
  Session-ID, or all rIKs held by a particular entity. By using a
  strong cryptographic mixing function all specificity of the key names
  has been lost across every single key hierarchy that a HOKEY server
  may end up managing.

  This is a really bad idea and it should be changed before this
  Internet-Draft is advanced.

 4. Section 5.3.2 EAP-Initiate/Re-Auth Packet

  This packet has the following field:

     +-+-+-+-+-+-+-+-+
     |R|B|L| Reserved|
     +-+-+-+-+-+-+-+-+

   And "R" is, itself, reserved. This makes no sense. Please << 1
   this field.

  regards,

  Dan.

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

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 1 Feb 2008 17:45:32 -0800 (PST)

Hello again,

  Pardon my repetition but I have come up with a very valid
reason why naming keys using HMAC-SHA-256 is a bad idea.

  If one wants to administratively remove all keys in a particular
key hierarchy (which seems like an entirely reasonable request)
one must do a linear search of all keys in all key hierarchies
that a particular server maintains! This is because HMAC-SHA-256
has mapped all identifying key information for all key hierarchies
to the same name space. It precludes using something like a
hash table for fast lookup of all related keys.

  If keys were named by concatenating the EAP Session-ID with
a string that identified the particular key in the key hierarchy
rooted at the MK derived in that EAP Session-ID then the EAP
Session-ID could be used as an index into a hash table and all
keys for that particular key hierarchy could be looked up very
efficiently.

  regards,

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 02 Feb 2008 22:30:11 -0800

Hi Dan,

Many thanks for your review.  Please see inline for some notes.

> regarding something only to have the question answered in a
Thanks.
>       threat model that is not discussed anywhere.

We'll document this in the revision.

>       added complexity for no benefit.

Well, the added complexity is 1 additional level in the key hierarchy. 
The advantage is that if a domain supports multiple usages, it is 
efficient to send a domain specific key, DSRK, and let the domain and 
the peer derive all the usage keys appropriate within that domain. 
Different domains may support different usages and all usages may or may 
not be supported or even understood within the home domain.

So, if a new usage is introduced and that is not supported by the key 
server in the home, that is ok; as long as the server in the visited 
domain supports the usage, it is sufficient.

>       mandatory requirements of RFC4962.

We got a clarification from the author of 4962 that proxies are ok.  As 
you noted earlier, we'll document that the properties that are not 
supported in the presence of proxies and summarize the kind of 
guarantees that are available.

>   already reached consensus on this matter.

Please see above about the need for domain specific keys.

>   the rMSK, rRK and the other keys being generated in ERP.

Using HMAC-SHA-1 for keyname derivation has been done for several years 
now.  SHA-256 is half as fast as SHA-1, I understand that.  We traded 
that off with having to implement two different algorithms.

>   Internet-Draft is advanced.

There are advantages to using blobs for key ids (that they are blobs, 
semantically meaningless and so easy to use in packets, e.g., SPI in 
IPsec) and that's how PMKIDs in 802.11i are derived for instance.

There was also the issue of not being able to export EAP session IDs 
(IIRC) that I referred to in my other message.

>   This packet has the following field:

R is for result.  Please see 5.3.3.  Perhaps I am confused and not 
understanding your note above.  Please clarify.

thanks,
Lakshminath

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 3 Feb 2008 00:28:12 -0800

Dan Harkins <> scribbled on Saturday, February 02, 2008 8:46 AM:

>   Hello again,
> 
>   Pardon my repetition but I have come up with a very valid reason
> why naming keys using HMAC-SHA-256 is a bad idea. 
> 

It doesn't seem particularly reasonable to me.  The one reason I can
think of for this is to disable access for a particular user in some
domain; to do that it doesn't seem necessary to explicitly remove all
the keys in the hierarchy, just the root key (after disconnecting the
user).  Disconnecting the user should delete the PMK, TSKs, etc., right?

> one
> must do a linear search of all keys in all key hierarchies that a
> particular server maintains! 
> all identifying key information for all key hierarchies to the same
> name space. It precludes using something like a hash table for fast
> lookup of all related keys.      
> 
>   If keys were named by concatenating the EAP Session-ID with a
> string that identified the particular key in the key hierarchy rooted
> at the MK derived in that EAP Session-ID then the EAP Session-ID
> could be used as an index into a hash table and all keys for that
> particular key hierarchy could be looked up very efficiently.    

I won't argue that indexing the keystore by Session-ID is a bad idea
(though Username might be better), but I can't see how that depends upon
the actual key name.

>>     - During discussions at a HOKEY meeting and on the list the
>>       rationale that justified proxies was that the peer is more
>>       concerned about receiving network access (which is confirmed
>>       in the ERP document when it says, "The primary purpose [of
>>       ERP] is network access control.") than about specifically
>>       authenticating "the network". Provided that service is
>>       obtained with no surprises in the bill at the end of the month
>>       the rationale was that the peer didn't care if the key was
>>       distributed to proxies if it was necessary to continue to
>>       provide network access. Which is a reasonable rationale. But
>>       it needs to be mentioned in this document. It has a unique
>>       "Domain Specific Keys". If the peer doesn't care whether
>>       proxies have a key, potentially for a different domain, then
>>       it doesn't care about key separation between domains. This is
>>       significant added complexity for no benefit.
>> 
>>       management protocol though and falls under the scope of
>>       RFC4962. There needs to be justification for why ERP is not
>>       meeting the mandatory requirements of RFC4962.
>> 
>>   I think all of these issues need addressing before advancement of
>> this   Internet-Draft. 
>> 
>>  2. Inter-Domain ERP
>> 
>>   It is this reviewers recollection that consensus was reached in
>>   HOKEY to require a peer to reauthenticate back to the home AAA
>>   server every time it attached to a POP in different domain.
>> 
>>   Therefore, I wonder why a "Domain-Specific" key, the DSRK, and all
>>   it's progeny-- DS-rIK, DS-rRK, DSUSRK, etc.-- continue to be used
>>   by this protocol. A "HOKEY-KEY", a USRK, should be derived from
>>   the EMSK and that is the key given, through proxies if need be, to
>>   the ER server in the visited domain. If the peer goes to a
>>   different domain then it does a full reauthentication resulting in
>>   a _new_ USRK, that has no relation to the previous USRK, being
>>   given to the ER server in the new domain. Again, it was my
>>   understanding that the group already reached consensus on this
>> matter. 
>> 
>>   SHA-256 is a computationally intensive operation; HMAC-SHA256
>>   doubly so. There should, therefore, be some justification to use
>>   such a strong cryptographic mixing function if all one wants to do
>>   is "uniquely name a key". EAP methods export a Session-ID. An rIK
>>   can be named by the concatenation of Session-ID and "rIK".
>>   Similarly for the rMSK, rRK and the other keys being generated in
>> ERP. 
>> 
>>   This has the added benefit of allowing for key management to
>>   quickly identify keys based on common queries-- all the keys for a
>>   specific Session-ID, or all rIKs held by a particular entity. By
>>   using a strong cryptographic mixing function all specificity of
>>   the key names has been lost across every single key hierarchy that
>> a HOKEY server   may end up managing. 
>>

---

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

Lakshminath Dondeti <> scribbled on Sunday, February 03, 2008 1:30 PM:

...

> (IIRC) that I referred to in my other message.

Hmmm.  draft-ietf-eap-keying-22.txt says 

   EAP methods supporting key derivation and mutual authentication
   SHOULD export a method-specific EAP conversation identifier known as
   the Session-Id, as well as one or more method-specific peer
   identifiers (Peer-Id(s)) and MAY export one or more method-specific
   server identifiers (Server-Id(s)).  EAP methods MAY also support the
   import and export of channel binding parameters.  EAP method
   specifications developed after the publication of this document MUST
   define the Peer-Id, Server-Id and Session-Id.  The Peer-Id(s) and
   Server-Id(s), when provided, identify the entities involved in
   generating EAP keying material. For existing EAP methods the Peer-Id,
   Server-Id and Session-Id are defined in Appendix A.

Not sure where the "can't export session IDs" idea came from, but the
above would seem to contradict it.

...

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 03 Feb 2008 10:57:29 -0800

> above would seem to contradict it.
Hi Glen,

Yeah, that was my recollection from an old discussion (that SHOULD was a 
MAY not too long ago).  In any event, it appears that my statements were 
incorrect or at least ambiguous.  My sincere apologies!

If the session-id based keyname derivation can be made to work, I have 
no objection to use it.  I looked at draft and in fact, this is what is 
stated there:

NameDerivationKey = EAP Session-ID, when K used in rRK derivation is
    the EMSK,

    NameDerivationKey = DSRK Name, when K used in rRK derivation is the
    DSRK.

I looked at some old versions and there was an explanation "Unlike the 
rRK_name, the EAP session ID is not used to derive the
    rIK_name.  This is done in order to avoid any collisions with USRK 
names.  The key label used for USRKs is IANA registered, while the 
string "rIK Name" is not. "  We probably need to mix in the domain name 
too to avoid key label collision.

I also recall (I know my recollection is bad :) ) Vidya and I discussing 
that ID collisions may be likely due to at least a couple of other 
reasons too when the domain specific keying is considered.  The various 
EAP servers do not coordinate session ID derivation and not all methods 
derive sufficiently long and random session IDs.  I now checked session 
ID derivation in some methods again and it seems reasonably random in 
methods that I care about (I know that's irresponsible :), but the 
generic solution is already in the draft).

Any suggestions on the direction here?

Would it help if we used the following?

NameDerivationKey = f(EAP Session-ID, domain-name), when K used in rRK 
derivation is the
    DSRK.

regards,
Lakshminath

---

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

> (though Username might be better), but I can't see how that depends upon

I like this approach :).  Indirection works here (too), it seems like, 
so let's do that.

I will add that session ID based naming as Dan proposes, while it has 
some interesting properties, needs to be further explored.  Semantic key 
names can also get very long and can make messages inefficient.  After 
some debates, we concluded that 64 bits are necessary (I don't quite 
agree with the necessary part, but I am willing to go with it) and 
sufficient.

Dan, could you elaborate further and specifically address collision 
issues and keyname length issues?

thanks,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 3 Feb 2008 12:33:13 -0800 (PST)

Hi Glen,

> user).  Disconnecting the user should delete the PMK, TSKs, etc., right?

  Yes, it should delete the other keys. And if I am the entity that
holds the "root key" and you are an ER server that holds some derivatives
like a DSUSRK and some derivatives of that like rMSKs for different
authenticators in that "domain" then what information should I give you to
identify the particular hierarchy I'm talking about? Remember you may
hold other key hierarchies for other users in other domains for other
usages and they all use the same name space.

  An incomprehensible string of random bits doesn't seem particularly
helpful in accomplishing the task.

> (though Username might be better), but I can't see how that depends upon

  Glen, the issue is that not only is every key in the hierarchy mapped
to the same name space, every key for every user's hierarchy for every
domain for every usage is all mapped to the same name space!

  Yea, mapping by Username might be better. Oone reason is that you
could develop a rational searching strategy to identify keys if you
indexed with something like "Username". That is a great suggestion and
a useful alternative to what is in the draft now. I would support such
a change.

  Can you tell me one use for a key name that is an incomprehensible string
of random bits?

  "Delete all keys associated with 0x58d610a8ff4128c9"

  "uhm, ok"

If not then don't you agree the current key naming scheme is completely
useless?

  Dan.

---

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

> a useful alternative to what is in the draft now. I would support such

  It is also existing practice.  The term "hotlining" refers to the
process of pro-actively kicking a user offline after they have
previously been authenticated.

  ERX has to be able to support this practice.  It has to be able to
delete *all* keys associated with a particular user/cui/session, so that
those keys can no longer be used to obtain network access.

  Alan DeKok.

---

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

Hi all,

Some of the reviews I have seen start with good things to say about the 
document pointing about a few things that need to be fixed.  Yoshi 
pointed out one issue that he apparently missed during the WGLC.  We 
have been going back and forth on these topics and not really making 
progress.  Many, if not most of the folks, are also active in the HOKEY 
WG and support the charter.   Let us get together on a telecon sometime 
next week, and resolve these pending issues.  I will send an offline 
request so we can figure out a time that works for all of us.  Thanks.

I have seen one comment so far which declares clear opposition.  I am 
going to respond to that separately.

regards,
Lakshminath

On 2/3/2008 1:14 PM, Alan DeKok wrote:
> Ietf mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 4 Feb 2008 01:09:27 -0800

...

>   Can you tell me one use for a key name that is an incomprehensible
> string of random bits? 
> 
> If not then don't you agree the current key naming scheme is
> completely useless? 

I don't think that it's really much worse for the purposes you describe
then a name based on EAP Session-Id, since the Session-Id is itself
pretty close to being an "incomprehensible string of random bits".  From
draft-ietf-eap-keying-22.txt: 'Where non-expanded EAP Type Codes are
used (EAP Type Code not equal to 254), the EAP Session-Id is the
concatenation of the single octet EAP Type Code and a temporally unique
identifier obtained from the method (known as the Method-Id)...The
Method-Id is typically constructed from nonces or counters used within
the EAP method exchange.'

Doesn't sound particularly readable to me; in any case, I don't think
that it really matters (for the purposes you describe, however unlikely
they may be) what the key name looks like.  What matters is how easy it
is to find the key, which depends upon the structure of the database in
which it resides.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Feb 2008 09:55:52 -0800 (PST)

Hi Glen,

On Mon, February 4, 2008 1:09 am, Glen Zorn wrote:
[snip]
> is to find the key, which depends upon the structure of the database in

  Bingo! And by putting every key for every hierarchy for every user for
every domain for every usage through SHA-256 the structure of the database
is flat.

  I'm not particularly wed to using the EAP session ID as an index. Your
suggestion of Username is perfectly fine. But the current idea of using
SHA-256 is wrong.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 5 Feb 2008 12:22:45 -0800 (PST)

So there's something else besides key name that is used to identify
keys. Great, so that means these hashed key names are unnecessary. No
need to do HMAC-SHA256 to generate a random string, throw away 3/4 of
that result and come up with something that is unusable.

  Let's get rid of this stuff since it serves no useful purpose and is
computationally expensive.

  Yes, EAP Session ID (or Username, as Glen suggests) will be hashed. So
if you have an rIK and an rRK and 5 or 6 rMSKs all derived from the same
EMSK then the EAP Session ID (or Username, as Glen suggests) that
identifies that EMSK can be used as the index in the hash table and all
the derivatives are guaranteed to end up in the same bucket. You look
up based on an identifier on the root and everything is right there in
your hands. If the namespace is completely flat then searching for all
related keys is a pain.

  Dan.

On Tue, February 5, 2008 12:02 pm, Joseph Salowey (jsalowey) wrote:
> There is nothing in the document that says you must index keys only by
> key id.  I don't really understand the problem here, there is other
> context associated with a key besides a name that can be used for
> indexing.  The key name provides a fixed length unique identifier for
> the key.  EAP Session-ID is not fixed length and can be awkward to use
> in protocols, most likely you will end up hashing it anyway.
>
> Joe
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Dan Harkins
>> Sent: Friday, February 01, 2008 5:46 PM
>> To: Dan Harkins
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP
>> Extensions for EAP Re-authentication Protocol (ERP)) to
>> Proposed Standard
>>
>>
>>   Hello again,
>>
>>   If one wants to administratively remove all keys in a
>> particular key hierarchy (which seems like an entirely
>> reasonable request) one must do a linear search of all keys
>> in all key hierarchies that a particular server maintains!
>> This is because HMAC-SHA-256 has mapped all identifying key
>> information for all key hierarchies to the same name space.
>> It precludes using something like a hash table for fast
>> a string that identified the particular key in the key
>> hierarchy rooted at the MK derived in that EAP Session-ID
>> then the EAP Session-ID could be used as an index into a hash
>> table and all keys for that particular key hierarchy could be
>> looked up very efficiently.
>>
>>   regards,
>>
>>   Dan.
>>
>> subsequent
>> > paragraph.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 5 Feb 2008 12:02:54 -0800

Joe

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 5 Feb 2008 13:08:24 -0800

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Tuesday, February 05, 2008 12:23 PM
> To: Joseph Salowey (jsalowey)
> Cc: Dan Harkins; [email-masked]; [email-masked]
> Subject: RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP 
>   So there's something else besides key name that is used to 
> identify keys. Great, so that means these hashed key names 
> are unnecessary. No need to do HMAC-SHA256 to generate a 
> random string, throw away 3/4 of that result and come up with 
> something that is unusable.
> 
>   Let's get rid of this stuff since it serves no useful 
> purpose and is computationally expensive.
>
[Joe] That something else mat not be sufficient to disambiguate keys.
For example if MAC address or username is used it is possible that there
is more than one session with that entity. 
 
>   Yes, EAP Session ID (or Username, as Glen suggests) will be 
> hashed. So if you have an rIK and an rRK and 5 or 6 rMSKs all 
> derived from the same EMSK then the EAP Session ID (or 
> Username, as Glen suggests) that identifies that EMSK can be 
> used as the index in the hash table and all the derivatives 
> are guaranteed to end up in the same bucket. You look up 
> based on an identifier on the root and everything is right 
> there in your hands. If the namespace is completely flat then 
> searching for all related keys is a pain.
> 
>   Dan.
> 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Dan Harkins
> Extensions 
> >> for EAP Re-authentication Protocol (ERP)) to Proposed Standard
> >>
> >>
> >>   Hello again,
> >>
> >> key hierarchy (which seems like an entirely reasonable 
> request) one