Subject: [IPsec] Simultaneous re-authentication of an IKE_SA

From: David Wierbowski <[email-masked]>
Date: Tue, 24 Jun 2008 12:15:52 -0400

RFC 4718 highlights the difference between re-keying an IKE_SA and
re-authenticating an IKE_SA; however, it does not address the issue of both
peers simultaneously re-authenticating an IKE_SA.

Re-authentication of an IKE_SA involves creating a new IKE_SA from scratch
(using the initial exchanges), creating new CHILD_SAs within the new
IKE_SA, and finally deleting the old IKE_SA.  The window between sending
the SA_INIT request and deleting the IKE_SA is relatively significant in
size.

Unlike the re-keying, there is nothing that ties the IKE_SA being
re-authenticated to the new IKE_SA.  How can one even detect that a
simultaneous re-authentication has even occurred?

Much of the previous discussion on the mailing list about re-authentication
of the IKE_SA was in an EAP context.  I am asking this question is in a
non-EAP context.

The concern is that if a simultaneous re-authentication goes undetected
that both peers will end up with 2 identical IKE_SAs.  In a worst case
scenario the peers will simultaneously re-authenticate both the new IKE_SAs
and then end up with 4  identical IKE_SAs, and so on.

Dave Wierbowski

z/OS Comm Server Developer

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jun 2008 13:17:02 +0300

Hi David.

I agree that RFC 4718 is silent about simultaneous re-authentication.   
I guess the jitter recommendation should extend to re-authentication  
as well.

I guess we can recommend some text in the revision document saying  
that an IKE peer MUST NOT re-authenticate multiple IKE SAs with the  
same peer.  This should limit the amount of IKE SAs to (at most) two  
at a time.

If you're following the list, you will have noticed that a revision  
document for IKEv2 is planned for the hopefully-soon-to-be-formed  
IPsec extensions and maintenance working groups, so we can hope to fix  
this.

Yoav

On Jun 24, 2008, at 7:15 PM, David Wierbowski wrote:

> re-authenticating an IKE_SA; however, it does not address the issue  
> of both peers simultaneously re-authenticating an IKE_SA.
>
> Re-authentication of an IKE_SA involves creating a new IKE_SA from  
> scratch (using the initial exchanges), creating new CHILD_SAs within  
> the new IKE_SA, and finally deleting the old IKE_SA. The window  
> between sending the SA_INIT request and deleting the IKE_SA is  
> relatively significant in size.
>
> Unlike the re-keying, there is nothing that ties the IKE_SA being re- 
> authenticated to the new IKE_SA. How can one even detect that a  
> Much of the previous discussion on the mailing list about re- 
> authentication of the IKE_SA was in an EAP context. I am asking this  
> question is in a non-EAP context.
>
> The concern is that if a simultaneous re-authentication goes  
> undetected that both peers will end up with 2 identical IKE_SAs. In  
> a worst case scenario the peers will simultaneously re-authenticate  
> both the new IKE_SAs and then end up with 4 identical IKE_SAs, and  
> so on.
>
>
> Dave Wierbowski
>
> Scanned by Check Point Total Security Gateway.
>
>

---

From: David Wierbowski <[email-masked]>
Date: Thu, 26 Jun 2008 10:03:28 -0400

Yoav,

RFC 4306 and draft-hoffman-ikev2bis-03.txt indicate that a minimal
implementation may accept only one CHILD_SA per IKE_SA; however, it does
not restrict such implementations to creating only one IKE_SA/CHILD_SA pair
with the same peer.  They also state that the ability to rekey SAs without
restarting the entire IKE_SA is optional (i.e. an implementation can chose
to only re-authenticate).  Given that I don't think we can restrict that an
IKE peer MUST NOT re-authenticate multiple IKE SAs with the same peer.

Detecting simultaneous attempts to re-authenticate an IKE_SA  would have
been simplified if IKEv2 contained a REAUTH_SA notify similar to the
REKEY_SA notify.  Such a notify could have been included in the IKE_AUTH
exchange to clearly identify that an IKE_SA was being created for the
purpose of re-authenticating an existing IKE_SA.

Since the decision of when to rekey or re-authenticate an IKE_SA is not
negotiated the likelihood of simultaneous re-authentications should be
small to begin with.  Jittering the time would reduce it even further.
Still the possibility of a simultaneous re-authentication does exist.  It
would be nice if this issue could be addressed by the IP Security
Maintenance and Extensions working group as part of it's work item to
produce a revision to IKEv2 (assuming the working group's charter is
actually approved).

             Yoav Nir                                                      
             <ynir@checkpoint.                                             
             com>                                                       To 
                                       David Wierbowski/Endicott/IBM@IBMUS 
             06/25/2008 06:17                                           cc 
             AM                        [email-masked]                      
                                                                   Subject 
                                       Re: [IPsec] Simultaneous            
                                       re-authentication of an IKE_SA