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

[Yaron Sheffer <[e-mail]>]

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:
>
> 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)
>
>
> [e-mail] 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:
> >
> > [e-mail]
> >
> >
> > 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.
> >
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
>
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec