Forwarding to the IETF mailing list, which is the proper home for this discussion. On Nov 3, 2012, at 10:26 PM, Tero Kivinen wrote: > In Introduction section (1) there is text saying: > > ---------------------------------------------------------------------- > Bringing these two technologies together allows a remote access IPsec > client to create multiple tunnels with different gateways that belong > to a single domain, as well as using the keys from other contexts of > using EAP, such as network access within the same domain, to > transparently connect to VPN gateways within this domain. > ---------------------------------------------------------------------- > > I think that is missing one possible use for the EAP Re-authentication > Protocol, then one that has been proposed for example in the IEEE > 802.11ai. I.e the possibility that the client does full EAP with AAA > backend only once, and then reuses that authentication later to > recreate the IPsec connection when it was lost for some reason > (network problems, device suspending, going out of range etc). > > I.e. use it in similar ways as resumption protocol can be used, but > now the state is stored in the AAA backend, not in the SGW. > > In section "3. Protocol Outline" there is text saying: > > ---------------------------------------------------------------------- > The responder sends the EAP payload content to a backend AAA server, > and receives the rMSK and an EAP-Finish/Re-auth message. It then > forwards the EAP-Finish/Re-auth message to the Initiator in an EAP > payload within the first IKE_AUTH response. > ---------------------------------------------------------------------- > > There is possibility that even when the client has ERX connection > still up, but the backend AAA server might have already destroyed it. > This means that it is possible that when initiator sends the first > EAP_Initiate/Re-Auth message to the SGW, which forwards it to the AAA > server, the AAA server will NOT respond with EAP-Finish/Re-auth > message, but simply starts normal full EAP. This should be explained > here. It does not really change the actual protocol flow, as AAA > server will send EAP packet back, and then the initiator and responder > will exchange some number of EAP packets before responder sends the > EAP-Finish to initiator and they do the final AUTH exchange. > > If it is not mentioned here, some implementations might assume they > always get EAP-Finish/Re-auth back and not work if the AAA server goes > through the full EAP exchange. > > In section "4. ERX_SUPPORTED Notification" there is text saying: > > ---------------------------------------------------------------------- > o Protocol ID (1 octet) MUST be 1, as this message is related to an > IKE SA. > ---------------------------------------------------------------------- > > This is wrong. The RFC 5996 in section 3.10 says: > > ---------------------------------------------------------------------- > o Protocol ID (1 octet) - If this notification concerns an existing > SA whose SPI is given in the SPI field, this field indicates the > type of that SA. For notifications concerning Child SAs, this > field MUST contain either (2) to indicate AH or (3) to indicate > ESP. Of the notifications defined in this document, the SPI is > included only with INVALID_SELECTORS and REKEY_SA. If the SPI > field is empty, this field MUST be sent as zero and MUST be > ignored on receipt. > ---------------------------------------------------------------------- > > I.e. the Protocol ID MUST be sent as zero if the SPI field is empty. > -- > kivinen@xxxxxx > > Scanned by Check Point Total Security Gateway.