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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf