Network Working Group P. Srisuresh INTERNET-DRAFT Jasmine Networks Expires by July 24, 2001 J. Vilhuber Cisco Systems January 2001 IKE extensions to support Dynamic Policies 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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 As IPsec is widely deployed, there is increasing need to negotiate security keys using IKE at application level granularity. IKE, as currently proposed, has restrictions in negotiating keys for applications with bundled sessions and complex policies. The draft identifies the problem with IKE and suggests extensions to make IKE application and policy friendly. The proposed solution suggests extensions to the conceptual operation of IPsec as well as IKE, but does not require changes to existing IKE payloads. The document introduces a new policy payload that complements existing IKE payloads and suggests replacing ID payload with the Policy payload, in Quick mode. Srisuresh & Vilhuber [Page 1] Internet-Draft Policy extensions to IKE January 2001 1. Introduction and Overview IP packets may be subject to IPsec security enforcement by peering end nodes or enroute by intermediate systems. The enforcement is policy based. As IPsec is widely deployed, there is increasing desire to make these policies granular to a specific application detail. The focus of the document is facilitating enforcement of application driven dynamic policies across peering nodes, using IKE. IKE protocol uses part of Oakley and part of SKEME ([SKEME] in conjunction with ISAKMP ([ISAKMP])to obtain authenticated keying material for use with ISAKMP, and for IPsec DOI security associations such as AH ([AH]) and ESP (ESP]. As such, any changes and extension to IKE ([IKE]) could potentially mandate changes to every one of the sub-components. This document identifies extensions required of each of the sub-components to bring about the appropriate policy extensions to IKE Phase-II based security associations for IPsec DOI ([IPSEC-DOI). 2.0 Terms and Technical Definitions Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [STD-KEYWORDS]. Further, the security terms defined in [IPSEC] and keywords used in [IKE] have been used profusely throughout the document. As such, prior understanding of [IPSEC] and [IKE] are a requirement for reviewing this document. 2.1 Technical Definitions 2.1.1 Security Gateway A security gateway refers to an intermediate system that implements IPSec protocols. For example, a router or a firewall implementing IPSec is a security gateway. 2.1.2 Security Domain A set of communicating entities and resources that share a common security policy enforced at one or more enforcement agents or at an individual host. The definition of security domain applies to networks protected by security gateways as well as to single hosts, since a host may be the enforcer of its own policies. Security domains could exist inside other security domains. Srisuresh & Vilhuber [Page 2] Internet-Draft Policy extensions to IKE January 2001 2.1.3 Application Level Gateway (ALG) Application Level Gateway (ALG) is a trusted entity that has application specific knowledge it can use to determine dynamic security policy requirements for the application. ALG on an IPsec enforcement node may use the information to update the SPD of IPsec and to interface with IKE (directly or indirectly) to enforce the policy extensions with peering Ipsec node. 2.1.4 Dynamic Policy Agent (DPA) Dynamic Policy Agent (DPA) is an entity that interfaces with ALGs, IKE and IPsec-SPD to keep the applications, Ipsec security engine and policy enforcement with peers in sync. Specifically, the Dynamic Policy Agent interfaces with the ALGs to gather the dynamic policy requirements of applications, exchanges the information with peering security node and updates the IPsec-SPD to enforce security. 2.1.5 Policy Payload Policy Payload is a new ISAKMP payload introduced to facilitate flexible definition of policy description and dynamic updates to the original description. 3. Problem with dynamic policy enforcement in IPsec and IKE We will consider the following diagram to illustrate IPsec policy enforcement, as packets traverse the enforcement devices. For the purposes of this document, a security gateway is an intermediate system implementing IPSec. An application on Host-A that needed to communicate with Host-B, in a different administrative domain would typically cross a minimum of two policy enforcement devices - A security gateway local to the administrative domain and another local to the peer node's administrative domain. Figure 3.1 below is meant to be an example and does not cover the various configurations in which administrative domains may be connected to each other. In practice, there may be multiple security gateways. However, the diagram does provide the necessary base to address policy specific issues. Further, even though we selected a security Gateway to illustrate, the discussion is applicable to both transport and tunnel odes of IPsec, equally well. Srisuresh & Vilhuber [Page 3] Internet-Draft Policy extensions to IKE January 2001 ________________ ( ) +--+ ( Administrative ) |__|------( Boundary - B ) /____\ ( ) Host-B (________________) | +--------------------+ | Security Gateway | | - GW-B | +--------------------+ __________ | ( ) | +-----------------+ ( ) +-----------------+ | Border Router-A |--( Internet )--| Border Router-B | +-----------------+ ( ) +-----------------+ | (__________) | +--------------------+ | Security Gateway | | - GW-A | +--------------------+ | ---------------- ( ) +--+ ( Administrative ) |__|------( Boundary - A ) /____\ ( ) Host-A (________________) Figure 3.1: Security Gateways connected across the Internet. A security gateway operating in tunnel mode may encrypt and/or authenticate a packet and forward it through a tunnel destined to peer security gateway. The peer gateway in turn, de-tunnels the IP packet from the tunnel and reverse-transforms it to extract the original packet. It then forwards it to the destination, as specified in the original packet [Ref 8]. There is however a pitfall for certain type of applications. An application comprised of a session bundle may work only partially. For example, a security Gateway cannot create an SA (one or more) that can secure all session of the FTP application (i.e., FTP control and data sessions), unless your policy is to preserve all of TCP. Here is why. You could have a policy that preserves FTP control session by selecting src or Dest TCP port Srisuresh & Vilhuber [Page 4] Internet-Draft Policy extensions to IKE January 2001 to be 21. But, the data session parameters set by, say PASV response, will decide the port number used by the ensuing data session. Only the end-nodes know the data session port numbers. Dynamically selected ports in a session cannot not be known to IKE or IPsec, unless IKE and Ipsec have application specific knowledge to examine the payload. Even as applications can notify the security Gateway of the data sessions, IKE does not know to add or delete sessions to reuse of the same key (as used for FTP control session) for securing data sessions. 3. Suggested changes to Security policy enforcement in IPsec and IKE The solution we are about to propose requires changes in the way the IPsec SPD rules are defined and accessed. A Dynamic policy Agent (DPA) is introduced to interface with IPsec-SPD to keep the SPD in sync with the requirements of end-to-end applications. Further, additional changes in IKE are proposed to communicate dynamic policy updates securely across peering security nodes. 3.1 Dynamic Policy Agent (DPA) A new entity, labeled Dynamic Policy Agent (DPA) is envisioned to coordinate exchange of dynamic policy updates between peering IKE nodes, followed by an update of the same in the local IPsec SPD. DPA uses Policy-ID to co-ordinate these policy updates. 3.2 Suggested changes to IPsec SPD Application specific IPsec policy rules in SPD must be allowed to be associated with an application specific ALGs. Each policy rule in the SPD will also have a 4-octet long Policy-ID to uniquely identify the policy within the node. These Policy rules, along with their policy ID are exchanged with peering IKE nodes. Specification of an ALG for a policy rule is optional. When an ALG is specified in the policy, the ALG will become a part of the IPsec data path. The ALGs are trusted entities by the application and will have application specific knowledge to determine the dynamic policy requirements of an application. These ALGs interface with dynamic policy agent (DPA) to notify policy updates to the existing policy rules in IPsec SPD. Changes to IPsec data path at the enforcement points may be captured as follows in the following two diagrams. Srisuresh & Vilhuber [Page 5] Internet-Draft Policy extensions to IKE January 2001 +---------+ +---------+ +------------+ | | | | | | Outgoing |Does the | Yes |Redirect | SA |Perform | Forward -------->|pkt match|---->|pkt to |----->|Outbound |-------> Packet |Outbound | |ALG, if | Keys |Security | Packet |Policy? | |specified| |(ex:encrypt)| +---------+ +---------+ +------------+ Figure 3.2.1. Operation of IPsec on outgoing packets. +------------+ +---------+ +---------+ Incoming |Perform | Clear |Does the | Yes |Redirect | Send to -------->|Inbound |------>|pkt match|---->|pkt to |-------> Packet |Security | Pkt |Inbound | |ALG, if | Appl. |(ex:Decrypt)| |Policy? | |specified| +------------+ +---------+ +---------+ Figure 3.2.2. Operation of IPsec on Incoming packets 3.3. Suggested changes to IKE A new type of Policy payload is added to the list of ISAKMP payloads. This payload is to be used only in IKE phase II and is designed to be flexible, so as not to be constrained to the form of a single rule. Each new policy will have a policy-ID associated with it. A policy may be defined using one or more policy payloads. The payload allows for the specification of a range of addresses and transport ports, while also permitting selective exclusion. 3.3.1. Provide Dynamic Policy Updates(Add/Delete) to Enforcement Points For IPsec, the end nodes should be able to influence policies associated with an IPsec SA dynamically. This is independent of whether the SA was between the peers directly or between 2 gateway nodes in between. An end node should be able to add/delete policies dynamically from an SA. Without this, application specific policies are hard to enforce on an SA. For instance, take a policy that mandates security for FTP application between 2 hosts. Once a SA is established for securing the control session of the FTP application, the end nodes ought to be able to (a) add/delete newer policies (describing the parameters of ensuing FTP data sessions) to the existing FTP control session SA, or (b) create newer SAs dynamically confirming to dynamically Srisuresh & Vilhuber [Page 6] Internet-Draft Policy extensions to IKE January 2001 generated policy parameters. Exchange of Dynamic policy updates in IKE phase II is made possible with the notion of DPA. The DPA interacts with IKE locally to either notify IKE to initiate a policy update or to confirm the validity of a proposed update coming in from a remote node. IKE peers exchange new policies and the policy updates securely in quick mode. The policy updates may involve addition or subtractions to the original policy rule. Each policy rule is uniquely identified by a Policy-ID. Once the policy updates are securely exchanged, the DPA updates the local SPD to reflect the changes associated with the Policy-ID. The following diagram summarizes the role of DPA in conjunction with IKE in dynamic policy update process. +------+ +--------+ +---------+ | | Dynamic | | Exchange Policy | | +-| ALGn |<------->| Dynamic|<----------------->| IKE | | +------+ Policy | Policy | Updates (based on | Process | +-| ...| Updates | Agent | Policy-ID handle) | | | +------+ +--------+ +---------+ | ALG1 | | ^ | +------+ Reflect dynamic | | | policy updates | Security | |Negotiated exchanged with | Policies & | |parameters, peering IKE node| SA proposals | |SA Keys v | v +---------+ +---------+ | |------------------>| | | IPsec- | | IPsec | | SPD | | Process | | | | | +---------+ +---------+ Figure 3.3.3. DPA coordinating between ALGs, IKE and IPsec-SPD. 4. New Policy Payload for use in IKE phase 2 IKE uses ID payload in phase I to authenticate the peers. The ID payload is further extended in phase II to exchange the IPsec policies. While this reduces the number of payload types to work with, it became a stretch to extend the ID payload to describe IPsec policies in IKE phase 2. Policy specification using ID payload has been rather inflexible and prone to errors. So, a new policy payload is introduced for a policy definition that is more flexible and less error prone. Srisuresh & Vilhuber [Page 7] Internet-Draft Policy extensions to IKE January 2001 4.1 IPsec Policy Payload format The Policy Payload contains DOI-specific data used to exchange Policy information. This information is used for exchanging the Policies of communicating peers for which keys need to be generated. Figure 4.1 shows the format of the Policy Payload. The Policy Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o Policy OpCode (1 octet) - Specifies the type of Operation to be performed. This can be one of POLICY-OP-CREATE (0x00), POLICY-OP-ADD (0x01) or POLICY-OP-DEL (0x02). o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. 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 ! Policy Opcode ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Policy IDentifier ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ~ Policy Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4.1. Policy Payload Format o DOI Specific Policy-ID (4 octets) - Contains DOI specific Identification data. o Policy Data (variable length) - Contains Policy information. Specific details for the IETF IP Security DOI Policy Data may be specified as follows. The payload type for the Policy Payload may be assigned a value of fourteen (14), so as not to conflict with the definitions for recognized ISAKMP payload types, as defined in [ISAKMP] sections 4.3 through 4.14. Srisuresh & Vilhuber [Page 8] Internet-Draft Policy extensions to IKE January 2001 4.2 IPsec Policy Payload Content format The Policy Payload, used in IKE phase II, is used to ensure that a certain security association is applied only to those packets that confirm to the policy exchanged in conjunction with the SA negotiation. The policy payload of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association. For example, a host might choose to require authentication and integrity without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (ESP) from another range of IP addresses. The policy Payload provides information that can be used by the responder to make this decision. The following diagram illustrates the content of the Policy Payload. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !P!RSRVD! IPvx !SA-Type!DA-Type!SP-type|DP-type! Protocol ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Src-address-Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Src-Port-Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Dest-address-Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Dest-Port-Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional Policy Extensions in Tag-Length-Value format ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4.2. IPsec DOI Policy Data content Format The Policy Payload fields are defined as follows: o P (1 bit) - Polarity of the Policy. The policy must be interpreted as outbound policy from the policy senders view. When set to 0, the position of source and destination fields for Address and port are interpreted as described in the figure. When set to 1, the position of the source and destination fields must be reversed. o RSRVD (4 bits) - Must be set to 0. o IPvx (4 bits) - Value describing the IP address Length. A value of 4 refers to IPv4 and an IP address length of 4 octets. A value of 6 refers to IPv6 and an IP address Srisuresh & Vilhuber [Page 9] Internet-Draft Policy extensions to IKE January 2001 length of 16 octets. o SA-Type (4 bits) - Value describing the format of information found in the Src-Address-Data field. o DA-Type (4 bits) - Value describing the format of information found in the Dest-Address-Data field. o SP-Type (4 bits) - Value describing the format of information found in the Src-Port-Data field. o DP-Type (4 bits) - Value describing the format of information found in the Dest-Port-Data field. o Protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g. UDP/TCP). A value of zero means that the Protocol ID field should be ignored. o Src-address-Data, Src-Port-Data, Dest-address-Data, Dest-Port-Data (variable length) - Value, as indicated by the fields IPvx, SA-Type, SP-type, DA-Type and DP-type. 4.2.1 SA-Type and DA-Type Values The following table lists the assigned values for the Address type fields found in the Policy data. Address Type Value ------------ ----- RESERVED 0 POLICY_ADDR_SINGLE 1 POLICY_ADDR_RANGE 2 POLICY_ADDR_SUBNET 3 POLICY_ADDR_LIST_SINGLE 9 POLICY_ADDR_LIST_RANGE 10 POLICY_ADDR_LIST_SUBNET 11 The POLICY_ADDR_SINGLE type specifies a single IP address in the Address-Data field. This will be four (4) octets, when IPvx is set to 4. This will be sixteen (16) octets, when IPvx is set to 6. The POLICY_ADDR_RANGE type specifies a range of IP addresses, represented by two four or sixteen octet values, based on whether IPvx is set to 4 or 6. The first value is the beginning IP address (inclusive) and the second value is the ending IP address (inclusive). Note that all addresses falling between the two specified addresses are considered to be within the list. Srisuresh & Vilhuber [Page 10] Internet-Draft Policy extensions to IKE January 2001 The POLICY_ADDR_SUBNET type specifies two IP addresses, each represented by two four or sixteen octet values, based on whether IPvx is set to 4 or 6. The first value is an IP address. The second is an IP network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. The POLICY_ADDR_LIST_SINGLE type specifies a variable number of individual IP addresses in the Address-Data field. The Address-Data field will have the addresses listed as follows. <----List of individual IP Addresses------> <- 2 bytes -> <- Multiples of 4(IPv4) or 16(IPv6) bytes-> The is the sum total of octets required to specify the address list and the 2 bytes required by the field. The The POLICY_ADDR_LIST_RANGE type specifies a variable number of individual IP address ranges in the Address-Data field. The Address-Data field will have the address ranges listed as follows. <------List of IP Address ranges----------> <- 2 bytes -> <- Multiples of 8(IPv4) or 32(IPv6) bytes-> The is the sum total of octets required to specify the address ranges and the 2 bytes required by the field. The POLICY_ADDR_LIST_SUBNET type specifies a variable number of individual IP address subnets in the Address-Data field. The Address-Data field will have the address subnets listed as follows. <------List of IP Address subnets---------> <- 2 bytes -> <- Multiples of 8(IPv4) or 32(IPv6) bytes-> The is the sum total of octets required to specify the address subnets and the 2 bytes required by the field. 4.2.2 SP-Type and DP-Type Values The following table lists the assigned values for the Port type fields(SP-Type, DP-Type) found in the Policy data. Srisuresh & Vilhuber [Page 11] Internet-Draft Policy extensions to IKE January 2001 Type Value ------------ ----- POLICY_PORT_IGNORE 0 POLICY_PORT_SINGLE 1 POLICY_PORT_RANGE 2 POLICY_PORT_LIST_SINGLE 9 POLICY_PORT_LIST_RANGE 10 POLCY_PORT_IGNORE type indicates that the associated Port-Data field should be ignored. POLICY_PORT_SINGLE type would specify a 2 octet port-data field. POLICY_PORT_RANGE type would specify a pair of 2-octet port numbers in Port-Data field. The first value is the beginning port number (inclusive) and the second value is the ending port number (inclusive). POLICY_PORT_LIST_SINGLE would specify a variable number of bytes in the Port-Data field as follows. The Port-date filed will have the variable count of port numbers listed as follows: <- 2 bytes -> <----- Multiples of 2 bytes ----> The is the sum total of octets required to specify the individual ports and the 2 bytes required by the field. POLICY_PORT_LIST_RANGE would specify a variable number of bytes in the Port-Data field as follows. The Port-date filed will have the variable count of port ranges listed as follows: <- 2 bytes -> <------ Multiples of 4 bytes --------> The is the sum total of octets required to specify the individual ports and the 2 bytes required by the field. 4.2.3. Optional policy extensions Optionally, additional fields (over and above 5 tuples for address, protocol and port numbers) may also be specified as part of the Policy specification in Tag-Length-Value format. Existense of additional fields in policy specification may be surmised when the Policy payload length (refer section 4.2.1) exceeds the five-tuple policy data. Srisuresh & Vilhuber [Page 12] Internet-Draft Policy extensions to IKE January 2001 For example, the Diffserv Field in IP header may be specified as as an additional field as follows, The will be specified in a single octet. field is the sum total of bytes necessary to list the DS-fields allowed and the two bytes necessary to specify the and fields. 5. Modifications to IKE Phase 2 - Quick Mode IKE Quick Mode is used to derive keying material for IPsec policies commonly shared between the IKE peers. The information exchanged in Quick Mode is protected by the ISAKMP SA (Phase 1). The message ID in the ISAKMP header identifies the Quick Mode in progress. Quick Mode is essentially a SA negotiation, IPsec policy communication and an exchange of nonces that provides replay protection. The Policies for which SAs negotiated in Quick Mode are implicitly assumed to be between the IP addresses of the ISAKMP peers, unless policy operations are explicitly specified in Quick Mode. With the new approach, Policy based payloads are exchanged in place of IDci and IDcr. If the client policies are not acceptable to the Quick Mode responder, a Notify payload with Notify Message Type INVALID-POLICY-INFORMATION SHOULD be sent. A value of thirty one (31) may be assigned to INVALID-POLICY-INFORMATION, so as not to conflict with the error codes listed in 3.14.1 of [ISAKMP]. Srisuresh & Vilhuber [Page 13] Internet-Draft Policy extensions to IKE January 2001 5.1. New Policy Exchange in Quick mode Policy based Quick Mode may be described as follows for brand new key generation. Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] (, POLi)* --> <-- HDR*, HASH(2), SA, Nr [, KE ] (, POLr)* HDR*, HASH(3) --> Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash, including all payload headers, but excluding any padding added for encryption. HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, minus the payload header-- is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for a liveliness proof. HASH(3)-- for liveliness-- is the prf over the value zero represented as a single octet, followed by a concatenation of the message id and the two nonces-- the initiator's followed by the responder's-- minus the payload header. In other words, the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] | POLi* ) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | POLr* ) HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) HASH, SA, and Nonce payloads must be sent in that order. A single SA negotiation results in two security associations-- one inbound and one outbound. Different SPIs for each SA (one chosen by the initiator, the other by the responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA. Multiple SAs and keys can be negotiated with one exchange such that you have two keys each way for both SAs. New policy payload must be accompanied by a SA negotiation payload. 5.2. Dynamic Policy update in Quick Mode For exchanges that do not involve Key generation, but simply policy updates, Updates to Policies previously negotiated may be performed as follows. These policy updates do not mandate SA negotiation Srisuresh & Vilhuber [Page 14] Internet-Draft Policy extensions to IKE January 2001 payload. However, a single SA negotiation payload is optional. Initiator Responder ----------- ----------- HDR*, HASH(1), [SA, ] Ni , POLi (, POLi)* --> <-- HDR*, HASH(2), [SA, ] Nr , POLr (, POLr)* HDR*, HASH(3) --> Hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | [ SA |] Ni | POLi* ) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | [SA |] Nr | POLr* ) HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) When no SA is specified, the policy updates made in POLi/POLr simply update the corresponding policy rule in SPD. Hence, the SA associated with the POLICY-ID will be reused for the updated policy. However, when SA payload is present, the new SA negotiation results in two new security associations-- one inbound and one outbound for the Policy Updates. These new SA keys will be used to secure the policy updates exchanged. 6. Security Considerations The document suggests a new Policy-ID payload and modifications to IKE protocol. This however, does not jeopardize the security provided by the base IKE protocol. Additions and deletions pertaining to a Policy ID are communicated in a secure way so as not to jeopardize the ability of the application to run. 7. IANA Considerations This document proposes a new ISAKMP payload type and a new Notify error code. 7.1. ISAKMP Policy Payload type The ISAKMP payload types are discussed in sections 3.4 through 3.15 of [ISAKMP]. And, Section 4.6 of [IPSEC-DOI] lists the ISAKMP payloads whose data representations are dependent on the applicable DOI. The new ISAKMP payload type discussed in section 4.1 of this document will be an addition to the payload types discussed in [ISAKMP] as well as [IPSEC_DOI]. However, the ISAKMP payload types are not listed as items to be managed by IANA in [ISAKMP]. Assuming this to have been an omission, we propose that the new payload type Srisuresh & Vilhuber [Page 15] Internet-Draft Policy extensions to IKE January 2001 specified in this document be considered by IANA as an addition to the ISAKMP payload types listed in sections 3.4 through 3.15 in [ISAKMP]. Within the context of this new policy payload type, three sub-fields are defined that may be assigned newer values in the future. The following sub-section explains the criteria to be used by the IANA to assign additional numbers as values to these sub-fields, described in section 4.1, 4.2.1 and 4.2.2 7.1.1. Policy Opcode field Values 0-2 of the Policy-Opcode field are defined in Section 4.1. the remaining values [3-255] are available for assignment by the IANA with IETF Consensus [IANA]. 7.1.2. SA-Type and DA-Type fields SA-Type and DA-type fields are 4-bits long. Values 0-3, 9-11 for these fields are defined in Section 4.2.1. The remaining values 4-8, 12-15 are available for assignment by the IANA with IETF Consensus [IANA]. It is recommended that values 4 through 7 be allowed to specify fixed length types and the values 8 and 12 through 15 be alowed to specify variable length types. 7.1.3. SP-Type and DP-Type fields SP-Type and DP-Type fields are 4-bits long. Values 0-2, 9-10 for these fields are defined in Section 4.2.2. The remaining values 3-8, 11-15 are available for assignment by the IANA with IETF Consensus [IANA]. It is recommended that values 3 through 7 be allowed to specify fixed length types and the values 8 and 11 through 15 be alowed to specify variable length types. 7.2. ISAKMP Notify payload error message type Section 3.14.1 of [ISAKMP] lists the Notification error codes in the range of 1-30. Error codes 31-8191 are reserved for future use and error codes 8192-16383 are set aside for private use. Of these, error code 8192 is reserved by the IPSEC-DOI in section 4.6.3 of [IPSEC-DOI]. We define a new INVALID-POLICY-INFORMATION error code 31 in section 5.0. Once again, the error codes lised for use within the Notify payload in [ISAKMP] are not listed as items to be managed by IANA in [ISAKMP]. Assuming this to have been an omission, we propose that the error code specified in this document be considered by IANA as an addition to the Notify payload error codes listed in Srisuresh & Vilhuber [Page 16] Internet-Draft Policy extensions to IKE January 2001 3.14.1 of [ISAKMP]. REFERENCES [STD-KEYWORDS] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401. [AH] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 [ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406. [IPSEC-DOI] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407. [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2412. [CRYPTO] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition. [IKE] Harkins, D., Carrel, D.,"The Internet Key Exchange (IKE)", RFC 2409. [IANA] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Authors' Address: Pyda Srisuresh Jasmine Networks, Inc. 3061 Zanker Road, Suite B San Jose, CA 95134 U.S.A. Srisuresh & Vilhuber [Page 17] Internet-Draft Policy extensions to IKE January 2001 Voice: (408) 895-5032 EMail: srisuresh@yahoo.com Jan Vilhuber Cisco Systems 170 West Tasman Drive San Jose, CA 95134 U.S.A. E-mail: vilhuber@cisco.com Srisuresh & Vilhuber [Page 18]