Network Working Group T. Jinmei
Internet-Draft Toshiba
Expires: January 10, 2005 July 12, 2004
Clarifications on DHCPv6 Authentication
draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes issues about the DHCPv6 authentication
mechanism identified from implementation experiences. It also tries
to propose resolutions to some of the issues.
1. Introduction
Several questions arose on the authentication mechanism of DHCPv6
[RFC3315] from implementation experiences, particularly on its
delayed authentication protocol. Some of the questions may require a
change or addition to the current protocol, and one of them may even
Jinmei Expires January 10, 2005 [Page 1]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
cause discussions on a security threat.
This document describes the issues based on the questions, and tries
to propose resolutions for some of them, hoping the resolutions will
be merged, if valid and accepted, to the next version of the base
specification.
2. Usage with Information-Request
According to [RFC3315], it seems possible to use the authentication
mechanism for Information-request and Reply exchanges. The RFC says
in Section 21.4.4.4 as follows:
If the server has selected a key for the client in a previous
message exchange (see section 21.4.5.1), the client MUST use the
same key to generate the authentication information throughout the
session.
However, this description is not really clear. Section 21.4.5.1,
which is referred from the above part, actually describes the case of
Solicit and Advertise exchange:
21.4.5.1. Receiving Solicit Messages and Sending Advertise
Messages
The server selects a key for the client and includes
authentication information in the Advertise message returned to
the client as specified in section 21.4. [...]
It does not necessarily mean contradiction because the client and the
server may have exchanged Solicit and Advertised with authentication
before starting the Information-request and Reply exchange. However,
it then restricts the usage scenario of the authentication mechanism
for Information-request and Reply exchanges. In particular, this
assumption prohibits the use of the mechanism with the "stateless"
service using DHCPv6 [RFC3736]. Whereas the specification allows an
implementation that only supports the stateless service and does not
support Solicit and Advertise messages, the authentication mechanism
depends on Solicit and Advertise exchanges.
This fact can (partly) invalidate a security consideration in
[RFC3736]:
Authenticated DHCP, as described in sections 21 and 22.11 of the
DHCP specification [1], can be used to avoid attacks mounted
through the stateless DHCP service.
(where [1] refers to [RFC3315].) In fact, as was just shown above,
Jinmei Expires January 10, 2005 [Page 2]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
authenticated DHCP cannot be used unless the implementations also
support Solicit and Advertise messages (or the entire [RFC3315] in
general).
It should also be noted that [RFC3315] does not define how the server
should do when it receives an Information-request message containing
an authentication option; Section 21.4.5.2 excludes the
Information-request message.
2.1 Suggested Resolution
Considering the fact that [RFC3736] allows implementations that only
support the subset of the full specification [RFC3315], it should
make sense to define the authentication usage for Information-request
and Reply exchanges separately.
One significant difference between Information-request and other
"stateful" cases is that there is no explicit notion of "session" in
the former. In some cases, however, the same client and server may
exchange Information-request and Reply multiple times, where the
entire exchanges can be regarded as a "session". For example, the
client may want to get different configuration information in
multiple exchanges. Also, if the client and the server use the
lifetime option, [I-D.ietf-dhc-lifetime] they will restart exchanges
when the lifetime expires.
The proposed revision of Section 21.4.4.4 is therefore as follows:
21.4.4.4. Sending Information-request Messages
When the client sends an Information-request message and wishes to
use authentication, it includes an Authentication option with the
desired protocol, algorithm and RDM as described in section 21.4.
The client does not include any replay detection or authentication
information in the Authentication option.
If the client authenticated past exchanges of Information-request
and Reply, the client MAY reuse the same key used in the previous
exchanges to generate the authentication information. In this
case, the client generates authentication information for the
Information-request message as described in section 21.4.
Note that the keys used for these exchanges are separately managed
from the keys used for the other exchanges beginning with the
Solicit message when the two types of exchanges run concurrently,
while the two keys may happen to be the same. For example, replay
detection should be performed separately, and validation failure
for one type of exchanges does not affect the other.
Jinmei Expires January 10, 2005 [Page 3]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
Section 21.4.4.5 will also need to be revised. However, since this
section has a separate issue per se as will be discussed in Section
6, we do not discuss further details on this here.
The server side behavior needs to be described, too. Along with the
change to Section 21.4.4.4 above, we propose to add a new subsection
of Section 21.4.5:
21.4.5.x. Receiving Information-request Messages and Sending
Reply Messages
If the Information-request message includes an authentication
option without authentication information, the server selects a
key for the client and includes authentication information in the
Reply message returned to the client as specified in section 21.4.
The server MUST record the identifier of the key selected for the
client so that it can validate further Information-request
messages from the client if the client reuses the same key for the
future exchanges.
If the Information-request message includes an authentication
option with authentication information, the server uses the key
identified in the message and validates the message as specified
in section 21.4.2. If the message fails to pass the validation
test, the key identified by the authentication information of the
message is not identical to the key that the server used in the
previous exchange, or the server has not recorded a key for the
client, the server MUST discard the message and MAY choose to log
the validation failure.
If the message passes the validation test, the server responds to
the Reply message as described in section 18.2.5. The server MUST
include authentication information generated using the key just
selected or identified in the received message, as specified in
section 21.4.
Note that the keys used for these exchanges are separately managed
from the keys used for the other exchanges beginning with the
Solicit message when the two types of exchanges run concurrently
(See Section 21.4.4.4).
3. What If Replay Is Detected
It is not clear what the receiver should do when an attempt of replay
attack is detected from either Section 21.3 or Section 21.4.2 of
[RFC3315].
Jinmei Expires January 10, 2005 [Page 4]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
3.1 Suggested Resolution
It should be natural to discard a DHCP message containing an
authentication option whose replay detection field indicates a replay
attack.
Instead of concentrating on this particular case, we propose to
revise the entire second paragraph of Section 21.4.2 as follows:
To validate an incoming message, the receiver first checks that
the value in the replay detection field is acceptable according to
the replay detection method specified by the RDM field. If no
replay is detected, then the receiver computes the MAC as
described in [8]. The entire DHCP message (setting the MAC field
of the authentication option to 0) is used as input to the
HMAC-MD5 computation function. If the MAC computed by the
receiver matches the MAC contained in the authentication option,
the message regarded as valid. If the above procedure fails at
any stage, the receiver MUST discard the DHCP message.
4. Definition of Unauthenticated Messages
[RFC3315] uses the phrase of "unauthenticated message(s)" in Sections
21.4.4.2 and 21.4.4.5 without formally defining the term. A
reasonable interpretation of the phrase is probably as follows: a
DHCPv6 message is called unauthenticated when it fails the validation
test described in Section 21.4.2, it does not contain an
authentication option, or when it includes an authentication option
but does not have authentication information when necessary.
In this document, we assume the above interpretation.
5. Inconsistent Behavior for Unauthenticated Messages
[RFC3315] says in Section 21.4.2 (Message Validation) as follows:
If the MAC computed by the receiver does not match the MAC
contained in the authentication option, the receiver MUST discard
the DHCP message.
On the other hand, Section 21.4.4.2 allows the client to respond to
an Advertise even if it fails to authenticate the message:
Client behavior, if no Advertise messages include authentication
information or pass the validation test, is controlled by local
policy on the client. According to client policy, the client MAY
choose to respond to an Advertise message that has not been
authenticated.
Jinmei Expires January 10, 2005 [Page 5]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
This seems to say, for example, that the client MAY accept an
Advertise message based on its local policy, even if the MAC computed
by the receiver does not match the MAC contained in the
authentication option. Apparently this contradicts with the
requirement in Section 21.4.2.
5.1 Suggested Resolution
There seems to be no valid reason for accepting an Advertise message
if it fails validation. On the other hand, it may make sense in some
cases that the client accepts the other type of unauthenticated
messages, that is, messages that do not include an authentication
option.
The suggested change to Section 21.4.4.2 is thus as follows. We use
a new term "non-authenticated messages" meaning DHCPv6 messages that
do not contain an authentication option.
[...]
Client behavior, if no Advertise messages include authentication
information is controlled by local policy on the client.
According to client policy, the client MAY choose to respond to a
non-authenticated Advertise message.
The decision to set local policy to accept non-authenticated
messages should be made with care. Accepting a non-authenticated
Advertise message can make the client vulnerable to spoofing and
other attacks. If local users are not explicitly informed that
the client has accepted a non-authenticated Advertise message, the
users may incorrectly assume that the client has received an
authenticated address and is not subject to DHCP attacks through
non-authenticated messages.
A client MUST be configurable to discard non-authenticated
messages, and SHOULD be configured by default to discard
non-authenticated messages if the client has been configured with
an authentication key or other authentication information. If a
client does accept a non-authenticated message, the client SHOULD
inform any local users and SHOULD log the event.
The second paragraph of Section 21.4.4.5 also needs a change:
If the client accepted a non-authenticated Advertise message, the
client MAY accept a non-authenticated Reply message from the
server.
If we take this suggestion, then we will not need the notion of
Jinmei Expires January 10, 2005 [Page 6]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
"unauthenticated message". As a result, the issue described in
Section 4 will become a non issue.
6. Possibility of Dos Attack
Section 21.4.4.5 of the RFC says as follows:
If the Reply fails to pass the validation test, the client MUST
restart the DHCP configuration process by sending a Solicit
message.
The purpose of this specification is probably to avoid a deadlock
scenario when the server suddenly reboots forgetting the
authentication key and/or the replay detection counter.
However, this behavior can easily cause denial of service (DoS)
attacks; the attacker can simply send an invalid Reply message at
some valid timing and can invalidate configuration information of the
client or can prevent the client from configuring itself.
As a side issue, this section seems to not consider
Information-request and Reply exchanges.
6.1 Discussion on Resolution
Even if a Reply message does not pass the validation tests, it is
probably reasonable to wait for an authenticated one until the first
timeout. Additionally, if the Reply message is a response to
Release, the client will not have to restart the configuration
process by Solicit. It can simply quit the session when the first
timeout occurs.
Reply messages to Information-request will need a separate
consideration. Obviously, it does not make sense to send a Solicit
message when the validation tests for a Reply message to
Information-request fail. The appropriate behavior is probably to
resend an Information-request message without including
authentication information based on the key previously used, and to
restart authentication.
7. Lack of Authentication from Client
It is not clear what the server should do when the client does not
include an authentication option while the server has previously sent
authentication information in the same session.
For messages other than Information-request, the appropriate behavior
depends on the resolution for the issue discussed in Section 5.
Jinmei Expires January 10, 2005 [Page 7]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
Assuming the proposed resolution is adopted, the server should
discard the message, since the client should have accepted the key as
long as it is valid and then must use the key for succeeding message
according to Section 21.4.4.3 of [RFC3315].
The appropriate behavior for Information-request depends on the
resolution discussed in Section 2. If we take the proposed
resolution, then the server should accept the message and select a
new key, which may be the same as the one used before though, for the
new exchanges as described in Section 2.
8. Key Consistency
[RFC3315] requests in Section 21.4.4.3 that the client use the same
key used by the server to generate the authentication information.
However, it is not clear from the RFC what the server should do if
the client breaks this rule. It says in Section 21.4.5.2 that
If the message [...] or the server does not know the key
identified by the 'key ID' field, the server MUST discard the
message and MAY choose to log the validation failure.
It is not clear whether "does not know the key" means a different key
from the one the server specified in the Advertise message. If this
is the intent, this sentence should be clarified as follows:
If the message [...] or the key identified by the authentication
information of the message is not identical to the key that the
server has been using in the session, the server MUST discard the
message and MAY choose to log the validation failure.
9. Security Considerations
This document specifically talks about security issues for DHCPv6.
It also points out a possibility of DoS attacks, and gives some
considerations on how to prevent them.
10. IANA Considerations
This document has no actions for IANA.
11. References
11.1 Normative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
Jinmei Expires January 10, 2005 [Page 8]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
(DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
11.2 Informative References
[I-D.ietf-dhc-lifetime]
Venaas, S. and T. Chown, "Lifetime Option for DHCPv6",
draft-ietf-dhc-lifetime-00 (work in progress), March 2004.
Author's Address
Tatuya Jinmei
Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582
Japan
Phone: +81 44-549-2230
EMail: jinmei@isl.rdc.toshiba.co.jp
Jinmei Expires January 10, 2005 [Page 9]
Internet-Draft Clarifications on DHCPv6 Authentication July 2004
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
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jinmei Expires January 10, 2005 [Page 10]