In general, this specification appears to be ok, but there are places where the language could be cleaned up. Section 1 "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials, and often EAP is used for authentication, which makes it unreasonable or impossible for the remote access gateway to initiate the exchange." This statement is misleading. In EAP, re-authentication (like authentication) is initiated by the authenticator sending an EAP-Request. So it is not correct to imply that EAP "makes it unreasonable or impossible for the remote access gateway to initiate the exchange". In IKEv2, the desire to do EAP authentication is indicated by the initiator leaving out the AUTH payload from message 3. The responder then can send an EAP payload in message 4. However, no mechanism is specified to enable a responder to initiate an EAP re-authentication. As noted in draft-eronen-ipsec-ikev2-clarifications, Section 5.2: " While creation of a new IKE_SA can be initiated by either party (initiator or responder in the original IKE_SA), the use of EAP authentication and/or configuration payloads means in practice that reauthentication has to be initiated by the same party as the original IKE_SA. IKEv2 does not currently allow the responder to request reauthentication in this case; however, there is ongoing work to add this functionality [ReAuth]." Given that this is not an EAP issue, but rather an IKEv2 issue, it might be helpful for the document to explain why it has chosen not to "allow the responder to request reauthentication" as implied in the above passage, opting for the lifetime approach instead. Is this because it is not clear exactly how a responder-initiated EAP re-authentication would proceed (e.g. no state machine for IKEv2/EAP interactions)? Section 2 "The Responder MUST send this information to the Initiator in an AUTH_LIFETIME notification either in the last message of an IKE_AUTH exchange, or in a separate Informational exchange, which can be sent at any time." In AAA, the Session-Time attribute is typically used to control EAP re-authentication. Since this attribute is sent along with EAP keying material, it is not known until EAP authentication has completed (e.g. at the time the EAP-Success message is sent). This means that during an initial authentication, AUTH_LIFETIME cannot be communicated at any time; this can only occur during re-authentication, because the Session-Time attribute has presumably been cached on the remote access gateway. This needs to be clarified. Section 4 "IKEv2 implementations that do not support the AUTH_LIFETIME notification will ignore it and will not repeat the authentication. In that case the original Responder will send a Delete notification for the IKE SA in an Informational exchange. Such implementations may be configured manually to repeat the authentication periodically." I'd suggest that this paragraph needs to be stronger. If the maximum re-authentication time expires (e.g. Session-Timeout attribute) and the Initiator has not initiated re-authentication, then the Responder SHOULD send a Delete notification. 5. Security Considerations "The AUTH_LIFETIME notification sent by the Responder does not override any security policy on the Initiator. In particular, the Initiator may have a different policy regarding re-authentication, requiring more frequent re-authentication. Such an Initiator can repeat the authentication earlier then is required by the notification." This paragraph suggests that an Initiator complying with this specification can ignore the AUTH_LIFETIME notification entirely. That seems odd. Shouldn't an Initiator compliant with this specification be required to initiatie re-authentication no later than specified in the AUTH_LIFETIME notification? _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf