Re: [Ipsec] Re: IKEv2 AUTH payload

[Geoffrey Huang <ghuang@cisco.com>]

[changed cc to ipsec@ietf.org]

Yoav Nir wrote:

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

I don't think it does.  This idea of an AUTH_LIFETIME goes against the notion of 
enforcing an IKE lifetime as local policy.  I understand that the auth lifetime 
is slightly different from an IKE lifetime, but the difference is fairly nuanced.

Nonetheless, if we do decide to have such a notification, I object to using a 
private value, as this would only add to interoperability issues.

I'm not too familiar with the various user authentication methods, but do any of 
these methods support the notion of an authentication lifetime?

Note that we'll have a similar problem with certificate lifetimes.  The way 
IKEv2 is currently written, an entity can present a certificate that expires in 
say, 5 minutes.  In the absence of another authentication exchange, the IKE 
peers could rekey indefinitely using the child SA exchange (even though the 
certificate is no longer valid).  In this case, as with the authentication 
lifetime, the implementation will have to enforce the certificate lifetime by 
deleting the SA(s) when the certificate validity expires.

-g

> 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


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