Subject: [secdir] SECDIR review of draft-ietf-hokey-erp-aak

From: Radia Perlman <[email-masked]>
Date: Wed, 8 Feb 2012 22:38:58 -0800

have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is mostly OK technically, but sloppily written.  It's about giving a MH
the keys to a new access point after a handoff.

Starting from section 3..."Peer" is sometimes called "MH" (mobile host). It's
preferable to use a single term, and I'd prefer MH (since it's not clear who
the MH is peer with in this protocol).

I found it surprising that the SAP knows where the MH will roam to.  I'd think
that the MH would need to see a new CAP and tell its SAP who it wants to connect
with, or that the MH finds the CAP and tells the CAP who its SAP is/was.

Under figure 6, it says "The x flag is reserved. It MUST be set to 0".
Shouldn't the document say "and ignored on receipt"?

There are various values that say TBD in the spec, but in the IANA
considerations,
there are values.  So shouldn't they be copied into the spec instead of TBD?
Also, not all the TBD values are listed in the IANA considerations.

In the 4th paragraph before section 5.3, it talks about computing an integrity
checksum over the ERP/AAK packet, excluding the authentication tag field.
Does this mean that the authentication tag field is zeroed out for the
computation,
or that the message is truncated to exclude that field?

In the paragraph before section 5.3, it talks about silently discarding the
EAP-Initiate/Re-auth packet if it's not supported by the SAP.  On a silent
discard, how long do you wait for a response before assuming there won't be any,
or perhaps that it got lost? (does it run over a reliable Transport?  Even so,
it might be silently discarded).

There's also lots of minor typos.  Should be proof-read.

Radia

---

From: Qin Wu <[email-masked]>
Date: Thu, 09 Feb 2012 18:11:38 +0800

Hi, Radia:
Thank for your valuable review. please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Radia Perlman" <[email-masked]>
To: "The IESG" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, February 09, 2012 2:38 PM
Subject: SECDIR review of draft-ietf-hokey-erp-aak

> the MH is peer with in this protocol).

[Qin]: Okay. We can use MH for terminology consistency.

> with, or that the MH finds the CAP and tells the CAP who its SAP is/was.

[Qin]: SAP doesn't know where the MH will roam to. But SAP knows which CAP is adjacent
 to itself and therefore SAP can provide the MH a list of CAPs which are all neighbor of that 
SAP via EAP-Initiate/Re-auth-Start message. Then MH can override CAP list carried in the 
EAP-Initiate/Re-auth-Start message and send a new CAP list using EAP-Initiate/Re-auth
 message to backend server through SAP. We can add some text to make this clear if you 
believe this addresses your concern.

> Shouldn't the document say "and ignored on receipt"?

[Qin]: Agree, will fix this by following your suggestion. Thanks.

> Also, not all the TBD values are listed in the IANA considerations.

[Qin]: Okay.

> or that the message is truncated to exclude that field?

[Qin]: I think it is the latter case. The integrity checksum over ERP/AAK packet is computed 
from the first bit of code field of packet to the last bit of cryptosuit field of the packet which
 is placed before authenticator tag field.

> it might be silently discarded).

[Qin]: That's a good point. In the case of SAP initiating ERP/AAK, this is not a issue since SAP has 
already support ERP/AAK. In the case of Peer initiating ERP/AAK, the peer should maintain 
retransmission timer and maximum retransmission times. Based on retransmission timeout estimation,
 the peer can know there won't be any response. Does this address your comment?

> There's also lots of minor typos.  Should be proof-read.

[Qin]: Okay, will fix this in the update. Thanks.

---

From: Radia Perlman <[email-masked]>
Date: Thu, 9 Feb 2012 10:51:29 -0800

Inline

>  is placed before authenticator tag field.

I don't care which it is.  But the document has to specify.  I assume
when answering me, you were also going to specify it in the document.
:-)

>  the peer can know there won't be any response. Does this address your comment?

That is somewhat significant text (not just a typo), but I assume
you'll get it right.

Radia

---

From: Qin Wu <[email-masked]>
Date: Fri, 10 Feb 2012 09:25:02 +0800

Hi, Radia:
We will impement the clarification texts into the update to fix the issues you pointed out below. 
Thank you again.

Regards!
-Qin
----- Original Message ----- 
From: "Radia Perlman" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "The IESG" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, February 10, 2012 2:51 AM
Subject: Re: SECDIR review of draft-ietf-hokey-erp-aak

Inline

Radia