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

                          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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft expires in August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   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",
   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

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

   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

       - 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
       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

   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

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

   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

   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

       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

   1. Clients implementing the KDC option implement the KDC discovery
   with DNS SRV records that specified in section 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

      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

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

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

   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-

S.Sakane, Y.Akisada and K.Kamada                               [Page 11]