dhc Working Group M. Ota M.Yanagiya Internet Draft NTT Expires: December 2005 June 30, 2005 CHAP-based Authentication for DHCPv6 draft-ota-dhc-auth-chap-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 30, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract In delayed authentication in DHCPv6[RFC3315], the hardware identifier is used to select the key, and the key is exchanged between the server and the client in advance. Therefore, when a user tries to use a new device, it is necessary to add key information to the new device and DHCPv6 servers. In this document, we propose a procedure for introducing CHAP[RFC1994] into the DHCPv6 authentication procedure. This procedure allows the client get the host configuration information Ota Expires December 30, 2005 [Page 1] Internet-Draft CHAP based authentication for DHCPv6 June 2005 related to the user and exchanges a secret key to use in later sequence. 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. Most of the terms used in this draft are defined in RFC3315. Table of Contents 1. Introduction...................................................3 2. Issues.........................................................3 3. Protocol Overview..............................................4 4. Packet Format of the Authentication Option in the CHAP-based Authentication Procedure..........................................5 4.1. Authentication Information in Advertise Messages..........7 4.2. Authentication Information in Request Messages............7 4.3. Authentication Information in Reply Messages corresponding to Request Message................................................8 5. Client and Server Considerations...............................9 5.1. Client Considerations.....................................9 5.1.1. Sending Solicit Messages.............................9 5.1.2. Receiving Advertise Messages.........................9 5.1.3. Sending Request Messages.............................9 5.1.4. Sending Confirm, Renew, Rebind, Decline or Release Messages....................................................9 5.1.5. Sending Information-Request Messages.................9 5.1.6. Receiving Reply Messages............................10 5.1.7. Receiving Reconfigure Messages......................10 5.1.8. When the key life time is over......................10 5.2. Server Considerations....................................10 5.2.1. Receiving Solicit Messages and Sending Advertise Messages...................................................10 5.2.2. Receiving Request Messages and Sending Reply Messages10 5.2.3. Receiving Confirm, Renew, Rebind, Decline or Release Messages...................................................11 5.2.4. Sending Reply Messages in Information-Request/Reply sequence...................................................11 6. Security Considerations.......................................11 7. IANA Consideration............................................11 8. Informative Reference.........................................11 Author's Addresses...............................................11 Intellectual Property Statement..................................12 Ota Expires December 30, 2005 [Page 2] Internet-Draft CHAP based authentication for DHCPv6 June 2005 Disclaimer of Validity...........................................12 Copyright Statement..............................................12 Acknowledgment...................................................13 1. Introduction In delayed authentication, which is the authentication procedure described in RFC3315, the hardware identifier, such as the MAC address, is used to select the key, and it is assumed that the key is exchanged between the server and the client in advance. Therefore, when a user tries to use a new device, it is necessary to submit new hardware identifiers and new key information to the DHCPv6 server. We think that it will be deployment issue. To avoid this problem, we propose a user based authentication procedure. In this procedure, DHCPv6 server authenticates user using CHAP mechanism during solicitation procedure. To identify users, we assumed that user identifier, such as FQDN of user, is used as identifier of peer. And shared secret, which is used to establish security association between DHCPv6 client and server for subsequent sequences, is exchanged using Diffie-Hellman mechanism. 2. Issues In the Delayed Authentication procedure, the DHCPv6 server selects a key based on the hardware identifier of the DHCPv6 client, such as MAC address, and it is assumed that keys are exchanged between the server and the client in advance. Therefore, when a user tries to use a new device, it is necessary to add the key to the new device and DHCPv6 servers. We think that there will be the following deployment issues: -The user is required to submit a new hardware identifier and a new key to the operator of the DHCPv6 server. The original purpose of DHCPv6 authentication was to avoid server and client spoofing in general environments such as a LAN, so the DHCPv6 authentication procedure is required to provide mutual authentication. On the other hand, we can assume that nobody can spoof the DHCPv6 server in a commercial network. In such a network, we think that it is unnecessary for the client to authenticate the server. A network access authentication procedure, such as CHAP, is one of the major one-way authentication procedures. A lot of network access procedures use the user identifier to select a secret. Therefore, an AAA server is required to manage one secret per user even if users change terminal. Ota Expires December 30, 2005 [Page 3] Internet-Draft CHAP based authentication for DHCPv6 June 2005 Therefore, we propose a new authentication procedure that applies an access authentication method based on the user identifier to the DHCPv6 authentication procedure. 3. Protocol Overview Here, we introduce a new authentication procedure that uses CHAP as the authentication method. This procedure allows the server to execute authentication based on the user identifier. We call it the CHAP-based Authentication Procedure. An example sequence of this procedure is illustrated in Figure 1. When the DHCPv6 server receives a Solicit message, the server replies with the Advertise message, which carries the challenge and identifier. The client calculates the Response value using the challenge and a pre-shared secret such as a password. And the client sends a Request message with the user-identifier, identifier, and Response value. When the DHCPv6 server receives a Request message, it selects a challenge based on the identifier. The DHCPv6 server may send an authentication request message to the AAA server, and the AAA server selects a secret based on the user identifier and evaluates the Response value. But the protocol between the DHCPv6 server and the AAA server is out of our scope. If the evaluation has been completed successfully, the DHCPv6 server sends a Reply message to the DHCPv6 client. DHCPv6 DHCPv6 AAA client Server Server | | | | Solicit [Auth-opt] | | | (demands authentication using this procedure) | |-------------------------->| | | | | | Advertise | | | [Auth-opt (Challenge, Identifier)] | |<--------------------------| | | | | | Request | | |[Auth-opt (User-Identifier,| | | Identifier, Response, DH-group, KeyExchange)] | |-------------------------->| | | | Authentication Request | | |------------------------->| | | | | | Authentication Reply | Ota Expires December 30, 2005 [Page 4] Internet-Draft CHAP based authentication for DHCPv6 June 2005 | Reply[Auth-opt |<-------------------------| | (Success or Failure, KeyExchange, etc.)] | |<--------------------------| | | | | Fig. 1. Example sequence of CHAP-based authentication procedure. 4. Packet Format of the Authentication Option in the CHAP-based Authentication Procedure In a Solicit message, the client fills in the protocol, algorithm, and RDM fields in the Authentication option with the clientÆs preferences. The client sets the replay detection field to zero and omits the authentication information field. The client sets the option-len field to 11. In all other messages, the protocol and algorithm fields identify the procedure used to construct the contents of the authentication information field. The RDM field identifies the procedure used to construct the contents of the replay detection field. The format of the Authentication information for CHAP-based authentication procedure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSG_TYPE | Identifier | MSG_Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ......... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MSG TYPE The MSG TYPE identifies the type of message. We set the following types. 1 Challenge 2 Response 3 Success 4 Failure Identifier The Identifier shows that it is a series of a CHAP sequence. When a Challenge value is generated, the identifier is generated at random by DHCPv6 Server. Ota Expires December 30, 2005 [Page 5] Internet-Draft CHAP based authentication for DHCPv6 June 2005 MSG_Length The total size of the authentication information field. The value contains MSG TYPE, Identifier, MSG length, and Attribute field length. Attribute The Attribute carries authentication information. Details of the format in the Attribute field are shown below. 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 | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TYPE The TYPE of Attribute shows the type of information of Value. 1 User-Name 3 CHAP-Password 60 CHAP-Challenge 80 DH-group 81 KeyExchange 82 DHCP realm 83 key ID 84 life time of the key Length Length of Value in octets. Value Value of Attribute related to TYPE number. Information corresponding to the TYPE number buried under the Value field is shown below. TYPE Value 1 String of User-Name and domain tied by using @. 3 Response value 60 Challenge value 80 Diffie-Hellman group value 81 Diffie-Hellman public key value 82 DHCP realm info 83 key Identifier 84 Exchanged keyÆs life time Ota Expires December 30, 2005 [Page 6] Internet-Draft CHAP based authentication for DHCPv6 June 2005 4.1. Authentication Information in Advertise Messages The Advertise message has the following authentication information field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge(1) | Identifier | MSG_Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(60) | Length | Challenge value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MSG TYPE field is 1 (Challenge). The values of Identifier and Challenge value are generated by the server. This authentication information has an attribute, Type(60). The attribute Type 60 is filled with the Challenge value. 4.2. Authentication Information in Request Messages A Request message has the following authentication information field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response(2) | Identifier | MSG_Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(1) | Length | User-Name@domain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(3) | Length | Response value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DH-group(80) | Length | DH-group value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |KeyExchange(81)| Length | public key value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MSG TYPE field is 2 (Response). Identifier is the same as the one included in the Advertise message. This authentication information has two attributes: Type (1) and Type (3). The attribute Type 1 is filled with User-Name@domain, which the client has beforehand. The attribute Type 3 is filled with Response value, which is calculated by the client. The attribute Type 80 is filled with DH-group value. The attribute Type 81 is filled with public key value generated by the client, which uses to calculate secret key with the server. Ota Expires December 30, 2005 [Page 7] Internet-Draft CHAP based authentication for DHCPv6 June 2005 4.3. Authentication Information in Reply Messages corresponding to Request Message The server selects authentication information included in the Reply message according to the authentication information received from the AAA server. When the server receives the message of authentication success, it sends a Reply message containing authentication information with the MSG_TYPE field set to 3 (Success). The attribute Type 80 is filled with DH-group value. The attribute Type 81 is filled with public key value generated by the server, which uses to calculate secret key by the client. Additionally, the message includes other necessary information (DHCP realm, key ID, life time of the key). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Success | Identifier | MSG_Length (4[Octets]) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DH-group(80) | Length | DH-group value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |KeyExchange(81)| Length | public key value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHCP realm(82)| Length | DHCP realm info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key ID(83) | Length | key identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | life time(84) | Length | Exchanged keyÆs life time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the server receives the message of the authentication failure, the server sends the Reply message with the MSG TYPE field set to 4 (Failure). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failure | Identifier | MSG_Length (4[Octets]) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The server that receives an authentication failure can be allowed to send a Reply message that does not include other options. Ota Expires December 30, 2005 [Page 8] Internet-Draft CHAP based authentication for DHCPv6 June 2005 5. Client and Server Considerations 5.1. Client Considerations The client announces its intention to use DHCPv6 authentication by including an authentication option in its Solicit message. 5.1.1. Sending Solicit Messages When the client demands to authenticate, a Solicit message includes an authentication option with the desired protocol, algorithm, and RDM. The client does not include any replay detection or authentication information in the authentication option. 5.1.2. Receiving Advertise Messages The client validates Advertise messages. If the Advertise messages have a Challenge value in the authentication information field, the client generates a Response value by applying MD5 to the data connecting Identifier, the secret that the client has beforehand, and the Challenge value. 5.1.3. Sending Request Messages The client sends a Request message with User-Name as the user identifier, Identifier, Response value, DH-group, and KeyExchange attribute in the authentication information fields. A public key value in KeyExchange attribute is calculated by the client using DH- group which received in Advertise message. 5.1.4. Sending Confirm, Renew, Rebind, Decline or Release Messages If the client received Reply messages before, it can send Confirm, Renew, Decline or Release Messages with authentication information using generated key. In this time, the client follows the sequence at section 21.4.4.3 in RFC3315. It is different only to put put the number of this authentication in the protocol field in the Authentication option. 5.1.5. Sending Information-Request Messages In this document, we support only stateful DHCP. Because, this procedure assumes use to the situation which is disbursed the address to the client, and managed by the server. The client follows the sequence at section 21.4.4.3 in RFC3315 using the secret key which the client gets in section 5.1.6. It is different only to put put the Ota Expires December 30, 2005 [Page 9] Internet-Draft CHAP based authentication for DHCPv6 June 2005 number of this authentication in the protocol field in the Authentication option. 5.1.6. Receiving Reply Messages If the messages which client received include "Success" in authentication information, the client draws the public key value in KeyExchange Attribute. And the client calculates secret key by Diffie-Hellman algorism. 5.1.1. Receiving Reconfigure Messages The client follows the sequence at section 21.4.4.6 in RFC3315. It is different only to put put the number of this authentication in the protocol field in the Authentication option. 5.1.2. When the key life time is over The client sends Solicit Message and start solicitation procedure to exchange new secret key. It is different only to put put the number of this authentication in the protocol field in the Authentication option. 5.2. Server Considerations 5.2.1. Receiving Solicit Messages and Sending Advertise Messages A server that receives a Solicit message with the protocol field set to CHAP-based authentication procedure value generates a Challenge value and Identifier. The server sends them with Advertise Messages. The server MUST record the identifier related to the Challenge value during the authentication procedure. 5.2.2. Receiving Request Messages and Sending Reply Messages If the Request message includes authentication option which type is set with CHAP Authentication, the receiving server chooses a Challenge value related to the Identifier and sends the User-Name, Identifier, Challenge value, and Response value to the AAA server. After the server has received the authentication result from the AAA server, it sends the client a Reply message containing the authentication option, which includes success or failure in MSG TYPE and KeyExchange attribute which include public key value generated by the server and other information. And the server get secret key of the client calculated by received public key value from the client. Ota Expires December 30, 2005 [Page 10] Internet-Draft CHAP based authentication for DHCPv6 June 2005 5.2.3. Receiving Confirm, Renew, Rebind, Decline or Release Messages The client follows the sequence at section 21.4.5.2 in RFC3315. It is different only to put put the number of this authentication in the protocol field in the Authentication option. 5.2.4. Sending Reply Messages in Information-Request/Reply sequence The client follows the sequence at section 21.4.5.2 in RFC3315. It is different only to put put the number of this authentication in the protocol field in the Authentication option. 6. Security Considerations The CHAP-based authentication procedure gives the procedure for authenticating the client. This protocol does not give the means of server authentication, so it has a weakness in terms of clarifying the server. 7. IANA Consideration This document introduces a new authentication mechanism. The type numbers for the protocol field in the authentication option are currently TBD. An appropriate request will be made to IANA if this Internet draft gets accepted as an RFC. 8. Informative Reference [RFC3315] R. Dorms ed., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," July 2003. [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)," August 1996. Author's Addresses Masazumi Ota, Mayumi Yanagiya NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi Tokyo, Japan Phone: 81-422-597629 Email: oota.masazumi@lab.ntt.co.jp yanagiya.mayumi@lab.ntt.co.jp Ota Expires December 30, 2005 [Page 11] Internet-Draft CHAP based authentication for DHCPv6 June 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Ota Expires December 30, 2005 [Page 12] Internet-Draft CHAP based authentication for DHCPv6 June 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ota Expires December 30, 2005 [Page 13]