ietf
[Top] [All Lists]

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

2008-02-03 14:47:27
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. 

  If one wants to administratively remove all keys in a particular
key hierarchy (which seems like an entirely reasonable request) 

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.


  regards,

  Dan.

On Fri, February 1, 2008 5:16 pm, Dan Harkins wrote:

  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
HOKEY(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/hokey



_______________________________________________
HOKEY mailing list
HOKEY(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/hokey
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>