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