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]