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