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]