ietf
[Top] [All Lists]

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

2008-01-30 23:55:53
Alan,

Thanks much for your comments.  Please see inline:

On 1/29/2008 8:32 AM, Alan DeKok wrote:
  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.

Ok.


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.

Ok, perhaps it should be split into two.  These exchanges in fact could
happen at different points in time.  We will revise the figure and split
into two and add text to clarify.


   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?

Note the square brackets on the first two messages.  The peer could
proactively start with EAP Initiate/Re-auth


  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.

Yes.

  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?

Kedar noted from his implementation experience and it worked with
hostap/wpa_supplicant.
Shouldn't compliant implementations discard EAP messages with unknown codes?


   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?

When the peer attaches to an authenticator.


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

Yes.

Do ERP servers have a routing relationship?  If so,
how does it interact with AAA routing?

That is the topic of draft-gaonkar.  We'll include a reference.


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

Wouldn't that be duplication?


   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.

I see your point. On the other hand, EAP methods don't send lifetime of the MSK. The peer already relies on the authenticator for lifetime management. If the consensus shifts along these lines, I don't mind doing this.


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.

Yeah, topology may not be the right word. We'll try to use the phrase local domain and refer to the EMSK-hierarchy document.


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

  I think this should be "co-located".
Ok, thanks.

   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.

Should be covered in draft-gaonkar.


   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.
Not sure I understand. We are trying to treat the rMSK as similar to the MSK as possible and so the peer does not know the lifetime. It could, as you note earlier, but it does not at the moment.

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

Ok.

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

Ok, so this would also address your note above about the motivation for the hierarchy too, right?


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?

All of this comes from the EMSK document. Everything is specified in that document. We might repeat it in this I-D, but that would be bad in that we'd have to change things in two places if things do change.

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

Section 4.1.3:

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

  How is "cryptosuite" encoded?

Good catch.  Will specify.


Section 4.1.6:

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

   The rMSK label is the 8-bit ASCII string "Re-authentication Master
   Session Key(_at_)ietf(_dot_)org" and the length refers to the length of the 
rMSK
   in octets.

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

From the EMSK-hierarchy document "The length is a 2 byte unsigned integer in
   network byte order of the output key length in octets."


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

Ok.


  Alan DeKok.

Thanks a lot Alan. It appears that we need to clarify some things in the draft. There was one figure that needs to be split into two, some text that needs to be reworded, some definitions to be added. I will look for your comments on the rest of the draft.

It appears that on the issue of lifetime communication, the consensus of the WG was different (e.g., lifetime communication). So, barring more momentum in that direction, we'll leave those parts as they are.

I hope in the end the I-D is much more readable than it is now. Thanks for your review.

best regards,
Lakshminath


_______________________________________________
HOKEY mailing list
HOKEY(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/hokey



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf