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

From: "Yoav Nir" <[email-masked]>
Date: Tue, 27 Dec 2005 13:56:41 +0200

My comments inline (beginning with [ynir]) 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Sunday, December 25, 2005 4:59 PM
To: Yoav Nir
Cc: 'IPsec WG'
Subject: RE: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt

> 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.

I assume you're talking about initiating the re-authentication exchange 
prior to expiration of the lifetime, correct?  That's ok, but attempting 
to anticipate the EAP method exchange before it occurs is difficult:

a. The EAP server, while typically utilizing the same EAP method for 
re-authentication, is under no obligation to do so, and in fact commonly 
used EAP methods support "fast re-authentication", in which different 
credentials are used.  So "popping up a credential request" may not be 
necessary, depending on the method chosen. 

b. Unless the EAP method doesn't support freshness, the peer cannot 
pre-compute the re-authentication respose. 

The core issue here is the EAP retransmission timer, but that is under 
the control of the authenticator, not the peer. From RFC 3579, Section 
2.3: 

   It may be necessary to adjust retransmission strategies and
   authentication timeouts in certain cases.  For example, when a token
   card is used additional time may be required to allow the user to   
   find the card and enter the token.  Since the NAS will typically not
   have knowledge of the required parameters, these need to be provided
   by the RADIUS server.  This can be accomplished by inclusion of
   Session-Timeout attribute within the Access-Challenge packet.
   
   If Session-Timeout is present in an Access-Challenge packet that also
   contains an EAP-Message, the value of the Session-Timeout is used to
   set the EAP retransmission timer for that EAP Request, and that
   Request alone.  Once the EAP-Request has been sent, the NAS sets the
   retransmission timer, and if it expires without having received an
   EAP-Response corresponding to the Request, then the EAP-Request is
   retransmitted.

[ynir] Agree. For several IKEv2 authentication methods, like some EAP
methods, or RSA signatures or pre-shared secrets it is possible for the user
to enter the credentials before the exchange starts. Even when using EAP
methods that don't allow this, it is still better that the client software
be able to make sure the user is available to do her part of the process, by
doing some UI interaction such as displaying a count-down, popping up an
alert (and beginning the exchange when the user clicks OK), or beeping.

> 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.

One implication is that a new DH exchange occurs on each re-authentication.
Is 
that desired? 

[ynir] It's not. It would be better to be able to just start an AUTH
exchange under the existing IKE SA with no DH and without disturbing the
IPsec SAs. When I suggested this in early 2004, people objected because that
would mean a new exchange type or at least a new state machine for a
relatively minor feature. If it could be done pretty well with the addition
of a simple notification and a 3-page draft (that was before all the IPR
boilerplate took it to 4 pages), I shouldn't invent a new variation on the
AUTH exchange.

> 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."

It seems that the issue is really the state machine, not the 
retransmission timer, right? 

[ynir] It is. But given that we're not doing a new type of exchange, it
still remains up to the client (or supplicant) to initiate the IKEv2
exchange for the gateway (or authenticator) to be able to initiate the EAP
negotiation. And we've got two sets of retransmission timers and timeouts:
those of EAP and those of IKEv2.

> 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. 

Right.  But the AUTH_LIFETIME can't be sent before the Success message is 
received from the AAA server. 

> 
> 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.

That's fine.  But if it attempts to do it later, what should the server 
do? 

[ynir] A re-authentication is just an ordinary Initial+AUTH exchange. It
should be accepted as usual. If it contains an INITIAL-CONTACT, it also
erases the old IKE SA (if that still exists)

> -----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
> 
> 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
> 

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