idnits 2.17.1 draft-sakane-dhc-dhcpv6-kdc-option-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2012) is 4236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sakane 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track M. Ishiyama 5 Expires: March 17, 2013 Toshiba Corporation 6 September 13, 2012 8 Kerberos Options for DHCPv6 9 draft-sakane-dhc-dhcpv6-kdc-option-18.txt 11 Abstract 13 This document defines four new options for the Dynamic Host 14 Configuration Protocol for IPv6 (DHCPv6). These options are used to 15 carry coniguration information for Kerberos. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 17, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . 4 65 3. Kerberos Options . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Kerberos Principal Name Option . . . . . . . . . . . . . . 5 67 3.2. Kerberos Realm Name Option . . . . . . . . . . . . . . . . 6 68 3.3. Kerberos Default Realm Name Option . . . . . . . . . . . . 6 69 3.4. Kerberos KDC Option . . . . . . . . . . . . . . . . . . . 6 70 4. Client and Server Operation . . . . . . . . . . . . . . . . . 9 71 4.1. KDC discovery for a client . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Appendix A. An example of the operation of the client . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Kerberos Version 5 [RFC4120] is a trusted third-party authentication 84 system. Each organization wishing to use Kerberos establishes its 85 own "realm" and each client is registered as part of that realm. At 86 least one Key Distribution Center (KDC) is required for the operation 87 of a Kerberos realm. 89 When a client wishes to communicate with, and be authenticated to, a 90 Kerberos application server (also a client of the KDC), the client 91 identifies itself, and its realm, to the KDC and acquires a 92 credential from the KDC. The client then presents the credential to 93 the Kerberos application server which can use the credential to 94 authenticate the client. The client needs to know at least one IP 95 address for a KDC in order to initiate this process. 97 One example of the application of this protocol is as follows. A 98 student might want to use a shared, public workstation, one that is 99 not configured for Kerberos. If there is a mechanism for the 100 workstation to obtain a realm name and IP address for a KDC, then a 101 student need only input a user-id and pass phrase to be able to use 102 Kerberos. 104 The Kerberos V5 specification [RFC4120] defines the use of DNS SRV 105 records [RFC2782] for KDC discovery. Some systems, such as 106 industrial systems, do not use DNS. Such systems already have their 107 own name spaces and their own name resolution systems, including pre- 108 configured mapping tables for devices, and do not use Fully Qualified 109 Domain Names. However, many of these systems do use DHCP. 111 Adding a DNS server to such systems may decrease the reliability of 112 the system and increase the management cost. In such an environment, 113 another mechanism is needed to provide an IP address for the KDC. 114 For the PacketCable Architecture [PCARCH], RFC 3634 [RFC3634] defines 115 the KDC Server Address sub-option for the DHCPv4 CableLabs Client 116 Configuration option. However, a mechanism is still needed to 117 provide a realm name and an IPv6 address, one which does not depend 118 on any external architecture. 120 This document defines a Kerberos option for DHCPv6 which provides a 121 realm name and/or a list of KDC IP addresses. This option does not 122 replace or modify any of the existing methods for obtaining this 123 information. 125 2. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 It is assumed that the readers are familiar with the terms and 132 concepts described in DHCPv6 [RFC3315], Kerberos V5 [RFC4120], and 133 DNS SRV [RFC2782]. 135 3. Kerberos Options 137 This document defines four DHCPv6 configuration parameters for 138 Kerberos. 140 Kerberos Principal Name Option 142 Kerberos Realm Name Option 144 Kerberos Default Realm Name Option 146 Kerberos KDC Option 148 This section describes the format of each option, and the usage of 149 each field in that option. 151 These options except of the Kerberos KDC Option MUST NOT appear more 152 than once in a DHCPv6 message. 154 3.1. Kerberos Principal Name Option 156 The Kerberos Principal Name Option carries the name of a Kerberos 157 principal. This is sent by the client to the DHCPv6 server which MAY 158 use it to select a specific set of configuration parameters, either 159 for a client or for a Kerberos application server. 161 The format of the Kerberos Principal Name option is: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | OPTION_KRB_PRINCIPAL_NAME | option-len | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 : : 169 : principal-name : 170 : (variable length) : 171 : : 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 o option-code (16-bit): OPTION_KRB_PRINCIPAL_NAME (TBD by IANA) 176 o option-len (16-bit): length of the principal-name field. 178 o principal-name (variable): a client principal name. The encoding 179 of the principal-name field MUST conform to the definition of 180 "PrincipalName" in section 5.2.2 of RFC 4120 [RFC4120]. 182 3.2. Kerberos Realm Name Option 184 The Kerberos Realm Name Option carries a Kerberos realm name. A 185 DHCPv6 client uses this option to specify to a DHCPv6 server which 186 realm the client wants to access. 188 The format of the Kerberos Realm Name option is: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | OPTION_KRB_REALM_NAME | option-len | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 : : 196 : realm-name : 197 : (variable length) : 198 : : 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 o option-code (16-bit): OPTION_KRB_REALM_NAME (TBD by IANA) 203 o option-len (16-bit): the length of the realm-name field in octets. 205 o realm-name (variable): a realm-name. The encoding of the realm- 206 name field MUST conform to the definition of "Realm" in section 207 5.2.2 of RFC 4120 [RFC4120]. 209 3.3. Kerberos Default Realm Name Option 211 The Kerberos Default Realm Name Option is used to specify a default 212 realm name for the Kerberos system. A DHCPv6 server uses this option 213 to specify the default realm name to both clients and Kerberos 214 application servers. 216 The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME (TBD 217 by IANA). The format and usage of the option-len and realm-name 218 fields are identical to those for the Kerberos Realm Name Option. 220 3.4. Kerberos KDC Option 222 The Kerberos KDC Option is used to provide configuration information 223 about a KDC. 225 The format of the Kerberos KDC Option is: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | OPTION_KRB_KDC | option-len | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Priority | Weight | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Transport Type| Port Number | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 236 | | 237 | | 238 | KDC IPv6 address +---------------+ 239 | | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 241 : : 242 : realm-name : 243 : (variable length) : 244 : : 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 o option-code (16-bit): OPTION_KRB_KDC (TBD by IANA) 249 o option-len (16-bit): 23 + the length of the realm-name field in 250 octets. 252 o Priority (16-bit): see the description of Weight field. 254 o Weight (16-bit): the Priority and Weight fields provide a hint to 255 the client as to which KDC to select. The usage of the Priority 256 and Weight values MUST follow the specification for DNS SRV 257 [RFC2782]. 259 o Transport Type (8-bit): The Transport Type specifies the transport 260 protocol used for Kerberos. Kerberos [RFC4120] defines UDP and 261 TCP transports. Exchanges over TCP are further described in 262 [RFC5021] while the transport of Kerberos over TLS is described in 263 [RFC6251]. 265 The transport type is defined in below. 267 Value Transport Type 268 ---- -------------- 269 0 Reserved 270 1 UDP 271 2 TCP 272 3 TLS 273 4-254 Unassigned 274 255 Reserved 276 o Port Number (16-bit): the port number on which the KDC listens. 278 o KDC IPv6 address (128-bit): the IPv6 address of the KDC. 280 o realm-name (variable): the name of the realm for which the 281 specified KDC provides service. The encoding of the realm- name 282 field MUST conform to the definition of "Realm" in section 5.2.2 283 of RFC 4120 [RFC4120]. 285 4. Client and Server Operation 287 This section describes the operations of client and server. It 288 assumes that the client has been configured with a principal name. 290 If a client requires a realm name, the client sends a DHCPv6 Option 291 Request option (ORO) specifying the Kerberos Default Realm Name 292 Option. The DHCPv6 server responds with a Reply message containing a 293 Kerberos Default Realm Name Option. 295 If a client requires configuration parameters for a KDC, the client 296 sends a DHCPv6 ORO specifying the Kerberos KDC Option. The client 297 MAY include a Kerberos Principal Name Option. The client MAY include 298 a Kerberos Realm Name Option. 300 The DHCPv6 server replies with one or more sets of configuration 301 parameters for a Kerberos KDC. If the client has specified either a 302 Kerberos Principal Name Option or a Kerberos Realm Name Option, then 303 the DHCPv6 server MAY use those parameters to select specific sets of 304 configuration parameters. 306 Where the server replies with more than one set of configuration 307 paramers, the usage of priority and weight fields by the client MUST 308 follow the specification for DNS SRV [RFC2782]. 310 The client MAY include other options with data values as hints to the 311 DHCPv6 server about parameter values the client would like to have 312 returned; this is specified in section 18.1.5 of RFC 3315 [RFC3315]. 314 4.1. KDC discovery for a client 316 When a client implements both the DNS method defined by section 317 7.2.3.2 of [RFC4120] and the DHCP method defined by this document, 318 the choice of method is determined by local policy. The 319 administrator of the realm usually defines the method as part of the 320 configuration of the client before the client is installed. 322 When no criteria have been specified and the client could get the 323 Kerberos information from either the DNS server or the DHCPv6 server, 324 then the information from DNS SHOULD be preferred. 326 5. IANA Considerations 328 IANA is requested to assign four option codes from the "DHCPv6 329 Options Codes" registry for the following: 331 OPTION_KRB_PRINCIPAL_NAME 333 OPTION_KRB_REALM_NAME 335 OPTION_KRB_DEFAULT_REALM_NAME 337 OPTION_KRB_KDC 339 IANA is requested to create a sub-registry of Kerberos Message 340 Transport Type, under the Kerberos Parameters Registry. The initial 341 entries are described in section 3.4. 343 The assignment of future entries is by "IETF Review" policy as 344 described in BCP 26 [RFC5226]. The RFC specifies the symbolic name 345 of such entries which are assigned numeric codes by IANA once 346 publication is approved. 348 6. Security Considerations 350 The security considerations in RFC 3315 [RFC3315] apply. 352 DHCPv6 messages can be modified in transit. If an adversary modifies 353 the response from a DHCPv6 server or injects its own response, a 354 client may be led into contacting a malicious KDC. Both cases are 355 categorized as a Denial of Service (DoS) attack. However, a 356 malicious KDC does not know the shared key and so is unable to 357 proceed any further with the exchange. If a client receives a 358 response from such a KDC, the client can use the shared key to detect 359 that the message originates from a malicious KDC. 361 A shared, unconfigured workstation may obtain its KDC information, 362 and default realm, via DHCPv6. Such a workstation may not have a 363 host or other service key, and thus be unable to validate the Ticket- 364 Granting Ticket issued by the KDC. A modified DHCPv6 response would 365 then result in the workstation talking to a malicious KDC and be 366 unable to detect that has happened. This in turn could allow access 367 by unauthorized users. 369 To minimize potential vulnerabilities, a client SHOULD use DHCPv6 370 authentication as defined in section 21 of RFC 3315 [RFC3315]. 372 Kerberos information may be manually configured into the client 373 before requesting information from DHCPv6. Manual configuration of 374 the device SHOULD be preferred to configuration via the DHCPv6 375 server. 377 7. Acknowledgments 379 The authors are very grateful to Nobuo Okabe and Shigeya Suzuki. 380 They contributed the explanation as to why DNS is inappropriate for 381 some industry networks. Ted Lemon made many suggestions to improve 382 DHCP aspects of this specification. Ken'ichi Kamada and Yukiyo 383 Akisada contributed to the initial work on this document. Tom Petch 384 helped to improve the readability of this document. The authors also 385 thank Jeffrey Hutzelman, Kazunori Miyazawa, Kensuke Hosoya, Nicolas 386 Williams, Nobumichi Ozoe, Sam Hartman, and Stephen Farrell. They 387 made valuable comments and suggestions. 389 8. References 391 8.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 397 specifying the location of services (DNS SRV)", RFC 2782, 398 February 2000. 400 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 401 and M. Carney, "Dynamic Host Configuration Protocol for 402 IPv6 (DHCPv6)", RFC 3315, July 2003. 404 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 405 Kerberos Network Authentication Service (V5)", RFC 4120, 406 July 2005. 408 [RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key 409 Distribution Center (KDC) Exchanges over TCP", RFC 5021, 410 August 2007. 412 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 413 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 414 May 2008. 416 8.2. Informative References 418 [PCARCH] CableLabs, "PacketCable 1.0 Architecture Framework 419 Technical Report", December 1999, . 423 [RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, 424 "Key Distribution Center (KDC) Server Address Sub-option 425 for the Dynamic Host Configuration Protocol (DHCP) 426 CableLabs Client Configuration (CCC) Option", RFC 3634, 427 December 2003. 429 [RFC6251] Josefsson, S., "Using Kerberos Version 5 over the 430 Transport Layer Security (TLS) Protocol", RFC 6251, 431 May 2011. 433 Appendix A. An example of the operation of the client 435 When no criteria have been specified and the client could get the 436 Kerberos information from either the DNS server or the DHCPv6 server, 437 then the information from DNS should be preferred. The following is 438 an informational guide for the client in such an environment. 440 No Resp. or 441 +------------+ DNS Info. +-----------+ No Resp. 442 Start --> | Ask DHCP(1)| ---------> | Ask DNS(3)| ------> 443 +------------+ +-----------+ Terminate(4) 444 / \ \ 445 Only KRB / \ DNS and \ KRB Info. 446 Info. / \ KRB Info. \ 447 / \ \ 448 | | | 449 | V | 450 V No Ans. +-----------+ KRB Info. V 451 Use Info. <-------- | Ask DNS(6)| ---------> Use Info. 452 from DHCP +-----------+ from DNS 453 (2), (7) (5), (8) 455 Abbreviations: 456 Resp.: Response 457 Info.: Information 458 KRB : Kerberos 460 1) Initially, the client requests both DNS and Kerberos information 461 from the DHCPv6 server. 463 2) If the DHCPv6 server replies with Kerberos information and not 464 with DNS information, then the client uses that information. 466 3) If the DHCPv6 server does not reply or replies with only DNS 467 information, then the client requests Kerberos information from 468 the DNS server. 470 4) If the client gets no response or no Kerberos information from the 471 DNS server, then the client terminates the process. 473 5) If the client gets Kerberos information from the DNS server, then 474 the client uses that information. 476 6) If, as the result of (1), the DHCPv6 server replies with both DNS 477 and Kerberos information, then the client requests Kerberos 478 information from the DNS server. 480 7) If the client gets no response from the DNS server, then the 481 client uses the Kerberos information from the DHCPv6 server. 483 8) If, as the result of (6), the DNS server replies with Kerberos 484 information, then the client uses the information from the DNS 485 server and not that from the DHCPv6 server. 487 Authors' Addresses 489 Shoichi Sakane 490 Cisco Systems 491 9-7-1 Akasaka 492 Minato-ku, Tokyo 107-6227 493 Japan 495 Email: ssakane@cisco.com 497 Masahiro Ishiyama 498 Toshiba Corporation 499 1, komukai-toshiba-cho, Saiwai-ku, 500 Kawasaki, Kanagawa 212-8582 501 Japan 503 Email: masahiro.ishiyama@toshiba.co.jp