[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 6784

INTERNET-DRAFT                                                 S. Sakane
Intended Status: Informational                   Yokogawa Electric Corp.
Expires: August 29, 2010                                     M. Ishiyama
                                                           Toshiba Corp.
                                                       February 25, 2010


                       Kerberos Option for DHCPv6
               draft-sakane-dhc-dhcpv6-kdc-option-07.txt


                          Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 August 29, 2010.


Copyright Notice

   Copyright (c) 2010 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



Sakane & Ishiyama                                               [Page 1]

Internet-Draft                                             February 2010


   described in the Simplified BSD License.


Abstract

   This document defines a new DHCPv6 option to carry a set of
   configuration information related to the Kerberos protocol [RFC4120].
   This document also defines three sub-options to be used within this
   new option, which specify a realm name of the Kerberos, a list of IP
   addresses of the Key Distribution Center of that realm, and a client
   principal name to distinguish a Kerberos client by the DHCPv6 server.


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 the DHCPv6 [RFC3315].






























Sakane & Ishiyama                                               [Page 2]

Internet-Draft                                             February 2010


Table of Contents

    1. Introduction .................................................  4
    2. Kerberos Option ..............................................  5
       2.1. Realm Name Sub-Option ...................................  5
       2.2. KDC Sub-Option ..........................................  6
       2.3. Client Principal Name Sub-Option ........................  8
    3. Client Operation .............................................  8
       3.1. A recommendation of KDC discovery for a client ..........  9
    4. Server Operation ............................................. 10
    5. Appearance of this option .................................... 11
    6. IANA Considerations .......................................... 12
    7. Security Considerations ...................................... 12
    8. Acknowledgments .............................................. 13
    9. References ................................................... 13
       9.1. Normative References .................................... 13
       9.2. Informative References .................................. 13
   Appendix A. Why DNS is not acceptable in some environment ........ 14
   Authors' Addresses ............................................... 18
































Sakane & Ishiyama                                               [Page 3]

Internet-Draft                                             February 2010


1.  Introduction

   The Kerberos Version 5 [RFC4120] is an authentication system which is
   based on the trusted third-party authentication protocol.  Each
   organization wishing to use the Kerberos protocol establishes its own
   "realm", and each client is assigned to the realm.  At least one Key
   Distribution Center (KDC) is required for the Kerberos operation of
   the realm.

   When the client wants to begin communication with the peer and to be
   authenticated by the peer, the client needs to take a credential from
   the KDC.  In this process, the client presents both an identifier
   itself, and a realm name to which the client itself belongs.  After
   the client gets a credential from the KDC, the client presents it to
   the peer.  The peer can authenticate the access from the client with
   the credential.  Hence, the client needs to know at least one IP
   address of KDC from which the client can get a credential before the
   client begins the communication with the peer.

   Here is a use case that a client has to know a realm name.  A public
   workstation for an unspecified several number of students in a
   college does not have any initial configuration for the Kerberos.  If
   there is a mechanism providing a realm name and a set of IP addresses
   of the KDC, a student only puts a user identifier and a pass phrase
   into the workstation, and can user the Kerberos authentication
   system.

   To provide a set of IP addresses of the KDC, the Kerberos V5
   specification [RFC4120] defines a KDC discovery by utilizing DNS SRV
   records [RFC2782].  In the meantime, the system which does not employ
   DNS, but does use DHCP, exists like the industrial system.  Some
   industrial systems don't use DNS because they have already had their
   own name spaces and their own name resolution systems, including the
   pre-configured mapping table into the device, rather than FQDN and
   DNS.  And these systems dare not to employ DNS for only the name
   resolution because adding a new server brings to decrease the
   reliability of the system, and to increase the management cost of the
   system.  (The detail is described in the APPENDIX), For such
   environment, another mechanism is required to provide a set of IP
   addresses of the KDC.  Providing a set of IPv4 addresses of the KDC
   to the devices deployed into the PacketCable Architecture [PCARCH],
   the KDC Server Address sub-option for the DHCPv4 CableLabs Client
   Configuration option is defined in RFC 3634 [RFC3634].  However, a
   mechanism which does not depend on any architecture is required for
   providing a realm name and a set of IPv6 addresses.

   The Kerberos option for DHCPv6 defined by this document allows to
   provide a realm name and/or a list of IP addresses of the KDC.  The



Sakane & Ishiyama                                               [Page 4]

Internet-Draft                                             February 2010


   Kerberos option does not replace and deny of the previous methods,
   and this option does not interfere with those methods.


2.  Kerberos Option

   The Kerberos option provides a realm name and/or a set of IP
   addresses of the KDC.  The option contains one or more sub-options
   defined in this document.

   The format of the Kerberos 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         |           option-len          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                 Kerberos sub-options (variable)               :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  option-code (16-bit): OPTION_KRB (TBD by IANA)

   o  option-len (16-bit): the length of the Kerberos sub-options in
      octets.

   o  Kerberos sub-options (variable): each sub-option is listed in the
      Kerberos sub-options field sequentially.  The order of the sub-
      options is discussed in section of the server behavior of this
      document.  Currently, the following sub-options are defined.

           Realm Name sub-option
           KDC sub-option
           Client Principal Name sub-option

   Any other sub-options may be defined in the future.  Those should be
   defined in another document.


2.1.  Realm Name Sub-Option

   The Realm Name sub-option provides a realm name.

   The format of the Realm Name sub-option is:





Sakane & Ishiyama                                               [Page 5]

Internet-Draft                                             February 2010


       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_REALM_NAME     |          sub-opt-len          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |                                               |
       +-+-+-+-+-+-+-+-+                                               |
       :                                                               :
       :                       realm-name (variable)                   :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  sub-option-code (16-bit): SUB_OPTION_REALM_NAME (TBD by IANA)

   o  sub-opt-len (16-bit): 1 octets for the length of the Flags field +
      the length of the realm-name field in octets.

   o  Flags (8-bit): indicates specific options of the Realm sub-option.

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |D|   Reserved  |
       +-+-+-+-+-+-+-+-+

   This document only defines the default realm bit (bit 0).  When the
   default realm bit is set to 1 by a DHCP server, it indicates this sub
   option containing the default realm name for the client.  Other bits
   are reserved for the future use, and MUST be set to 0.

   o  realm-name (variable): a realm-name.  The encoding of the realm-
      name field MUST be conformed to "Realm" which is defined in
      section 5.2.2 of RFC 4120 [RFC4120].


2.2.  KDC Sub-Option

   The KDC sub-option provides several parameters of the KDC, including
   an address of the KDC, a priority, a weight, a service type and a
   port number.

   The format of the KDC sub-option is:









Sakane & Ishiyama                                               [Page 6]

Internet-Draft                                             February 2010


       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_KDC        |          sub-opt-len          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Priority            |            Weight             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Service Type |   Reserved    |          Port Number          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                       KDC address (variable)                  :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  sub-option-code (8-bit): SUB_OPTION_KDC (TBD by IANA)

   o  sub-opt-len (8-bit): 8 octets + the length of the KDC address
      field in octets.  This value becomes 24 when an IPv6 address is
      provided.  It is not recommended to provide an IPv4 address.  If
      it is required, the address family should be agreed within the
      system.  Such a case is that for example a host supports both
      families and the KDC only supports IPv4 address for example.  This
      value becomes 12 in this case.

   o  Priority (16-bit): see below.

   o  Weight (16-bit): both Priority and Weight are for a server
      selection mechanism.  These parameters indicate a hint for a kind
      of server selection mechanism of a client.  An implementer could
      refer to the DNS SRV specification [RFC2782] for this usage.

   o  Service Type (8-bit): The Service Type specifies the transport of
      the Kerberos communication.  The Kerberos specification [RFC4120]
      defines to use both UDP and TCP for communication between clients
      and servers.  The exchanges over TCP is described in [RFC5021].
      The exchanges over TLS is described in [STARTTLS].

      The service type is defined in below.

      Reserved 0
      UDP      1
      TCP      2
      TLS      3
      Reserved 4-15






Sakane & Ishiyama                                               [Page 7]

Internet-Draft                                             February 2010


   o  Port Number (8-bit): a port number listened to by the KDC.

   o  KDC address (variable): an address of the KDC.  The length of this
      field is 8-octet when an IPv6 address is provided.


2.3.  Client Principal Name Sub-Option

   The Client Principal Name sub-option provides a client principal
   name.  It is desirable to use the principal name in order that the
   server determines a specific Kerberos information for the client.

   The format of the Client Principal Name sub-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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     SUB_OPTION_CLIENT_NAME    |          sub-opt-len          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                    principal-name (variable)                  :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  sub-option-code (8-bit): SUB_OPTION_CLIENT_NAME (TBD by IANA)

   o  sub-opt-len (8-bit): length of the principal-name field.

   o  principal-name (variable): a client principal name.  The encoding
      of the principal-name field MUST be conformed to "PrincipalName"
      defined in section 5.2.2 of RFC 4120 [RFC4120].


3.  Client Operation

   When a client needs to know information of the Kerberos, the client
   may send an Information-request Message. The client MAY include the
   DHCPv6 option number of the Kerberos option in the Option Request
   Option defined in section 22.7 of RFC 3315 [RFC3315] in the
   Information-request message.  The client MAY include any other
   options with data values as hints to the server as it is described in
   section 18.1.5 of RFC 3315 [RFC3315].  When the client needs to know
   a specific information of a certain realm, the client MAY specify the
   realm name into the Realm Name sub-option.  When the client wants to
   get a specific information related to its own client principal name,
   the client MAY put own principal name into the Client Principal Name
   sub-option.



Sakane & Ishiyama                                               [Page 8]

Internet-Draft                                             February 2010


   Multiple KDC address sub-options MAY be listed in a Kerberos Option
   of the Reply Message from the server.  If a client receives a set of
   addresses of the KDC, the client MUST contact to the addresses in the
   order of the value of the priority field in each KDC sub-option.  The
   value of the weight field might be considered simultaneously.  For
   this usage, an implementer could refer to the DNS SRV specification
   [RFC2782].

   An implementor should also refer to the Stateless Dynamic Host
   Configuration Protocol (DHCP) Service for IPv6 [RFC3736].


3.1.  A recommendation of KDC discovery for a client

   When a client has a capability of both the DNS method defined by
   section 7.2.3.2 of [RFC4120] and the DHCP method defined by this
   document, which methods the client adopts depends on the policy of
   the environment.  The administrator of the realm MUST define the
   method to the client before the client is installed into the
   environment.

   When there is no criteria in the environment, and the client could
   get the Kerberos information from both the DNS server and the DHCP
   server, then the information from DNS is recommended.  The following
   is a recommendation of the behavior of the client in such environment
   where there is no criteria.

                               No Ans. or
               +------------+  DNS Info.  +-----------+ No Ans.
     Start --> | Ask DHCP(1)| ----------> | Ask DNS(3)| ------> Abort(4)
               +------------+             +-----------+
                /          \                       \
      Only KRB /            \ DNS and               \ KRB Info.
        Info. /              \ KRB Info.             \
             /                \                       \
            |                  |                       |
            |                  V                       |
            V     No Ans.  +-----------+  KRB Info.    V
     Adopt Info. <-------- | Ask DNS(6)| ---------> Adopt Info.
     from DHCP             +-----------+            from DNS
      (2), (7)                                      (5), (8)

        Abbreviations:
          Ans.: Answer
          Info.: Information
          KRB: Kerberos





Sakane & Ishiyama                                               [Page 9]

Internet-Draft                                             February 2010


   1) At the first, the client asks both DNS and KRB information to the
      DHCP server.

   2) If the client gets only a response with KRB information from the
      DHCP server, the client adopts the information from the DHCP
      server.

   3) As the result of (1), if the client gets either no answer or only
      a response with DNS information from the DHCP server, the client
      then asks KRB information to the DNS server.

   4) If the client gets no answer from the DNS server, then the client
      will abort.

   5) If the client gets KRB information from the DNS server, then the
      client adopts the information from the DNS server.

   6) As the result of (1), if the client gets both DNS and KRB
      information from the DHCP server, then the client asks KRB
      information to the DNS server.

   7) If the client gets no answer from the DNS server, the client
      adopts the KRB information from the DHCP server.

   8) As the result of (6), if the client gets KRB information from the
      DNS server, the client adopts the information instead of another
      from the DHCP server.


4.  Server Operation

   After the DHCPv6 server receives a message which is contained an
   Option Request Option, what information the server will provide
   depends on the policy of the server in the end.  If there is no
   criteria on the server, the following operation is recommended.

   The server SHOULD send a Reply Message back to the client when the
   option number of the Kerberos option is specified in the Option
   Request option by the client.

   When the message did not include any information which can be used to
   determine data for a specific client, the server SHOULD reply at
   least a realm name sub-option as a default realm.  The form of the
   Kerberos option in this case is:







Sakane & Ishiyama                                              [Page 10]

Internet-Draft                                             February 2010


       (Kerberos option) | (Realm Name sub-option)

             '|' means concatenation.

   When the server determines to reply a set of addresses of the KDC by
   its configuration or by information specified in the message, the
   server SHOULD reply the KDC sub-options.  The Kerberos option MUST
   contain the Realm Name sub-option followed by a set of the KDC sub-
   options.  The form of the Kerberos option in this case is:

      (Kerberos option |
         (Realm Name sub-option) |
         (KDC sub-option) [| (KDC sub-option) [|...]]

         '|' means concatenation.
         '[|...]' means other sub-options might be optionally
                 concatenated.

   When the server decided to provide different multiple Realms and a
   set of IP addresses of each KDCs by its configuration, the server
   SHOULD list a set of the Realm Name sub-option and a set of the
   corresponding KDC sub-options.  The form of the Kerberos option in
   this case is:

      (Kerberos option |
         (Realm Name sub-option) |
         (KDC sub-option) [| (KDC sub-option) [|...]]
         (Realm Name sub-option) |
         (KDC sub-option) [| (KDC sub-option) [|...]]

         '|' means concatenation.
         '[|...]' means other sub-options might be optionally
                 concatenated.

   When the server does not have any information to be responded to the
   client the server SHOULD send the Kerberos option which does not
   contain any sub-option.  This behavior prevents the client from
   retransmitting the Information-request message indefinitely.


5.  Appearance of this option

   The Kerberos option MUST NOT appear in any other than the following
   messages: Solicit, Advertise, Request, Renew, Rebind, Information-
   request and Reply.  The option MAY also appear in the DHCP-relay-
   message field of both Relay-forward or Relay-reply message.  If this
   option appears in messages other than those specified above, the
   receiver MUST ignore it.



Sakane & Ishiyama                                              [Page 11]

Internet-Draft                                             February 2010


   The number of the Kerberos option MAY appear in the Option Request
   Option in the DHCPv6 message types Solicit, Request, Renew, Rebind,
   Information-request and Reconfigure.  The number MAY also appear in
   the DHCP-relay-message field of both Relay-forward or Relay-reply
   message.

   The sub-option of the Kerberos option MUST appear only in the
   Kerberos option.


6.  IANA Considerations

   When this document is published, the IANA is requested to assign an
   option code from the option-code space defined in "DHCPv6 Options"
   section of [RFC3315] for the Kerberos option named OPTION_KRB.

   The IANA is also requested to create a new name space "DHCPv6
   Kerberos Sub-option Codes", and these sub-options should be placed
   under the same registry.

          o Reserved                                 0
          o SUB_OPTION_REALM_NAME                    1
          o SUB_OPTION_KDC                           2
          o SUB_OPTION_CLIENT_NAME                   3
          o Reserved                                 4 - 65535



7.  Security Considerations

   The security considerations in RFC 3315 fully apply.  The message of
   DHCPv6 could be altered undesirably.  If an adversary modifies the
   response from a DHCPv6 server or inserts its own response, a client
   could be led to contact a rogue KDC or a server which does not know
   the client access.  Both cases are categorized into a kind of the
   denial of service attack.  However, such incorrect KDC does not know
   the shared key between the client and a valid KDC.  The incorrect KDC
   is not be able to proceed any further state of the client.  Even when
   the client receives a response from such KDC, the client can know the
   fact that it has received an inappropriate message after it verifies
   the response with the shared key.  In order to minimize potential
   vulnerabilities, a client SHOULD require to use the DHCPv6
   authentication defined in section 21 of RFC 3315, or any other
   authentication mechanism.

   Sometimes, the Kerberos information is manually configured into the
   client before the DHCPv6 process starts.  Generally, the manual
   configuration to the device should be preferred to the configuration



Sakane & Ishiyama                                              [Page 12]

Internet-Draft                                             February 2010


   by the DHCP server.  Overwriting the manual configuration should be
   considered in anytime.


8.  Acknowledgments

   The authors are very grateful to Nobuo Okabe and Shigeya Suzuki.
   They contributed the summary explaining why DNS is not appropriate to
   the Industry networks, which is put as the appendix of this document.
   Ken'ichi Kamada and Yukiyo Akisada contributed for the initial work
   of making this document.  The authors also thank Jeffrey Hutzelman,
   Kazunori Miyazawa, Kensuke Hosoya, Nicolas Williams, Nobumichi Ozoe,
   and Sam Hartman.  They gave us valuable comments and suggestions for
   this document.


9.  References


9.1.  Normative References

   [RFC2119]
      Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]
      A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the
      location of services (DNS SRV)", RFC 2782, February 2000.

   [RFC3315]
      R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney.
      "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315,
      July 2003.

   [RFC3736]
      R. Droms, "Stateless Dynamic Host Configuration Protocol (DHCP)
      Service for IPv6", RFC 3736, April 2004.

   [RFC4120]
      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
      Network Authentication Service (V5)", RFC 4120, July 2005.


9.2.  Informative References

   [PCARCH]
      "PacketCable 1.0 Architecture Framework Technical Report", PKT-TR-
      ARCH-V01-991201, http://www.packetcable.com/downloads/specs/pkt-



Sakane & Ishiyama                                              [Page 13]

Internet-Draft                                             February 2010


      tr-arch-v01-991201.pdf

   [RFC3634]
      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.

   [RFC5021]
      Josefsson, S., "Extended Kerberos Version 5 Key Distribution
      Center (KDC) Exchanges over TCP", RFC 5021, August 2007.

   [STARTTLS]
      Josefsson, S., "Using Kerberos V5 over the Transport Layer
      Security (TLS) protocol", draft-josefsson-kerberos5-starttls-07
      (work in progress), July 2009.

Appendix A. Why DNS is not acceptable in some environment

































Sakane & Ishiyama                                              [Page 14]

Internet-Draft                                             February 2010


   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.



Sakane & Ishiyama                                              [Page 15]

Internet-Draft                                             February 2010


      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 a single large process automation system:
           About 20000 field devices over 2km*2km area

           References:
              - http://www.process-worldwide.com/fachartikel/pw_facha
                rtikel_2699276.html

         - An example of a distributed process automation systems:
           About 30000 field devices for 26 distributed sites
           over 30km*30km area.

           References:
              - http://www.mikrocentrum.nl/FilesPage/3462/Presentatie
                %20C3-1.pdf
              - http://www.nam.nl/home/Framework?siteId=nam-en&FC2=/n
                am-en/html/iwgen/algemeen/zzz_lhn.html&FC3=/nam-en/ht
                ml/iwgen/algemeen/over_de_nam.html

         - An example of a single large building automation system:
           170000 control points of 16500 field devices in
           729,000 sq. meters (7.8 million sq. ft.) building complex.

           References:
              - http://www.echelon.com/company/press/2003/echelon_mor
                i.htm

      2) Reducing the chance of human error.

      3) Making disaster-recovery easier.

   3.3. Security mechanism suited to resource-limited devices are
        necessary.



Sakane & Ishiyama                                              [Page 16]

Internet-Draft                                             February 2010


      Kerberos-based security can be suited resource-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
      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 the
   process
      automation systems and Device ID is the common logical identifier
      for the building automation 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



Sakane & Ishiyama                                              [Page 17]

Internet-Draft                                             February 2010


Authors' Addresses

   Shoichi Sakane
   Yokogawa Electric Corporation
   2-9-32 Nakacho, Musashino-shi,
   Tokyo  180-8750 Japan
   E-mail: Shouichi.Sakane@jp.yokogawa.com


    Masahiro Ishiyama
    Toshiba Corporation
    1, komukai-toshiba-cho, Saiwai-ku,
    Kawasaki  212-8582 Japan
    E-mail: masahiro@isl.rdc.toshiba.co.jp





































Sakane & Ishiyama                                              [Page 18]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/