[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ipsec] Re: IKEv2 AUTH payload



It's a pity we haven't thought of it months ago.  I think there is a 
general consensus that it is too late now to do anything so radical as 
add new exchange types.

I don't like the idea of the gateway triggering a new authentication 
with a DELETE notification, because a delete notification requires the 
client to delete all the child SAs.  If the EAP method requires the 
user to enter a password (or the token card value) this means many 
seconds without an IPSec SA.  That could kill an ongoing FTP, Telnet or 
mail download.

A better solution would be a notification within the original IKE_AUTH 
exchange, where the gateway tells the client how long the 
authentication is valid.  In essence, the gateway tells the client to 
re-authenticate within 2 hours.  A properly designed client will ask 
the user for a password 5 minutes before the deadline, and begin a new 
initial exchange from scratch.  This way, the IKE and IPSec SAs can be 
replaced without a loss of connectivity.  If the client does not 
re-authenticate in time, then the gateway can send a delete 
notification.

We could add an AUTH_LIFETIME notification (16395?) with 4 bytes of 
data signifying the time (in seconds) before the authentication 
expires.  If it's too late for it to enter the IKEv2 RFC, it can still 
be used as a private notification.  In IKEv1 few configure an IKE SA 
lifetime shorter than 2 hours.  Many extend it to 24 hours.  The worst 
interoperability problem that could happen, is that clients abruptly 
disconnect after 2 hours.

Does that sound reasonable?

On Apr 14, 2004, at 2:48 PM, <Pasi.Eronen@nokia.com> wrote:

> Yoav Nir wrote:
>>
>> I still haven't received any responses to my question of last
>> week, about what to do if the autentication exchange is repeated
>> later on.  It appears that in order to support this, I would have
>> to store the old initial exchanges so as to produce and verify the
>> AUTH payloads, but that seems wasteful.
>
> I don't think that storing the initial exchange messages, or
> even re-keying, is that big a problem if the reauthentication
> works just fine.
>
> However, as you pointed out, IKEv2 spec does not really talk
> about reauthentication at all... At least additional IKE_AUTH
> exchanges are not allowed (within the same SA) after the first
> authentication has completed.
>
> Presumably the original initiator could start a new IKE SA from
> scratch, establish new child SAs (for the same "internal" address
> in remote access VPN gateway situations, without REKEY flag), and
> then delete the old IKE SA and the old child SAs, right?
>
> However, at least when EAP is used, the original responder
> ("VPN gateway") can't trigger this reauthentication... because
> if it created a new IKE SA, it would be the initiator in that.
>
> Any ideas how to solve this?
>
> Perhaps the gateway (original responder) could delete the old
> IKE SA (with Delete payload), and that would signal the client
> (initiator) to start from scratch? Or perhaps a notification message
> should be used? Or perhaps additional IKE_AUTH exchange could
> be allowed within the same IKE SA?
>
> (IMHO the notification sounds like the simplest approach,
> if it actually works; there might be some aspects I haven't
> considered. The overhead of setting up a new IKE SA is probably
> not very serious if reauthentication happens every couple
> of hours or so.)
>
> Best regards,
> Pasi


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec