RFC 6784 PROPOSED STANDARD DHCPV6 · KERBEROS · CONFIGURATION
Kerberos DHCPv6 options: Kerberos Options for DHCPv6
Four DHCPv6 options that tell a client which Kerberos realm and key servers to use.
RFC EDITOR
Sakane, S. and M. Ishiyama, "Kerberos Options for DHCPv6", RFC 6784, DOI 10.17487/RFC6784, November 2012, <https://www.rfc-editor.org/info/rfc6784>.
BIBTEX
@misc{rfc6784,
series = {Request for Comments},
number = 6784,
howpublished = {RFC 6784},
publisher = {RFC Editor},
doi = {10.17487/RFC6784},
url = {https://www.rfc-editor.org/info/rfc6784},
author = {S. Sakane and M. Ishiyama},
title = {{Kerberos Options for DHCPv6}},
pagetotal = 12,
year = 2012,
month = nov,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Sakane
Request for Comments: 6784 Cisco Systems
Category: Standards Track M. Ishiyama
ISSN: 2070-1721 Toshiba Corporation
November 2012
Kerberos Options for DHCPv6
Abstract
This document defines four new options for the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6). These options are used to
carry configuration information for Kerberos.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6784.
Copyright Notice
Copyright (c) 2012 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
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Kerberos Options ................................................4
3.1. Kerberos Principal Name Option .............................4
3.2. Kerberos Realm Name Option .................................5
3.3. Kerberos Default Realm Name Option .........................6
3.4. Kerberos KDC Option ........................................6
4. Client and Server Operation .....................................7
4.1. KDC Discovery for a Client .................................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Appendix A. An Example of the Operation of the Client .............11
1. Introduction
Kerberos Version 5 [RFC4120] is a trusted third-party authentication
system. Each organization wishing to use Kerberos establishes its
own "realm", and each client is registered as part of that realm. At
least one Key Distribution Center (KDC) is required for the operation
of a Kerberos realm.
When a client wishes to communicate with, and be authenticated to, a
Kerberos application server (also a client of the KDC), the client
identifies itself, and its realm, to the KDC and acquires a
credential from the KDC. The client then presents the credential to
the Kerberos application server, which can use the credential to
authenticate the client. The client needs to know at least one IP
address for a KDC in order to initiate this process.
One example of the application of this protocol is as follows. A
student might want to use a shared, public workstation, one that is
not configured for Kerberos. If there is a mechanism for the
workstation to obtain a realm name and IP address for a KDC, then a
student need only input a user-id and pass phrase to be able to use
Kerberos.
The Kerberos V5 specification [RFC4120] defines the use of DNS SRV
records [RFC2782] for KDC discovery. Some systems, such as
industrial systems, do not use DNS. Such systems already have their
own name spaces and their own name resolution systems, including
preconfigured mapping tables for devices, and do not use Fully
Qualified Domain Names. However, many of these systems do use DHCP.
Adding a DNS server to such systems may decrease the reliability of
the system and increase the management cost. In such an environment,
another mechanism is needed to provide an IP address for the KDC.
For the PacketCable Architecture [PCARCH], RFC 3634 [RFC3634] defines
the KDC Server Address sub-option for the DHCPv4 CableLabs Client
Configuration option. However, a mechanism is still needed to
provide a realm name and an IPv6 address -- one that does not depend
on any external architecture.
This document defines a Kerberos option for DHCPv6 that provides a
realm name and/or a list of KDC IP addresses. This option does not
replace or modify any of the existing methods for obtaining this
information.
2. 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 DHCPv6 [RFC3315], Kerberos V5 [RFC4120], and
DNS SRV [RFC2782].
3. Kerberos Options
This document defines four DHCPv6 configuration parameters for
Kerberos.
Kerberos Principal Name Option
Kerberos Realm Name Option
Kerberos Default Realm Name Option
Kerberos KDC Option
This section describes the format of each option and the usage of
each field in that option.
These options, except for the Kerberos KDC Option, MUST NOT appear
more than once in a DHCPv6 message.
3.1. Kerberos Principal Name Option
The Kerberos Principal Name Option carries the name of a Kerberos
principal. This is sent by the client to the DHCPv6 server, which
MAY use it to select a specific set of configuration parameters,
either for a client or for a Kerberos application server.
The format of the Kerberos Principal Name 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_PRINCIPAL_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: principal-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_PRINCIPAL_NAME (75)
o option-len (16 bits): length of the principal-name field.
o principal-name (variable): a client principal name. The encoding
of the principal-name field MUST conform to the definition of
"PrincipalName" in Section 5.2.2 of RFC 4120 [RFC4120].
3.2. Kerberos Realm Name Option
The Kerberos Realm Name Option carries a Kerberos realm name. A
DHCPv6 client uses this option to specify to a DHCPv6 server which
realm the client wants to access.
The format of the Kerberos Realm Name 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_REALM_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_REALM_NAME (76)
o option-len (16 bits): the length of the realm-name field in
octets.
o realm-name (variable): a realm-name. The encoding of the
realm-name field MUST conform to the definition of "Realm" in
Section 5.2.2 of RFC 4120 [RFC4120].
3.3. Kerberos Default Realm Name Option
The Kerberos Default Realm Name Option is used to specify a default
realm name for the Kerberos system. A DHCPv6 server uses this option
to specify the default realm name to both clients and Kerberos
application servers.
The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME (77).
The format and usage of the option-len and realm-name fields are
identical to those for the Kerberos Realm Name Option.
3.4. Kerberos KDC Option
The Kerberos KDC Option is used to provide configuration information
about a KDC.
The format of the Kerberos 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_KRB_KDC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Type| Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| KDC IPv6 address +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_KDC (78)
o option-len (16 bits): 23 + the length of the realm-name field in
octets.
o Priority (16 bits): see the description of the Weight field.
o Weight (16 bits): the Priority and Weight fields provide a hint to
the client as to which KDC to select. The usage of the Priority
and Weight values MUST follow the specification for DNS SRV
[RFC2782].
o Transport Type (8 bits): The Transport Type specifies the
transport protocol used for Kerberos. Kerberos [RFC4120] defines
UDP and TCP transports. Exchanges over TCP are further described
in [RFC5021], while the transport of Kerberos over Transport Layer
Security (TLS) is described in [RFC6251].
The transport type is defined below.
Value Transport Type
---- --------------
0 Reserved
1 UDP
2 TCP
3 TLS
4-254 Unassigned
255 Reserved
o Port Number (16 bits): the port number on which the KDC listens.
o KDC IPv6 address (128 bits): the IPv6 address of the KDC.
o realm-name (variable): the name of the realm for which the
specified KDC provides service. The encoding of the realm-name
field MUST conform to the definition of "Realm" in Section 5.2.2
of RFC 4120 [RFC4120].
4. Client and Server Operation
This section describes the operations of the client and server. It
assumes that the client has been configured with a principal name.
If a client requires a realm name, the client sends a DHCPv6 Option
Request Option (ORO) specifying the Kerberos Default Realm Name
Option. The DHCPv6 server responds with a Reply message containing a
Kerberos Default Realm Name Option.
If a client requires configuration parameters for a KDC, the client
sends a DHCPv6 ORO specifying the Kerberos KDC Option. The client
MAY include a Kerberos Principal Name Option. The client MAY include
a Kerberos Realm Name Option.
The DHCPv6 server replies with one or more sets of configuration
parameters for a Kerberos KDC. If the client has specified either a
Kerberos Principal Name Option or a Kerberos Realm Name Option, then
the DHCPv6 server MAY use those parameters to select specific sets of
configuration parameters.
Where the server replies with more than one set of configuration
parameters, the usage of the Priority and Weight fields by the client
MUST follow the specification for DNS SRV [RFC2782].
The client MAY include other options with data values as hints to the
DHCPv6 server about parameter values the client would like to have
returned; this is specified in Section 18.1.5 of RFC 3315 [RFC3315].
4.1. KDC Discovery for a Client
When a client implements both the DNS method defined by
Section 7.2.3.2 of [RFC4120] and the DHCP method defined by this
document, the choice of method is determined by local policy. The
administrator of the realm usually defines the method as part of the
configuration of the client before the client is installed.
When no criteria have been specified and the client could get the
Kerberos information from either the DNS server or the DHCPv6 server,
then the information from DNS SHOULD be preferred.
5. IANA Considerations
IANA has assigned four option codes from the DHCPv6 Option Codes
registry for the following:
75 OPTION_KRB_PRINCIPAL_NAME
76 OPTION_KRB_REALM_NAME
77 OPTION_KRB_DEFAULT_REALM_NAME
78 OPTION_KRB_KDC
IANA has created the Kerberos Message Transport Types sub-registry,
under the Kerberos Parameters registry. The initial entries are
described in Section 3.4.
The assignment of future entries is by "IETF Review" policy as
described in BCP 26 [RFC5226]. Per that policy, a document specifies
the symbolic name of such entries, which are assigned numeric codes
by IANA once publication is approved.
6. Security Considerations
The security considerations in RFC 3315 [RFC3315] apply.
DHCPv6 messages can be modified in transit. If an adversary modifies
the response from a DHCPv6 server or injects its own response, a
client may be led into contacting a malicious KDC. Both cases are
categorized as a Denial-of-Service (DoS) attack. However, a
malicious KDC does not know the shared key and so is unable to
proceed any further with the exchange. If a client receives a
response from such a KDC, the client can use the shared key to detect
that the message originates from a malicious KDC.
A shared, unconfigured workstation may obtain its KDC information,
and default realm, via DHCPv6. Such a workstation may not have a
host or other service key, and thus it may be unable to validate the
Ticket-Granting Ticket issued by the KDC. A modified DHCPv6 response
would then result in the workstation talking to a malicious KDC, and
the workstation would not be able to detect that this has happened.
This in turn could allow access by unauthorized users.
To minimize potential vulnerabilities, a client SHOULD use DHCPv6
authentication as defined in Section 21 of RFC 3315 [RFC3315].
Kerberos information may be manually configured on the client before
requesting information from DHCPv6. Manual configuration of the
device SHOULD be preferred to configuration via the DHCPv6 server.
7. Acknowledgments
The authors are very grateful to Nobuo Okabe and Shigeya Suzuki.
They contributed the explanation as to why DNS is inappropriate for
some industry networks. Ted Lemon made many suggestions to improve
DHCP aspects of this specification. Ken'ichi Kamada and Yukiyo
Akisada contributed to the initial work on this document. Tom Petch
helped to improve the readability of this document. The authors also
thank Jeffrey Hutzelman, Kazunori Miyazawa, Kensuke Hosoya, Nicolas
Williams, Nobumichi Ozoe, Sam Hartman, and Stephen Farrell. They
made valuable comments and suggestions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key
Distribution Center (KDC) Exchanges over TCP", RFC 5021,
August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
8.2. Informative References
[PCARCH] CableLabs, "PacketCable 1.0(TM) Architecture Framework
Technical Report", December 1999,
<http://www.packetcable.com/downloads/specs/
pkt-tr-arch-v01-991201.pdf>.
[RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and 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.
[RFC6251] Josefsson, S., "Using Kerberos Version 5 over the
Transport Layer Security (TLS) Protocol", RFC 6251,
May 2011.
Appendix A. An Example of the Operation of the Client
When no criteria have been specified and the client could get the
Kerberos information from either the DNS server or the DHCPv6 server,
then the information from DNS SHOULD be preferred. The following is
an informational guide for the client in such an environment.
No Resp. or
+------------+ DNS Info. +-----------+ No Resp.
Start --> | Ask DHCP(1)| ---------> | Ask DNS(3)| ------>
+------------+ +-----------+ Terminate(4)
/ \ \
Only KRB / \ DNS and \ KRB Info.
Info. / \ KRB Info. \
/ \ \
| | |
| V |
V No Ans. +-----------+ KRB Info. V
Use Info. <-------- | Ask DNS(6)| ---------> Use Info.
from DHCP +-----------+ from DNS
(2), (7) (5), (8)
Abbreviations:
Resp.: Response
Info.: Information
KRB : Kerberos
1) Initially, the client requests both DNS and Kerberos information
from the DHCPv6 server.
2) If the DHCPv6 server replies with Kerberos information and not
with DNS information, then the client uses that information.
3) If the DHCPv6 server does not reply or replies with only DNS
information, then the client requests Kerberos information from
the DNS server.
4) If the client gets no response or no Kerberos information from
the DNS server, then the client terminates the process.
5) If the client gets Kerberos information from the DNS server, then
the client uses that information.
6) If, as the result of (1), the DHCPv6 server replies with both DNS
and Kerberos information, then the client requests Kerberos
information from the DNS server.
7) If the client gets no response from the DNS server, then the
client uses the Kerberos information from the DHCPv6 server.
8) If, as the result of (6), the DNS server replies with Kerberos
information, then the client uses the information from the DNS
server and not that from the DHCPv6 server.
Authors' Addresses
Shoichi Sakane
Cisco Systems
9-7-1 Akasaka
Minato-ku, Tokyo 107-6227
Japan
EMail: ssakane@cisco.com
Masahiro Ishiyama
Toshiba Corporation
1, Komukai-toshiba-cho, Saiwai-ku,
Kawasaki, Kanagawa 212-8582
Japan
EMail: masahiro.ishiyama@toshiba.co.jp
AI ELI5
On this page
PROBLEMA Kerberos client needs a realm name and the address of a Key Distribution Center, but some networks, such as industrial systems, do not use DNS, which is the standard way to find a KDC.
MECHANISMRFC 6784 defines four DHCPv6 options (option codes 75 to 78) that carry a principal name, a realm name, a default realm name and KDC details such as priority, weight, transport, port and IPv6 address.
WHY IT MATTERSA client can get Kerberos settings from its DHCPv6 server without DNS. Where DNS is also available, DNS information SHOULD be preferred when no other criteria apply.
§1Finding Kerberos Without DNS
In Kerberos Version 5 (RFC 4120), each organization runs a realm, and at least one Key Distribution Center (KDC) is needed. A client must know at least one KDC IP address before it can get a credential and prove who it is to an application server.
RFC 4120 defines DNS SRV records (RFC 2782) for finding a KDC. Some systems, such as industrial ones, do not use DNS, and adding a DNS server may reduce reliability and raise management cost. Many of those systems do use DHCP. For DHCPv4 in PacketCable, RFC 3634 already defined a KDC address sub-option, but a mechanism with a realm name and an IPv6 address that does not depend on another architecture was still missing.
This document fills that gap. It does not replace or modify existing ways to get this information.
Usually a computer looks up the login server in a phone book (DNS). Some networks have no phone book, so the helper that hands out network settings tells the computer directly.
§3The Four Options
Four options are defined, all with a 16-bit option code and a 16-bit option-len. Except for the KDC option, none may appear more than once in a DHCPv6 message.
- Kerberos Principal Name (
OPTION_KRB_PRINCIPAL_NAME, 75): sent by the client; the server MAY use it to choose configuration parameters. The name MUST follow PrincipalName in Section 5.2.2 of RFC 4120. - Kerberos Realm Name (
OPTION_KRB_REALM_NAME, 76): the realm the client wants to access. - Kerberos Default Realm Name (
OPTION_KRB_DEFAULT_REALM_NAME, 77): used by a server to give the default realm to clients and application servers. Its format is the same as the Realm Name option. - Kerberos KDC (
OPTION_KRB_KDC, 78): configuration information about one KDC.
Realm names MUST follow the definition of Realm in Section 5.2.2 of RFC 4120.
There are four kinds of notes: who I am, which login area I want, the default login area, and where the login server is.
- 75OPTION_KRB_PRINCIPAL_NAME — Client principal name, sent by the client.
- 76OPTION_KRB_REALM_NAME — Realm the client wants to access.
- 77OPTION_KRB_DEFAULT_REALM_NAME — Default realm named by the server.
- 78OPTION_KRB_KDC — Configuration for a KDC.
§4The KDC Option Fields
The KDC option carries Priority and Weight (16 bits each), a Transport Type (8 bits), a Port Number (16 bits), the KDC IPv6 address (128 bits) and a variable-length realm name for which the KDC serves. The option-len is 23 plus the length of the realm name in octets.
Priority and Weight are hints for choosing a KDC, and their use MUST follow DNS SRV (RFC 2782). Transport Type says whether to use UDP (1), TCP (2) or TLS (3); 0 and 255 are reserved and 4 to 254 are unassigned. TCP exchanges are described in RFC 5021, and Kerberos over TLS in RFC 6251.
The KDC note says where the login server lives, how to talk to it, which door number to knock on, and which server to try first if there are several.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
OPTION-CODE | Option Code | 2 bytes | 78 | OPTION_KRB_KDC (78). |
OPTION-LEN | Option Length | 2 bytes | 23 plus the length of the realm name in octets. | |
PRIORITY | Priority | 2 bytes | Hint for KDC selection, as in DNS SRV. | |
WEIGHT | Weight | 2 bytes | Hint for KDC selection, as in DNS SRV. | |
TRANSPORT | Transport Type | 1 byte | 1 UDP, 2 TCP, 3 TLS. | |
PORT | Port Number | 2 bytes | Port on which the KDC listens. | |
ADDRESS | KDC IPv6 Address | 16 bytes | IPv6 address of the KDC. |
§5Client and Server Operation
The text assumes the client is already configured with a principal name. If the client needs a realm name, it sends a DHCPv6 Option Request Option (ORO) naming the Default Realm Name option, and the server answers with a Reply containing that option.
If the client needs KDC settings, it sends an ORO naming the KDC option. It MAY also include a Principal Name option and a Realm Name option. The server replies with one or more sets of KDC parameters and MAY use the principal or realm to select among them. When more than one set is returned, the client MUST use Priority and Weight as DNS SRV specifies.
If a client supports both DNS discovery and this DHCP method, local policy decides, usually set by the realm administrator before installation. With no criteria given, DNS information SHOULD be preferred. An appendix gives an informative decision flow for such a client.
The computer asks the helper, 'Which login area is default?' or 'Where is the login server?' and the helper answers with the right notes.
§6IANA Considerations
IANA assigned four option codes in the DHCPv6 Option Codes registry: 75 OPTION_KRB_PRINCIPAL_NAME, 76 OPTION_KRB_REALM_NAME, 77 OPTION_KRB_DEFAULT_REALM_NAME and 78 OPTION_KRB_KDC.
IANA also created the Kerberos Message Transport Types sub-registry under the Kerberos Parameters registry, with initial entries as in the KDC option. Future entries are assigned by the IETF Review policy of BCP 26 (RFC 5226).
IANA is the librarian who keeps the official list of numbers. It gave these four notes the numbers 75, 76, 77 and 78.
§7Security Considerations
The security considerations of RFC 3315 apply. DHCPv6 messages can be modified in transit, so an attacker who alters or injects a reply could lead a client to a malicious KDC. The RFC treats this as a denial-of-service attack, because a malicious KDC does not know the shared key and cannot go further, and a client holding the shared key can detect it.
A shared, unconfigured workstation may lack a host or service key and so cannot validate the Ticket-Granting Ticket. It would not notice a malicious KDC, which could allow access by unauthorized users.
To reduce the risk, a client SHOULD use DHCPv6 authentication from Section 21 of RFC 3315. Manual configuration of Kerberos information SHOULD be preferred to configuration through the DHCPv6 server.
If a trickster slips the computer a fake note, it could be sent to a fake login desk. Using a secret handshake with the helper, or setting things up by hand, is safer.
§7References
[RFC4120]RFC 4120Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.July 2005[RFC3315]RFC 3315Droms, R., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.July 2003[RFC2782]RFC 2782Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.February 2000[RFC5021]RFC 5021Josefsson, S., "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP", RFC 5021, August 2007.August 2007[RFC6251]RFC 6251Josefsson, S., "Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol", RFC 6251, May 2011.May 2011[RFC3634]RFC 3634Luehrs, K., et al., "Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option", RFC 3634, December 2003.December 2003