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]