GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6784

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,
            <http://www.packetcable.com/downloads/specs/
            pkt-tr-arch-v01-991201.pdf>.
 [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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6784.txt · Last modified: 2012/11/06 19:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki