Network Working Group D. Zhang Internet-Draft Huaweisymantec, Inc. Intended status: Standards Track February 27, 2009 Expires: August 31, 2009 Negotiating IPv6 Encapsulating Security Payload (ESP) Security Association (SA) with Cryptographically Generated Addresses (CGA) draft-dong-esp-sa-cga-00.txt Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. This Internet-Draft will expire on August 31, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang Expires August 31, 2009 [Page 1] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo specifies a new approach of Encapsulating Security Payload (ESP) Security Association (SA) negotiation. Because of the existing of the Cryptographically Generated Addresses (CGA) extension header and the key pair in CGA, it is convenient and feasible to negotiate ESP SA under the protection of key pair. Zhang Expires August 31, 2009 [Page 2] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scenarios and Premises . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Echanges . . . . . . . . . . . . . . . . . . . . . . . 5 5. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Message ID . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Cryptographic Algorithm Negotiation . . . . . . . . . . . 6 5.3. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Diffie-Hellman Exchange . . . . . . . . . . . . . . . . . 7 5.5. Certificate Distribution . . . . . . . . . . . . . . . . . 7 5.6. Generating Keying Material . . . . . . . . . . . . . . . . 7 5.7. About SP . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.8. About SA . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.9. Retransmissions . . . . . . . . . . . . . . . . . . . . . 9 6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 11 6.4. DH Payload . . . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 14 6.6. CGA Params and CGA Sig . . . . . . . . . . . . . . . . . . 14 7. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Processing Outgoing Message I . . . . . . . . . . . . . . 15 7.2. Processing Incoming Message I . . . . . . . . . . . . . . 15 7.3. Processing Incoming Message R . . . . . . . . . . . . . . 16 7.4. Creating SA . . . . . . . . . . . . . . . . . . . . . . . 17 7.5. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 17 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 Zhang Expires August 31, 2009 [Page 3] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 1. Introduction The purpose of this memo is to describe an application of CGA extension header in SA negotiation. The proposed approach here is based on CGA Extension Header of IPv6 [I-D. draft-dong-savi-cga-header]. Because of the public and private key pair existed in CGA [RFC3972], it can provide protections of source authentication and integrity authentication for packets. It happens that the impacts of the public and private key pair could replace some functions of the initial exchanges in IKEv2 [RFC4306]. Thus, the advantages of the public and private key pair are used in SA negotiation, which is quite suitable. This memo states a method of SA negotiation, called CGA-SA. Especially, the process of ESP SA negotiation is thoroughly introduced in detail. In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119]. 2. Scenarios and Premises CGA-SA MAY be used in all the scenarios where IKE is available. The usage scenarios of IKE are stated in [RFC4306]. Whereas this memo just illustrates a special case of CGA-SA usage. CGA-SA is used to negotiate the ESP SA between two nodes supporting CGA extension header. Here we suppose the mode of IPsec is tunnel. What the tunnel protects MAY be either endpoint or subnet. +-+-+-+-+-+ +-+-+-+-+-+ ! ! IPsec tunnel ! ! !Protected! mode (ESP) SA !Protected! !Endpoint !<-------------------------------->!Endpoint ! ! ! ! ! +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ IPsec +-+-+-+-+-+ ! ! tunnel mode ! ! Protected ! Tunnel ! (ESP) SA !Tunnel ! Protected Subnet <-->!Endpoint !<------------->!Endpoint !<--> Subnet ! ! ! ! +-+-+-+-+-+ +-+-+-+-+-+ Zhang Expires August 31, 2009 [Page 4] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 3. Terminology The following list terms are specific to this memo. CGA: Cryptographically Generated Address. A technique [RFC3972] whereby the IPv6 address of a node is cryptographically generated by using a one-way hash function from the node's public key and some other parameters. CGA extension header: a new IPv6 extension header. It contains three options: CGA Request, CGA Params and CGA Signature [I-D. draft-dong-savi-cga-header]. CGA Params: a type data of the options carries CGA parameters according to which the node validates the source address. Sending CGA Params, must be accompanied with CGA Signature. CGA Sig: short for CGA Signature. a type data of the options is responsible for carrying the signature. The other of terms used in this memo are borrowed almost as is from [RFC2409] and [RFC4306]. 4. Message Echanges In the following descriptions, the payloads contained as the new options in CGA extension header of IPv6 are indicated by names as listed below. Notation Payload -------------- ----------------------- ESP_INFO ESP_INFO parameter ESP_TRANSFORM ESP_TRANSFORM parameter Ni,Nr Nonce DHi,DHr Diffie-Hellman value CERT Certificate An ESP SA negotiation between nodes using CGA extension header consists of two messages passed between the nodes. The typical exchange is as follows: Message I: Initiator Responder ----------- ----------- ESP_INFO,ESP_TRANSFORM, --> Ni,DHi,[CERT],CGA Params, CGA Sig Zhang Expires August 31, 2009 [Page 5] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 The ESP_INFO parameter is used to transmit the SPI value and the Message ID, which can identify the message (or packet), between the nodes. The ESP_TRANSFORM parameter is used during ESP SA establishment. The initiator sends a selection of transform families in the ESP_TRANSFORM parameter. Ni is the initiator's nonce. The DHi payload sends the initiator's Diffie-Hellman value. The CERT states the initiator's certificate, which is optional and reserved for future use. The CGA Params carries the initiator's CGA parameters, and the CGA Sig carries the signature, signed by the initiator's private key. Message R: Initiator Responder ----------- ----------- <-- ESP_INFO,ESP_TRANSFORM, Nr,DHr, [CERT],CGA Params, CGA Sig The ESP_INFO parameter transmits the SPI value and the Message ID. The ESP_TRANSFORM parameter is used during ESP SA establishment. The responder MUST select one of the proposed values from the ESP_TRANSFORM of the initiator and include it in the response ESP_TRANSFORM parameter. Nr is the responder's nonce. The DHr payload sends the responder's Diffie-Hellman value. Once the CERT is found in Message I received, the responder MUST put the CERT of its own in Message R. Although the CGA Params and the CGA Sig have the same usage as in Message I, they carry the responder's parameters. 5. Details 5.1. Message ID Every CGA-SA message contains a Message ID. Message ID is used to control retransmission of lost packets and matching of requests and responses. It is essential to the security of the protocol because it is used to prevent message replay attacks. The details of this Message ID can be found in [RFC4306]. 5.2. Cryptographic Algorithm Negotiation As what it is said at the beginning of this memo, here only ESP SA negotiation is discussed. Cryptographic Algorithms, of course, are associated with ESP protocol. The initiator sends a set of choices of cryptographic suits. The responder MUST accept a single proposal or reject them all and return a Notify packet. If an ESP proposal includes five transforms AES- Zhang Expires August 31, 2009 [Page 6] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 CBC, 3DES-CBC, BLOWFISH-CBC, HMAC-SHA1 and HMAC-MD5, thus six combinations are acceptable. 5.3. Nonces In the negotiation of ESP SA, both messages contain a nonce. These nonces are used as inputs to cryptographic functions. Nonces used here MUST be randomly chosen, which are used to add freshness to the key derivation technique. 5.4. Diffie-Hellman Exchange An ephemeral DH exchange is responsible for generating keying material. CGA-SA implementations require that the initiator SHOULD send all DH MODP groups supported in the exchange message in which it MUST contain 768-bit MODP Group and 1024-bit MODP Group [RFC3526]. In this case, the problem of no available DH group between the two nodes can be eliminated. Once the DH exchange has been done, both of the two nodes compute the keying material from the DH public value. 5.5. Certificate Distribution This document does not define how to use certificates or how to transfer them between hosts. These functions are expected to be defined in a future specification. A parameter, CERT, means to be used for carrying certificates, is reserved. 5.6. Generating Keying Material In CGA-SA, a pseudo-random function (prf) is negotiated as well. The pseudo-random function is used for the construction of keying material. In this memo, prf uses Hashed Message Authentication Code (HMAC) [RFC2104]. Which type of the algorithm, HMAC-SHA1 or HMAC- MD5, is chose according to the cryptographic suits in the ESP_TRONSFORM. We assume that each encryption algorithm and integrity protection algorithm uses a fixed-size key and that any randomly chosen value of that fixed size can serve as an appropriate key [RFC4306]. When the key for the pseudo-random function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula. Keying material will always be derived as the output of the negotiated prf algorithm. Since the amount of keying material needed may be greater than the size of the output of the prf algorithm, we will use the prf iteratively. The expressions are showed as follows: Zhang Expires August 31, 2009 [Page 7] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 T1 = prf (K, S) T2 = prf (K, T1) T3 = prf (K, T2) T4 = prf (K, T3) The expressions above can use the terminology prf+ to describe the function where | indicates concatenation. prf+ (K,S) = T1 | T2 | T3 | T4 | ... When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary. The shared key is computed as follows. From the nonces and DH values exchanged, a quantity called SKEYSEED is calculated. SKEYSEED is used to calculate the secret: SK_d. SKEYSEED and the secret are computed as follows: SKEYSEED = prf (Ni | Nr,g^ir) {SK_d} = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. Ni and Nr are the nonces. SPIi and SPIr are the SPI of the initiator and the responder respectively. Keying material for ESP SA is generated as follows: KEYMAT = prf+(SK_d, Ni | Nr) And the production way of keying material are described as [RFC4306]. 5.7. About SP The protection type of each packet is defined by a Security Policy Database (SPD). Actually, Security Policy (SP) is corresponding to an entry in SPD. How to use and manage SPD can be found in [RFC2401]. 5.8. About SA The usage of SA is the same as [RFC2401]. However, there is something special. Since the simplicity of SA negotiation defined in this memo, it May not need special ways to rekeying and update SA. When a pair of nodes rekeying their SA, it is suggested that any party SHOULD send a Notify packet so as to inform its peer to re- negotiate. Zhang Expires August 31, 2009 [Page 8] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 5.9. Retransmissions The mobile node is responsible for retransmissions. The CGA-SA negotiation messages exist in pairs: a Message I and a Message R. The initiator MUST record the Message ID of each Message I and the retransmitted Message I MUST including the same Message ID. Whenever timeout, the initiator have not received corresponding Message R, then it MUST retransmit the Message I. A same request SHOULD NOT be retransmitted more than three times. Once the initiator receives the first Message R, it will ignore the rest responds to the same Message I. The responder sends the Message R only when a new request coming according to the Message ID, whatever the request is either first time received or the retransmitted ones. 6. Payload Formats In this section, new payloads and parameters are presented. All of the payloads adopt the TLV format. The length of the packet, which is multiple of 8 octets, is convenient for handling in the implement. To meet this requirement, it SHOULD use padding when necessary. 6.1. ESP_INFO During the initial ESP SA negotiation, the host sends the SPI value that it wants the peer to use when sending ESP data to it. The format of ESP_INFO is described as follows: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type | Length | Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for ESP_INFO. The value is TBD1. Length 8-bit unsigned integer. The length of all the options (including the Type, Length, Pad Length, Reserved, SPI and Message ID) in units of byte. Reserved An 16-bit field reserved for future use. The value MUST be initialized to zero. SPI SPI for data sent to address(es) associated with this SA. Message ID 32-bit unsigned integer. A notation of the packet. Zhang Expires August 31, 2009 [Page 9] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 6.2. ESP_TRANSFORM The ESP_TRANSFORM parameter is used during ESP SA establishment. The first party sends a selection of transform families in the ESP_TRANSFORM parameter, and the peer MUST select one of the proposed values and include it in the response ESP_TRANSFORM parameter. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type | Length | Pad Length | Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Suite ID #1 | Suite ID #2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Suite ID #n | padding ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for ESP_TRANSFORM. The value is TBD2. Length 8-bit unsigned integer. The length of all the fields in units of byte. Pad Length 8-bit unsigned integer. The number of padding octets beyond the end of the ESP_TRANSFORM field but within the length specified by the Length field in byte. Padding octets MUST be set to zero by senders and ignored by receivers. Reserved An 8-bit field reserved for future use. The value MUST be initialized to zero. Suite ID # Defines the ESP Suite to be used. Padding A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. The contents of padding MUST be zero. The following Suite IDs are defined in [RFC5201]: Suite ID Value --------------------------- ------ RESERVED 0 AES-CBC with HMAC-SHA1 1 3DES-CBC with HMAC-SHA1 2 3DES-CBC with HMAC-MD5 3 BLOWFISH-CBC with HMAC-SHA1 4 NULL with HMAC-SHA1 5 NULL with HMAC-MD5 6 Zhang Expires August 31, 2009 [Page 10] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 6.3. Notify Payload Notify messages MUST use CGA and CGA signature validation as well. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type | Length | Pad Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Reserved | Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! / / Notification Data / / +-+-+-+-+-+-+--+ / | Padding ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for notify payload. The value is TBD3. Length 16-bit unsigned integer. The length of all the fields in units of byte. Pad Length 8-bit unsigned integer. The number of padding octets beyond the end of the notify payload field but within the length specified by the Length field in byte. Padding octets MUST be set to zero by senders and ignored by receivers. Reserved An 16-bit field reserved for future use. The value MUST be initialized to zero. Notify Message 16-bit unsigned integer. Specifies the type of Type notification. Notification Variable length. Informational or error data Data transmitted in addition to the Notify Message Type. Values for this field are type specific (see below). Padding A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. The contents of padding MUST be zero. Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process. To avoid certain types of DoS attacks, a responder SHOULD avoid sending a NOTIFICATION to any host with which it has not successfully verified CGA and CGA signature. An implementation that receives a NOTIFY packet with a NOTIFICATION error parameter in response to a request packet SHOULD assume that the corresponding request has failed entirely. Unrecognized error Zhang Expires August 31, 2009 [Page 11] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 types MUST be ignored except that they SHOULD be logged [RFC5201]. The table below lists the NOTIFY messages and their corresponding values. NOTIFICATION PARAMETER - ERROR TYPES Value ------------------------------------ ----- RESERVED 0 INVALID_SYNTAX 7 Indicates that the HIP message received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. NO_DH_PROPOSAL_CHOSEN TBD None of the proposed group IDs was acceptable. INVALID_DH_CHOSEN TBD The DH Group ID field does not correspond to one offered by the responder. NO_PROPOSAL_CHOSEN 14 None of the proposed cryptographic suits was acceptable. INVALID_TRANSFORM_CHOSEN TBD The cryptographic suit does not correspond to anyone offered by the responder. INVALID_CERT TBD The certificate obtained from the peer of the host is invalid. NOTIFY MESSAGES - STATUS TYPES Value ------------------------------ ----- REKEY_SA TBD If a host wants to update the ESP SA, it MAY use this type notification. 6.4. DH Payload The format of DH payload is showed below: Zhang Expires August 31, 2009 [Page 12] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type | Length | Pad Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DH Group #1 | Public Value Length | Public Value / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DH Group #2 | Public Value Length | Public Value / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DH Group #n | Public Value Length | Public Value / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for DH payload. The value is TBD4. Length 16-bit unsigned integer. The length of all the fields in units of byte. Pad Length 8-bit unsigned integer. The number of padding octets beyond the end of the nonce payload field but within the length specified by the Length field in byte. Padding octets MUST be set to zero by senders and ignored by receivers. Public Value Length of the following Public Value in octets Length DH Group# Notation of DH group, 8-bit unsigned integer. Public Value DH public value, variable-length. Padding A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. The contents of padding MUST be zero. Except the four groups defined in IKE [RFC2409], numbered one through four, additional DH groups are also included [RFC3526]: Group Modulus ------ -------- 5 1536-bit 14 2048-bit 15 3072-bit 16 4096-bit 17 6144-bit 18 8192-bit Zhang Expires August 31, 2009 [Page 13] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 6.5. Nonce Payload The Nonce Payload denoted Ni and Nr in this memo for the initiator's and responder's nonce respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type | Length | Pad Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Reserved | / +-+-+-+-+-+-+-+-+ Nonce Data / / +-+-+-+-+-+-+-+-+ / | Padding ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for Nonce payload. The value is TBD5. Length 16-bit unsigned integer. The length of all the fields in units of byte. Pad Length 8-bit unsigned integer. The number of padding octets beyond the end of the nonce payload field but within the length specified by the Length field in byte. Padding octets MUST be set to zero by senders and ignored by receivers. Reserved An 8-bit field reserved for future use. The value MUST be initialized to zero. Nonce data Variable length. Contains the random data generated by the transmitting hosts. Padding A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. The contents ofpadding MUST be zero. The size of a nonce MUST be between 16 and 256 octets inclusive. Nonce values MUST NOT be reused. Ni and Nr stand for the initiator's and the responder's nonce respectively. 6.6. CGA Params and CGA Sig These two types of parameters are described in detail in [I-D. draft-dong-savi-cga-header]. 7. Packet Processing Zhang Expires August 31, 2009 [Page 14] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 7.1. Processing Outgoing Message I Before sending a Message I, the node MUST confirm whether it already has SA between it and its peer. 1. There is none SA relevant in SAD. Send Message I. 2. The SA relevant has already existed in SAD. The node does not initialize negotiation, not sending the Message I. 7.2. Processing Incoming Message I When the node receives a Message I, it handles the packet as the steps below. 1. CGA validation [I-D. draft-dong-savi-cga-header] * Succeed, go to the next step. * Fail, the host MUST drop the packet, which leads to the generation of an ICMP message. 2. CGA signature validation [I-D. draft-dong-savi-cga-header] * Succeed, go to the next step. * Fail, the host MUST drop the packet, which leads to the generation of an ICMP message 3. Message ID validation. * When the Message ID in the packet is larger than that, which was used in the last time of SA negotiation, go to the next step. * If the Message ID is smaller, drop the packet and send none message to notify the error. 4. Whether the node has already sent a Message I to the same peer that MUST be checked. * The node has not sent a Message I, go to the next step. * If the node did, then it MUST compare the nonce coming from its peer with that it sent before. When the nonce received is larger, the node sends the Message R to its peer. Otherwise, the node drops the Message I received and waits for the response from its peer. Zhang Expires August 31, 2009 [Page 15] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 5. Check the cryptographic suits in ESP_TRANSFORM. * When there are cryptographic algorithms available in the cryptographic suits, the node chooses one from them and put it in the Message R to be sent at the same time. * If none of the cryptographic algorithms transported from the initiator of the negotiation is supported by the node, Message I MUST be dropped, which results in sending a NOTIFY message of NO_PROPOSAL_CHOSEN. 6. Check the DH payload. * Because this memo has defined that the node MUST support at least two DH groups in section 5.4, of course, one group can be chose in Message I. Then the node uses the DH shared secrets and nonces of both the peer and its own to generate the shared key for ESP SA. Probably the node would not like to build an ESP SA up, so it does not have to deal with the packet. This makes sense to prevent DoS attack. The node SHOULD constrict the frequency of sending Message I from a same source address. It SHOULD ignore the repeated Message I. The response, Message R, do not depend on upper layer protocols. 7.3. Processing Incoming Message R After a node receives a Message R, some steps MUST be complied with. 1. CGA validation [I-D. draft-dong-savi-cga-header] * Succeed, go to the next step. * Fail, the host MUST drop the packet, which leads to the generation of an ICMP message. 2. CGA signature validation [I-D. draft-dong-savi-cga-header] * Succeed, go to the next step. * Fail, the host MUST drop the packet, which leads to the generation of an ICMP message 3. Message ID validation. * The node compares the Message ID in the Message R with that it sent in Message I before. If the Message IDs are the same, go to the next step. Zhang Expires August 31, 2009 [Page 16] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 * Otherwise, drop the packet and send none message to notify the error. 4. Check the cryptographic suits in ESP_TRANSFORM. * After the node finds a cryptographic suit, which was provided in Message I by itself before, this cryptographic suit is used as the encryption algorithm and the integrity protection algorithm. * If the cryptographic suit received is not provided in Message I, the node MUST drop the packet. And this behavior leads the generation of sending INVALID_TRANSFORM_CHOSEN notification. 5. Get the DH shared secret and the nonce in Message R. Then the node uses the DH shared secrets and nonces of both the peer and its own to generate the shared key for ESP SA. Since the node as the initiator of the negotiation probably has sent several Message I, thus it may received a few responses in a period. In order to cope with this case, the node just needs to handle the packet first come and drop the others. 7.4. Creating SA After sending the response, the responder creates the SA record in SAD. Similarly, the initiator is capable of doing the same thing when it receives the Message R. Then the ESP SA is built up. According to SP, the two nodes can use the SA to protect the communication between them. 7.5. Processing NOTIFY Packets Processing NOTIFY packets is OPTIONAL. If processed, any errors in a received NOTIFICATION parameter SHOULD be logged. Received errors MUST be considered only as informational. 8. Error Handling There are many kinds of errors that can occur during negotiation processing. If a request is received that is badly formatted or unacceptable for reasons of policy (e.g. no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. Some error types are pointed out in Section 6.3. Zhang Expires August 31, 2009 [Page 17] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 9. Security Considerations This document shows a way to establish an ESP SA between two nodes. The reason why the negotiation can be completed by two messages exchange is that the two nodes have already protected by CGA extension header. The Security Considerations for CGA extension header are discussed in [I-D. draft-dong-savi-cga-header]. In CGA-SA, for CGA validation and CGA signature existence, the base exchange and NOTIFY messages cannot be forged, which avoid many threats. Besides, the Message ID is able to defend partial types of anti-replay attacks. Other security problems may need further discussion. 10. IANA Considerations This document specifies several new types of payloads: Payload Type value ----------------- ----------- ESP_INFO TBD1 ESP_TRANSFORM TBD2 Notify TBD3 DH TBD4 Nonce TBD5 The new NOTIFY error types and their values are defined: Error type Value -------------------------- -------- NO_DH_PROPOSAL_CHOSEN TBD INVALID_DH_CHOSEN TBD INVALID_TRANSFORM_CHOSEN TBD INVALID_CERT TBD REKEY_SA TBD 11. Acknowledgements 12. References 12.1. Normative References [I-D. draft-dong-savi-cga-header] Zhang, D., "CGA Extension Header of IPv6", October 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Zhang Expires August 31, 2009 [Page 18] Internet-Draft Negotiating IPv6 ESP SA with CGA February 2009 [RFC2401] Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2409] Harkins, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5201] Moskowitz, R., "Host Identity Protocol", RFC 5201, April 2008. 12.2. Informative References [RFC2104] Krawczyk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC3526] Kivinen, T., "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. Author's Address Dong Zhang Huaweisymantec, Inc. Building 17, ZhongGuanCun Software Park, No.8 Dongbeiwang West Road Beijing, HaiDian district China Phone: 86-10-82829263 EMail: zhangdong_rh@huaweisymantec.com Zhang Expires August 31, 2009 [Page 19]