INTERNET-DRAFT Keith Welter Intended Status: Experimental IBM Expires: July 18, 2011 January 14, 2011 Reauthentication Extension for IKEv2 draft-welter-ipsecme-ikev2-reauth-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Keith Welter Expires July 18, 2011 [Page 1] INTERNET DRAFT Reauthentication Extension for IKEv2 January 14, 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Outline . . . . . . . . . . . . . . . . . . . . . . . . 4 3. REAUTH_SA Notification . . . . . . . . . . . . . . . . . . . . . 4 4. Modified IKE_AUTH Exchange for Reauthenticating the IKE SA . . . 5 5. Authentication Payload for Reauthenticating the IKE SA . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . . 6 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Keith Welter Expires July 18, 2011 [Page 2] INTERNET DRAFT Reauthentication Extension for IKEv2 January 14, 2011 1. Introduction 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. This problem is solved by not creating any new IKE SAs using the modified IKE_AUTH exchange described in section 4. 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. This problem is solved by not creating any new Child SAs using the modified IKE_AUTH exchange described in section 4. The Child SAs retain all associated state including any internal address assignments following the modified IKE_AUTH exchange. 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. The only exchange collision that may occur with the modified IKE_AUTH exchange is simultaneous reauthentication and this has no negative side effects. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Keith Welter Expires July 18, 2011 [Page 3] INTERNET DRAFT Reauthentication Extension for IKEv2 January 14, 2011 2. Protocol Outline A supporting initiator MUST include the Notify payload, described in Section 3, within the IKE_SA_INIT request. A supporting responder MUST include the Notify payload, described in Section 3, within the IKE_SA_INIT response. After the initial exchanges, a supporting host MAY send the modified IKE_AUTH request, described in Section 4, if the notification was received from the peer. A supporting host MUST NOT send the modified IKE_AUTH request if the notification was not received from the peer. A supporting host that has advertised support by including the notification in the IKE_SA_INIT exchange MUST process a modified IKE_AUTH request, and MUST reply with a modified IKE_AUTH response. Such a host MUST NOT reply with a modified IKE_AUTH response if the peer did not send a modified IKE_AUTH request. A supporting host that has been configured not to support this extension to the protocol MUST behave the same as if it didn't support this extension. It MUST NOT advertise the capability with a notification, and it SHOULD reply with an INVALID_SYNTAX Notify payload if the peer sends an IKE_AUTH request that is modified as described in Section 4. 3. REAUTH_SA Notification The Notify payload is as described in [IKEv2] 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID ! SPI Size ! Reauthenticate SA Notify Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Protocol ID (1 octet) MUST be 1, as this message is related to an IKEv2 SA. o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 of [IKEv2]. o Reauthenticate SA Notify Type (2 octets) - MUST be {TBA}, the value assigned for REAUTH_SA. Keith Welter Expires July 18, 2011 [Page 4] INTERNET DRAFT Reauthentication Extension for IKEv2 January 14, 2011 4. Modified IKE_AUTH Exchange for Reauthenticating the IKE SA [RFC6023] Section 5 describes a modified IKE_AUTH exchange for creating a childless IKE SA. The modified IKE_AUTH exchange for reauthenticating the IKE SA is the same as that except for the following differences: o It MUST NOT be used during the initial exchanges. In other words, the Message ID in the IKE headers of the modified IKE_AUTH exchange MUST be greater than 1. o It MUST be sent on the IKE SA to be reauthenticated. In other words, the SPIs in the IKE headers of the modified IKE_AUTH exchange MUST be the same as the SPIs of the IKE SA to be reauthenticated. o The reauthenticated IKE SA retains all of the Child SAs it had prior to the modified IKE_AUTH exchange or no Child SAs if the IKE SA was childless prior to the modified IKE_AUTH exchange. o When not using extensible authentication (see [IKEv2] Section 2.16), the Authentications payloads are generated as specified in Section 5. 5. Authentication Payload for Reauthenticating the IKE SA When not using extensible authentication, the peers are authenticated by having each sign (or MAC using a padded shared secret as the key, as described later in this section) a block of data. The octets to be signed for the modified IKE_AUTH exchange are different than those described in [IKEv2] Section 2.15. For the modified IKE_AUTH request, the octets to be signed start with the first octet of the previous Authentication payload sent by the initiator and end with the last octet of that payload. For the modified IKE_AUTH response, the octets to be signed start with the first octet of the previous Authentication payload sent by the responder and end with the last octet of that payload. 6. Acknowledgements Martin Willi was the first to document the problems with IKEv2 reauthentication and propose an extension to fix it. David Wierbowski provided the initial nudge of encouragement for producing the first version of this document and provided many helpful comments, as did Scott Moonen. Yoav Nir suggested the essential feature of sending the modified IKE_AUTH exchange on the IKE SA to be reauthenticated. Keith Welter Expires July 18, 2011 [Page 5] INTERNET DRAFT Reauthentication Extension for IKEv2 January 14, 2011 7. Security Considerations This protocol variation inherits all the security properties of regular IKEv2 as described in [IKEv2]. The new notification carried in the initial exchange advertises the capability, and cannot be forged or added by an adversary without being detected, because the response to the initial exchange is authenticated with the AUTH payload of the IKE_AUTH exchange. 8. IANA Considerations IANA has assigned a notify message type from the "IKEv2 Notify Message Types" registry with the name "REAUTH_SA" and the value {TBA}. 9. Normative References [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6023] Nir, Y., Tschofenig, H. Deng, H. and Singh, R, "A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)", RFC 6023, October 2010. [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Addresses Keith Welter IBM 425 Market Street San Francisco, CA 94105-2406 USA EMail: welterk@us.ibm.com Keith Welter Expires July 18, 2011 [Page 6]