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

From: Alan DeKok <[email-masked]>
Date: Tue, 29 Jan 2008 17:32:33 +0100

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 [email-masked]" 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.

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 30 Jan 2008 22:53:25 -0800

Alan,

Thanks much for your comments.  Please see inline:

>   It should also define "key lifetime", which is a concept used multiple

Ok.

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

>  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

>    authenticator to send both the EAP-Request/Identity and EAP-Initiate/

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

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

When the peer attaches to an authenticator.

> requests by NAI? 

Yes.

> Do ERP servers have a routing relationship?  If so,

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

> it stands, the document is unclear as to interaction between ERP and AAA

Wouldn't that be duplication?

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

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

>   I think this should be "co-located".
Ok, thanks.
> no definition of AAA proxy, and no discussion of how they interact with,

Should be covered in draft-gaonkar.

> 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.
>    The rRK is used to derive a rIK, and rMSKs for one or more

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

>  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.
> removed from use, but that it should also be completely forgotten.
Ok.
>   How is "cryptosuite" encoded?

Good catch.  Will specify.

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

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 31 Jan 2008 09:23:00 -0500

> Shouldn't compliant implementations discard EAP messages with unknown codes?

I am rather concerned with authenticator behavior.  Since EAP is
designed as a lock-step protocol which only supports a single packet
in flight, allowing two outstanding requests breaks one basic design
principle of EAP.  In order to allow two outstanding requests, I would
expect significant modifications to EAP state machines described in
RFC 4137, and such modifications should be described in ERP document.

Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Thu, 31 Jan 2008 16:01:02 +0100

> Shouldn't compliant implementations discard EAP messages with unknown

  Well, yes.  But I've successfully crashed EAP implementations in the
past by intentionally violating SHOULD or MUST requirements.  We need to
be pro-active to ensure that this change not only is compatible with the
standards, but also existing implementations and deployments.

> When the peer attaches to an authenticator.

  The text needs to be clarified to explain that.  Right now, it appears
that there are no time or state sequence restrictions on sending those
messages.

> Wouldn't that be duplication?

  A paragraph or two explaining the issues and concepts would help
clarify the ERX document.  As it stands now, the ERX document cannot
really be understood without also reading a number of other documents.

  i.e. small amounts of duplication that stop a potential infinite
regression is likely acceptable.

> management.  If the consensus shifts along these lines, I don't mind

  EAP supplicants don't need to know the lifetime of the MSK because
their network connection drops when the MSK expires.  i.e. they are
pro-actively notified.

 ERX supplicants need to know the lifetime of the keys that they use for
re-authentication, because they may not be connected when a key expires.
 In that case, ERX would *increase* the number of packets and time
required to authenticate.  This is because the supplicant would have to
try ERX, fail, and then fall back to EAP.

> Should be covered in draft-gaonkar.

  I strongly suggest adding *some* text about AAA and ERP interaction in
this document.

> could, as you note earlier, but it does not at the moment.

  As it stands, the text I quoted has no time restrictions on the use of
the rMSK.  Text should be added to the section I quoted, saying that the
ERP exchange may only be performed during the lifetime of the rMSK.

  Saying that here would also clarify the motivation for *always*
sending the lifetime of the keys to the peer.  If the rMSK is valid only
for a particular time, then the peer *must* have that information.

  Yes.

> that we'd have to change things in two places if things do change.

  My issue was that as it stands, it's unclear as to what that text
means.  Perhaps the EMSK document could define parameterized functions
to calculate S.  This document could then reference those functions.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 31 Jan 2008 08:07:51 -0800

> that there are no time or state sequence restrictions on sending those

It is specified elsewhere in the document.  We'll make it more 
consistent and clear.

> regression is likely acceptable.

We'll add some text, hopefully generic text that does not force a 
lock-step update of multiple specifications each time something needs to 
change.

> try ERX, fail, and then fall back to EAP.

I understand.

Ok.

> for a particular time, then the peer *must* have that information.
This is convincing to me and as it stands does not hurt anything (other 
than one of the prototypes we have, but I can deal with that).
> to calculate S.  This document could then reference those functions.

I understand.  Referencing is a tough balance.  I will talk to Joe and 
others and see what might make sense.

>   Alan DeKok.
Thanks Alan.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 31 Jan 2008 08:09:54 -0800

> RFC 4137, and such modifications should be described in ERP document.

Hi Yoshi,

We have had these discussions in the WG.  The consensus was that there 
may be a notion of an ERP state machine and it interacts with the EAP 
state machine.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 31 Jan 2008 11:42:32 -0500

Lakshminath,

I remember ERP state machine is discussed in
http://www1.ietf.org/mail-archive/web/hokey/current/msg00713.html, but
lock-step issue was not discussed in the thread.  Please point out a
particular HOKEY thread or meeting minutes where lock-step issue was
discussed.

(I was paying attention to re-auth DoS attack issue during WG-level
review, not to lock-step issue.)

Best Regards,
Yoshihiro Ohba

On Thu, Jan 31, 2008 at 08:09:54AM -0800, Lakshminath Dondeti wrote:
> We have had these discussions in the WG.  The consensus was that there may 
> be a notion of an ERP state machine and it interacts with the EAP state 
> machine.
>
> regards,
> Lakshminath
>
>>
>> Yoshihiro Ohba
>>
>
>