Internet Engineering Task Force Andrew Krywaniuk IP Security Working Group Alcatel Networks Corporation Internet Draft July 14, 2000 The Isakmp Attribute Exchange Mode Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPsec) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 made obsolete 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. Copyright Notice This document is a product of the IETF's IPsec Working Group. Copyright (C) The Internet Society (2000). All Rights Reserved. Krywaniuk Expires January 14, 2001 [Page 1] Internet Draft Attribute Exchange Mode July 14, 2000 Abstract This document describes a simple method for exchanging attributes with the peer. IPsec Working Group [Page 2] Internet Draft Attribute Exchange Mode July 14, 2000 Table of Contents 1. History.........................................................4 2. Specification of Requirements...................................4 3. Changes Since Last Revision.....................................4 4. Goals...........................................................4 5. Attribute Exchange..............................................5 6. Protocol Details................................................6 6.1 Attribute Payload..............................................7 6.2 The HASH Payload...............................................8 6.3 Attribute Action Types.........................................8 6.4 Attribute Values...............................................8 7. Implementation Hints............................................9 8. Use of Values from the Private Range...........................10 9. Security Considerations........................................10 10. References....................................................10 IPsec Working Group [Page 3] Internet Draft Attribute Exchange Mode July 14, 2000 1. History This memo is derived in large part from the Isakmp Configuration Method [IKECFG] by Roy Pereira. Some text is copied verbatim. Although [IKECFG] provides a useful method for exchanging basic configuration attributes, it suffers from two problems: 1) It uses an exchange number from the Isakmp reserved to IANA range. 2) It sanctions the use of the specific configuration attributes for which there is not clear consensus in the IPsec community. This document attempts to fix these two problems with [IKECFG] by 1) Using an exchange number from the Isakmp private range. 2) Deferring the assignment of attribute numbers to documents provided by the relevant IETF working groups. 2. Specification of Requirements This document shall use the keywords "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [Bradner97]. 3. Changes Since Last Revision This is the initial revision of the Attribute Exchange Mode. It differs from [IKECFG] in that all references to specific configuration attributes have been deleted and a new exchange number has been assigned (this time from the Isakmp private range). 4. Goals One of the functions of [IKECFG] is to define a DHCP-like mechanism for passing configuration information to a "road-warrior" VPN client. Whether or not this is a suitable way to effect DHC has been a subject of vigorous debate among WG members. However, one should not overlook the other function of [IKECFG], which is to provide a simple and generic method of exchanging IPsec Working Group [Page 4] Internet Draft Attribute Exchange Mode July 14, 2000 attributes with the peer. We believe that it is desirable to standardize this attribute exchange property of [IKECFG] in a form that is free from the baggage of the DHC mechanism. Currently, there is no standardized way for Isakmp-based hosts to exchange simple session parameters. To bypass this limitation, various solutions have been employed or suggested: 1) The use of vendor ids to specify parameters 2) Encoding the session parameters in a notify message 3) Wrapping the session parameters in a new payload which gets tacked onto an unrelated exchange. All of these solutions are undesirable because they involve hijacking an existing exchange to suit a different purpose. This creates undesirable interactions between the attribute exchange protocol and the transport protocol, which can lead to interoperability problems. An alternate approach is simply to design protocols that avoid the exchange of session parameters. We do not encourage this approach because the operational complexity that can result when two hosts choose incongruent sets of operational parameters is often far worse than the actual work of transmitting those parameters. The goal of this document is to establish the framework for a common attribute exchange protocol. This will allow other protocols to exchange session parameters with very little incremental work. 5. Attribute Exchange An "Attribute Exchange" is defined as two messages, the first being either a Set or a Request and the second being either an Acknowledge or a Reply, respectively. The exchange may be part of a larger, multi-exchange transaction. A common identifier is used to identify the transaction between exchanges. There are two paradigms to follow for this method: o "Request/Reply" allows a host to request information from another host. If the attributes in the Request message are not empty, then these attributes are taken as suggestions for that attribute. The Reply message MAY wish to choose those values, or return new values. It MAY also add new attributes and not include some requested IPsec Working Group [Page 5] Internet Draft Attribute Exchange Mode July 14, 2000 attributes. A Reply SHOULD always be sent when a Request is received (subject to DoS considerations), even if it is an empty Reply or if there are missing attributes in the Request. This merely means that the requested attributes were not available or unknown. Initiator Responder --------------- -------------- REQUEST --> <-- REPLY o "Set/Acknowledge" works on the push principle that allows a host to send information to another host. This code implies attributes that it wants the peer to accept or alter. The Acknowledge code MUST return the zero length attributes that it accepted. Those attributes that it did not accept will NOT be sent back in the acknowledgement. Initiator Responder --------------- -------------- SET --> <-- ACKNOWLEDGE Exchanges are completed once the Reply or Acknowledge code is received. If one is not received, the implementation MAY wish to retransmit the original packet, as described in [ISAKMP]. The initiator and responder are not necessarily the same as the initiator and responder of the ISAKMP phase 1 exchange. 6. Protocol Details The Attribute Exchange Mode will use the value 236 from the Isakmp private range. The packets SHOULD NORMALLY be encrypted, depending on exchange positioning and the sensitivity of the data. An unprotected exchange looks like this: Initiator Responder ----------- ----------- HDR, ATTR(s) --> <-- HDR, ATTR(s) IPsec Working Group [Page 6] Internet Draft Attribute Exchange Mode July 14, 2000 Multiple ATTR payloads MAY be present in a single packet. (This was previously not allowed in [IKECFG]). A protected exchange looks like this: Initiator Responder ----------- ----------- HDR*, HASH, ATTR(s) --> <-- HDR*, HASH, ATTR(s) 6.1 Attribute Payload A new payload is defined to carry attributes as well as the type of transaction message. It is assigned the value 228 from the Isakmp private range. 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! RESERVED ! Identifier ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Attributes ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attributes 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 RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, the transaction- specific header and all attributes. o Attribute Action Type (1 octet) - Specifies the protocol action to which the attributes refer (REQUEST/REPLY/SET/ACK). o RESERVED (1 octet) - Unused, set to 0. IPsec Working Group [Page 7] Internet Draft Attribute Exchange Mode July 14, 2000 o Transaction Identifier (2 octets) - An identifier used to reference an overall transaction within the individual messages. o Attributes (variable length) - Zero or more ISAKMP Data Attributes as defined in [ISAKMP]. 6.2 The HASH Payload The HASH is calculated according to the recommendations in [REVISED- HASH]. HASH = prf(SKEYID_a, PAYLOAD_FRAG_1 | HASH_0 | PAYLOAD_FRAG_2) Where: PAYLOAD_FRAG_1 is the set of ISAKMP payloads that precede the HASH. HASH_0 is a HASH payload with an empty hash (all 0s). PAYLOAD_FRAG_2 is the set of ISAKMP payloads that follow the HASH. In the typical case: PAYLOAD_FRAG_1 = HDR HASH_0 = Payload Header | sizeof(HASH) bytes of 0 PAYLOAD_FRAG_1 = ATTR(s) 6.3 Attribute Action Types These values are to be used within the Type field of an Isakmp Attribute payload. Types Value ========================== =========== RESERVED 0 ISAKMP_CFG_REQUEST 1 ISAKMP_CFG_REPLY 2 ISAKMP_CFG_SET 3 ISAKMP_CFG_ACK 4 Reserved for Future Use 5-127 Reserved for Private Use 128-255 Messages with unknown types SHOULD be silently discarded. 6.4 Attribute Values The following attribute ranges are currently allocated: IPsec Working Group [Page 8] Internet Draft Attribute Exchange Mode July 14, 2000 Attribute Range ============================================ ===================== RESERVED 0 Reserved for backwards compatibility 1-14 Reserved to IPsec WG 15-1024 Reserved to IPSRA WG 1024-1535 Reserved to IPSP WG 1536-2047 Reserved for future use 2048-16383 Reserved for private use 16384-32767 In cases where a range of attributes is assigned to a specific IETF working group, the description of those attributes may be specified by a DOI-style document specific to that WG. 7. Implementation Hints The Attribute Exchange protocol comes with no guarantee of merchantability, and no implied condition of fitness for any particular purpose. However, protocol designers who wish to use the Attribute Exchange mode to exchange session information should keep the following in mind: Attribute Exchange mode is backwards compatible with Isakmp-Config. If two hosts implement a protocol which uses Isakmp-Config and they both also implement the Attribute Exchange protocol (and send the appropriate vendor id) then they may use the Attribute Exchange mode in lieu of the Isakmp-Config Transaction mode. Multiple Attribute payloads may be included in a single packet in order to pipeline multiple unrelated exchanges. There is no implication that the payloads are correlated in any way. If a protocol requires an Attribute Exchange transaction that spans more than two messages, it may mandate than the transaction id in the Attribute payload be preserved across multiple exchanges. Some attributes may be sufficiently generic that they could be used by multiple negotiation protocols. A negotiation protocol SHOULD require that the first attribute in the payload be unique to that protocol. In many cases, the exchange of vendor ids only indicates that the peers are CAPABLE of using a certain protocol. If the protocol can be enabled on a case-by-case basis then an Attribute Exchange may be used to do this. IPsec Working Group [Page 9] Internet Draft Attribute Exchange Mode July 14, 2000 8. Use of Values from the Private Range This memo describes a protocol that is still in the experimental stages. As such, all protocol-specific constants have been assigned from the private range. Use of these constants is enabled by the exchange of the following vendor id: Vendor Id = 0xE25FF48C52C49180 If and when this document is accepted by the IETF for incorporation into the set of IPsec standards, all or some of the following will occur: The Attribute Exchange mode and Attribute payload type will be assigned a permanent value by the IANA. The vendor id will no longer be needed. 9. Security Considerations This document is a product of the IPsec working group; hence security considerations permeate this specification. Since attribute exchange transactions are two messages long, no explicit protection against replay attacks is provided. This is also a limitation of [IKE] in general. Protocols which require protection against replay may add this in one of the usual ways. 10. References [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998 [IKECFG]R. Pereira, "The ISAKMP Configuration Method", draft-ietf- ipsec-isakmp-cfg-05 (EXPIRED) [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998 [REVISED-HASH] T. Kivinen, "Fixing IKE Phase 1 Authentication HASH", draft-ietf-ipsec-ike-hash-revised-01.txt (WORK IN PROGRESS) IPsec Working Group [Page 10] Internet Draft Attribute Exchange Mode July 14, 2000 Authors' Addresses Andrew Krywaniuk Alcatel Networks Corporation 600 March Rd. Kanata, ON Canada, K2K 2P5 +1 (613) 599-3610 x4237 E-mail: andrew.krywaniuk@alcatel.com The IPsec working group can be contacted via the IPsec working group's mailing list (ipsec@lists.tislabs.com) or through its chair: Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology Expiration This document expires January 14, 2001. IPsec Working Group [Page 11]