idnits 2.17.1 draft-roe-mobileip-updateauth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 32 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 32: '...fferent protocols that MAY be used for...' RFC 2119 keyword, line 38: '...eir peers. Nodes MAY choose a differen...' RFC 2119 keyword, line 40: '... example, a host MAY accept Binding Ac...' RFC 2119 keyword, line 42: '...g Updates. Nodes MAY vary the level of...' RFC 2119 keyword, line 44: '...e-only mechanism MAY require use of th...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 2001) is 8288 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1750 (ref. '3') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2373 (ref. '4') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1305 (ref. '6') (Obsoleted by RFC 5905) Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group M. Roe 3 INTERNET DRAFT Microsoft 4 Expires: December 2001 August 2001 6 Authentication of Mobile IPv6 Binding Updates and Acknowledgments 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 1 Introduction 32 This memo describes four different protocols that MAY be used for 33 authenticating Binding Update or Binding Acknowledgment destination 34 options [5]. Each protocol provides a different level of security, 35 ranging from no authentication to a challenge-response mechanism 36 using digital signatures. These mechanisms include a negotiation 37 facility that enables nodes to determine which of these mechanisms 38 are acceptable to their peers. Nodes MAY choose a different level of 39 security for Binding Acknowledgments than for Binding Updates. For 40 example, a host MAY accept Binding Acknowledgments with no 41 authentication while requiring the signed challenge-response 42 mechanism for Binding Updates. Nodes MAY vary the level of security 43 that they require dynamically. For example, a node that normally 44 accepts the signature-only mechanism MAY require use of the signed- 45 challenge response mechanism when it has detected that it is being 46 subjected to a denial of service attack. 48 2 IP Addresses derived from Cryptographic Keys 50 In some of the mechanisms described in this memo, a node uses a home 51 address that is derived from the node's public key. The idea behind 52 this is that if the address is the same as the public key, nodes can 53 work out which key corresponds to an address without needing to use a 54 secure key distribution mechanism such as X.509 certificates. Such 55 key distribution mechanism typically needs to be configured manually, 56 and this conflicts with the design goal of IPv6 that it should be 57 possible to configure hosts automatically. However, it is not 58 possible to set the IP address equal to the public key, because they 59 will normally be of different length, and the network part of the 60 address must be set to the right value for the packet to be routed 61 correctly. Instead, we use a more complex relationship between the 62 address and the key, in which the last 64 bits of the address (the 63 "Interface ID") are defined as follows: 65 InterfaceId = First64(SHA1(M | RFU | Public Key)) 66 & 0xfcffffffffffffff 68 The field "RFU" is reserved for future use, and shall be set to zero. 69 The field "M" is a modifier, who use is as follows. A node generates 70 a private/public key pair, and then attempts duplicate address 71 detection for an address generated using the above equation with M 72 set to zero. It is very unlikely that a collision will occur except 73 as a result of an attack on the protocol. However, if a collision is 74 detected the host MAY attempt duplicate address detection again with 75 a different address, generated using the same public key and with M 76 equal to one. If necessary, this process may be be repeated with M 77 equal to 2 and M equal to 3. Nodes MUST NOT use values of M greater 78 than three. Four collisions in a row are very, very unlikely to occur 79 by chance, and are almost certainly the result of either an attack on 80 the protocol or an error in the implementation. 82 Bit 6 of the host part of the address is the universal/local bit [4]. 83 It is set to zero to indicate that it is not guaranteed to be 84 globally unique. Bit 7 of the host part of the address is the 85 individual/group bit [4]. It is set to zero to indicate that it is 86 the address of an individual node, not a group of nodes. 88 3 Abstract Protocols 90 This section provides a high-level description of the four 91 authentication protocols. Each of these protocols MAY be used for 92 authenticating Binding Updates or Binding Acknowledgments, although 93 the details of the packet formats are different in these two cases. 95 3.1 No authentication 97 A -> B : message 99 In this mechanism, messages are sent without authentication. 101 3.2 Challenge-Response Mechanism 103 B -> A : RA 105 A -> B : RA, message 107 In the challenge-response mechanism, the verifier (B) will only 108 accept messages if they contain a challenge which the verifier has 109 sent to the claimant (A) in a previous message. The challenges should 110 be generated in way that makes them unpredictable, so that an 111 attacker cannot guess the right response to send. 113 This mechanism does not protect against attackers who can monitor 114 messages sent to other parties. It protects against attackers who can 115 forge their source address but are unable to intercept messages. 117 3.3 Signature Mechanism 119 -1 120 A -> B : KA, M, { message, HA(A), COA(A), HA(B), COA(B), TA } KA 122 In the signature mechanism, the claimant (A) signs messages with a 123 private key, and uses a home address that is derived from their 124 public key in the way that was described in section 2. The claimant 125 sends their public key (KA), the modifier (M) that was used to derive 126 their home address from the key, and the signed message to the 127 verifier (B). The signed message contains a timestamp (TA) to protect 128 the message against replay. 130 The verifier checks that the timestamp is recent, that the the 131 claimant's home address is derived from the public key, and that the 132 signature matches. 134 This mechanism requires the clocks of the claimant and the verifier 135 to be loosely synchronized. They do not need to be exactly the same, 136 but they SHOULD be within a few seconds of each other. Too large a 137 difference between the sender's and receiver's clocks can cause 138 genuine messages to be rejected as replays and replays to be accepted 139 as genuine. 141 An out of date timestamp can be caused either by an attacker 142 replaying messages or by the clocks not being adequately 143 synchronized. A verifier that detects an out of data timestamp MAY 144 request the claimant to resend the message using an alternative 145 authentication mechanism that does not depend on synchronized clocks. 147 3.4 Signed Challenge-Response Mechanism 149 B -> A : RA 150 -1 151 A -> B : KA, M, { message, HA(A), COA(A), HA(B), COA(B), RA } KA 153 The signed challenge-response mechanism combines the features of the 154 challenge-response mechanism and the signature mechanism. The 155 verifier will only accept messages if they contain a challenge that 156 the verifier has previously sent, and are signed with a private key 157 that is related to the claimant's home address as described in 158 section 2. Unlike the signature mechanism, this mechanism does not 159 depend on synchronized clocks. The challenge serves two purposes: it 160 is used as a quick check that will detect many attempted forgeries 161 without needing to perform any public-key operations, and it is also 162 used to detect replays of old messages. 164 Verifiers SHOULD check that the response (RA) is correct before 165 attempting to verify the digital signature. It is typically much 166 quicker to verify RA than to verify the signature, and so verifying 167 RA first provides better protection against denial of service attacks 168 in which the verifier is flooded with many bogus messages. 170 4 New IPv6 Sub-option Types 172 This memo defines the following IPv6 sub-option types: 174 4.1 Address-related RSA Public Key Sub-option 176 Alignment requirement: none 178 0 1 2 3 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | TBA | Length | M | RFU | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Public Key (variable length) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 The Address-related RSA Public Key sub-option is valid only in Home 187 Address destination options. The Public Key field contains an RSA 188 public key, encoded as the ASN.1 Basic Encoding Rules [1] 189 representation of the type PublicKey. 191 PublicKey ::= SEQUENCE 192 { 193 modulus INTEGER, 194 exponent INTEGER 195 } 197 The RFU (reserved for future use) field SHALL contain zero bits. 198 Packets in which these bits are non-zero MUST be rejected as invalid. 199 (See the security considerations section of this memo for the 200 rationale for this) 202 The following relationship SHALL hold between the public key field 203 and the network part of the home address, where SHA1 is the SHA-1 204 message digest algorithm [2] and First64 extracts the first 64 bits 205 of the 128 bit hash value. 207 InterfaceId = First64(SHA1(M | RFU | Public Key)) & 0xfcffffffffffffff 209 Packets where this relationship does not hold MUST be rejected as 210 invalid. 212 4.2 Time Sub-option 214 Alignment requirement: 4n+2 216 0 1 2 3 217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | TBA | 4 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Time | 222 +---------------------------------------------------------------+ 224 The Time sub-option is valid only in Binding Update or Binding 225 Acknowledgment destination options. The Time field contains the time 226 that the Binding Update or Acknowledgment was generated, as measured 227 by the sender's clock. The time is represented by the middle 32 bits 228 of the NTP timestamp [6]. 230 4.3 Challenge Sub-option 232 Alignment requirement: 4n+2 233 0 1 2 3 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | TBA | 4 | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Challenge | 239 +---------------------------------------------------------------+ 241 The Challenge sub-option is valid only in Binding Acknowledgment, 242 Binding Update or Binding Request destination options. This field 243 MUST NOT occur in a Binding Acknowledgment whose status field is zero 244 (success). The Challenge field contains a challenge which has been 245 generated randomly or pseudo-randomly by the sender. 247 This sub-option is used to request the use of the Challenge-Response 248 Response authentication mechanisms. 250 4.4 Signature Challenge Sub-option 252 Alignment requirement: 4n+2 254 0 1 2 3 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | TBA | 4 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Challenge | 260 +---------------------------------------------------------------+ 262 The Signature Challenge sub-option is valid only in Binding 263 Acknowledgment, Binding Update or Binding Request destination 264 options. This field MUST NOT occur in a Binding Acknowledgment whose 265 status field is zero (success). The Challenge field contains a 266 challenge which has been generated randomly or pseudo-randomly by the 267 sender. 269 This sub-option is used to request the use of the Signed Challenge 270 Response authentication mechanisms. 272 4.5 Response to Challenge Sub-option 274 Alignment requirement: 4n+2 276 0 1 2 3 277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | TBA | 4 | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Response | 282 +---------------------------------------------------------------+ 284 The Response to Challenge sub-option is valid only in Binding Update 285 or Binding Acknowledgment destination options. A Binding 286 Acknowledgment destination option MUST NOT include a Response to 287 Challenge sub-option unless it is generated in response to a Binding 288 Request destination sub-option that includes a Challenge sub-option. 289 A Binding Update destination option MUST NOT include a Response to 290 Challenge sub-option unless it is generated in response to a Binding 291 Request destination option that includes a Challenge sub-option. 293 The Response field contains a copy of the Challenge field from the 294 Challenge (or Signature Challenge) sub-option from the Binding Update 295 (or Request) that caused the Binding Acknowledgment (or Update) to be 296 generated. 298 5 New Assigned Numbers 300 5.1 Binding Acknowledgment Status Values 302 The following new values for the Status field within a Binding 303 Acknowledgment sub-option are defined: 305 Authentication Required 306 Authentication Failed 307 Time Error 309 A status of "Authentication Required" indicates that sender requires 310 authentication for Binding Update destination options. If the status 311 is "Authentication Required", then the sub-options field SHALL 312 include one or more sub-options that describe authentication methods 313 that the sender will accept (e.g. a Challenge sub-option) 315 A status of "Authentication Failed" indicates that verification of 316 the authenticator field in the Binding Update failed. If the status 317 is "Authentication Failed", then the sub-options field MUST NOT 318 include sub-options that describe alternative authentication methods. 320 A status of "Time Error" indicates that the Binding Acknowledgment 321 was rejected because the difference between the time as measured by 322 the sender's local and the time as indicated in the Time sub-option 323 of the Binding Update was too great, Possible causes of this 324 situation include: either the sender or the receiver's clock is set 325 incorrectly; an attacker is replaying old Binding Updates. If the 326 status is "Time Error", then the sub-options field SHALL include one 327 or more sub-options that describe authentication methods that the 328 sender will accept and that do not depend on the sender and receiver 329 having synchronized clocks. 331 5.2 Security Parameters Index 333 The following new value for the Security Parameters Index field 334 within a Binding Update or Binding Acknowledgment destination option 335 is defined: 337 Signature with Key related to Address 339 6 Realization of the Abstract Protocols for Binding Updates 341 6.1 Challenge-Response Mechanism 343 A correspondent node MAY request use of the Challenge-Response 344 mechanism for binding updates either by sending a Binding Request 345 destination option containing a Challenge sub-option, or by sending a 346 Binding Acknowledgment destination option with the status not equal 347 to zero and containing a Challenge sub-option. 349 To use the challenge-response mechanism for binding updates, a mobile 350 node includes a Response to Challenge sub-option. 352 6.2 Signature Mechanism 354 This memo does not specify a method for a correspondent node to 355 explicitly request the use of the signature mechanism. It is 356 recommended that the Signed Challenge Response mechanism SHOULD be 357 used in preference to the Signature mechanism in situations where the 358 claimant sends an authenticated message in response to a request from 359 the verifier. The signature mechanism is mainly useful in situations 360 where the claimant sends a message to the verifier without having 361 received a message in the opposite direction first. 363 To use the Signature mechanism for binding updates, a mobile node 364 includes a Time sub-option, sets the Security Parameters Index field 365 of the binding update destination option to Signature with Key 366 Related to Address (defined in section 5), and places a digital 367 signature within the authentication information field of the binding 368 update option. 370 6.3 Signed Challenge-Response Mechanism 372 A correspondent node MAY request the use of the Signed Challenge- 373 Response mechanism for binding updates either by sending a Binding 374 Request destination option containing a Signature Challenge sub- 375 option, or by sending a Binding Acknowledgment destination option 376 with the status not equal to zero and containing a Signature 377 Challenge sub-option. 379 To use the Signed Challenge-Response mechanism for binding updates, a 380 mobile node includes a Response to Challenge sub-option, sets the 381 Security Parameters Index fielf of the binding update destiantion 382 option to Signature with Key Related to Address (as defined in 383 section 5), and places a digital signature within the authentication 384 information field of the binding update option. 386 7 Realization of the Abstract Protocols for Binding Acknowledgments 388 7.1 Challenge-Response Mechanism 390 A mobile node MAY request the use of the Challenge-Response mechanism 391 for a binding acknowledgments by sending a Binding Update containing a 392 Challenge sub-option. 394 To use the challenge-response mechanism for binding acknowledgments, a 395 mobile node includes a Response to Challenge sub-option. 397 7.2 Signature Mechanism 399 It is recommended that the Signed Challenge Response mechanism SHOULD 400 be used in preference to the Signature mechanism for Binding 401 Acknowledgments, as these acknowledgments are always sent in response 402 to a message in the opposite direction. 404 7.3 Signed Challenge-Response Mechanism 406 A mobile node MAY request the use of the Signed Challenge-Response 407 mechanism by including a Signature Challenge sub-option within a 408 Binding Update destination option. 410 To use the signed challenge-response mechanism for binding 411 acknowledgments, a node includes a Response to Challenge sub-option, 412 sets the Security Parameters Index to Signature with Key Related to 413 Address, and places a digital signature within the Authentication 414 Information field of the binding acknowledgment. 416 8 Security Considerations 418 8.1 Risks of unauthenticated binding updates 420 If a node accepts binding updates without authentication, then it is 421 vulnerable to several attacks in which an attacker sends forged 422 binding updates for other nodes. These include a denial of service 423 attack in which the attacker sends the victim a forged binding update 424 for a service that the victim relies on (e.g. the domain name 425 service), and sets this service's care of address to a non-existent 426 address. The victim will be unable to contact the service at the 427 falsified care of address, and henceforth will be unable to make use 428 of the service. A variation on this attack with consequences beyond 429 denial of service is when the attacker sets the service's care of 430 address to the attackers own address, and the attacker then provides 431 a maliciously modified version of the service. 433 For this reason, it is recommended that nodes on the Internet SHOULD 434 use some form of authentication for binding updates. Nodes on private 435 intranets that use other means to exclude potential attackers MAY 436 accept binding updates without authentication. 438 8.2 Risks of unauthenticated binding acknowledgments 440 The consequences of forged binding acknowledgments are, in general, 441 less serious that those of forged binding updates. The usual 442 consequence of forging a binding acknowledgment is that the victim's 443 correspondent will fail to obtain an up-to-date binding for the 444 victim, the correspondent's previous binding for the victim will 445 expire, and the correspond will revert to sending packets via the 446 victim's home agent. Communications between the victim and its 447 correspondent will still work, but may suffer degraded performance. 448 In some circumstances this degradation of performance will be 449 sufficiently severe to constitute a denial of service attack. 451 Forged binding updates sent to the victim's home agent have more 452 serious consequences than forgeries sent to other correspondents. If 453 victim is away from home, and its home agent does not have a valid 454 binding for it, then the victim will become uncontactable. 456 One possible security policy that takes into account these 457 considerations is to require authenticated binding updates from a 458 home agent, but to accept unauthenticated binding updates from other 459 correspondents. 461 8.3 Denial of service attacks on the Signature only mechanism 463 The signature mechanism protects hosts against denial of service 464 attacks in which they are sent forged binding updates, but it makes 465 them vulnerable to a new denial of service attack in which the 466 attacker floods them with a very large number of binding updates with 467 invalid signatures. These binding updates will be rejected, but 468 because the signature takes a significant amount of computing time to 469 check, the victim may not have CPU time left in which to do anything 470 else. The Signed Challenge-Response mechanism is not vulnerable to 471 this attack, and it SHOULD be used instead of the Signature Only 472 mechanism in environments where this attack is a concern. 474 8.4 Challenges must be unpredictable 476 In the Challenge-Response and Signed Challenge-Response mechanisms, 477 the value chosen for the challenge must be difficult for an attacker 478 to predict. RFC 1750 [3] has recommendations on how to choose 479 unpredictable random numbers. 481 8.5 Meet in the Middle Attacks 483 The Signature Only and Signed Challenge-Response are vulnerable to a 484 meet in the middle attack, where the attacker wishes to masquerade as 485 one of a large number of hosts, but does not care which of those host 486 they are able to impersonate. In this attack. the attacker generates 487 a large number of key pairs and addresses until they obtain an 488 address that collides with one of the possible victims. If the set of 489 possible victims is very large, this is faster than attempting to 490 impersonate one specific victim. In view of this attack, care should 491 be taken when using these mechanisms to authenticate messages other 492 than binding updates or acknowledgments. The use of these mechanisms 493 for other purposes is outside the scope of this memo. 495 8.6 Risks of making the Modifier field too large 497 This memo restricts the possible values of the modifier field to the 498 range 0 to 3. If the protocol had permitted a wider range of modifier 499 values, it would have been easier to attack. An attacker who wishes 500 to masquerade as a particular address can generate a key pair and 501 then try different values of the modifier to see if any of them hash 502 to the address they wish to impersonate. When all possible values of 503 the modifier have been tried, the attacker can try different keys. 504 Generating a new key pair takes much longer than trying a different 505 modifier, so by restricting the range of modifier values we make the 506 attacker's job harder. If this attack succeeds, the attacker will 507 (with high probability) still not know the victim's private key. The 508 attacker will have a different private key who corresponding public 509 component happens to hash to the same value as the victim's public 510 key. However, this is sufficient to break the protocol. 512 A variation on this attack is to try public keys which are 513 cryptographically weak (e.g. easy to factorize), and to start work on 514 calculating the corresponding private key when a public key has been 515 found that hashes to the right value. It is quicker to generate a 516 weak key than a strong one (at least with RSA), and so this may speed 517 up the attack. 519 8.7 Strength of Mechanism 521 The Signature and Signed Challenge-Response mechanism construct a 522 home address using 62 bits out of the 160 bit output of SHA-1. Only 523 62 bits can be used, because the host part of an address is 64 bits 524 long, and two of those bits are the universal/local and the 525 individual/group bit. The number of address bits is fixed by the IPv6 526 addressing architecture [4] and cannot be increased. Using only some 527 of the bits of the SHA-1 output reduces the cryptographic security of 528 the hash function. It is much easier for an attacker to find an input 529 which gives particular values for 62 of the output bits than it is to 530 find an input which gives particular values for all 160 of the output 531 bits. Accordingly, users of these mechanism should take care that the 532 reduced level of security of these mechanisms is appropriate for the 533 environment in which they are being used. 535 When evaluating the strength of these mechanisms, it is important to 536 bear in mind that SHA-1 is designed to have two properties (non- 537 invertability and collision-freedom), and that the mechanisms 538 described in this memo only rely on the non-invertability property. 539 To achieve a particular level of security,it takes approximately 540 twice as many bits of the hash output to provide the non-invertabiity 541 property as it does to provide the collision-freedom property. 542 Mechanisms that only rely on non-invertability can get away with 543 using half as many bits of the hash output as mechanisms that rely on 544 collision-freedom. 546 9 References 548 [1] Information processing systems - Open Systems Interconnection - 549 Specification of Basic Encoding Rules for Abstract Syntax Notation 550 One (ASN.1). ISO 8825, International Organization for 551 Standardization, 1987. 553 [2] Secure hash standard. FIPS PUB 180-1, NIST, April 1995 555 [3] D. Eastlake, S. Crocker and J. Schiller. Randomness 556 recommendations for security. RFC 1750, December 1994. 558 [4] R. Hinden and S. Deering. Ip Version 6 Addressing Architecture. 559 RFC 2373, July 1998. 561 [5] D. B. Johnson and C. Perkins. Mobility Support in IPv6. Internet 562 draft, July 2001. 564 [6] D. L. Mills. Network time protocol (version 3) specification, 565 implementation and analysis. RFC 1305, March 1992. 567 10 Author's Address 569 Michael Roe 570 Microsoft Research Limited 571 St George House 572 1 Guildhall Street 573 Cambridge CB2 3NH 574 UK