IP Security Protocol Working Group (IPSEC) Internet Draft S. Fanning Document: draft-ietf-ipsec-ike-lifetime-00.txt Cisco Systems Expires: December 2001 July 2001 Responder Lifetime Notify Message for IKE Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes how the RESPONDER-LIFETIME notify message, used within the ISAKMP DOI can be used to facilitate lifetime negotiation and rekeying. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................2 2. Conventions used in this document...............................2 3. Justification...................................................2 4. The IKE Responder Lifetime Notify Message.......................3 5. Security Considerations.........................................4 6. Acknowledgments.................................................5 7. References......................................................5 8. Authors' Addresses..............................................5 Responder Lifetime Notify Message for IKE December 2001 1. Introduction Currently, IKE[RFC-2409], Phase One (Main Mode / Aggressive Mode) lifetimes are not negotiated. By sending a RESPONDER-LIFETIME Notify message over the IKE SA (ISAKMP DOI), both parties can be aware of the lifetime of the IKE SA thus allowing for the initiating peer to take whatever action required. 2. Conventions used in this document 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 3. Justification In cases where the responders IKE lifetime is shorter than the one presented by the initiator, it is often desirable that the responder be able to communicate to the initiator what lifetime is preferred according to its local policy. Although the IKE and IPSec Security Associations are independent, there are implementations that bind the two together. Such an implementation is not contrary to the standard, but can result in interoperability problems. In section 4.5.4 of IPSec DOI [IPSEC], it states that there are 3 options for handling lifetimes for QM (IPSec DOI). If we extend the three ways of handling lifetimes to ISAKMP, the following behavior will result. a) Fail the negotiation entirely. Although, a legitimate, and entirely secure response to a lifetime that does not match local policy, it does not promote connectivity. Responding this way SHOULD be a matter of local policy. b) Complete the negotiation but use a shorter lifetime than what was offered. Due to the fact that you can not alter the proposals presented by the initiator, another common solution to mismatched lifetimes is to accept the proposed lifetime of the initiator and delete the IKE SA when the shorter lifetime is exceeded. This however, can cause a "black hole" problem. Example: - Peer A initiates IKE to Peer B, proposing a lifetime of 1 year. - Peer Bs local policy says that lifetimes are acceptable only ifs they are 60 minutes. S. Fanning 2 Responder Lifetime Notify Message for IKE December 2001 - Peer B accepts the 1 year lifetime, but will send a DELETE notification when the 60 minutes is exceeded. However, in the case where Peer B sends a DELETE notify message and is not received by the Initiator (Peer A), the peer A will not delete its IKE SA until 1 year is up. Peer A will then send IKE messages that from Peer BĘs perspective cannot be authenticated. Peer A will now have that IKE SA information until it exceeds 1 year (or manual intervention removes it). Although some solutions will initiate a new IKE SA From Peer B to Peer A when an unauthenticated NOTIFY message is received, this behavior could facilitate a DoS attack unless some sort of rate limiting mechanism/logging facility was implemented. c) Complete the negotiation and send an advisory notification to the initiator indicating the responder's true lifetime. Since altering the proposal from the initiator is a violation of the IKE, there is no way to communicate to the initiator what IKE SA lifetime is being used by the responder another method of communicating this is required. 4. The IKE Responder Lifetime Notify Message The RESPONDER-LIFETIME notify message is the same as described in the IPSec DOI[RFC 2407] documentation, but has the IKE DOI. Notify Messages - Status Types Value ------------------------------ ----- RESPONDER-LIFETIME 24576 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 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RESPONDER-LIFETIME status message may be used to communicate the IKE SA lifetime chosen by the responder. S. Fanning 3 Responder Lifetime Notify Message for IKE December 2001 When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data(var) o DOI - set to IKE DOI (0) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3 of [RFC2507]) o SPI - set to the two ISAKMP cookies o Notification Data - contains an ISAKMP attribute list with the responder's actual IKE SA lifetime. The RESPONDER-LIFETIME SHOULD be sent by the responder if the initiating peers lifetime for IKE is longer than the lifetime defined in the responders local policy. The receiver of the RESPONDER-LIFETIME MAY perform the following actions; a) MAY Adjust its IKE SA lifetime to the suggested value. This is the preferred action as this most facilitates communication. b) MAY terminate the negotiation if the initiating peer insists on that lifetime. This action does not facilitate communication, but no unexpected loss of traffic will occur. c) MAY ignore the RESPONDER-LIFETIME and continue to use the proposed one. This is not the preferred action as it may result in the "black hole" problem outlined in section 3. NOTE: Notify messages are UDP based and are unacknowledged, therefore assured delivery cannot be guaranteed. 5. Security Considerations The RESPONDER-LIFETIME notify MUST be sent when the notify message can be authenticated as per Section 4.6.3 of IPSec DOI[RFC 2407]. S. Fanning 4 Responder Lifetime Notify Message for IKE December 2001 6. Acknowledgments I would like to thank Darren Dukes, Stephane Beaulieu, Dany Rochefort, Natalie Timms, Victor Volpe and Paul Del Fante for their time reviewing this document and recognizing that such a small change can be a big benefit to customers. 7. References [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", November 1998 [RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8. Authors' Addresses Scott Fanning Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 525-3166 Email: sfanning@cisco.com The IPsec working group can be contacted through the chairs: Barbara Fraser byfraser@cisco.com Cisco Systems, Inc. Ted T'so tytso@mit.edu Massachusetts Institute of Technology S. Fanning 5