dhc Ma Internet-Draft CNNIC Intended status: Informational October 13, 2010 Expires: April 16, 2011 Extended DHCPv6 for Piggybacking Security Association Configuration draft-madi-dhc-dhcpv6-psac-00 Abstract IPSec [RFC2401]is pervasive in many scenarios to build the channel of security mechanism to protect the communication between the host and the local servers, such as DNS recursive name server [RFC1304]. In the public wireless access environment, an extra trust relationship configuration between the roaming host and the local server, manually or by IKE [RFC2409], is indispensible. DHCP is typically the first protocol executed by a mobile host when it enters a new network, so this document present an extension to DHCPv6 to piggyback the parameters needed for IPSec, avoiding the delay invited by manual configuration of security association or IKE interaction for IPSec. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 16, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Ma Expires April 16, 2011 [Page 1] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. Ma Expires April 16, 2011 [Page 2] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements and Considerations . . . . . . . . . . . . . . . 5 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5 5. Extended DHCPv6 Operation . . . . . . . . . . . . . . . . . . 6 5.1. Message and Option Definitions . . . . . . . . . . . . . . 6 5.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. Options . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 12 5.1.4. Transmission and Retransmission Parameters . . . . . . 13 5.2. Message Validation . . . . . . . . . . . . . . . . . . . . 13 5.2.1. SOLICIT . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. SACONFIGURATION . . . . . . . . . . . . . . . . . . . 14 5.2.3. SACONFIGURATION-REPLY . . . . . . . . . . . . . . . . 14 5.3. DHCP Server Solicitation . . . . . . . . . . . . . . . . . 14 5.4. SACONFIGURATION Behavior of DHCP Server . . . . . . . . . 15 5.4.1. Creation of SACONFIGURATION . . . . . . . . . . . . . 15 5.4.2. Transmission of SACONFIGURATION . . . . . . . . . . . 16 5.4.3. Receipt of SACONFIGURATION-REPLY . . . . . . . . . . . 16 5.5. Target Server Behavior . . . . . . . . . . . . . . . . . . 16 5.5.1. Receipt of SACONFIGURATION Messages . . . . . . . . . 17 5.5.2. Transmission of SACONFIGURATION-REPLY Messages . . . . 17 5.6. The extension brings to the DHCP exchange . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Ma Expires April 16, 2011 [Page 3] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 1. Introduction There are an increasing number of mobile hosts who, roaming across different access domains, want to resort to the shared key based method to gain secrecy and integrity of the data exchange with the local server of the access network, the communication between the DNS stub resolver and the local DNS recursive name sever as an example. IPSec, for instance, is pervasive in many scenarios to build the channel of security mechanism. And IPSec architecture has a security policy database that specifies which traffic is protected and how, which could be established with a manual configuration of security associations or with IKE [RFC5996]. As for the mobile host, its security association with the local server is usually established by IKE, which leads to an extra interaction delay. Even the delay MAY not be taken into consideration, IKE is not necessarily not be supported everywhere. DHCP allows a computer to be configured automatically, eliminating the need for intervention by a network administrator. For IPv4, DHCPv4 is typically the first protocol executed by a mobile host when it enters a new network. Even in the era of IPv6, according to the point of view of Ralph, DHCP service is typically provided by a centralized service composed of fewer managed components [21], so DHCP server misconfiguration is less likely than delivery of misconfigured Route Advertisements. Since DHCP also takes the responsibility in configuring the IP address of the local server, the security association information between the host and the specific local server, such as SIP server and DNS recursive name server, could be piggybacked via DHCP messages, avoiding the delay invited by manual configuration of security association or IKE interaction for IPSec. This document describes the extension to DHCP to integrate security association construction course into the DHCP interaction to build the trust relationship between the roaming host and the specific local server of the access network. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. DHCPv6 terminology is defined in [RFC3315]. Terminology specific to the extension of DHCPv6 can be found below: Throughout this document, "DHCP" refers to DHCP for IPv6. DHCP terminology is defined in [RFC3315] and IPSec terminology is defined Ma Expires April 16, 2011 [Page 4] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 in [RFC2401]. Terminology specific to the extension of DHCP can be found below: SA - SA is short for Security Association and defined in IPSec specification [RFC2401]. SPI - SPI is short for Security Parameter Index and defined in IPSec specification [RFC2401]. target server - A local server of the access network, DNS recursive name server for instance, which is to be configured the security association with a specific host, by DHCP. The target server works as a DHCP client listening for DHCP messages on UDP port 546. requestor - A host that wants to establish security association with a specific local server. The requestor works as a DHCP client requesting the configuration parameters for security association. SA binding - SA binding is employed by DHCP server to manage the SA information which is indexed by the tuple [requestor's DUID, target server's DUID, SPI]. 3. Requirements and Considerations Although DHCP is being challenged by the SLAAC [RFC4862], yet this document is intended to take the position that DHCP is indispensible and necessary to the network administrative need. DHCP server and the target server are usually deployed within one same organization and public key schemes are not necessary, trust relationship based on preshared secret could be established between them by administrator's manual configuration to gain secrecy and integrity. Accordingly, the extension in this document takes the position that DHCP service is indispensible and there is secured channel between DHCP server and the target server. To realize the very function of the extended DHCP, the host in question MUST have the ability to generate asymmetric key pair, the public key of which is used to encrypt the symmetric key to be shared with the target server. The extension of DHCPv6 SHOULD go with stateful service DHCPv6 provides. 4. Design Overview The focus of this document is to extend DHCP to piggyback SA information for the entities that want to employ IPSec, providing a Ma Expires April 16, 2011 [Page 5] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 quick configuration for security parameters. It is especially appropriate for processes and devices that already interpret DHCP messages. With the extended DHCP, the host especially the roaming host is able to build trust relationship with the target server, the service from which is desired to be provided in a security channel. Accordingly, the host called requestor in this document is on the initiative in the course of the SA establishment in SOLICIT message. The DHCP server configured to take the responsibility responds. The requestor SHOULD also present its public key to DHCP server for encrypting the symmetric key as an element of SA, and the DHCP server MUST provide the symmetric key in cipher text together with other parameters of the very SA. If selected by REQUEST message, the DHCP server will determine which target server will be configured with SA parameters according to the SA establishment request indicated by the requestor in a new defined option. Then the DHCP server sends message to convey the SA to the selected target server and waiting REPLY message to make sure whether the SA parameters have been configured successfully or not. To guarantee the confidentiality of the symmetric key, the access key SHOULD be encrypted by pre-shared key. Once the DHCP server gets the confirmation of SA configuration from the intended target server, it responds to requestor in REPLY message that includes SA parameter shared between the requestor and the target server whose service is wanted to be secured by the requestor. If needed, the DHCP serve MAY choose to update a current SA by sending RECONFIG-INIT message to the requestor. 5. Extended DHCPv6 Operation 5.1. Message and Option Definitions 5.1.1. Messages Extended DHCP for Security Association Configuration specified in this document uses the Client/Server message formats described in [RFC3315], Section 6. Two new message codes are defined: SACONFIGURATION (TDB by IANA)) - A DHCP server sends a SACONFIGURATION message to a target server to configure the SA parameters that are indicated in an option called OPTION_SA. SACONFIGURATION-REPLY (TDB by IANA) - A target server sends a REGISTRATION-REPLY message to a DHCP server the SA from which has Ma Expires April 16, 2011 [Page 6] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 been configured successfully. 5.1.2. Options 5.1.2.1. Client Public Key Option The Client Public Key Option is used to specify the public key associated with the client that sends the option. The Client Public Key Option SHOULD be bound to the DUID of the client. The format of the Client Public Key Option is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION CPK | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | reserved | key-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ public key (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_CPK (TDB by IANA). option-len 4 + length of public key field. algorithm the algorithm used to perform the encryption of the shared key.The algorithm are: RSA(1), defined in [RFC3447]. key-len length of the public key. public key This is a variable-length field containing the public key of the DHCP client. 5.1.2.2. Requestor's Parameters Option The Requestor's Parameters Option is used to specify the security parameter provided by the requestor, with which the SA will be established. The Requestor's Parameters Option must be encapsulated in the Options field of an SA Request Option. The format of the Requestor's Parameters is: Ma Expires April 16, 2011 [Page 7] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION RP | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | requested-service-code | pro | tra | algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | requestor's IP address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_RP (TDB by IANA). option-len 20. requested-service-code To indicate which service is wanted to be secured according to the requestor. The requested-service-code is consistent with the option-code which means if the host wants to use IPSec with a DNS recursive name server, it set the requested-service-code as the option-code for the addresses of DNS recursive name servers. pro To specify the security protocol IPSec employ. AH(1). ESP(2). tra To specify which traffic, INBOUND or OUTBOUND will be processed from the point of view of the requestor. INBOUND(1), traffic from the target server to the requestor. OUTBOUND(2), traffic from the requestor to the target server. Two-Way(3), all traffic between the requestor and the target server. algorithm The algorithm employed by IPSec: HMAC-MD5-96(1), defined in [RFC2403] Ma Expires April 16, 2011 [Page 8] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 HMAC-SHA1-96(2), defined in [RFC2404] DES(3), defined in [RFC1829] 3DES(4), defined in [RFC1851] DES-CBC(5), defined in [RFC2405] AES(6), defined in [RFC3686] requestor's IP address To indicate which address of the requestor will be involved in SA. If the address is of all-zero and the requestor's has one or more assigned address from the DHCP server, the DHCP server will select an involved address for the requestor. 5.1.2.3. SA Request Option The SA Request option is used to encapsulate SA Requestor's Parameters Option(s) to indicate which local service is required to be secured by the requestor and the related parameters. The format of the SA Request Option is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION SAR | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requestor's Parameters Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_SAR (TDB by IANA). option-len 20 * number of Requestor's Parameters Options. Requestor's Parameters Options Different Requestor's Parameters Options intended for target servers of different local services. 5.1.2.4. SA Option The SA Option is used to specify the SA parameters shared between the requestor and a specific target server. The format of the SA Option is: Ma Expires April 16, 2011 [Page 9] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION SA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | requestor's IP address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | target server's IP address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pro | tra | algorithm | esk-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ symmetric key (in cypher text, variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_SA (TDB by IANA). option-len 44 + length of symmetric key field. SPI Security Parameter Index created by the DHCP serverand defined in IPSec specification [RFC2401]. lifetime The valid lifetime for the SA, expressed in units of seconds. requestor's IP address A copy of the requestor's IP address field in the Requestor's Parameters Option included in SOLICIT message or REQUEST message. target server's IP address To indicate which address of the target server will be involved in SA. The addresses of a specific target server SHOULD be maintained by the DHCP server. pro A copy of the pro field of Requestor's Parameters Option included in SOLICIT message or REQUEST message. Ma Expires April 16, 2011 [Page 10] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 tra A copy of the tra field of Requestor's Parameters Option included in SOLICIT message or REQUEST message. algorithm A copy of the algorithm field of Requestor's Parameters Option included in SOLICIT message or REQUEST message. esk-len The length of the encrypted symmetric key. symmetric key The encryption of the key shared by the requestor and the target server to use IPSec. 5.1.2.5. SA List Option The SA List Option is used to contain one or more SA Options in response to the SA request indicated in the SA Request Option included in SOLICIT message from the requestor. In the SA List Option, the Requestor' parameters Option and the SA Option give the alterative appearances to indicate their correlation. The format of the SA List Option is: Ma Expires April 16, 2011 [Page 11] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION SAL | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requestor's Parameters Option | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA Option | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Requestor's Parameters Options and SA Options ~ | in alterative appearance | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_SAR (TDB by IANA). option-len 20 * number of Requestor's Parameters Options + the total length of all SA Options. Requestor's Parameters Option A copy of Requestor's Parameters Option of the SA Request Option included in SOLICIT message or REQUEST message. SA Option A SA Option in response to a specific Requestor's Parameters Option included in SOLICIT message or REQUEST message. 5.1.3. Status Codes Some status codes defined in [RFC5007] are redefined in the messages newly defined in this document, together with the new status codes, they are defined: NotConfigured (9) - The status code is originally defined in [RFC5007] and redefined with the massage defined in this document. The intended SACONFIGURATION-receiver is not configured to provide secured service based on IPSec. NotAllowed (10) - The status code is originally defined in [RFC5007] and redefined with the massage defined in this document. The sender of SACONFIGURATION is not the authorized DHCP server to configure SA for IPSec. The authentication of the DHCP server MAY be based on Authentication of DHCP Messages specified in Section 2.3.1 of [RFC3315]. InappropriateAddress (TBD) - The requestor's IP address in the Ma Expires April 16, 2011 [Page 12] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 Requestor's Parameters Option is not a authorised one for the requestor or the target server's IP addressis in the SA Option is not one of the valid IP address of the target server. UnsupportedAlgorithm (TBD) - The algorithm specified in the Requestor's Parameters Option is not supported by the target server whose service is wanted to be secured. MalformedSACONFIGURATION (TBD) - The SACONFIGURATION is not valid; for example, the required symmetric key field is missing from the SA Option. This status code is used only in SACONFIGURATION-REPLY message. FailedSACONFIGURATION (TBD) - The SACONFIGURATION interaction between the DHCP server and the target server is failed for some reasons. This status code is used only in REPLY message from DHCP server to the requestor. 5.1.4. Transmission and Retransmission Parameters This section presents a table of values used to describe the message transmission behavior for IP address registration. Parameter Default Description ------------ --------- ----------------------------------- SAC_TIMEOUT 1 sec Initial SACONFIGURATION timeout SAC_MAX_RT 10 secs Max SACONFIGURATION timeout value SAC_MAX_RC 5 Max SACONFIGURATION retry attempts 5.2. Message Validation The Message Validation specified in this document follow the basic message validation principles in [RFC3315], Section 15. Requestors, target servers and DHCP servers SHOULD discard any messages that contain options that are not allowed to appear in the received message. 5.2.1. SOLICIT Extended DHCP for Security Association Configuration with the Local Server in the Access Network mandates the confidentiality of the shared symmetric key. The requestor MUST include Client Public key Option for encrypting the shared symmetric key. DHCP Servers MUST discard any received SOLICIT messages that meet any of the following conditions: o the message does not include an OPTION_SERVERID option. Ma Expires April 16, 2011 [Page 13] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 5.2.2. SACONFIGURATION The target server MUST discard any received SACONFIGURATION messages that meet any of the following conditions: o the message does not include an OPTION_SERVERID option. o the message includes an OPTION_CLIENTID option but the contents of the OPTION CLIENTID option does not match the target server's identifier. o the message does not include a SA Option. DHCP servers, relay agents and the non-requestor DHCP clients MUST discard any received SACONFIGURATION messages. 5.2.3. SACONFIGURATION-REPLY The target server MUST discard any received SACONFIGURATION-REPLY messages that meet any of the following conditions: o the message does not include an OPTION_CLIENTID option. o the message includes an OPTION_SERVERID option but the contents of the OPTION_SERVERID option does not match the server's identifier. o the message does not include a SA Option. o the "transaction-id" field in the message does not match the value used in the original message. Target servers (on the DHCP server port, 546 [RFC3315]), relay agents and DHCP clients MUST discard any received SACONFIGURATION-REPLY messages. 5.3. DHCP Server Solicitation This section describes how the SA configuration with the target server in the access network will affect DHCP Server Solicitation specified in [RFC3315], Section 17. Once a host especially a mobile one intends to establish a SA with a local server in the access network to secure one certain service such as DNS recursive resolution service, it will include a SA Request Option together with the Client Public Key Option in its SOLICIT message. Once informed by SA Request Option included in the SOLICIT message, Ma Expires April 16, 2011 [Page 14] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 the DHCP server will decide whether to provide the service for SA establishment according to its policies configured by the administrator of the access network. If a DHCP server takes the responsibility in managing SA establishment for the requestor and the target server, it responds, via the ADVERTISE message, to the requestor it is able to find a proper IP address for IPSec as the requestor's agent. On receiving the ADVERTISE messages from several DHCP servers, the requestor selects one according to its local policies and then multicast the REQUEST message including the SA Request Option. Once the selected DHCP server gets the REQUEST message, it decides which IP address will be involved in the intended SA establishment according to the requested-service-code of the Requestor's Parameters Option in the SA Request Option. Then DHCP server initiates SACONFIGURATION exchange with the target server. Once the SACONFIGURATION has been confirmed from the intended target server, DHCP server sends Reply message to the requestor. The DHCP server use the SA binding to manage the SA parameters shared between the requestor and the target server. The SA binding is indexed by the tuple [requestor's DUID, target server's DUID, SPI]. The SACONFIGURATION mechanism is not compatible with Rapid-commit mode specified in [RFC3315], Section 17.1.1. 5.4. SACONFIGURATION Behavior of DHCP Server Once receiving a REQUEST message with SA Request Option, the DHCP server then initiates the SACONFIGURATION exchange with the target server. This section describes how DHCP Server initiates exchange with a specific target server in SACONFIGURATION. 5.4.1. Creation of SACONFIGURATION The DHCP server sets the "msg-type" field to SACONFIGURATION. The DHCP server generates a transaction ID and inserts this value in the "transaction-id" field. The DHCP server MUST include an OPTION_ SERVERID option to identify itself to the target server which works as a DHCP client. The DHCP server MUST include a SA Option specified in Section 5.1.2.4. Ma Expires April 16, 2011 [Page 15] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 5.4.2. Transmission of SACONFIGURATION According to the requested-service-code of the Requestor's Parameters Option in the SA Request Option included in the REQUEST message and the address list of one certain local service, the DHCP server is able to choose an IP address of a proper target server for the requestor to establish SA. The DHCP server transmits SACONFIGURATION messages according to Section 14 of [RFC3315], using the following parameters: IRT SAC_TIMEOUT MRT SAC_MAX_RT MRC SAC_MAX_RC MRD 0 If the message exchange fails, the DHCP server takes an action based on the local policy of the access network. Examples of actions the DHCP server might take include: o Inform the client of the failure with denying offering service. o Inform the client of the failure while assigning IP address as usual. 5.4.3. Receipt of SACONFIGURATION-REPLY A successful SACONFIGURATION-REPLY is one without an OPTION_STATUS_CODE option (or an OPTION_STATUS_CODE option with a success code). Then the DHCP server responds to the requestor in the REPLY message with SA List Option to indicate the SA to be established between the requestor and one certain target server. An unsuccessful SACONFIGURATION-REPLY is one that has an OPTION_STATUS_CODE with an error code. Depending on the status code, the DHCP server may try a different target server (such as for NotAllowed, and NotConfigured), try a different or corrected SACONFIGURATION request (such as for MalformedSACONFIGURATION and FailedRegistraion), or terminate the SACONFIGURATION request. 5.5. Target Server Behavior A Target Server sends SACONFIGURATION-REPLY messages in response to valid SACONFIGURATION messages it receives to inform the DHCP server that the information conveyed by the SA Option has been configured. Ma Expires April 16, 2011 [Page 16] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 5.5.1. Receipt of SACONFIGURATION Messages Upon receipt of a valid SACONFIGURATION message, the target server updates the SA database it maintains and returns a SACONFIGURATION- REPLY. No matter whether the SA establishment has been successfully built, the target server configures itself the SA. Once the lifetime of the SA index by SPI expires, the target server removes this SA. With SPI field of the SA Option, SAVP decides how to deal with the binding request described in SACONFIGURATION message: o If the SPI is new to the target server, the target server records the SA parameters included in the SACONFIGURATION message. o If the SPI has been maintained by the target server, the target server overwrites the SA parameters index by the SPI as an update. The target server constructs a SACONFIGURATION-REPLY message by setting the "msgtype" field to SACONFIGURATION-REPLY, and copying the transaction ID from the SACONFIGURATION message into the transaction-id field. If the SA intended to be configured is not a proper one, the target server adds the error status code according to Section 5.1.3 and sends the SACONFIGURATION-REPLY to the DHCP server. If the target server fails to configure SA for some unknown reasons, the target server MAY discard the SACONFIGURATION message or MAY add an OPTION_STATUS_CODE option with the FailedSACONFIGURATION status code and send the SACONFIGURATION-REPLY to the DHCP server. 5.5.2. Transmission of SACONFIGURATION-REPLY Messages The target server sends the SACONFIGURATION-REPLY message as described in the "Transmission of Reply Messages" section of [RFC3315]. 5.6. The extension brings to the DHCP exchange As in Section 5.1.2, some new defined options MUST be supported for the DHCP server solicitation. And on the receipt of REQUEST message containing the SA Request Option from the requestor, the DHCP server initiates the SA establishment exchange with the intended target server before it assigns IP address and other network parameters for the requestor. The IP address registration exchange happens every time the DHCP server updates the lease on IP address assigned, which means once the Ma Expires April 16, 2011 [Page 17] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 DHCP server is ready to reply to the RENEW or REBIND message, the IP address registration exchange takes places before sending the these very messages for DHCP client. 6. Security Considerations The original intention of the extension to DHCP for piggybacked SA configuration makes security consideration a necessity. As mentioned before, the symmetric key to be used for IPSec should be in a confidential form. By the virtue of the Client Public Key Option, the DHCP server is able to use client's public key to encrypt the symmetric key and included it in SA Option. As for the very symmetric key transmission between the DHCP server and the target server, administrator MAY choose to make a key pre-shared between the DHCP server and the target server, or MAY employ the public key scheme for the encryption of the symmetric key shared between the DHCP server and the target server. 7. IANA Considerations IANA is requested to assign the following new DHCPv6 Message types in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters: SACONFIGURATION SACONFIGURATION-REPLY IANA is requested to assign the following new DHCPv6 Option Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters: OPTION_OPTION CPK OPTION_OPTION RP OPTION_OPTION SAR OPTION_OPTION SA OPTION_OPTION SAL IANA is requested to assign the following new DHCPv6 Status Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters: InappropriateAddress Ma Expires April 16, 2011 [Page 18] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 UnsupportedAlgorithm MalformedSACONFIGURATION FailedSACONFIGURATION 8. References 8.1. Normative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC1829] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC Transform", RFC 1829, August 1995. [RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, September 1995. [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. 8.2. Informative References [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. Ma Expires April 16, 2011 [Page 19] Internet-Draft draft-madi-dhc-dhcpv6-psac-00 October 2010 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Author's Address Di Ma CNNIC 4, South 4th Street,Zhongguancun, Beijing China(100085) Phone: +86 010 58813216 EMail: madi@cnnic.cn Ma Expires April 16, 2011 [Page 20]