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-02 23:30:57
Hi Dan,

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

On 2/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.
Thanks.

  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.

We'll document this in the revision.


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

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.


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

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.


  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.

Please see above about the need for domain specific keys.


 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.

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.


  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.

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.


 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.

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

thanks,
Lakshminath


  regards,

  Dan.




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