IETF dhc Working Group T. Jinmei Internet-Draft Toshiba Expires:
April 16, 2005 October 16, 2004December 28, 2006 June 26, 2006 Clarifications on DHCPv6 Authentication draft-ietf-dhc-dhcpv6-clarify-auth-00.txtdraft-ietf-dhc-dhcpv6-clarify-auth-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667.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 becomebecomes aware will be disclosed, in accordance with RFC 3668.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. 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 April 16, 2005.December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2004).(2006). Abstract This document describes issues about the authentication mechanism of the Dynamic Host Configuration Protocol for IP version 6 that were 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 cause discussions on a security threat. This document describes the issues based on the questions and proposes resolutions, hoping the resolutions will be merged in 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 126.96.36.199 as follows: If the server has selected a key for the client in a previous message exchange (see section 188.8.131.52), the client MUST use the same key to generate the authentication information throughout the session. However, this description is not really clear. Section 184.108.40.206, which is referred from the above part, actually describes the case of Solicit and Advertise exchange: 220.127.116.11. 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 Advertise with authentication before starting the Information-request and Reply exchange. However,But 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 , can be used to avoid attacks mounted through the stateless DHCP service. (where  refers to [RFC3315].) In fact, as was just shown above, 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 what the server should do when it receives an Information-request message containing an authentication option; Section 18.104.22.168 excludes the Information-request message. 2.12.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 Information Refresh Time Option [I-D.ietf-dhc-lifetime],[RFC4242], they will restart exchanges when the refresh time expires. On the other hand,A naive implementation of keeping a "session" in the server decreaseswill decrease an advantage of the [RFC3736] usage that the server can run in a stateless fashion without any client-specific state. Thus, it is worth considering a trade off between securing multiple exchanges as a single session and keeping the server stateless. Securing multiple exchanges has two beneficial points: oSpecifically, the server can authenticate Information-request messages frommay have to maintain the client.following three types of state per client: o the client andauthentication key shared between the server can perform replay protection. In other words, it would make sense to separate each exchangeand to keep the server stateless inthe case where neither of them is desired. And, in fact, it is not so important to authenticate client'sclient o replay detection information for messages into the client (such as the current usage of [RFC3736] for providing client-independent information. Additionally,replay attacks in such a typical usage might not be a big threat, since any Replydetection value sent most recently) o replay detection information for messages from the server will simply be the same. Still, there will be other cases where (one of) the above two points are important. For example, if the address of a DNS recursive name resolver [RFC3646] is provided in reply to an Information-request message andclient (such as the addressreplay detection value received most recently) It is renumbered,possible for the client will not wantserver to be confused with the previous address containinghave different keys for different clients without having per-client information by the previous valid authentication information.method described in Appendix A of [RFC3118]. In this case,approach the server only maintains a single master key and creates the key for a particular client wants to reject such an invalid or stale Replyby computing some one-way hash digest based on the reply protection mechanism. Also, the current design ofmaster key and the client's DUID. Since an Information-request message still allows including theto be authenticated must have a Client DUIDIdentifier option as specified in orderSection 18.1.5 of [RFC3315], this approach should work well. 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 per-client configuration, while it is not common today. Inthis typepurpose. Without keeping the replay detection information for messages from the client, the server may be vulnerable to a replay attack from a malicious client. This should be relatively a minor issue because a "stateless" server usually provides the same information for all clients without consuming any of configuration,its resource. When the malicious client can get an old valid message, e.g., by snooping the traffic, it would also be able to get and use the response; it does not have to mount the replay attack. There is still a subtle case to be considered. If the server uses a monotonically increasing counter for stateless replay detection information to clients and the server does not maintain per client replay detection information from the client, a malicious client can reuse a valid Information-request message to get a reusable valid Response message. The malicious client will wantthen be able to authenticatemount a replay attack on the client's request.client later. The proposed revision of Section 22.214.171.124 is therefore as follows: 126.96.36.199. 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 exchanges of Information-request and Reply in the past, 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. 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 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. Section 188.8.131.52 will also need to be revised. However, since this section has a separate issue per se as will be discussed in Section 5, we do not discussfurther details on this are not discussed here. The server side behavior needs to be described, too. Along with the above change to Section 184.108.40.206, we propose to adda new proposed subsection of Section 21.4.5:21.4.5 should be added as follows: 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 SHOULD recordspecified in section 21.4. If the key is selected from pre-configured information for the client maintained in the server, 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. The server MAY alternatively use a stateless method such as the identifierone described in Appendix A of [RFC3118]. Then the server MUST consistently use the same key selectedfor the client so that it canto validate further Information-request messages from the client if the client reusesclient. When the sameserver uses such a stateless method for key utilization, it may also seek to avoid having per client state for the future exchanges. In some cases, however,replay detection. For outbound messages, it is easy when the server would rather be just stateless,has a source of monotonically increasing values such as system timestamp; however, it is difficult if not impossible to refuse inbound replay messages without maintaining any per-clientper client state. Thus, theThe server MAY skip keeping per-client state, in which case it will not authenticatethe replay detection for inbound Information-request messages from clients or necessarily provide a validif the benefit of being stateless outweighs the risk of replay detection information withattacks 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 which performs replay detection.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 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, or the key identified by the authentication information of the message is not identical to the key that the server used in the previous exchange (when it has recorded the key), the server MUST discard the message and MAY choose to log the validation 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 themessage passes the validation test, the server responds with a 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. Finally, if the server previously recorded the key but receives an Information-request message without including an authentication option, the server MUST accept the message and respond with a Reply message without including authentication information. The server SHOULD then remove the recorded information. 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 220.127.116.11). 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]. 3.13.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 . The entire DHCP message (setting the MAC field of the authentication option to 0) is used as input to the HMAC-MD5HMAC- 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. 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 18.104.22.168 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. 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 the requirement in Section 21.4.2. 4.14.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 messages that do not include an authentication option or even messages with an authentication option which specifies a key the client does not know. As a related terminology issue, [RFC3315] uses the phrase of "unauthenticated message(s)" in Sections 22.214.171.124 and 126.96.36.199 without formally defining the term. Based on the above discussion, the most appropriate definition of this term is the acceptable types of messages. Specifically, a message that fails to pass the validation test should not be regarded as an "unauthenticated" message. The suggested change to Section 188.8.131.52 is thus as follows. The client validates any Advertise messages containing an Authentication option specifying the delayed authentication protocol using the validation test described in section 21.4.2. Client behavior, if all Advertise messages are "unauthenticated", is controlled by local policy on the client, where an unauthenticated message means a message that does not include an authentication option or a message with an authentication option which specifies a key the client does not know. According to client policy, the client MAY choose to respond to an unauthenticated Advertise message. [...] A client MUST be configurable to discard unauthenticated messages, and SHOULD be configured by default to discard unauthenticated messages if the client has been configured with an authentication key or other authentication information. A client MAY choose to differentiate between unauthenticated Advertise messages with no authentication information and unauthenticated Advertise messages that specifies a key the client does not know; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event. The second paragraph of Section 184.108.40.206 also needs a change. But, again, we will discuss this case in Section 5. 5. Possibility of DoS Attack Section 220.127.116.11 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-requestInformation- request and Reply exchanges. 5.15.1. Discussion on Resolution Even if a Reply message does not pass the validation tests, it is probably reasonable to wait a certain period for an authenticated one. Additionally, if the Reply message is a response to Release, the client will not have to restart the configuration process with Solicit. It can simply quit the session after the waiting period. The appropriate waiting period would be the first timeout for the message, since in the intended scenario described above the legitimate (but without knowing a valid key) server should be working and respond within the timeout period. Reply messages to Information-request will need a separate consideration. According to the resolution (to a different issue) 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 is the first time the client sends an Information-request message, there should be no other behavior than simply discarding the message and waiting for a valid response (usual timeout and resend will apply). Otherwise, the appropriate behavior would be similar to the case described in the previous paragraph. That is, the client should wait for a while and start new exchanges without including authentication information with the reused key. 5.25.2. Suggested Resolution The suggested change to Section 18.104.22.168 based on the above analysis is as follows. It includes resolutions to the issues discussed in Section 2.1 and Section 4.1. For Reply to a message other than Information-request, if the client authenticated the Advertise it accepted, the client MUST validate the associated Reply message from the server. The client MUST discard the Reply if the message fails to pass the validation test and MAY log the validation failure. Then the client MUST wait until the corresponding timeout expires as specified in Section 14 as if it did not receive any Reply. If the client cannot receive a valid Reply within the first timeout period, the client MUST restart the DHCP configuration process by sending a Solicit message or the client MUST simply quit the configuration process if the Reply should be a response to a Release message. If the client accepted an unauthenticated Advertise message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated Reply message from the server. If the client sent an Information-request message including an authentication option, the client MUST validate the associated Reply message from the server. The client MUST discard the Reply if the message fails to pass the validation test and MAY log the validation failure. If the client reuses the key used in previous exchanges and authenticated the Information-request message with the key, the client MUST wait until the corresponding timeout expires. If the client cannot receive a valid Reply within the first timeout period, the client MUST restart the configuration process by restarting exchanges of Information-request and Reply without reusing the previous key. The client MAY choose to accept an unauthenticated Reply message to an Information request message. All the discussions and behaviors described in Section 22.214.171.124 should simply apply to this case. 6. 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. A proposal for the Information-request message was provided in Section 2.1. For messages other than Information-request, the lack of an authentication information would mean the Advertise message sent from the server was "unauthenticated" to the client and the client chose to accept that message. Thus, the server should basically accept that message, while it may still want to reject the message if the server uses the authentication information to authenticate the client. The proposed change to Section 126.96.36.199 based on the above discussion is to add the following paragraph at the end of the section. If the message does not include an authentication option while the server included an authentication option in previous messages of the session, the server SHOULD accept the message. In this case, the server MAY skip including an authentication option in the Reply message. The server MAY still choose to discard the received message in this case based on its local policy. 7. Key Consistency [RFC3315] requests in Section 188.8.131.52 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 184.108.40.206 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. 8. Security Considerations This document specifically talks about security issues for DHCPv6. It also points out a possibility of DoS attacks, and proposes a resolution to prevent the attacks. 9. Acknowledgements Christian Strauf, Stig Venaas and Bernie Volz reviewed a preliminary version of this document, and provided specific suggestions and further clarifications. 10. IANA Considerations This document has no actions for IANA. 11. References 11.111.1. Normative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. 11.2[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 11.2. Informative References [I-D.ietf-dhc-lifetime][RFC4242] Venaas, S., Chown, T.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 forDynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. 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: firstname.lastname@example.org, November 2005. Appendix A. CHANGE HISTORY Changes since draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt are: o Loosened the description of Information-request and Reply exchanges so that the server can skip maintaining per-client information. o Changed the lifetime option to Information Refresh Time Option, according to the change of the document. o Clarified the definition of "unauthenticated" messages so that those would not include messages that failed the validation, and revise the specification using the term. Section 4 of the previous version was removed accordingly. o Provided specific suggestion to solve denial of service attacks. 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: email@example.com 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 firstname.lastname@example.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).(2006). 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.