INTERNET-DRAFT S. Sakane
Intended Status: Informational Yokogawa Electric Corp.
Expires: September 12, 2009 M. Ishiyama
Toshiba Corp.
March 11, 2009
Kerberos Option for DHCPv6
draft-sakane-dhc-dhcpv6-kdc-option-04.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 September 12, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (
http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Sakane & Ishiyama [Page 1]
Internet-Draft March 2009
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 March 2009
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 ........................ 7
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. Specification Issue Consideration ............................ 12
6.1. Providing a Service Type ................................ 12
6.2. Other configuration values to be provided ............... 13
6.3. Providing IPv4 Address .................................. 13
6.4. Behavior when there is no information ................... 14
7. IANA Considerations .......................................... 14
8. Security Considerations ...................................... 15
9. Acknowledgments .............................................. 15
10. References ................................................... 15
10.1. Normative References ................................... 16
Appendix A. Why DNS is not acceptable in some environment ........ 16
Authors' Addresses ............................................... 20
Sakane & Ishiyama [Page 3]
Internet-Draft March 2009
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 more
than 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 the credential, 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 its realm name, and at
least more than one IP address of KDC from which the client can get
the credential, before the client begins the communication with the
peer.
An example case for providing a realm name is that 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
to the workstation, a student only puts a user identifier and a pass
phrase into the workstation, and can user the Kerberos authentication
system.
For providing 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
Sakane & Ishiyama [Page 4]
Internet-Draft March 2009
provide a realm name and/or a list of IP addresses of the KDC. The
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 more than one sub-option
defined in this document. This document defines the Realm Name sub-
option, the KDC sub-option and the Client Principal Name sub-option.
Any other sub-option may be defined in other documents.
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: OPTION_KRB (TBD by IANA)
o option-len: 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. Any
other sub-options my be defined in the future.
Realm Name sub-option
KDC sub-option
Client Principal Name sub-option
2.1. Realm Name Sub-Option
The Realm Name sub-option provides a realm name. The encoding of the
realm-name field MUST be conformed to "Realm" defined in section
5.2.2 of RFC 4120. In fact, it is "KerberosString" defined in
section 5.2.1 of RFC 4120. The naming constraints MUST be conformed
to section 6.1 of RFC 4120.
Sakane & Ishiyama [Page 5]
Internet-Draft March 2009
The format of the realm 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_REALM_NAME | sub-opt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | |
+-+-+-+-+-+-+-+-+ |
: :
: realm-name (variable) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o sub-option-code: SUB_OPTION_REALM_NAME (TBD by IANA)
o sub-opt-len: length of the realm-name field in octets.
o Flags: indicates specific options of the Realm sub-option.
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
| Reserved |D|
+-+-+-+-+-+-+-+-+
This document only defines the default realm bit (bit 0). When
the default realm bit is set to 1, 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 is defined in
section 5.2.2 of RFC4120.
2.2. KDC Sub-Option
The KDC sub-option provides an address of the KDC, a weight and a
port number. See section of the Specification Issue Consideration
for discussion of providing a service type of the Kerberos protocol.
The format of the KDC sub-option is:
Sakane & Ishiyama [Page 6]
Internet-Draft March 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: KDC address (16) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o sub-option-code: SUB_OPTION_KDC (TBD by IANA)
o sub-opt-len: 8 + length of the KDC address field in octets.
o Weight: a value for a server selection mechanism. It specifies 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 Port Number: a port number listened to by the KDC
o KDC address (16): an IPv6 address of the KDC
2.3. Client Principal Name Sub-Option
The Kerberos protocol uses a "principal identifier" as the client
identifier. A principal identifier consists of both a principal name
and a Realm name. It is desirable to use the principal name in order
that the server determines a specific Kerberos information for the
client. The Client Principal Name sub-option provides 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.
The naming constraints MUST be conformed to section 6.2 of RFC 4120
as well.
Sakane & Ishiyama [Page 7]
Internet-Draft March 2009
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: SUB_OPTION_CLIENT_NAME (TBD by IANA)
o sub-opt-len: 4 + length of the name-string field.
o principal-name (variable): a client principal name. The encoding
is defined in section 5.2.2 of 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. If the client wants to get a specific information
related to its own client principal name, the client MUST put own
principal name into the Client Principal Name sub-option of the
Kerberos option.
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].
Sakane & Ishiyama [Page 8]
Internet-Draft March 2009
3.1. A recommendation of KDC discovery for a client
When a client has a capability of both the DNS method defined by RFC
4120 and the DHCP method defined this document, which methods the
client should use to get the kerberos information 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
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.
Sakane & Ishiyama [Page 9]
Internet-Draft March 2009
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 for example. The
form of the Kerberos option in this case is:
(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. Essentially, the priority
is specified by the value of the priority field in the KDC sub-
option. The Kerberos option is followed by the Realm Name sub-option
followed by a set of the KDC sub-options. The form of the Kerberos
option in this case is:
Sakane & Ishiyama [Page 10]
Internet-Draft March 2009
(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
must list a pair of a 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.
If there is no information related to the Kerberos option in the
server's DHCPv6 configuration database, See the section of "the
behavior when there is no information" in this document.
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.
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.
Sakane & Ishiyama [Page 11]
Internet-Draft March 2009
6. Specification Issue Consideration
This section discusses what we should have to further consider for
specifying the Kerberos option. We are expecting any input from
experts to solve below issues. This section will be removed after
the specification is clear or the issues are solved.
6.1. Providing a Service Type
The Service Type specifies the transport medium of the Kerberos
communication. The Kerberos specification [RFC4120] defines to use
UDP and TCP for communication between clients and servers. Other
transports are not defined in RFC 4120. However, SCTP might be used
in the future. In addition, the Heimdal implementation can use HTTP
as a transport type for that purpose.
The Service Type should be put into each KDC sub-option if required.
To put it into the KDC sub-option, the "Weight" field could be
shortened to 8-bit from 16-bit. And the Service Type could put the
place immediately after the Weight field.
If the Service Type is required and above proposals are accepted, the
form of the KDC sub-option becomes like the following:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | Service Type | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: KDC address :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Service Type: the value of the type is defined in below.
Reserved 0
UDP 1 (default)
TCP 2
SCTP 3
HTTP 4
Reserved 5-15
Sakane & Ishiyama [Page 12]
Internet-Draft March 2009
6.2. Other configuration values to be provided
CableLabs Configuration Option [RFC3495] is the option using in the
PacketLabs Architecture [PCARCH]. This option can provide a timer
and a counter to a client. These are used to determine how long time
the client keeps trying to contact to the KDC for the Kerberos
processing until the KDC will respond, and how many times the client
needs to contact to the KDC for retrying. This option can also
provide a flag to determine whether or not the client needs to use
the special credential(ticket-granting ticket) to get a new
credential(application ticket) from the KDC. There is another
special sub-option can provide a FQDN of the KDC in the CableLabs
Registry.
The Kerberos option defined in this document can be added these
feature as its sub-option if these are needed. However, these
feature is out of scope of this document, and might be defined in
another document in the future.
6.3. Providing IPv4 Address
Basically, one of the purpose of this specification is to configure
an IPv6 client by using the DHCPv6 server. However, the address
family of the communication of any Kerberos service does not depend
on the address family of the DCHPv6 service. Essentially, the DHCPv6
server could provide a set of IPv4 addresses of the KDC by using the
KDC sub-option. As one solution to enable this, the sub-opt-len of
the KDC sub-option could be used to determine whether the KDC-address
contained in the sub-option is an IPv6 address or an IPv4 address.
If the length is 8 (fixed field length + IPv4 address length), it
means that the type of the address is IPv4. Another solution is to
add a field identifying the address family into the KDC sub-option.
It requires further 2 octets of the sub-option. This value [ADDRFAM]
is maintained by the IANA.
After deciding which type of IP address is provided by this
specification, one of the following description is added into this
document.
1) This document describes to configure a set of IPv6 addresses into
a host. To provide a set of IP addresses except of IPv6 address
is out of scope of this document.
2) This document describes to configure a set of IP addresses into a
host. The hint of the type of the address family is the value of
the sub-opt-len in the KDC sub-option. The type of the address
Sakane & Ishiyama [Page 13]
Internet-Draft March 2009
family have to be agreed within the system where this
specification is used, because the length of different address
family might be same.
3) This document describes to configure a set of IP addresses into a
host. The type of the address family is distinguished by the
address family identifier in the KDC sub-option.
Authors vote #1, currently.
6.4. Behavior when there is no information
This problem is not only issue for the Kerberos option. Actually, no
server's behavior is not defined in RFC 3315 when there is no
information in the server's configuration database related to an
option which is specified at an Option Request option from a client.
One solution in this case is that the server just send the option
which does not contain any sub-option to the client. Another
solution is that the server could just ignore the message. On the
other hand, there is another solution in section 18.2.5 of RFC 3315,
If the Information-request message received from the client
did not include a Client Identifier option, the server SHOULD
respond with a Reply message containing any configuration
parameters that are not determined by the client's identity.
If the server chooses not to respond, the client may continue
to retransmit the Information-request message indefinitely.
For the latter case, we need to define a new status code which means
"there is no information of the option in the ORO". And the server
sends it back to the client.
7. 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.
Sakane & Ishiyama [Page 14]
Internet-Draft March 2009
o Reserved 0
o SUB_OPTION_REALM_NAME 1
o SUB_OPTION_KDC 2
o SUB_OPTION_CLIENT_NAME 3
o Reserved 4 - 65535
8. 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
by the DHCP server. Overwriting the manual configuration should be
considered in anytime.
9. 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.
10. References
Sakane & Ishiyama [Page 15]
Internet-Draft March 2009
10.1. Normative References
[ADDRFAM] Internet Assigned Numbers Authority, "Protocol
Registries: Address Family Numbers",
http://www.iana.org/assignments/address-family-numbers/
[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.
[RFC3495] B. Beser, P. Duffy, Ed., "Dynamic Host Configuration
Protocol (DHCP) Option for CableLabs Client
Configuration", RFC 3495, March 2003.
[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.
[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.
[PCARCH] "PacketCable 1.0 Architecture Framework Technical
Report", PKT-TR-ARCH-V01-991201,
http://www.packetcable.com/downloads/specs/pkt-tr-arch-
v01-991201.pdf
Appendix A. Why DNS is not acceptable in some environment
Sakane & Ishiyama [Page 16]
Internet-Draft March 2009
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 17]
Internet-Draft March 2009
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 18]
Internet-Draft March 2009
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 19]
Internet-Draft March 2009
Authors' Addresses
Shoichi Sakane
Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi,
Tokyo 180-8750 Japan
E-mail:
[email protected]
Masahiro Ishiyama
Toshiba Corporation
1, komukai-toshiba-cho, Saiwai-ku,
Kawasaki 212-8582 Japan
E-mail:
[email protected]
Sakane & Ishiyama [Page 20]
