Last Call Review of draft-ietf-hokey-erp-aak-
review-ietf-hokey-erp-aak-secdir-lc-perlman-2012-02-15-00

Request Review of draft-ietf-hokey-erp-aak
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-02-14
Requested 2012-01-27
Authors Zehn Cao, Hui Deng, Qin Wu, Glen Zorn
Draft last updated 2012-02-15
Completed reviews Genart Last Call review of -?? by Miguel García
Genart Telechat review of -?? by Miguel García
Secdir Last Call review of -?? by Radia Perlman
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-hokey-erp-aak-secdir-lc-perlman-2012-02-15
Review completed: 2012-02-15

Review
review-ietf-hokey-erp-aak-secdir-lc-perlman-2012-02-15

 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