idnits 2.17.1 draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 430. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 446), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 63: '...ion 21.4.5.1), the client MUST use the...' RFC 2119 keyword, line 134: '...eply, the client MAY reuse the same ke...' RFC 2119 keyword, line 161: '... The server MUST record the ident...' RFC 2119 keyword, line 173: '...ient, the server MUST discard the mess...' RFC 2119 keyword, line 177: '...ed in section 18.2.5. The server MUST...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2004) is 7227 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 96 -- Looks like a reference, but probably isn't: '8' on line 206 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-03) exists of draft-ietf-dhc-lifetime-00 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Jinmei 2 Internet-Draft Toshiba 3 Expires: January 10, 2005 July 12, 2004 5 Clarifications on DHCPv6 Authentication 6 draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 10, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes issues about the DHCPv6 authentication 40 mechanism identified from implementation experiences. It also tries 41 to propose resolutions to some of the issues. 43 1. Introduction 45 Several questions arose on the authentication mechanism of DHCPv6 46 [RFC3315] from implementation experiences, particularly on its 47 delayed authentication protocol. Some of the questions may require a 48 change or addition to the current protocol, and one of them may even 49 cause discussions on a security threat. 51 This document describes the issues based on the questions, and tries 52 to propose resolutions for some of them, hoping the resolutions will 53 be merged, if valid and accepted, to the next version of the base 54 specification. 56 2. Usage with Information-Request 58 According to [RFC3315], it seems possible to use the authentication 59 mechanism for Information-request and Reply exchanges. The RFC says 60 in Section 21.4.4.4 as follows: 62 If the server has selected a key for the client in a previous 63 message exchange (see section 21.4.5.1), the client MUST use the 64 same key to generate the authentication information throughout the 65 session. 67 However, this description is not really clear. Section 21.4.5.1, 68 which is referred from the above part, actually describes the case of 69 Solicit and Advertise exchange: 71 21.4.5.1. Receiving Solicit Messages and Sending Advertise 72 Messages 74 The server selects a key for the client and includes 75 authentication information in the Advertise message returned to 76 the client as specified in section 21.4. [...] 78 It does not necessarily mean contradiction because the client and the 79 server may have exchanged Solicit and Advertised with authentication 80 before starting the Information-request and Reply exchange. However, 81 it then restricts the usage scenario of the authentication mechanism 82 for Information-request and Reply exchanges. In particular, this 83 assumption prohibits the use of the mechanism with the "stateless" 84 service using DHCPv6 [RFC3736]. Whereas the specification allows an 85 implementation that only supports the stateless service and does not 86 support Solicit and Advertise messages, the authentication mechanism 87 depends on Solicit and Advertise exchanges. 89 This fact can (partly) invalidate a security consideration in 90 [RFC3736]: 92 Authenticated DHCP, as described in sections 21 and 22.11 of the 93 DHCP specification [1], can be used to avoid attacks mounted 94 through the stateless DHCP service. 96 (where [1] refers to [RFC3315].) In fact, as was just shown above, 97 authenticated DHCP cannot be used unless the implementations also 98 support Solicit and Advertise messages (or the entire [RFC3315] in 99 general). 101 It should also be noted that [RFC3315] does not define how the server 102 should do when it receives an Information-request message containing 103 an authentication option; Section 21.4.5.2 excludes the 104 Information-request message. 106 2.1 Suggested Resolution 108 Considering the fact that [RFC3736] allows implementations that only 109 support the subset of the full specification [RFC3315], it should 110 make sense to define the authentication usage for Information-request 111 and Reply exchanges separately. 113 One significant difference between Information-request and other 114 "stateful" cases is that there is no explicit notion of "session" in 115 the former. In some cases, however, the same client and server may 116 exchange Information-request and Reply multiple times, where the 117 entire exchanges can be regarded as a "session". For example, the 118 client may want to get different configuration information in 119 multiple exchanges. Also, if the client and the server use the 120 lifetime option, [I-D.ietf-dhc-lifetime] they will restart exchanges 121 when the lifetime expires. 123 The proposed revision of Section 21.4.4.4 is therefore as follows: 125 21.4.4.4. Sending Information-request Messages 127 When the client sends an Information-request message and wishes to 128 use authentication, it includes an Authentication option with the 129 desired protocol, algorithm and RDM as described in section 21.4. 130 The client does not include any replay detection or authentication 131 information in the Authentication option. 133 If the client authenticated past exchanges of Information-request 134 and Reply, the client MAY reuse the same key used in the previous 135 exchanges to generate the authentication information. In this 136 case, the client generates authentication information for the 137 Information-request message as described in section 21.4. 139 Note that the keys used for these exchanges are separately managed 140 from the keys used for the other exchanges beginning with the 141 Solicit message when the two types of exchanges run concurrently, 142 while the two keys may happen to be the same. For example, replay 143 detection should be performed separately, and validation failure 144 for one type of exchanges does not affect the other. 146 Section 21.4.4.5 will also need to be revised. However, since this 147 section has a separate issue per se as will be discussed in Section 148 6, we do not discuss further details on this here. 150 The server side behavior needs to be described, too. Along with the 151 change to Section 21.4.4.4 above, we propose to add a new subsection 152 of Section 21.4.5: 154 21.4.5.x. Receiving Information-request Messages and Sending 155 Reply Messages 157 If the Information-request message includes an authentication 158 option without authentication information, the server selects a 159 key for the client and includes authentication information in the 160 Reply message returned to the client as specified in section 21.4. 161 The server MUST record the identifier of the key selected for the 162 client so that it can validate further Information-request 163 messages from the client if the client reuses the same key for the 164 future exchanges. 166 If the Information-request message includes an authentication 167 option with authentication information, the server uses the key 168 identified in the message and validates the message as specified 169 in section 21.4.2. If the message fails to pass the validation 170 test, the key identified by the authentication information of the 171 message is not identical to the key that the server used in the 172 previous exchange, or the server has not recorded a key for the 173 client, the server MUST discard the message and MAY choose to log 174 the validation failure. 176 If the message passes the validation test, the server responds to 177 the Reply message as described in section 18.2.5. The server MUST 178 include authentication information generated using the key just 179 selected or identified in the received message, as specified in 180 section 21.4. 182 Note that the keys used for these exchanges are separately managed 183 from the keys used for the other exchanges beginning with the 184 Solicit message when the two types of exchanges run concurrently 185 (See Section 21.4.4.4). 187 3. What If Replay Is Detected 189 It is not clear what the receiver should do when an attempt of replay 190 attack is detected from either Section 21.3 or Section 21.4.2 of 191 [RFC3315]. 193 3.1 Suggested Resolution 195 It should be natural to discard a DHCP message containing an 196 authentication option whose replay detection field indicates a replay 197 attack. 199 Instead of concentrating on this particular case, we propose to 200 revise the entire second paragraph of Section 21.4.2 as follows: 202 To validate an incoming message, the receiver first checks that 203 the value in the replay detection field is acceptable according to 204 the replay detection method specified by the RDM field. If no 205 replay is detected, then the receiver computes the MAC as 206 described in [8]. The entire DHCP message (setting the MAC field 207 of the authentication option to 0) is used as input to the 208 HMAC-MD5 computation function. If the MAC computed by the 209 receiver matches the MAC contained in the authentication option, 210 the message regarded as valid. If the above procedure fails at 211 any stage, the receiver MUST discard the DHCP message. 213 4. Definition of Unauthenticated Messages 215 [RFC3315] uses the phrase of "unauthenticated message(s)" in Sections 216 21.4.4.2 and 21.4.4.5 without formally defining the term. A 217 reasonable interpretation of the phrase is probably as follows: a 218 DHCPv6 message is called unauthenticated when it fails the validation 219 test described in Section 21.4.2, it does not contain an 220 authentication option, or when it includes an authentication option 221 but does not have authentication information when necessary. 223 In this document, we assume the above interpretation. 225 5. Inconsistent Behavior for Unauthenticated Messages 227 [RFC3315] says in Section 21.4.2 (Message Validation) as follows: 229 If the MAC computed by the receiver does not match the MAC 230 contained in the authentication option, the receiver MUST discard 231 the DHCP message. 233 On the other hand, Section 21.4.4.2 allows the client to respond to 234 an Advertise even if it fails to authenticate the message: 236 Client behavior, if no Advertise messages include authentication 237 information or pass the validation test, is controlled by local 238 policy on the client. According to client policy, the client MAY 239 choose to respond to an Advertise message that has not been 240 authenticated. 242 This seems to say, for example, that the client MAY accept an 243 Advertise message based on its local policy, even if the MAC computed 244 by the receiver does not match the MAC contained in the 245 authentication option. Apparently this contradicts with the 246 requirement in Section 21.4.2. 248 5.1 Suggested Resolution 250 There seems to be no valid reason for accepting an Advertise message 251 if it fails validation. On the other hand, it may make sense in some 252 cases that the client accepts the other type of unauthenticated 253 messages, that is, messages that do not include an authentication 254 option. 256 The suggested change to Section 21.4.4.2 is thus as follows. We use 257 a new term "non-authenticated messages" meaning DHCPv6 messages that 258 do not contain an authentication option. 260 [...] 262 Client behavior, if no Advertise messages include authentication 263 information is controlled by local policy on the client. 264 According to client policy, the client MAY choose to respond to a 265 non-authenticated Advertise message. 267 The decision to set local policy to accept non-authenticated 268 messages should be made with care. Accepting a non-authenticated 269 Advertise message can make the client vulnerable to spoofing and 270 other attacks. If local users are not explicitly informed that 271 the client has accepted a non-authenticated Advertise message, the 272 users may incorrectly assume that the client has received an 273 authenticated address and is not subject to DHCP attacks through 274 non-authenticated messages. 276 A client MUST be configurable to discard non-authenticated 277 messages, and SHOULD be configured by default to discard 278 non-authenticated messages if the client has been configured with 279 an authentication key or other authentication information. If a 280 client does accept a non-authenticated message, the client SHOULD 281 inform any local users and SHOULD log the event. 283 The second paragraph of Section 21.4.4.5 also needs a change: 285 If the client accepted a non-authenticated Advertise message, the 286 client MAY accept a non-authenticated Reply message from the 287 server. 289 If we take this suggestion, then we will not need the notion of 290 "unauthenticated message". As a result, the issue described in 291 Section 4 will become a non issue. 293 6. Possibility of Dos Attack 295 Section 21.4.4.5 of the RFC says as follows: 297 If the Reply fails to pass the validation test, the client MUST 298 restart the DHCP configuration process by sending a Solicit 299 message. 301 The purpose of this specification is probably to avoid a deadlock 302 scenario when the server suddenly reboots forgetting the 303 authentication key and/or the replay detection counter. 305 However, this behavior can easily cause denial of service (DoS) 306 attacks; the attacker can simply send an invalid Reply message at 307 some valid timing and can invalidate configuration information of the 308 client or can prevent the client from configuring itself. 310 As a side issue, this section seems to not consider 311 Information-request and Reply exchanges. 313 6.1 Discussion on Resolution 315 Even if a Reply message does not pass the validation tests, it is 316 probably reasonable to wait for an authenticated one until the first 317 timeout. Additionally, if the Reply message is a response to 318 Release, the client will not have to restart the configuration 319 process by Solicit. It can simply quit the session when the first 320 timeout occurs. 322 Reply messages to Information-request will need a separate 323 consideration. Obviously, it does not make sense to send a Solicit 324 message when the validation tests for a Reply message to 325 Information-request fail. The appropriate behavior is probably to 326 resend an Information-request message without including 327 authentication information based on the key previously used, and to 328 restart authentication. 330 7. Lack of Authentication from Client 332 It is not clear what the server should do when the client does not 333 include an authentication option while the server has previously sent 334 authentication information in the same session. 336 For messages other than Information-request, the appropriate behavior 337 depends on the resolution for the issue discussed in Section 5. 339 Assuming the proposed resolution is adopted, the server should 340 discard the message, since the client should have accepted the key as 341 long as it is valid and then must use the key for succeeding message 342 according to Section 21.4.4.3 of [RFC3315]. 344 The appropriate behavior for Information-request depends on the 345 resolution discussed in Section 2. If we take the proposed 346 resolution, then the server should accept the message and select a 347 new key, which may be the same as the one used before though, for the 348 new exchanges as described in Section 2. 350 8. Key Consistency 352 [RFC3315] requests in Section 21.4.4.3 that the client use the same 353 key used by the server to generate the authentication information. 354 However, it is not clear from the RFC what the server should do if 355 the client breaks this rule. It says in Section 21.4.5.2 that 357 If the message [...] or the server does not know the key 358 identified by the 'key ID' field, the server MUST discard the 359 message and MAY choose to log the validation failure. 361 It is not clear whether "does not know the key" means a different key 362 from the one the server specified in the Advertise message. If this 363 is the intent, this sentence should be clarified as follows: 365 If the message [...] or the key identified by the authentication 366 information of the message is not identical to the key that the 367 server has been using in the session, the server MUST discard the 368 message and MAY choose to log the validation failure. 370 9. Security Considerations 372 This document specifically talks about security issues for DHCPv6. 373 It also points out a possibility of DoS attacks, and gives some 374 considerations on how to prevent them. 376 10. IANA Considerations 378 This document has no actions for IANA. 380 11. References 382 11.1 Normative References 384 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 385 M. Carney, "Dynamic Host Configuration Protocol for IPv6 386 (DHCPv6)", RFC 3315, July 2003. 388 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 389 (DHCP) Service for IPv6", RFC 3736, April 2004. 391 11.2 Informative References 393 [I-D.ietf-dhc-lifetime] 394 Venaas, S. and T. Chown, "Lifetime Option for DHCPv6", 395 draft-ietf-dhc-lifetime-00 (work in progress), March 2004. 397 Author's Address 399 Tatuya Jinmei 400 Corporate Research & Development Center, Toshiba Corporation 401 1 Komukai Toshiba-cho, Saiwai-ku 402 Kawasaki-shi, Kanagawa 212-8582 403 Japan 405 Phone: +81 44-549-2230 406 EMail: jinmei@isl.rdc.toshiba.co.jp 408 Intellectual Property Statement 410 The IETF takes no position regarding the validity or scope of any 411 Intellectual Property Rights or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; nor does it represent that it has 415 made any independent effort to identify any such rights. Information 416 on the procedures with respect to rights in RFC documents can be 417 found in BCP 78 and BCP 79. 419 Copies of IPR disclosures made to the IETF Secretariat and any 420 assurances of licenses to be made available, or the result of an 421 attempt made to obtain a general license or permission for the use of 422 such proprietary rights by implementers or users of this 423 specification can be obtained from the IETF on-line IPR repository at 424 http://www.ietf.org/ipr. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights that may cover technology that may be required to implement 429 this standard. Please address the information to the IETF at 430 ietf-ipr@ietf.org. 432 Disclaimer of Validity 434 This document and the information contained herein are provided on an 435 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 436 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 437 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 438 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 439 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 440 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 442 Copyright Statement 444 Copyright (C) The Internet Society (2004). This document is subject 445 to the rights, licenses and restrictions contained in BCP 78, and 446 except as set forth therein, the authors retain all their rights. 448 Acknowledgment 450 Funding for the RFC Editor function is currently provided by the 451 Internet Society.