Subject: [IPsec] draft-welter-ipsecme-ikev2-reauth-01

From: Keith Welter <[email-masked]>
Date: Wed, 12 Jan 2011 12:32:07 -0800

A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has been 
successfully submitted by Keith Welter and posted to the IETF repository.

Filename:                 draft-welter-ipsecme-ikev2-reauth
Revision:                 01
Title:                            Reauthentication Extension for IKEv2
Creation_date:            2011-01-12
WG ID:                            Independent Submission
Number_of_pages: 6

Abstract:
This document describes an extension to the Internet Key Exchange
version 2 (IKEv2) protocol that allows an IKEv2 Security Association
(SA) to be reauthenticated without creating a new IKE SA or new Child
SAs.

The IETF Secretariat.

---

From: Keith Welter <[email-masked]>
Date: Wed, 12 Jan 2011 13:20:41 -0800

In the thread "Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00", Yoav 
proposed:
"having an IKE_AUTH exchange in the middle of the IKE SA lifetime. Suppose 
the IKE SA has been around for a couple of hours, and has been used for 
creating some child SAs, why not keep it and just pass one or more 
IKE_AUTH exchanges?"

draft-welter-ipsecme-ikev2-reauth-01 specifies this alternative design.

To refresh everyone's memory on the problems that the draft aims to solve, 
I'll include the introductory text from the new version of the draft here:

"IKE SA reauthentication as defined in [IKEv2] is accomplished by creating 
a new IKE SA, creating new Child SAs, and deleting the old IKE SA. 
Assuming that the old IKE SA has n Child SAs, reauthentication as defined 
in [IKEv2] requires at least n+1 message exchanges.  This style of 
reauthentication does not scale well when n is large.  The extension 
described in this document allows reauthentication of an IKE SA using a 
single IKE_AUTH exchange on the IKE SA to be reauthenticated without 
creating a new IKE SA or new Child SAs.  The terms IKEv2, IKEv2 SA, and 
Child SA and the various IKEv2 exchanges are defined in [IKEv2]

Other problems with IKE SA reauthentication as defined in [IKEv2] include:

   o  Simultaneous IKE SA reauthentication may result in redundant SAs.

   o  Child SAs for which an internal address was assigned using the 
Configuration Payload may experience a connection disruption for 
reassignment of an internal address.

   o  While [IKEv2] describes how to handle exchange collisions that may 
occur during IKE SA rekeying, it does not do so for exchange collisions 
that may occur during reauthentication which could inhibit 
interoperability in such cases."

Please share your comments on draft-welter-ipsecme-ikev2-reauth-01.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

[email-masked] wrote on 01/12/2011 12:32:07 PM:

> [image removed] 
> 
> [IPsec] draft-welter-ipsecme-ikev2-reauth-01
> 
> Keith Welter 
> 
> to:
> 
> ipsec
> 
> 01/12/2011 12:36 PM
> 
> Sent by:
> 
> [email-masked]
> 
> 
> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has 
> been successfully submitted by Keith Welter and posted to the IETF 
repository.
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 14 Jan 2011 10:47:35 +0200

Hi Keith,

I think this version makes a lot of sense. A few comments:

    * I don't like the asymmetrical nature of the notification, which
      implies that only the original initiator can initiate the second
      IKE_AUTH. There may be cases when the responder would like to
      reauthenticate (e.g. mutual EAP with passwords). So I suggest to
      have both peers send the notification if they support this extension.
    * Please say explicitly whether/how this extension interacts with
      RFC 6023: can the reauthenticated IKE SA be childless?
    * The introduction mentions three problems. Please add text
      somewhere on how they are solved by this proposal.
    * Typo in Sec. 4: "MUST be the same as the as the SPIs".

Thanks,
     Yaron

On 12/01/2011 23:20, Keith Welter wrote:
> "having an IKE_AUTH exchange in the middle of the IKE SA lifetime. 
> Suppose the IKE SA has been around for a couple of hours, and has been 
> used for creating some child SAs, why not keep it and just pass one or 
> more IKE_AUTH exchanges?"
>
> To refresh everyone's memory on the problems that the draft aims to 
> solve, I'll include the introductory text from the new version of the 
> draft here:
>
> "IKE SA reauthentication as defined in [IKEv2] is accomplished by 
> creating a new IKE SA, creating new Child SAs, and deleting the old 
> IKE SA.  Assuming that the old IKE SA has n Child SAs, 
> reauthentication as defined in [IKEv2] requires at least n+1 message 
> exchanges.  This style of reauthentication does not scale well when n 
> is large.  The extension described in this document allows 
> reauthentication of an IKE SA using a single IKE_AUTH exchange on the 
> IKE SA to be reauthenticated without creating a new IKE SA or new 
> Child SAs.  The terms IKEv2, IKEv2 SA, and Child SA and the various 
> IKEv2 exchanges are defined in [IKEv2]
>
>    o  While [IKEv2] describes how to handle exchange collisions that 
> may occur during IKE SA rekeying, it does not do so for exchange 
> collisions that may occur during reauthentication which could inhibit

---

From: Keith Welter <[email-masked]>
Date: Fri, 14 Jan 2011 11:50:57 -0800

Version 02 is in the mail.

> Hi Keith,
> 
> I think this version makes a lot of sense. 
Thanks.

> A few comments:
> I don't like the asymmetrical nature of the notification, which 
Fixed in version 02.

> Please say explicitly whether/how this extension interacts with RFC 
> 6023: can the reauthenticated IKE SA be childless?
My intent was to permit reauthentication of a childless SA.  That is now 
explicitly stated in version 02.

> The introduction mentions three problems. Please add text somewhere 
> on how they are solved by this proposal.
I beefed-up the introduction to state how these problems are solved in 
version 02.

> Typo in Sec. 4: "MUST be the same as the as the SPIs".
Fixed in 02.