From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6784.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc6784.txt (limited to 'doc/rfc/rfc6784.txt') diff --git a/doc/rfc/rfc6784.txt b/doc/rfc/rfc6784.txt new file mode 100644 index 0000000..54299e7 --- /dev/null +++ b/doc/rfc/rfc6784.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Sakane +Request for Comments: 6784 Cisco Systems +Category: Standards Track M. Ishiyama +ISSN: 2070-1721 Toshiba Corporation + November 2012 + + + Kerberos Options for DHCPv6 + +Abstract + + This document defines four new options for the Dynamic Host + Configuration Protocol for IPv6 (DHCPv6). These options are used to + carry configuration information for Kerberos. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6784. + + + + + + + + + + + + + + + + + + + + + + + +Sakane & Ishiyama Standards Track [Page 1] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + (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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................4 + 3. Kerberos Options ................................................4 + 3.1. Kerberos Principal Name Option .............................4 + 3.2. Kerberos Realm Name Option .................................5 + 3.3. Kerberos Default Realm Name Option .........................6 + 3.4. Kerberos KDC Option ........................................6 + 4. Client and Server Operation .....................................7 + 4.1. KDC Discovery for a Client .................................8 + 5. IANA Considerations .............................................8 + 6. Security Considerations .........................................9 + 7. Acknowledgments .................................................9 + 8. References .....................................................10 + 8.1. Normative References ......................................10 + 8.2. Informative References ....................................10 + Appendix A. An Example of the Operation of the Client .............11 + + + + + + +Sakane & Ishiyama Standards Track [Page 2] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + +1. Introduction + + Kerberos Version 5 [RFC4120] is a trusted third-party authentication + system. Each organization wishing to use Kerberos establishes its + own "realm", and each client is registered as part of that realm. At + least one Key Distribution Center (KDC) is required for the operation + of a Kerberos realm. + + When a client wishes to communicate with, and be authenticated to, a + Kerberos application server (also a client of the KDC), the client + identifies itself, and its realm, to the KDC and acquires a + credential from the KDC. The client then presents the credential to + the Kerberos application server, which can use the credential to + authenticate the client. The client needs to know at least one IP + address for a KDC in order to initiate this process. + + One example of the application of this protocol is as follows. A + student might want to use a shared, public workstation, one that is + not configured for Kerberos. If there is a mechanism for the + workstation to obtain a realm name and IP address for a KDC, then a + student need only input a user-id and pass phrase to be able to use + Kerberos. + + The Kerberos V5 specification [RFC4120] defines the use of DNS SRV + records [RFC2782] for KDC discovery. Some systems, such as + industrial systems, do not use DNS. Such systems already have their + own name spaces and their own name resolution systems, including + preconfigured mapping tables for devices, and do not use Fully + Qualified Domain Names. However, many of these systems do use DHCP. + + Adding a DNS server to such systems may decrease the reliability of + the system and increase the management cost. In such an environment, + another mechanism is needed to provide an IP address for the KDC. + For the PacketCable Architecture [PCARCH], RFC 3634 [RFC3634] defines + the KDC Server Address sub-option for the DHCPv4 CableLabs Client + Configuration option. However, a mechanism is still needed to + provide a realm name and an IPv6 address -- one that does not depend + on any external architecture. + + This document defines a Kerberos option for DHCPv6 that provides a + realm name and/or a list of KDC IP addresses. This option does not + replace or modify any of the existing methods for obtaining this + information. + + + + + + + + +Sakane & Ishiyama Standards Track [Page 3] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + +2. 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 RFC 2119 [RFC2119]. + + It is assumed that the readers are familiar with the terms and + concepts described in DHCPv6 [RFC3315], Kerberos V5 [RFC4120], and + DNS SRV [RFC2782]. + +3. Kerberos Options + + This document defines four DHCPv6 configuration parameters for + Kerberos. + + Kerberos Principal Name Option + + Kerberos Realm Name Option + + Kerberos Default Realm Name Option + + Kerberos KDC Option + + This section describes the format of each option and the usage of + each field in that option. + + These options, except for the Kerberos KDC Option, MUST NOT appear + more than once in a DHCPv6 message. + +3.1. Kerberos Principal Name Option + + The Kerberos Principal Name Option carries the name of a Kerberos + principal. This is sent by the client to the DHCPv6 server, which + MAY use it to select a specific set of configuration parameters, + either for a client or for a Kerberos application server. + + + + + + + + + + + + + + + + +Sakane & Ishiyama Standards Track [Page 4] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + + The format of the Kerberos Principal Name 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_KRB_PRINCIPAL_NAME | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : + : principal-name : + : (variable length) : + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o option-code (16 bits): OPTION_KRB_PRINCIPAL_NAME (75) + + o option-len (16 bits): length of the principal-name field. + + o principal-name (variable): a client principal name. The encoding + of the principal-name field MUST conform to the definition of + "PrincipalName" in Section 5.2.2 of RFC 4120 [RFC4120]. + +3.2. Kerberos Realm Name Option + + The Kerberos Realm Name Option carries a Kerberos realm name. A + DHCPv6 client uses this option to specify to a DHCPv6 server which + realm the client wants to access. + + The format of the Kerberos Realm Name 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_KRB_REALM_NAME | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : + : realm-name : + : (variable length) : + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o option-code (16 bits): OPTION_KRB_REALM_NAME (76) + + o option-len (16 bits): the length of the realm-name field in + octets. + + o realm-name (variable): a realm-name. The encoding of the + realm-name field MUST conform to the definition of "Realm" in + Section 5.2.2 of RFC 4120 [RFC4120]. + + + +Sakane & Ishiyama Standards Track [Page 5] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + +3.3. Kerberos Default Realm Name Option + + The Kerberos Default Realm Name Option is used to specify a default + realm name for the Kerberos system. A DHCPv6 server uses this option + to specify the default realm name to both clients and Kerberos + application servers. + + The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME (77). + The format and usage of the option-len and realm-name fields are + identical to those for the Kerberos Realm Name Option. + +3.4. Kerberos KDC Option + + The Kerberos KDC Option is used to provide configuration information + about a KDC. + + The format of the Kerberos 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_KRB_KDC | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Priority | Weight | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Transport Type| Port Number | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + | | + | KDC IPv6 address +---------------+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : + : : + : realm-name : + : (variable length) : + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o option-code (16 bits): OPTION_KRB_KDC (78) + + o option-len (16 bits): 23 + the length of the realm-name field in + octets. + + o Priority (16 bits): see the description of the Weight field. + + + + + + + +Sakane & Ishiyama Standards Track [Page 6] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + + o Weight (16 bits): the Priority and Weight fields provide a hint to + the client as to which KDC to select. The usage of the Priority + and Weight values MUST follow the specification for DNS SRV + [RFC2782]. + + o Transport Type (8 bits): The Transport Type specifies the + transport protocol used for Kerberos. Kerberos [RFC4120] defines + UDP and TCP transports. Exchanges over TCP are further described + in [RFC5021], while the transport of Kerberos over Transport Layer + Security (TLS) is described in [RFC6251]. + + The transport type is defined below. + + Value Transport Type + ---- -------------- + 0 Reserved + 1 UDP + 2 TCP + 3 TLS + 4-254 Unassigned + 255 Reserved + + o Port Number (16 bits): the port number on which the KDC listens. + + o KDC IPv6 address (128 bits): the IPv6 address of the KDC. + + o realm-name (variable): the name of the realm for which the + specified KDC provides service. The encoding of the realm-name + field MUST conform to the definition of "Realm" in Section 5.2.2 + of RFC 4120 [RFC4120]. + +4. Client and Server Operation + + This section describes the operations of the client and server. It + assumes that the client has been configured with a principal name. + + If a client requires a realm name, the client sends a DHCPv6 Option + Request Option (ORO) specifying the Kerberos Default Realm Name + Option. The DHCPv6 server responds with a Reply message containing a + Kerberos Default Realm Name Option. + + If a client requires configuration parameters for a KDC, the client + sends a DHCPv6 ORO specifying the Kerberos KDC Option. The client + MAY include a Kerberos Principal Name Option. The client MAY include + a Kerberos Realm Name Option. + + The DHCPv6 server replies with one or more sets of configuration + parameters for a Kerberos KDC. If the client has specified either a + + + +Sakane & Ishiyama Standards Track [Page 7] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + + Kerberos Principal Name Option or a Kerberos Realm Name Option, then + the DHCPv6 server MAY use those parameters to select specific sets of + configuration parameters. + + Where the server replies with more than one set of configuration + parameters, the usage of the Priority and Weight fields by the client + MUST follow the specification for DNS SRV [RFC2782]. + + The client MAY include other options with data values as hints to the + DHCPv6 server about parameter values the client would like to have + returned; this is specified in Section 18.1.5 of RFC 3315 [RFC3315]. + +4.1. KDC Discovery for a Client + + When a client implements both the DNS method defined by + Section 7.2.3.2 of [RFC4120] and the DHCP method defined by this + document, the choice of method is determined by local policy. The + administrator of the realm usually defines the method as part of the + configuration of the client before the client is installed. + + When no criteria have been specified and the client could get the + Kerberos information from either the DNS server or the DHCPv6 server, + then the information from DNS SHOULD be preferred. + +5. IANA Considerations + + IANA has assigned four option codes from the DHCPv6 Option Codes + registry for the following: + + 75 OPTION_KRB_PRINCIPAL_NAME + + 76 OPTION_KRB_REALM_NAME + + 77 OPTION_KRB_DEFAULT_REALM_NAME + + 78 OPTION_KRB_KDC + + IANA has created the Kerberos Message Transport Types sub-registry, + under the Kerberos Parameters registry. The initial entries are + described in Section 3.4. + + The assignment of future entries is by "IETF Review" policy as + described in BCP 26 [RFC5226]. Per that policy, a document specifies + the symbolic name of such entries, which are assigned numeric codes + by IANA once publication is approved. + + + + + + +Sakane & Ishiyama Standards Track [Page 8] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + +6. Security Considerations + + The security considerations in RFC 3315 [RFC3315] apply. + + DHCPv6 messages can be modified in transit. If an adversary modifies + the response from a DHCPv6 server or injects its own response, a + client may be led into contacting a malicious KDC. Both cases are + categorized as a Denial-of-Service (DoS) attack. However, a + malicious KDC does not know the shared key and so is unable to + proceed any further with the exchange. If a client receives a + response from such a KDC, the client can use the shared key to detect + that the message originates from a malicious KDC. + + A shared, unconfigured workstation may obtain its KDC information, + and default realm, via DHCPv6. Such a workstation may not have a + host or other service key, and thus it may be unable to validate the + Ticket-Granting Ticket issued by the KDC. A modified DHCPv6 response + would then result in the workstation talking to a malicious KDC, and + the workstation would not be able to detect that this has happened. + This in turn could allow access by unauthorized users. + + To minimize potential vulnerabilities, a client SHOULD use DHCPv6 + authentication as defined in Section 21 of RFC 3315 [RFC3315]. + + Kerberos information may be manually configured on the client before + requesting information from DHCPv6. Manual configuration of the + device SHOULD be preferred to configuration via the DHCPv6 server. + +7. Acknowledgments + + The authors are very grateful to Nobuo Okabe and Shigeya Suzuki. + They contributed the explanation as to why DNS is inappropriate for + some industry networks. Ted Lemon made many suggestions to improve + DHCP aspects of this specification. Ken'ichi Kamada and Yukiyo + Akisada contributed to the initial work on this document. Tom Petch + helped to improve the readability of this document. The authors also + thank Jeffrey Hutzelman, Kazunori Miyazawa, Kensuke Hosoya, Nicolas + Williams, Nobumichi Ozoe, Sam Hartman, and Stephen Farrell. They + made valuable comments and suggestions. + + + + + + + + + + + + +Sakane & Ishiyama Standards Track [Page 9] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [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. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key + Distribution Center (KDC) Exchanges over TCP", RFC 5021, + August 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +8.2. Informative References + + [PCARCH] CableLabs, "PacketCable 1.0(TM) Architecture Framework + Technical Report", December 1999, + . + + [RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and 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. + + [RFC6251] Josefsson, S., "Using Kerberos Version 5 over the + Transport Layer Security (TLS) Protocol", RFC 6251, + May 2011. + + + + + + + + +Sakane & Ishiyama Standards Track [Page 10] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + +Appendix A. An Example of the Operation of the Client + + When no criteria have been specified and the client could get the + Kerberos information from either the DNS server or the DHCPv6 server, + then the information from DNS SHOULD be preferred. The following is + an informational guide for the client in such an environment. + + No Resp. or + +------------+ DNS Info. +-----------+ No Resp. + Start --> | Ask DHCP(1)| ---------> | Ask DNS(3)| ------> + +------------+ +-----------+ Terminate(4) + / \ \ + Only KRB / \ DNS and \ KRB Info. + Info. / \ KRB Info. \ + / \ \ + | | | + | V | + V No Ans. +-----------+ KRB Info. V + Use Info. <-------- | Ask DNS(6)| ---------> Use Info. + from DHCP +-----------+ from DNS + (2), (7) (5), (8) + + Abbreviations: + Resp.: Response + Info.: Information + KRB : Kerberos + + 1) Initially, the client requests both DNS and Kerberos information + from the DHCPv6 server. + + 2) If the DHCPv6 server replies with Kerberos information and not + with DNS information, then the client uses that information. + + 3) If the DHCPv6 server does not reply or replies with only DNS + information, then the client requests Kerberos information from + the DNS server. + + 4) If the client gets no response or no Kerberos information from + the DNS server, then the client terminates the process. + + 5) If the client gets Kerberos information from the DNS server, then + the client uses that information. + + 6) If, as the result of (1), the DHCPv6 server replies with both DNS + and Kerberos information, then the client requests Kerberos + information from the DNS server. + + + + + +Sakane & Ishiyama Standards Track [Page 11] + +RFC 6784 Kerberos Options for DHCPv6 November 2012 + + + 7) If the client gets no response from the DNS server, then the + client uses the Kerberos information from the DHCPv6 server. + + 8) If, as the result of (6), the DNS server replies with Kerberos + information, then the client uses the information from the DNS + server and not that from the DHCPv6 server. + +Authors' Addresses + + Shoichi Sakane + Cisco Systems + 9-7-1 Akasaka + Minato-ku, Tokyo 107-6227 + Japan + + EMail: ssakane@cisco.com + + + Masahiro Ishiyama + Toshiba Corporation + 1, Komukai-toshiba-cho, Saiwai-ku, + Kawasaki, Kanagawa 212-8582 + Japan + + EMail: masahiro.ishiyama@toshiba.co.jp + + + + + + + + + + + + + + + + + + + + + + + + + + +Sakane & Ishiyama Standards Track [Page 12] + -- cgit v1.2.3