INTERNET-DRAFT S. Sakane Intended Status: Informational Y. Akisada Expires: February 21, 2009 K. Kamada Yokogawa Electric Corp. August 20, 2008 Key Distribution Center Address Option for DHCPv6 draft-sakane-dhc-dhcpv6-kdc-option-01.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 February 21, 2009. 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 August 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 August 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 Appendix A. Why DNS is not acceptable in some environment ........ 9 Authors' Addresses ............................................... 12 Full Copyright Statement ......................................... 13 Intellectual Property Statement .................................. 13 S.Sakane, Y.Akisada and K.Kamada [Page 3] Internet-Draft August 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 August 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 August 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 August 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 August 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 August 2008 9. Acknowledgments The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa, Jeffrey Hutzelman, Sam Hartman and Nicolas Williams. 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- ietf-dhc-option-guidelines-00.txt, July, 2007 Appendix A. Why DNS is not acceptable in some environment S.Sakane, Y.Akisada and K.Kamada [Page 9] Internet-Draft August 2008 1. Summary - This appendix describes reasons why DHCP-based KDC discovery is more suitable than DNS-based KDC discovery described in RFC4120 (= the RFC4120-way) for the industrial systems. - The main reason is that some industrial systems don't use DNS because they have already had their own name spaces and naming systems rather than FQDN and DNS. - Less servers benefits the industrial systems: 1) Less messages simplifying the systems. 2) Less servers contributing reliability, and reducing management cost. - We understand that RFC4120 does not require DHCP for KDC discovery. However, we will have to solve DNS discovery when considering the RFC4120-way. And it is natural way to use DHCP for the purpose. - DHCP-based KDC discovery is more efficient under those systems (=expecting not to use DNS). 2. Background (what's industrial systems?) Industrial systems are a kind of sensor systems. The systems have a large number of devices, i.e. sensors and actuators, usually called field devices by which the systems control plants, factories, buildings, etc. The field devices have the following features: 1) Their resources, e.g. processing capability, memory size, footprint, power consumption and user i/f, are limited even though they are physically large. 2) The field device is controlled as an I/O by a administrative device, usually called controller, with a legacy communication technology. 3) Security of the field devices have not been cared because they are regarded as being on I/O buses, not networks. 3. High-level goal and some requirements 3.1. IP and security can enhance the industrial systems. Our goal is to introduce latest IP-based network technology into field devices for enhancing the entire system. 1) Network architecture (=IP technology) can enhance the systems including the field devices. S.Sakane, Y.Akisada and K.Kamada [Page 10] Internet-Draft August 2008 2) The field devices will require security if network architecture is introduced. The field devices will not be I/O devices anymore. 3.2. Auto-configuration benefits the industrial systems. Auto-configuration will also be important for large systems like the industrial systems if introducing new technology or capability: 1) Reducing engineering cost when installing/configuring large number of field devices over spread area. The following are existing large systems. The size of a plant, the size of an industrial system and the number of field devices are growing. - An example of single large PA system: About 20000 field devices over 2km*2km area http://www.process- worldwide.com/fachartikel/pw_fachartikel_2699276.html - An example of distributed PA systems: About 30000 field devices for 26 distributed sites over 30km*30km area. http://www.mikrocentrum.nl/FilesPage/3462/Presentatie%20C3-1.pdf http://www.nam.nl/home/Framework?siteId=nam-en&FC2=/nam- en/html/iwgen/algemeen/zzz_lhn.html&FC3=/nam- en/html/iwgen/algemeen/over_de_nam.html - An example of single large BA system: 170000 control points of 16500 field devices in 729,000 sq. meters (7.8 million sq. ft.) building complex. http://www.echelon.com/company/press/2003/echelon_mori.htm 2) Reducing the chance of human error. 3) Making disaster-recovery easier. 3.3. Security mechanism suited to resouce-limited devices are necessary. Kerberos-based security can be suited resouce-limited devices, i.e. the field devices, because of not requiring public key cryptography (of course, when not using PKINIT). 4. Some industrial systems don't use DNS. For field devices, there have been multiple technologies (see S.Sakane, Y.Akisada and K.Kamada [Page 11] Internet-Draft August 2008 Section 6) which don't use DNS because of having already had their own name spaces and naming systems even though introducing IP (partially at this moment). For example, TAG is the common logical identifier for PA systems and Device ID is the common logical identifier for BA systems. (You may think those names are not so abstracted, though....) 5. KDC discovery with DHCP is more suitable than the one with DNS. If Kerberos is introduced into the field devices, auto-configuration will be achieved with the following steps: 1) Learning DNS address(es) by DHCP 2) Learning KDC address(es) by DNS based on RFC4120-way. However, DNS will be used by kerberos-related part only. Most application will not use DNS as described above. If DHCP can advertise KDC-related information instead of DNS, there are the following advantages. 1) It can reduce messages handled by the field devices. Consequently, it can reduce footprint of the field devices. 2) It can reduce the number of servers. Consequently, it contribute to management cost of the systems. 6. References There have been multiple technologies for field devices. Examples: - FOUNDATION Fieldbus (http://www.fieldbus.org/) - PROFIBUS (http://www.profibus.com/) - BACnet (http://www.bacnet.org/) - LonWorks (http://www.echelon.co.jp/products/lonworks.html) - Modbus (http://www.modbus.org/) You can learn about communication technology of field devices with wikipedia: - http://en.wikipedia.org/wiki/Fieldbus - http://en.wikipedia.org/wiki/BACnet - http://en.wikipedia.org/wiki/LonWorks Authors' Addresses S.Sakane, Y.Akisada and K.Kamada [Page 12] Internet-Draft August 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 13] Internet-Draft August 2008 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. S.Sakane, Y.Akisada and K.Kamada [Page 14]