HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 04:17:28 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 22 Sep 1997 10:55:00 GMT ETag: "2f544b-c4bc-34264e84" Accept-Ranges: bytes Content-Length: 50364 Connection: close Content-Type: text/plain Network Working Group Derrell Piper INTERNET-DRAFT cisco Systems draft-ietf-ipsec-ipsec-doi-04.txt September 19, 1997 The Internet IP Security Domain of Interpretation for ISAKMP Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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 learn the current status of any Internet Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. This draft will expire six months from date of issue. 1. Abstract The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. For a description of how the IPSEC DOI fits into the overall IP Security Documentation framework, please see [ROADMAP]. For a list of changes since the previous version of the IPSEC DOI, please see Section 5. Piper Expires in 6 months [Page 1] INTERNET DRAFT IPSEC DOI September 19, 1997 2. Introduction Within ISAKMP, a Domain of Interpretation is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. They also share a common interpretation of DOI-specific payload data content, including the Security Association and Identification payloads. Overall, ISAKMP places the following requirements on a DOI definition: o define the naming scheme for DOI-specific protocol identifiers o define the interpretation for the Situation field o define the set of applicable security policies o define the syntax for DOI-specific SA Attributes (phase II) o define the syntax for DOI-specific payload contents o define additional Key Exchange types, if needed o define additional Notification Message types, if needed The remainder of this document details the instantiation of these requirements for using the IP Security (IPSEC) protocols to provide authentication, integrity, and/or confidentiality for IP packets sent between cooperating host systems and/or firewalls. 3. Terms and Definitions 3.1 Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalized. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY Piper Expires in 6 months [Page 2] INTERNET DRAFT IPSEC DOI September 19, 1997 This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. Piper Expires in 6 months [Page 3] INTERNET DRAFT IPSEC DOI September 19, 1997 4.1 IPSEC Naming Scheme Within ISAKMP, all DOI's must be registered with the IANA in the ``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the Internet IP Security DOI is one (1). Within the IPSEC DOI, all well-known identifiers MUST be registered with the IANA under the Internet IP Security DOI. Unless otherwise noted, all tables within this document refer to IANA Assigned Numbers for the IPSEC DOI. All multi-octet binary values are stored in network byte order. 4.2 IPSEC Situation Definition Within ISAKMP, the Situation provides information that can be used by the responder to make a policy determination about how to process the incoming Security Association request. For the IPSEC DOI, the Situation field is a four (4) octet bitmask with the following values. Situation Value --------- ----- SIT_IDENTITY_ONLY 0x01 SIT_SECRECY 0x02 SIT_INTEGRITY 0x04 All other values are reserved to IANA. 4.2.1 SIT_IDENTITY_ONLY The SIT_IDENTITY_ONLY type specifies that the security association will be identified by source identity information present in an associated Identification Payload. See Section 4.6.2 for a complete description of the various Identification types. All IPSEC DOI implementations MUST support SIT_IDENTITY_ONLY by including an Identification Payload in at least one of the phase I Oakley exchanges ([IO], Section 5) and MUST abort any association setup that does not include an Identification Payload. If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the situation consists only of the 4 octet situation bitmap and does not include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) or any subsequent label information. Conversely, if the initiator supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain Identifier MUST be included in the situation payload. 4.2.2 SIT_SECRECY The SIT_SECRECY type specifies that the security association is being Piper Expires in 6 months [Page 4] INTERNET DRAFT IPSEC DOI September 19, 1997 negotiated in an environment that requires labeled secrecy. If SIT_SECRECY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes a sensitivity level and compartment bitmask. See Section 4.6.1 for a complete description of the Security Association Payload format. If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be set in the Situation bitmap and no secrecy level or category bitmaps shall be included. If a responder does not support SIT_SECRECY, a SITUATION-NOT- SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted. 4.2.3 SIT_INTEGRITY The SIT_INTEGRITY type specifies that the security association is being negotiated in an environment that requires labeled integrity. If SIT_INTEGRITY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes an integrity level and compartment bitmask. If SIT_SECRECY is also in use for the association, the integrity information immediately follows the variable-length secrecy level and categories. See section 4.6.1 for a complete description of the Security Association Payload format. If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST NOT be set in the Situation bitmap and no integrity level or category bitmaps shall be included. If a responder does not support SIT_INTEGRITY, a SITUATION-NOT- SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted. 4.3 IPSEC Security Policy Requirements The IPSEC DOI does not impose specific security policy requirements on any implementation. Host system policy issues are outside of the scope of this document. However, the following sections touch on some of the issues that must be considered when designing an IPSEC DOI host implementation. This section should be considered only informational in nature. 4.3.1 Key Management Issues It is expected that many systems choosing to implement ISAKMP will strive to provide a protected domain of execution for a combined Piper Expires in 6 months [Page 5] INTERNET DRAFT IPSEC DOI September 19, 1997 ISAKMP/Oakley key management daemon. On protected-mode multiuser operating systems, this key management daemon will likely exist as a separate privileged process. In such an environment, a formalized API to introduce keying material into the TCP/IP kernel may be desirable. The PF_KEY API [PFKEY] is an example of one such API that provides an abstracted key management interface. The IP Security architecture does not place any requirements for structure or flow between a host TCP/IP kernel and its key management provider. 4.3.2 Static Keying Issues Host systems that implement static keys, either for use directly by IPSEC, or for authentication purposes (see [IO] Section 5.3), should take steps to protect the static keying material when it is not residing in a protected memory domain or actively in use by the TCP/IP kernel. For example, on a laptop, one might choose to store the static keys in a configuration store that is, itself, encrypted under a private password. Depending on the operating system and utility software installed, it may not be possible to protect the static keys once they've been loaded into the TCP/IP kernel, however they should not be trivially recoverable on initial system startup without having to satisfy some additional form of authentication. 4.3.3 Host Policy Issues It is not realistic to assume that the transition to IPSEC will occur overnight. Host systems must be prepared to implement flexible policy lists that describe which systems they desire to speak securely with and which systems they require speak securely to them. Some notion of proxy firewall addresses may also be required. A minimal approach is probably a static list of IP addresses, network masks, and a security required flag or flags. A more flexible implementation might consist of a list of wildcard DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional firewall address. The wildcard DNS name would be used to match incoming or outgoing IP addresses, the in/out bitmask would be used to determine whether or not security was to be applied and in which direction, and the optional firewall address would be used to indicate whether or not tunnel mode would be needed to talk to the target system though an intermediate firewall. Piper Expires in 6 months [Page 6] INTERNET DRAFT IPSEC DOI September 19, 1997 4.3.4 Certificate Management Host systems implementing a certificate-based authentication scheme will need a mechanism for obtaining and managing a database of certificates. Secure DNS is to be one certificate distribution mechanism, however the pervasive availability of secure DNS zones, in the short term, is doubtful for many reasons. What's far more likely is that hosts will need an ability to import certificates that they acquire through secure, out-of-band mechanisms, as well as an ability to export their own certificates for use by other systems. However, manual certificate management should not be done so as to preclude the ability to introduce dynamic certificate discovery mechanisms and/or protocols as they become available. 4.4 IPSEC Assigned Numbers The following sections list the Assigned Numbers for the IPSEC DOI Security Protocol Identifiers, Transform Identifiers, and Security Association Attribute Types. 4.4.1 IPSEC Security Protocol Identifiers The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple security protocol suites within a single negotiation. As a result, the protocol suites listed below form the set of protocols that can be negotiated at the same time. It is a host policy decision as to what protocol suites might be negotiated together. The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC DOI. Protocol ID Value ----------- ----- RESERVED 0 PROTO_ISAKMP 1 PROTO_IPSEC_AH 2 PROTO_IPSEC_ESP 3 PROTO_IPCOMP 4 The size of this field is one octet. The values 5-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.1.1 PROTO_ISAKMP Piper Expires in 6 months [Page 7] INTERNET DRAFT IPSEC DOI September 19, 1997 The PROTO_ISAKMP type specifies message protection required during Phase I of the ISAKMP protocol. The specific protection mechanism used for the IPSEC DOI is described in [IO]. All implementations within the IPSEC DOI MUST support PROTO_ISAKMP. NB: ISAKMP reserves the value one (1) across all DOI definitions. 4.4.1.2 PROTO_IPSEC_AH The PROTO_IPSEC_AH type specifies IP packet authentication. The default AH transform provides data origin authentication, integrity protection, and replay prevention. For export control considerations, confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform. 4.4.1.3 PROTO_IPSEC_ESP The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Authentication, if required, must be provided as part of the ESP transform. The default ESP transform includes data origin authentication, integrity protection, replay prevention, and confidentiality. 4.4.1.4 PROTO_IPCOMP The PROTO_IPCOMP type specifies IP packet compression. 4.4.2 IPSEC ISAKMP Transform Values As part of an ISAKMP Phase I negotiation, the initiator's choice of Key Exchange offerings is made using some host system policy description. The actual selection of Key Exchange mechanism is made using the standard ISAKMP Proposal Payload. The following table lists the defined ISAKMP Phase I Transform Identifiers for the Proposal Payload for the IPSEC DOI. Transform Value --------- ----- RESERVED 0 KEY_OAKLEY 1 The size of this field is one octet. The values 2-248 are reserved to IANA. Values 249-255 are reserved for private use. Within the ISAKMP and IPSEC DOI framework it is possible to define key establishment protocols other than Oakley. Previous versions of this document defined types both for manual keying and for schemes based on use of a generic Key Distribution Center (KDC). These Piper Expires in 6 months [Page 8] INTERNET DRAFT IPSEC DOI September 19, 1997 identifiers have been removed from the current document. The IPSEC DOI can still be extended later to include values for additional non-Oakley key establishment protocols for ISAKMP and IPSEC, such as Kerberos [RFC-1510] or the Group Key Management Protocol (GKMP) [RFC-2093]. 4.4.2.1 KEY_OAKLEY The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman key exchange as defined in the [IO] document. All implementations within the IPSEC DOI MUST support KEY_OAKLEY. 4.4.3 IPSEC AH Transform Values The Authentication Header Protocol (AH) defines one mandatory and several optional transforms used to provide authentication, integrity, and replay detection. The following table lists the defined AH Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 AH_MD5_KPDK 1 AH_MD5 2 AH_SHA 3 AH_DES 4 The size of this field is one octet. The values 5-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.3.1 AH_MD5_KPDK The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key) described in RFC-1826. This mode MAY be negotiated for compatibility with older implementations. Implementations are not required to support this mode. 4.4.3.2 AH_MD5 The AH_MD5 type specifies a generic AH transform using MD5. The actual protection suite is determined in concert with an associated SA attribute list. A generic MD5 transform is currently undefined. All implementations within the IPSEC DOI MUST support AH_MD5 along with the Auth(HMAC-MD5) attribute. This suite is defined as the HMAC-MD5-96 transform described in [HMACMD5]. Piper Expires in 6 months [Page 9] INTERNET DRAFT IPSEC DOI September 19, 1997 4.4.3.3 AH_SHA The AH_SHA type specifies a generic AH transform using SHA-1. The actual protection suite is determined in concert with an associated SA attribute list. A generic SHA transform is currently undefined. All implementations within the IPSEC DOI are strongly encouraged to support AH_SHA along with the Auth(HMAC-SHA) attribute. This suite is defined as the HMAC-SHA-1-96 transform described in [HMACSHA]. 4.4.3.4 AH_DES The AH_DES type specifies a generic AH transform using DES. The actual protection suite is determined in concert with an associated SA attribute list. A generic DES transform is currently undefined. The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute to be the DES-MAC transform described in [DESMAC]. Implementations are not required to support this mode. 4.4.4 IPSEC ESP Transform Identifiers The Encapsulating Security Payload (ESP) defines one mandatory and many optional transforms used to provide data confidentiality. The following table lists the defined ESP Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform ID Value ------------ ----- ESP_NULL 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 ESP_ARCFOUR 10 The size of this field is one octet. The values 11-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.4.1 ESP_NULL Piper Expires in 6 months [Page 10] INTERNET DRAFT IPSEC DOI September 19, 1997 The ESP_NULL type specifies no confidentiality is to be provided by ESP. ESP_NULL is used when ESP is being used to tunnel packets which require only authentication and integrity protection. See the Auth Algorithm attribute description in Section 4.5 for additional requirements relating to the use of ESP_NULL. 4.4.4.2 ESP_DES_IV64 The ESP_DES_IV64 type specifies the DES-CBC transform defined in RFC-1827 and RFC-1829 using a 64-bit IV. This mode MAY be negotiated for compatibility with older implementations. Implementations are not required to support this mode. 4.4.4.3 ESP_DES The ESP_DES type specifies a generic DES transform using DES-CBC. The actual protection suite is determined in concert with an associated SA attribute list. A generic transform is currently undefined. All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5. 4.4.4.4 ESP_3DES The ESP_3DES type specifies a generic triple-DES transform. The actual protection suite is determined in concert with an associated SA attribute list. The generic transform is currently undefined. All implementations within the IPSEC DOI are strongly encourage to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [3DES] transform, with authentication and integrity provided by HMAC MD5. 4.4.4.5 ESP_RC5 The ESP_RC5 type specifies the RC5 transform defined in [RC5]. 4.4.4.6 ESP_IDEA The ESP_IDEA type specifies the IDEA transform defined in [IDEA]. 4.4.4.7 ESP_CAST The ESP_CAST type specifies the CAST transform defined in [CAST]. Piper Expires in 6 months [Page 11] INTERNET DRAFT IPSEC DOI September 19, 1997 4.4.4.8 ESP_BLOWFISH The ESP_BLOWFISH type specifies the BLOWFISH transform defined in [BLOW]. 4.4.4.9 ESP_3IDEA The ESP_3IDEA type is reserved for triple-IDEA. 4.4.4.10 ESP_DES_IV32 The ESP_DES_IV32 type specifies the DES-CBC transform defined in RFC-1827 and RFC-1829 using a 32-bit IV. This mode MAY be negotiated for compatibility with older implementations. Implementations are not required to support this mode. 4.4.4.11 ESP_ARCFOUR The ESP_ARCFOUR type specifies the ARCFOUR transform defined in [ARCFOUR]. 4.4.5 IPSEC IPCOMP Transform Identifiers The IP Compression (IPCOMP) transforms define optional compression algorithms that can be negotiated to provide for IP compression before ESP encryption. The following table lists the defined IPCOMP Transform Identifiers for the ISAKMP Proposal Payload within the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLAT 2 IPCOMP_LZS 3 IPCOMP_V42BIS 4 The size of this field is one octet. The values 5-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.5.1 IPCOMP_OUI The IPCOMP_OUI type specifies a proprietary compression transform. The IPCOMP_OUI type must be accompanied by an attribute which further identifies the specific vendor algorithm. 4.4.5.2 IPCOMP_DEFLATE Piper Expires in 6 months [Page 12] INTERNET DRAFT IPSEC DOI September 19, 1997 The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate algorithm. 4.4.5.3 IPCOMP_LZS The IPCOMP_LZS type specifies the use of the Stac Electronics LZS algorithm. 4.4.5.4 IPCOMP_V42BIS The IPCOMP_V42BIS type specifies the use of V42bis compression. 4.5 IPSEC Security Association Attributes The following SA attribute definitions are used in phase II of an ISAKMP/Oakley negotiation. Attribute types can be either Basic (B) or Variable-Length (V). Encoding of these attributes is defined in the base ISAKMP specification. Attribute Types class value type ------------------------------------------------- SA Life Type 1 B SA Life Duration 2 B/V Group Description 3 B Encapsulation Mode 4 B Authentication Algorithm 5 B Key Length 6 B Key Rounds 7 B Compress Dictionary Size 8 B Compress Private Algorithm 9 B/V The size of this field is two octets, with the high bit reserved for the ISAKMP B/V encoding. The values 10-32000 are reserved to IANA. Values 32001-32767 are for experimental use. Class Values SA Life Type SA Duration Specifies the time-to-live for the overall security association. When the SA expires, all keys negotiated under the association (AH or ESP) must be renegotiated. The life type values are: RESERVED 0 Piper Expires in 6 months [Page 13] INTERNET DRAFT IPSEC DOI September 19, 1997 seconds 1 kilobytes 2 Values 3-61439 are reserved to IANA. Values 61440-65535 are for experimental use. For a given Life Type, the value of the Life Duration attribute defines the actual length of the component lifetime -- either a number of seconds, or a number of Kbytes that can be protected. If unspecified, the default value shall be assumed to be 28800 seconds (8 hours). An SA Life Duration attribute MUST always follow an SA Life Type which describes the units of duration. See Section 4.5.4 for additional information relating to lifetime notification. Group Description RESERVED 0 768-bit Oakley group 1 1024-bit Oakley group 2 2048-bit Oakley group 3 Values 4-61439 are reserved to IANA. Values 61440-65535 are for private use among mutually consenting parties. This attribute must be included in PFS QM negotiations. Encapsulation Mode RESERVED 0 Tunnel 1 Transport 2 Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use among mutually consenting parties. If unspecified, the default value shall be assumed to be unspecified (host-dependent). Authentication Algorithm RESERVED 0 HMAC-MD5 1 HMAC-SHA-1 2 DES-MAC 3 Values 4-61439 are reserved to IANA. Values 61440-65535 are for private use among mutually consenting parties. Piper Expires in 6 months [Page 14] INTERNET DRAFT IPSEC DOI September 19, 1997 There is no default value for Auth Algorithm, as it must be specified to correctly identify the applicable AH or ESP transform, except in the following case. When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal. When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be included in the proposal and the ESP transform ID must be ESP_NULL. Key Length RESERVED 0 There is no default value for Key Length, as it must be specified for transforms using ciphers with variable key lengths. Key Rounds RESERVED 0 There is no default value for Key Rounds, as it must be specified for transforms using ciphers with varying numbers of rounds. Compression Dictionary Size RESERVED 0 Specifies the log2 maximum size of the dictionary. There is no default value for dictionary size. Compression Private Algorithm Specifies a private vendor compression algorithm. The first three (3) octets must be an IEEE assigned company_id (OUI). The next octet may be a vendor specific compression subtype, followed by zero or more octets of vendor data. 4.5.1 Required Attribute Support To ensure basic interoperability, all implementations MUST be prepared to negotiate all of the following attributes. SA Life Type SA Duration Auth Algorithm Piper Expires in 6 months [Page 15] INTERNET DRAFT IPSEC DOI September 19, 1997 4.5.2 Attribute List Parsing Requirement To allow for flexible semantics, the IPSEC DOI requires that a conforming ISAKMP implementation MUST correctly parse an attribute list that contains multiple instances of the same attribute class, so long as the different attribute entries do not conflict with one another. To see why this is important, the following example shows the binary encoding of a four entry attribute list that specifies an SA Lifetime of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a complete description of the attribute encoding format.) Attribute #1: 0x80010001 (AF = 1, type = SA Life Type, value = seconds) Attribute #2: 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) Attribute #3: 0x80010002 (AF = 1, type = SA Life Type, value = KB) Attribute #4: 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted. 4.5.3 Attribute Negotiation If an implementation receives a defined IPSEC DOI attribute (or attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted, unless the attribute value is in the reserved range. If an implementation receives an attribute value in the reserved range, an implementation MAY chose to continue based on local policy. 4.5.4 Lifetime Notification When an initiator offers an SA lifetime greater than what the responder desires based on their local policy, the responder has three choices: 1) fail the negotiation entirely; 2) complete the negotiation but use a shorter lifetime than what was offered; 3) complete the negotiation and send an advisory notification to the Piper Expires in 6 months [Page 16] INTERNET DRAFT IPSEC DOI September 19, 1997 initiator with the responder's true lifetime. In the latter case, the IPSEC DOI requires the following: if the initiator offers an SA lifetime longer than the responder is willing to accept, the responder SHOULD include an ISAKMP Notification Payload in the exchange that includes the responder's IPSEC SA payload. When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of Notify Data o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to eight (8) (two four octet IPSEC SPI's) o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) o SPI - set to the two IPSEC SPI's o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime(s) Implementation Note: saying that the Notification Data field contains an attribute list is equivalent to saying that the Notification Data field has zero length and the Notification Payload has an associated attribute list. 4.6 IPSEC Payload Content The following sections describe those ISAKMP payloads whose data representations are dependent on the applicable DOI. 4.6.1 Security Association Payload The following diagram illustrates the content of the Security Association Payload for the IPSEC DOI. See Section 4.2 for a description of the Situation bitmap. 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 (IPSEC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation (bitmap) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Labeled Domain Identifier ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Secrecy Length (in octets) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Secrecy Level ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Piper Expires in 6 months [Page 17] INTERNET DRAFT IPSEC DOI September 19, 1997 ! Secrecy Cat. Length (in bits) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Secrecy Category Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Integrity Length (in octets) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Level ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Integ. Cat. Length (in bits) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Category Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Security Association Payload Format The Security Association Payload is defined as follows: o Next Payload (2 octets) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0). o RESERVED (1 octet) - Unused, must be zero (0). o Payload Length (2 octets) - Length, in octets, of the current payload, including the generic header. o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, which has been assigned the value one (1). o Situation (4 octets) - Bitmask used to interpret the remainder of the Security Association Payload. See Section 4.2 for a complete list of values. o Labeled Domain Identifier (4 octets) - IANA Assigned Number used to interpret the Secrecy and Integrity information. o Secrecy Length (2 octets) - Specifies the length, in octets, of the secrecy level identifier. o RESERVED (2 octets) - Unused, must be zero (0). o Secrecy Category Length (2 octets) - Specifies the length, in bits, of the secrecy category (compartment) bitmap, excluding pad bits. o RESERVED (2 octets) - Unused, must be zero (0). o Secrecy Category Bitmap (variable length) - A bitmap used to Piper Expires in 6 months [Page 18] INTERNET DRAFT IPSEC DOI September 19, 1997 designate secrecy categories (compartments) that are required. The bitmap MUST be padded with zero (0) to the next 32-bit boundry. o Integrity Length (2 octets) - Specifies the length, in octets, of the integrity level identifier. o RESERVED (2 octets) - Unused, must be zero (0). o Integrity Category Length (2 octets) - Specifies the length, in bits, of the integrity category (compartment) bitmap, excluding pad bits. o RESERVED (2 octets) - Unused, must be zero (0). o Integrity Category Bitmap (variable length) - A bitmap used to designate integrity categories (compartments) that are required. The bitmap MUST be padded with zero (0) to the next 32-bit boundry. 4.6.1.1 Labeled Domain Identifier Values The following table lists the assigned values for the Labeled Domain Identifier field contained in the Situation field of the Security Association Payload. Domain Value ------- ----- RESERVED 0 The values 1-0x7fffffff are reserved to IANA. Values 0x8000000- 0xffffffff are reserved for private use. 4.6.2 Identification Payload Content The Identification Payload is used to identify the initiator of the Security Association. The identity 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 Identification Payload provides information that can be used by the responder to make this decision. The following diagram illustrates the content of the Identification Payload. Piper Expires in 6 months [Page 19] INTERNET DRAFT IPSEC DOI September 19, 1997 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Identification Payload Format The Identification Payload fields are defined as follows: o Next Payload (2 octets) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0). o RESERVED (1 octet) - Unused, must be zero (0). o Payload Length (2 octets) - Length, in octets, of the identification data, including the generic header. o Identification Type (1 octet) - Value describing the identity information found in the Identification 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 Port (2 octets) - Value specifying an associated port. A value of zero means that the Port field should be ignored. o Identification Data (variable length) - Value, as indicated by the Identification Type. 4.6.2.1 Identification Type Values The following table lists the assigned values for the Identification Type field found in the Identification Payload. ID Type Value ------- ----- RESERVED 0 ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 Piper Expires in 6 months [Page 20] INTERNET DRAFT IPSEC DOI September 19, 1997 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 The size of this field is one octet. The values 12-248 are reserved to IANA. Values 249-255 are reserved for private use. For types where the ID entity is variable length, the size of the ID entity is computed from size in the ID payload header. When an ISAKMP/Oakley exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange. 4.6.2.2 ID_IPV4_ADDR The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 4.6.2.3 ID_FQDN The ID_FQDN type specifies a fully-qualified domain name string. An example of a ID_FQDN is, "foo.bar.com". The string should not contain any terminators. 4.6.2.4 ID_USER_FQDN The ID_USER_FQDN type specifies a fully-qualified username string, An example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should not contain any terminators. 4.6.2.5 ID_IPV4_ADDR_SUBNET The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 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. 4.6.2.6 ID_IPV6_ADDR The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address. 4.6.2.7 ID_IPV6_ADDR_SUBNET Piper Expires in 6 months [Page 21] INTERNET DRAFT IPSEC DOI September 19, 1997 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is an IPv6 address. The second is an IPv6 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. 4.6.2.8 ID_IPV4_ADDR_RANGE The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 4.6.2.9 ID_IPV6_ADDR_RANGE The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 4.6.2.10 ID_DER_ASN1_DN The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501] of the principal whose certificates are being exchanged to establish the SA. 4.6.2.11 ID_DER_ASN1_GN The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 X.500 GeneralName [X.509] of the principal whose certificates are being exchanged to establish the SA. 4.6.2.12 ID_KEY_ID The ID_KEY_ID type specifies an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre- shared key should be used to authenticate Aggressive mode negotiations. 4.6.3 IPSEC DOI Notify Message Types ISAKMP defines two blocks of Notify Message codes, one for errors and one for status. ISAKMP also allocates a portion of each block for private use within a DOI. The IPSEC DOI defines the following private message types. Piper Expires in 6 months [Page 22] INTERNET DRAFT IPSEC DOI September 19, 1997 Notify Messages - Error Types Value ----------------------------- ----- RESERVED 8192 Notify Messages - Status Types Value ------------------------------ ----- RESPONDER-LIFETIME 24576 4.7 IPSEC Key Exchange Requirements The IPSEC DOI introduces no additional Key Exchange types. 5. Changes The following changes were made relative to the IPSEC DOI V3, that was posted to the IPSEC mailing list prior to the Munich IETF: o added ESP transform identifiers for NULL and ARCFOUR o renamed HMAC Algorithm to Auth Algorithm to accommodate DES-MAC and optional authentication/integrity for ESP o added AH and ESP DES-MAC algorithm identifiers o removed KEY_MANUAL and KEY_KDC identifier definitions o added lifetime duration MUST follow lifetype attribute to SA Life Type and SA Life Duration attribute definition o added lifetime notification and IPSEC DOI message type table o added optional authentication and confidentiality restrictions to MAC Algorithm attribute definition o corrected attribute parsing example (used obsolete attribute) o corrected several Internet Draft document references o added ID_KEY_ID per ipsec list discussion (18-Mar-97) o removed Group Description default for PFS QM ([IO] MUST) 6. Security Considerations This entire draft pertains to a negotiated key management protocol, combining Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), which negotiates and derives keying material for security associations in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references. Acknowledgements This document is derived, in part, from previous works by Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran Atkinson also contributed suggestions and, in many cases, text. Piper Expires in 6 months [Page 23] INTERNET DRAFT IPSEC DOI September 19, 1997 References [AH] Kent, S., Atkinson, R., "IP Authentication Header," draft-ietf- ipsec-auth-header-01.txt. [ARCFOUR] Thayer, R., "The ESP ARCFOUR Algorithm," draft-ietf-ipsec- ciph-arcfour-00.txt. [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)," draft-ietf-ipsec-esp-v2-00.txt. [BLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an Explicit IV," draft-ietf-ipsec-ciph-blowfish-cbc-00.txt. [CAST] Pereira, R., Carter, G., "The ESP CAST128-CBC Algorithm," draft-ietf-ipsec-ciph-cast128-cbc-00.txt. [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-00.txt. [3DES] Pereira, R., Thayer, R., "The ESP 3DES-CBC Algorithm Using an Explicit IV," draft-ietf-ipsec-ciph-3des-expiv-00.txt. [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft- bitan-auth-des-mac-00.txt. [HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5-96 IP Authentication with Replay Prevention," draft-ietf-ipsec-ah-hmac-md5-96-00.txt. [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA-1-96 IP Authentication with Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt. [IDEA] Adams, R., "The ESP IDEA-CBC Algorithm Using Explicit IV," draft-ietf-ipsec-ciph-idea-cbc-00.txt. [IO] Harkins, D., Carrel, D., "The Resolution of ISAKMP with Oakley," draft-ietf-ipsec-isakmp-oakley-04.txt. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-08.{ps,txt}. [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-ietf-ipsec-oakley-01.txt. [ROADMAP] Thayer, R., Doraswamy, N., Glenn, R., "IP Security Documentation Roadmap," draft-ietf-ipsec-doc-roadmap-00.txt. Piper Expires in 6 months [Page 24] INTERNET DRAFT IPSEC DOI September 19, 1997 [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key Management API, Version 2", draft-mcdonald-pf-key-v2-03.txt. [RC5] Pereira, R., Baldwin, R., "The ESP RC5-CBC Transform," draft- ietf-ipsec-ciph-rc5-cbc-00.txt. [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993. [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993. Author's Address: Derrell Piper cisco Systems 101 Cooper St. Santa Cruz, California, 95060 United States of America +1 408 457-5384 Piper Expires in 6 months [Page 25]