RE: IKEv2 AUTH payload

[<Pasi.Eronen@nokia.com>]

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