[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