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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  Reviewing the document, it looks very good overall.  I have a few
comments and questions about Sections 1 through 4.  The later sections
will be reviewed in a separate message.

Section 2:

  Defines a number of terms, but not AAA server, which is first
referenced in Section 3.1.  Similarly for AAA proxy.

  It should also define "key lifetime", which is a concept used multiple
times, but not defined.

Section 3.1, Figure 1.

  The diagram could be clarified to make it obvious that it is one
diagram split in two for space reasons.  e.g. having linking notes
between the different portions in the first half and second half.

   When the peer subsequently identifies a target authenticator that
   supports EAP re-authentication, it performs an ERP exchange, as shown
   in Figure 1 as well; the exchange itself may happen when the peer
   attaches to a new authenticator supporting EAP re-authentication, or
   prior to attachment.  The peer initiates ERP by itself; ...

  Figure 1 does not appear to show the peer initiating an ERP exchange.
 How does the peer advertise ERP capability?

  I am also unclear as to how the EAP exchange in Figure 1 will work
with existing implementations.  The Reauth-Start message at the top of
the second half of the diagram is unsolicited by the peer.

   ... hence the
   authenticator initiation of the ERP exchange may require the
   authenticator to send both the EAP-Request/Identity and EAP-Initiate/
   Re-auth-Start messages.

  Have existing EAP peer implementations been validated to work under
these assumptions?  i.e. will they break?  Will they see "unexpected"
EAP messages or content, and reject or discard the response?

   We introduce two new codes to EAP: EAP-Initiate and EAP-Finish.  The
   peer sends an EAP-Initiate/Re-auth message that includes the Peer-ID
   or a temporary NAI based on the rIKname, and a sequence number for
   replay protection. ...

  When does the peer send these messages?  Under what circumstances?

   ... The message is
   routed using the NAI in the rIKname-NAI [4], field and if that is not
   present, it is routed using the NAI in the Peer-ID.   ...

  Routed to where?  This is the first mention of "routing" in the
document.  Is this routing related to the common practice of routing AAA
requests by NAI?  Do ERP servers have a routing relationship?  If so,
how does it interact with AAA routing?

   ... Ongoing work in [10] describes an additional key
   distribution protocol that can be used to transport the rRK from an
   EAP server to one of many different ER servers that share a AAA trust
   relationship with the EAP server.

  This work would appear to be fairly core to the solution.  EAP servers
are commonly deployed in conjunction with AAA servers, and interact with
AAA proxies.  Can any of that discussion be added to this document?  As
it stands, the document is unclear as to interaction between ERP and AAA
protocols.

   In an ERP bootstrap exchange, the peer may request the rRK lifetime
   to be sent to it.  If so, the ER server sends the lifetime along with
   the EAP-Finish/Re-auth message.

  This is the first mention that they keys may have a lifetime.

  I would suggest always sending the key lifetime to the peer.  It is a
small amount of data, and is useful for the peer to know.  i.e. there
should be strong motivations for *not* sending the key lifetime.

Section 3.2

   The defined ER extensions allow executing the ERP with a local ER
   server that may be topologically closer to the authenticator.  ...

  I'm not sure what this means, because the previous text does not
discuss network topologies.

   ... The
   local ER server may be collocated with a local AAA server.

  I think this should be "co-located".

   As shown in Figure 2, the local ER server may be present in the path
   of the full EAP exchange (e.g., this may be one of the AAA entities,
   such as AAA proxies, in the path between the authenticator and the
   home EAP server of the peer). ...

  This is the first mention of AAA proxies in this document.  There is
no definition of AAA proxy, and no discussion of how they interact with,
or affect, ERP.

   Subsequently, when the peer attaches to an authenticator within the
   local domain, it may perform an ERP exchange with the local ER server
   to obtain an rMSK for the new authenticator.

  It would be good to mention that this process only occurs for the
lifetime of the relevant keys.

Section 4:

   We define a key hierarchy for ER, rooted at the rRK, and derived as a
   result of a full EAP exchange. ...

  This text is unmotivated.  Why is a hierarchy being defined?  An
explanation should be given.  Referencing the key hierarchy draft is
useful, but leaves this document without a clear problem state that the
key hierarchy solves.

   The rRK is used to derive a rIK and one or more rMSKs. ...

  I would suggest saying:

   The rRK is used to derive a rIK, and rMSKs for one or more
   authenticators. ...

  This change gives motivation to the derivation of multiple rMSKs, and
ties them into specific entities in the network.

Section 4.1.1

     S = rRK Label + "\0" + NULL + length

  Is this string concatenation?  What is NULL?  How is "length" encoded?
 Are there test vectors that can be used to validate these calculations?


Section 4.1.x

  It would be good to note than when a key expires, it not only MUST be
removed from use, but that it should also be completely forgotten.

Section 4.1.3:

   S = rIK Label + "\0" + cryptosuite + length

  How is "cryptosuite" encoded?

Section 4.1.6:

   S = rMSK label + "\0" + SEQ + length

   The rMSK label is the 8-bit ASCII string "Re-authentication Master
   Session Key@xxxxxxxx" and the length refers to the length of the rMSK
   in octets.

  Is "length" 8 bits?  16 bits?  32 bits?

   The SEQ is the sequence number sent by the peer in the EAP-Initiate/
   Re-auth message.

  SEQ is undefined in this document.  It would be good to include a
short definition here, to avoid requiring people to read another
document to discover how to calculate 'S'.

  Alan DeKok.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]