draft-ietf-dhc-dhcpv6-clarify-auth-00.txt   draft-ietf-dhc-dhcpv6-clarify-auth-01.txt 
IETF dhc Working Group T. Jinmei IETF dhc Working Group T. Jinmei
Internet-Draft Toshiba Internet-Draft Toshiba
Expires: April 16, 2005 October 16, 2004 Expires: December 28, 2006 June 26, 2006
Clarifications on DHCPv6 Authentication Clarifications on DHCPv6 Authentication
draft-ietf-dhc-dhcpv6-clarify-auth-00.txt draft-ietf-dhc-dhcpv6-clarify-auth-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2005. This Internet-Draft will expire on December 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes issues about the authentication mechanism of This document describes issues about the authentication mechanism of
the Dynamic Host Configuration Protocol for IP version 6 that were the Dynamic Host Configuration Protocol for IP version 6 that were
identified from implementation experiences. It also tries to propose identified from implementation experiences. It also tries to propose
resolutions to some of the issues. resolutions to some of the issues.
1. Introduction 1. Introduction
skipping to change at page 2, line 37 skipping to change at page 2, line 37
21.4.5.1. Receiving Solicit Messages and Sending Advertise 21.4.5.1. Receiving Solicit Messages and Sending Advertise
Messages Messages
The server selects a key for the client and includes The server selects a key for the client and includes
authentication information in the Advertise message returned to authentication information in the Advertise message returned to
the client as specified in section 21.4. [...] the client as specified in section 21.4. [...]
It does not necessarily mean contradiction because the client and the It does not necessarily mean contradiction because the client and the
server may have exchanged Solicit and Advertise with authentication server may have exchanged Solicit and Advertise with authentication
before starting the Information-request and Reply exchange. However, before starting the Information-request and Reply exchange. But it
it then restricts the usage scenario of the authentication mechanism then restricts the usage scenario of the authentication mechanism for
for Information-request and Reply exchanges. In particular, this Information-request and Reply exchanges. In particular, this
assumption prohibits the use of the mechanism with the "stateless" assumption prohibits the use of the mechanism with the "stateless"
service using DHCPv6 [RFC3736]. Whereas the specification allows an service using DHCPv6 [RFC3736]. Whereas the specification allows an
implementation that only supports the stateless service and does not implementation that only supports the stateless service and does not
support Solicit and Advertise messages, the authentication mechanism support Solicit and Advertise messages, the authentication mechanism
depends on Solicit and Advertise exchanges. depends on Solicit and Advertise exchanges.
This fact can (partly) invalidate a security consideration in This fact can (partly) invalidate a security consideration in
[RFC3736]: [RFC3736]:
Authenticated DHCP, as described in sections 21 and 22.11 of the Authenticated DHCP, as described in sections 21 and 22.11 of the
skipping to change at page 3, line 15 skipping to change at page 3, line 19
(where [1] refers to [RFC3315].) In fact, as was just shown above, (where [1] refers to [RFC3315].) In fact, as was just shown above,
authenticated DHCP cannot be used unless the implementations also authenticated DHCP cannot be used unless the implementations also
support Solicit and Advertise messages (or the entire [RFC3315] in support Solicit and Advertise messages (or the entire [RFC3315] in
general). general).
It should also be noted that [RFC3315] does not define what the It should also be noted that [RFC3315] does not define what the
server should do when it receives an Information-request message server should do when it receives an Information-request message
containing an authentication option; Section 21.4.5.2 excludes the containing an authentication option; Section 21.4.5.2 excludes the
Information-request message. Information-request message.
2.1 Suggested Resolution 2.1. Suggested Resolution
Considering the fact that [RFC3736] allows implementations that only Considering the fact that [RFC3736] allows implementations that only
support the subset of the full specification [RFC3315], it should support the subset of the full specification [RFC3315], it should
make sense to define the authentication usage for Information-request make sense to define the authentication usage for Information-request
and Reply exchanges separately. and Reply exchanges separately.
One significant difference between Information-request and other One significant difference between Information-request and other
"stateful" cases is that there is no explicit notion of "session" in "stateful" cases is that there is no explicit notion of "session" in
the former. In some cases, however, the same client and server may the former. In some cases, however, the same client and server may
exchange Information-request and Reply multiple times, where the exchange Information-request and Reply multiple times, where the
entire exchanges can be regarded as a "session". For example, the entire exchanges can be regarded as a "session". For example, the
client may want to get different configuration information in client may want to get different configuration information in
multiple exchanges. Also, if the client and the server use the multiple exchanges. Also, if the client and the server use the
Information Refresh Time Option [I-D.ietf-dhc-lifetime], they will Information Refresh Time Option [RFC4242], they will restart
restart exchanges when the refresh time expires. exchanges when the refresh time expires.
On the other hand, keeping a "session" in the server decreases an A naive implementation of keeping a "session" in the server will
advantage of the [RFC3736] usage that the server can run in a decrease an advantage of the [RFC3736] usage that the server can run
stateless fashion without any client-specific state. Thus, it is in a stateless fashion without any client-specific state.
worth considering a trade off between securing multiple exchanges as Specifically, the server may have to maintain the following three
a single session and keeping the server stateless. types of state per client:
Securing multiple exchanges has two beneficial points: o the authentication key shared between the server and the client
o replay detection information for messages to the client (such as
the replay detection value sent most recently)
o replay detection information for messages from the client (such as
the replay detection value received most recently)
o the server can authenticate Information-request messages from the It is possible for the server to have different keys for different
client. clients without having per-client information by the method described
in Appendix A of [RFC3118]. In this approach the server only
maintains a single master key and creates the key for a particular
client by computing some one-way hash digest based on the master key
and the client's DUID. Since an Information-request message to be
authenticated must have a Client Identifier option as specified in
Section 18.1.5 of [RFC3315], this approach should work well.
o the client and the server can perform replay protection. The server can also avoid a replay attack using an old message sent
from the server without maintaining per client state for replay
detection information about messages sent to the client if the server
has a source of replay protection value that monotonically increases.
For example, system timestamp can be used for this purpose.
In other words, it would make sense to separate each exchange and to Without keeping the replay detection information for messages from
keep the server stateless in the case where neither of them is the client, the server may be vulnerable to a replay attack from a
desired. And, in fact, it is not so important to authenticate malicious client. This should be relatively a minor issue because a
client's messages in the current usage of [RFC3736] for providing "stateless" server usually provides the same information for all
client-independent information. Additionally, replay attacks in such clients without consuming any of its resource. When the malicious
a typical usage might not be a big threat, since any Reply messages client can get an old valid message, e.g., by snooping the traffic,
from the server will simply be the same. it would also be able to get and use the response; it does not have
to mount the replay attack.
Still, there will be other cases where (one of) the above two points There is still a subtle case to be considered. If the server uses a
are important. For example, if the address of a DNS recursive name monotonically increasing counter for stateless replay detection
resolver [RFC3646] is provided in reply to an Information-request information to clients and the server does not maintain per client
message and the address is renumbered, the client will not want to be replay detection information from the client, a malicious client can
confused with the previous address containing the previous valid reuse a valid Information-request message to get a reusable valid
authentication information. In this case, the client wants to reject Response message. The malicious client will then be able to mount a
such an invalid or stale Reply by the reply protection mechanism. replay attack on the client later.
Also, the current design of the Information-request message still
allows including the Client DUID option in order for per-client
configuration, while it is not common today. In this type of
configuration, the server will want to authenticate the client's
request.
The proposed revision of Section 21.4.4.4 is therefore as follows: The proposed revision of Section 21.4.4.4 is therefore as follows:
21.4.4.4. Sending Information-request Messages 21.4.4.4. Sending Information-request Messages
When the client sends an Information-request message and wishes to When the client sends an Information-request message and wishes to
use authentication, it includes an Authentication option with the use authentication, it includes an Authentication option with the
desired protocol, algorithm and RDM as described in section 21.4. desired protocol, algorithm and RDM as described in section 21.4.
The client does not include any replay detection or authentication The client does not include any replay detection or authentication
information in the Authentication option. information in the Authentication option.
If the client authenticated exchanges of Information-request and If the client authenticated exchanges of Information-request and
Reply in the past, the client MAY reuse the same key used in the Reply in the past, the client MAY reuse the same key used in the
previous exchanges to generate the authentication information. In previous exchanges to generate the authentication information. In
this case, the client generates authentication information for the this case, the client generates authentication information for the
Information-request message as described in section 21.4. Information-request message as described in section 21.4.
Normally, the client performs replay detection when it reuses the
same key. However, to be able to interoperate with "stateless"
servers that do not maintain per-client state, the client MUST be
configurable to turn off replay detection for a Reply message to
Information-request. Since disabling replay detection can cause a
security threat, the client SHOULD be configured by default to
enable it.
Note that the keys used for these exchanges are separately managed Note that the keys used for these exchanges are separately managed
from the keys used for the other exchanges beginning with the from the keys used for the other exchanges beginning with the
Solicit message when the two types of exchanges run concurrently, Solicit message when the two types of exchanges run concurrently,
while the two keys may happen to be the same. For example, replay while the two keys may happen to be the same. For example, replay
detection should be performed separately, and validation failure detection should be performed separately, and validation failure
for one type of exchanges does not affect the other. for one type of exchanges does not affect the other.
Section 21.4.4.5 will also need to be revised. However, since this 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 section has a separate issue per se as will be discussed in
5, we do not discuss further details on this here. Section 5, further details on this are not discussed here.
The server side behavior needs to be described, too. Along with the The server side behavior needs to be described, too. Along with the
above change to Section 21.4.4.4, we propose to add a new subsection above change to Section 21.4.4.4, a new proposed subsection of
of Section 21.4.5: Section 21.4.5 should be added as follows:
21.4.5.x. Receiving Information-request Messages and Sending 21.4.5.x. Receiving Information-request Messages and Sending
Reply Messages Reply Messages
If the Information-request message includes an authentication If the Information-request message includes an authentication
option without authentication information, the server selects a option without authentication information, the server selects a
key for the client and includes authentication information in the key for the client and includes authentication information in the
Reply message returned to the client as specified in section 21.4. Reply message returned to the client as specified in section 21.4.
The server SHOULD record the identifier of the key selected for If the key is selected from pre-configured information for the
the client so that it can validate further Information-request client maintained in the server, the server MUST record the
messages from the client if the client reuses the same key for the identifier of the key selected for the client so that it can
future exchanges. validate further Information-request messages from the client if
the client reuses the same key for the future exchanges.
In some cases, however, the server would rather be just stateless, The server MAY alternatively use a stateless method such as the
without maintaining any per-client state. Thus, the server MAY one described in Appendix A of [RFC3118]. Then the server MUST
skip keeping per-client state, in which case it will not consistently use the same key for the client to validate further
authenticate Information-request messages from clients or Information-request messages from the client.
necessarily provide a valid replay detection information with the
client which performs replay detection. When the server uses such a stateless method for key utilization,
it may also seek to avoid having per client state for replay
detection. For outbound messages, it is easy when the server has
a source of monotonically increasing values such as system
timestamp; however, it is difficult if not impossible to refuse
inbound replay messages without per client state. The server MAY
skip the replay detection for inbound Information-request messages
if the benefit of being stateless outweighs the risk of replay
attacks for inbound messages. Care should be taken when this
relaxation applies because if the server also uses a stateless
method for outbound messages, a malicious client may be able to
get a valid reusable response by reusing an old, legitimate
Information-request message.
If the Information-request message includes an authentication If the Information-request message includes an authentication
option with authentication information, the server uses the key option with authentication information, the server uses the key
identified in the message and validates the message as specified identified in the message and validates the message as specified
in section 21.4.2. If the message fails to pass the validation in section 21.4.2. If the message fails to pass the validation
test, or the key identified by the authentication information of test, or the key identified by the authentication information of
the message is not identical to the key that the server used in the message is not identical to the key that the server used in
the previous exchange (when it has recorded the key), the server the previous exchange (when it has recorded the key), the server
MUST discard the message and MAY choose to log the validation MUST discard the message and MAY choose to log the validation
failure. failure.
If the server has not recorded the key, it MAY skip replay
detection in the above procedure, but MUST perform the rest of
validation.
If the message passes the validation test, the server responds If the message passes the validation test, the server responds
with a Reply message as described in section 18.2.5. The server with a Reply message as described in section 18.2.5. The server
MUST include authentication information generated using the key MUST include authentication information generated using the key
just selected or identified in the received message, as specified just selected or identified in the received message, as specified
in section 21.4. in section 21.4.
Finally, if the server previously recorded the key but receives an Finally, if the server previously recorded the key but receives an
Information-request message without including an authentication Information-request message without including an authentication
option, the server MUST accept the message and respond with a option, the server MUST accept the message and respond with a
Reply message without including authentication information. The Reply message without including authentication information. The
skipping to change at page 6, line 14 skipping to change at page 6, line 32
from the keys used for the other exchanges beginning with the from the keys used for the other exchanges beginning with the
Solicit message when the two types of exchanges run concurrently Solicit message when the two types of exchanges run concurrently
(See Section 21.4.4.4). (See Section 21.4.4.4).
3. What If Replay Is Detected 3. What If Replay Is Detected
It is not clear what the receiver should do when an attempt of replay 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 attack is detected from either Section 21.3 or Section 21.4.2 of
[RFC3315]. [RFC3315].
3.1 Suggested Resolution 3.1. Suggested Resolution
It should be natural to discard a DHCP message containing an It should be natural to discard a DHCP message containing an
authentication option whose replay detection field indicates a replay authentication option whose replay detection field indicates a replay
attack. attack.
Instead of concentrating on this particular case, we propose to Instead of concentrating on this particular case, we propose to
revise the entire second paragraph of Section 21.4.2 as follows: revise the entire second paragraph of Section 21.4.2 as follows:
To validate an incoming message, the receiver first checks that To validate an incoming message, the receiver first checks that
the value in the replay detection field is acceptable according to the value in the replay detection field is acceptable according to
the replay detection method specified by the RDM field. If no the replay detection method specified by the RDM field. If no
replay is detected, then the receiver computes the MAC as replay is detected, then the receiver computes the MAC as
described in [8]. The entire DHCP message (setting the MAC field described in [8]. The entire DHCP message (setting the MAC field
of the authentication option to 0) is used as input to the of the authentication option to 0) is used as input to the HMAC-
HMAC-MD5 computation function. If the MAC computed by the MD5 computation function. If the MAC computed by the receiver
receiver matches the MAC contained in the authentication option, matches the MAC contained in the authentication option, the
the message regarded as valid. If the above procedure fails at message regarded as valid. If the above procedure fails at any
any stage, the receiver MUST discard the DHCP message. stage, the receiver MUST discard the DHCP message.
4. Inconsistent Behavior for Unauthenticated Messages 4. Inconsistent Behavior for Unauthenticated Messages
[RFC3315] says in Section 21.4.2 (Message Validation) as follows: [RFC3315] says in Section 21.4.2 (Message Validation) as follows:
If the MAC computed by the receiver does not match the MAC If the MAC computed by the receiver does not match the MAC
contained in the authentication option, the receiver MUST discard contained in the authentication option, the receiver MUST discard
the DHCP message. the DHCP message.
On the other hand, Section 21.4.4.2 allows the client to respond to On the other hand, Section 21.4.4.2 allows the client to respond to
skipping to change at page 7, line 9 skipping to change at page 7, line 28
policy on the client. According to client policy, the client MAY policy on the client. According to client policy, the client MAY
choose to respond to an Advertise message that has not been choose to respond to an Advertise message that has not been
authenticated. authenticated.
This seems to say, for example, that the client MAY accept an This seems to say, for example, that the client MAY accept an
Advertise message based on its local policy, even if the MAC computed Advertise message based on its local policy, even if the MAC computed
by the receiver does not match the MAC contained in the by the receiver does not match the MAC contained in the
authentication option. Apparently this contradicts the requirement authentication option. Apparently this contradicts the requirement
in Section 21.4.2. in Section 21.4.2.
4.1 Suggested Resolution 4.1. Suggested Resolution
There seems to be no valid reason for accepting an Advertise message 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 if it fails validation. On the other hand, it may make sense in some
cases that the client accepts messages that do not include an cases that the client accepts messages that do not include an
authentication option or even messages with an authentication option authentication option or even messages with an authentication option
which specifies a key the client does not know. which specifies a key the client does not know.
As a related terminology issue, [RFC3315] uses the phrase of As a related terminology issue, [RFC3315] uses the phrase of
"unauthenticated message(s)" in Sections 21.4.4.2 and 21.4.4.5 "unauthenticated message(s)" in Sections 21.4.4.2 and 21.4.4.5
without formally defining the term. Based on the above discussion, without formally defining the term. Based on the above discussion,
skipping to change at page 8, line 25 skipping to change at page 8, line 42
The purpose of this specification is probably to avoid a deadlock The purpose of this specification is probably to avoid a deadlock
scenario when the server suddenly reboots forgetting the scenario when the server suddenly reboots forgetting the
authentication key and/or the replay detection counter. authentication key and/or the replay detection counter.
However, this behavior can easily cause denial of service (DoS) However, this behavior can easily cause denial of service (DoS)
attacks; the attacker can simply send an invalid Reply message at attacks; the attacker can simply send an invalid Reply message at
some valid timing and can invalidate configuration information of the some valid timing and can invalidate configuration information of the
client or can prevent the client from configuring itself. client or can prevent the client from configuring itself.
As a side issue, this section seems to not consider As a side issue, this section seems to not consider Information-
Information-request and Reply exchanges. request and Reply exchanges.
5.1 Discussion on Resolution 5.1. Discussion on Resolution
Even if a Reply message does not pass the validation tests, it is Even if a Reply message does not pass the validation tests, it is
probably reasonable to wait a certain period for an authenticated probably reasonable to wait a certain period for an authenticated
one. Additionally, if the Reply message is a response to Release, one. Additionally, if the Reply message is a response to Release,
the client will not have to restart the configuration process with the client will not have to restart the configuration process with
Solicit. It can simply quit the session after the waiting period. Solicit. It can simply quit the session after the waiting period.
The appropriate waiting period would be the first timeout for the The appropriate waiting period would be the first timeout for the
message, since in the intended scenario described above the message, since in the intended scenario described above the
legitimate (but without knowing a valid key) server should be working legitimate (but without knowing a valid key) server should be working
and respond within the timeout period. and respond within the timeout period.
skipping to change at page 9, line 5 skipping to change at page 9, line 22
suggested in Section 2.1, the client may or may not reuse the key for suggested in Section 2.1, the client may or may not reuse the key for
previous exchanges. If the client does not reuse the key, or if this previous exchanges. If the client does not reuse the key, or if this
is the first time the client sends an Information-request message, is the first time the client sends an Information-request message,
there should be no other behavior than simply discarding the message there should be no other behavior than simply discarding the message
and waiting for a valid response (usual timeout and resend will and waiting for a valid response (usual timeout and resend will
apply). Otherwise, the appropriate behavior would be similar to the apply). Otherwise, the appropriate behavior would be similar to the
case described in the previous paragraph. That is, the client should case described in the previous paragraph. That is, the client should
wait for a while and start new exchanges without including wait for a while and start new exchanges without including
authentication information with the reused key. authentication information with the reused key.
5.2 Suggested Resolution 5.2. Suggested Resolution
The suggested change to Section 21.4.4.5 based on the above analysis The suggested change to Section 21.4.4.5 based on the above analysis
is as follows. It includes resolutions to the issues discussed in is as follows. It includes resolutions to the issues discussed in
Section 2.1 and Section 4.1. Section 2.1 and Section 4.1.
For Reply to a message other than Information-request, if the For Reply to a message other than Information-request, if the
client authenticated the Advertise it accepted, the client MUST client authenticated the Advertise it accepted, the client MUST
validate the associated Reply message from the server. The client validate the associated Reply message from the server. The client
MUST discard the Reply if the message fails to pass the validation MUST discard the Reply if the message fails to pass the validation
test and MAY log the validation failure. Then the client MUST test and MAY log the validation failure. Then the client MUST
skipping to change at page 11, line 12 skipping to change at page 11, line 32
Christian Strauf, Stig Venaas and Bernie Volz reviewed a preliminary Christian Strauf, Stig Venaas and Bernie Volz reviewed a preliminary
version of this document, and provided specific suggestions and version of this document, and provided specific suggestions and
further clarifications. further clarifications.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. References 11. References
11.1 Normative References 11.1. Normative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 and M. Carney, "Dynamic Host Configuration Protocol for
(DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
11.2 Informative References [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[I-D.ietf-dhc-lifetime]
Venaas, S., Chown, T. and B. Volz, "Information Refresh
Time Option for DHCPv6", draft-ietf-dhc-lifetime-02 (work
in progress), September 2004.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
Author's Address
Tatuya Jinmei 11.2. Informative References
Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582
Japan
Phone: +81 44-549-2230 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
EMail: jinmei@isl.rdc.toshiba.co.jp Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
Appendix A. CHANGE HISTORY Appendix A. CHANGE HISTORY
Changes since draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt are: Changes since draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt are:
o Loosened the description of Information-request and Reply o Loosened the description of Information-request and Reply
exchanges so that the server can skip maintaining per-client exchanges so that the server can skip maintaining per-client
information. information.
o Changed the lifetime option to Information Refresh Time Option, o Changed the lifetime option to Information Refresh Time Option,
according to the change of the document. according to the change of the document.
o Clarified the definition of "unauthenticated" messages so that o Clarified the definition of "unauthenticated" messages so that
those would not include messages that failed the validation, and those would not include messages that failed the validation, and
revise the specification using the term. Section 4 of the revise the specification using the term. Section 4 of the
previous version was removed accordingly. previous version was removed accordingly.
o Provided specific suggestion to solve denial of service attacks. o Provided specific suggestion to solve denial of service attacks.
o Changed the draft name to an IETF dhc working group document. o Changed the draft name to an IETF dhc working group document.
Changes since draft-ietf-dhc-dhcpv6-clarify-auth-00.txt are:
o Updated the considerations and recommendation on the server
behavior for Information-request and Reply exchanges based on
stateless key utilization described in [RFC3118].
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
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 13, line 41 skipping to change at page 14, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 36 change blocks. 
108 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/