Subject: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Dec 2005 18:45:32 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 25 Dec 2005 11:16:20 +0200

Re: Section 1.
The motivation for the lifetime approach is because of the human interaction
that's involved. Protocols implementation are written with machines in mind
and have timeouts consistent with machine speed and Internet round-trip
time. People who must type in passwords or copy them from hardware tokens
are much slower, and that's why it is best to have the client application
decide how long before the lifetime expires it needs to start the
authentication process (get credentials and start an Initial exchange). A
good client may pop up the credential request 5 minutes before expiration
(maybe the user went to make coffee). A good client running on Windows may
increase this to 8 minutes if the accessibility options are set.  This is
why it's unreasonable for the server to initiate.
With the state machines that are currently defined, it is not possible for
the gateway to initiate an exchange where the client authenticates with EAP.
I did not want to add a new exchange type.
Does this look better?
"However, in the remote access scenario it is usually up to a human
User to supply the authentication credentials, which may take a long
time, and often EAP is used. This makes it unreasonable for the remote
Access gateway to initiate the IKEv2 AUTH exchange where these 
"redentials are passed."

Re: Section 2
If you look at the top of page 32 of RFC 4306, the EAP success message is
sent in message 4 of IKE_AUTH, while the notification is sent in the last
message, message 6. There is no problem then to send a lifetime with the
appropriate value. 

Re: Section 4
I can see a SHOULD there, but I can also see an implementation just
preventing new child SAs when the time expires (by using the NO-MORE-SAS
notification) and sending the DELETE only some 5 minutes. It may be worth a
SHOULD.

Re: Section 5
All I'm saying is that a compliant implementation may do the
re-authentication earlier than is required by the notification.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Saturday, December 24, 2005 4:46 AM
To: IPsec WG
Subject: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt

Section 1

Section 2

Section 4