INTERNET-DRAFT S. Sakane Intended Status: Proposed Standard Y. Akisada Expires: August 21, 2008 K. Kamada Yokogawa Electric Corp. February 18, 2008 Key Distribution Center Address Option for DHCPv6 draft-sakane-dhc-dhcpv6-kdc-option-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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft expires in August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines a new DHCPv6 option to convey a realm of Kerberos and IPv6 addresses of a KDC of that realm. S.Sakane, Y.Akisada and K.Kamada [Page 1] Internet-Draft February 2008 Conventions used in this document 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 [RFC2119]. It is assumed that the readers are familiar with the terms and concepts described in the DHCPv6 [RFC3315]. S.Sakane, Y.Akisada and K.Kamada [Page 2] Internet-Draft February 2008 Table of Contents 1. Introduction ................................................. 4 2. KDC option ................................................... 4 3. Server Operation ............................................. 6 4. Client Operation ............................................. 6 5. Appearance of this option .................................... 6 6. KDC IPv4 Address Consideration ............................... 6 7. IANA Considerations .......................................... 8 8. Security Considerations ...................................... 8 9. Acknowledgments .............................................. 9 10. References ................................................... 9 10.1. Normative References ................................... 9 10.2. Informative References ................................. 9 Authors' Addresses ............................................... 9 Full Copyright Statement ......................................... 10 Intellectual Property Statement .................................. 10 S.Sakane, Y.Akisada and K.Kamada [Page 3] Internet-Draft February 2008 1. Introduction The Kerberos Version 5 [RFC4120] is a widely deployed mechanism that a server can authenticate a client. Each client belongs to a managed domain called a realm. And the client also needs to know at least an IP address of the Key Distribution Center (KDC) from which the client gets a credential. KDC address option for DHCPv6 allows to provide a realm name and a list of IP addresses of the KDC which maintains the database of that realm. The clients can use these KDC addresses to handle the kerberos operation. This is one of the methods that a client can use to obtain the addresses of the KDC. One method to provide the KDC addresses is shown in RFC 4120. To provide the KDC IPv4 address by DHCPv4 is defined in [CCCKDC] as a sub-option of the CableLabs Client Configuration Option. Mechanisms for configuring IPv4/IPv6 dual- stack client should be considered, but are not specified in this document. 2. KDC option KDC option provides a realm name and a list of one or more IP addresses of KDC. Multiple KDC Options may present in a single message from the DHCPv6 server. The format of the KDC 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_KDC | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | realm-name-length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | realm-name (variable) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | KDC-information (multiple) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S.Sakane, Y.Akisada and K.Kamada [Page 4] Internet-Draft February 2008 option-code: OPTION_KDC option-len: Length of this option except of 4-byte header. It MUST conform to section 22.1 of RFC3315. realm-name-length: Length of realm-name in octets. realm-name: A Realm Name. It must conform to section 5.2.1 of RFC4120. TBC. KDC-information: It contains a set of information of a KDC. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | ST | port-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | KDC-address (ipv6 address) : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: must be filled with zero. CONSIDERATION: See the section of KDC IPv4 address consideration ST: Service Type. It specifies the medium over what the KDC should be contacted. Currently, the following numbers are defined. UDP 0 (default) TCP 1 HTTP 2 (TBC) SCTP 3 (TBC) Reserved 4-15 CONSIDERATION: - Is the ST necessary at all ? The transport type communicating with a KDC is UDP 88 basically. Occasionally, implementations use TCP 88. Other transports are not defined in RFC4120. However Heimdal implementation can define HTTP as a transport type to talk with a KDC. SCTP might be used in the future. - Should the new repository to maintain the ST be created ? port-number: It allows to specify the port number of the KDC to listen from the client's access, although the section of 7.2.3.2 in the Kerberos version 5 specification, RFC4120 S.Sakane, Y.Akisada and K.Kamada [Page 5] Internet-Draft February 2008 [RFC4120] strongly recommend to use the port number of 88. KDC-address: IPv6 address of KDC for the client to use. The IP addresses are listed in the order of preference for use by the client. 3. Server Operation The DHCPv6 server MAY send a client one or more KDC Options. The server MUST list addresses of KDC with preferred order into the KDC option. 4. Client Operation When a client needs to know the IP addresses of a specific KDC, the client may request the KDC options in an Options Request Option as described in RFC3315. See the section of Security Considerations also. Multiple KDC Informations MAY be listed in a KDC Option. If a client receives multiple KDC informations in the KDC option, the client SHOULD contact to KDC in order of the list. Multiple KDC informations are listed in the order of preference for use by the client. If a client receives multiple KDC options, it SHOULD use an appropriate KDC option by matching the realm name specified at the head of the KDC option. 5. Appearance of this option The KDC option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information- Request, and Reply. If this option appears in messages other than those specified above, the receiver MUST ignore it. 6. KDC IPv4 Address Consideration Basically, the option defined in this document can only be used to configure information about KDC addresses that can be reached using IPv6. However, the address space of the DHCPv6 service does not depends on the address type of the connection of any kerberos service. That is why DHCPv6 could provide IPv4 addresses of the KDC. To enable this, the 'Reserved' field is divided into three fields. S.Sakane, Y.Akisada and K.Kamada [Page 6] Internet-Draft February 2008 Another KDC Information container 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addr-len | AT | ST | port-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | KDC-address (IP address) : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ addr-len: Length of KDC Address. It allows a client to skip this KDC Information even when the client does not know the address type. AT: Address Type. It allows a client to know the address family explicitly because there will be address families which are same length of their address. Currently, the following numbers are defined. Not used 0 IPv4 1 IPv6 2 Reserved 3-15 CONSIDERATION: Should it request something to IANA consideration ? The value of this type lets the clients know the address family of this address even if there is another family which has same length of the address. According to section 4 of the guideline for creating new DHCP options [DHCPGUIDE], the KDC information should replace to a sub- option of the KDC Option. In this case, the sub-option should be the following style: S.Sakane, Y.Akisada and K.Kamada [Page 7] Internet-Draft February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-option | sub-opt-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Researved | AT | ST | port-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | KDC-address (IP address) : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. IANA Considerations This document requests IANA to assign a number for the KDC option named OPTION_KDC in this document, from the option-code space defined in "DHCPv6 Options" section of [DHCPv6]. TBC for ST. 8. Security Considerations The security considerations in RFC 3315 fully apply. If an adversary manages to modify the response from a DHCPv6 server or insert its own response, a client could be led to contact a rogue KDC or a server which does not know the client access. Both case are category of a denial of service. In the former case, however, such KDC does not know the share key between the client and a valid KDC. The KDC is not be able to proceed any further state of the client. The client receives a response from such KDC, the client can know to be given invalid KDC addresses from an adversary. In order to minimize potential vulnerabilities, it is recommended that: 1. Clients implementing the KDC option implement the KDC discovery with DNS SRV records that specified in section 7.2.3.2 of RFC4120. 2. Where KDC informations such as the IP addresses are manually configured in local. These informations SHOULD NOT be overridden by this option from the DHCPv6 server. 3. A client SHOULD require the use of DHCPv6 authentication (see the "Authentication of DHCP messages" in section of the DHCPv6 specification [1]). prior to accepting KDC option(s). S.Sakane, Y.Akisada and K.Kamada [Page 8] Internet-Draft February 2008 9. Acknowledgments The authors are very grateful to Nobuo Okabe and Kazunori Miyazawa. They gave us lots of comments and input for this document. 10. References 10.1. Normative References [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [DHCPv6] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [DNSSRV] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [CCCKDC] K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust, "Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option", RFC 3634, December 2003. [KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. 10.2. Informative References [DHCPGUIDE] D. Hankins, "Guidelines for Creating New DHCP Options", draft- dhankins-dhcp-option-guidelines-01.txt, July 11, 2007 Authors' Addresses S.Sakane, Y.Akisada and K.Kamada [Page 9] Internet-Draft February 2008 Shoichi Sakane Yukiyo Akisada Ken'ishi Kamada Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo 180-8750 Japan E-mail: Shouichi.Sakane@jp.yokogawa.com, Yukiyo.Akisada@jp.yokogawa.com, Ken-ichi.Kamada@jp.yokogawa.com Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. 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 S.Sakane, Y.Akisada and K.Kamada [Page 10] Internet-Draft February 2008 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. S.Sakane, Y.Akisada and K.Kamada [Page 11]