idnits 2.17.1 draft-jennings-sip-hashcash-06.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1323. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 549 has weird spacing: '... where prox...' -- 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 7, 2007) is 6135 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: 'RFC-XXXX' on line 625 ** Obsolete normative reference: RFC 3548 (ref. '1') (Obsoleted by RFC 4648) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '6') (Obsoleted by RFC 8224) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-spam-04 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track July 7, 2007 5 Expires: January 8, 2008 7 Computational Puzzles for SPAM Reduction in SIP 8 draft-jennings-sip-hashcash-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 8, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 One of the techniques used in SPAM prevention and various solutions 42 for denial of service attacks is to force the SIP client requesting a 43 service to perform a calculation that limits the rate and increases 44 the cost of the request. This draft defines a way to allow a UAS to 45 ask the UAC to compute a computationally expensive hash based 46 function and present the result to the UAS. Although the computation 47 is expensive for the UAC to compute, it is cheap for the UAS to 48 verify. The solution also allows for proxies to compute and check 49 the puzzle on behalf of the UAC or UAS. 51 This draft currently outlines enough information to evaluate and 52 consider this approach or even run experiments. It would need 53 finalization around the forking topics discussed in the open issues 54 before it would be implementable in production system. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. UAS Creating Puzzle . . . . . . . . . . . . . . . . . . . 7 64 5.2. UAC Receiving Puzzle . . . . . . . . . . . . . . . . . . . 7 65 5.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8. Open Issues and To Do Items . . . . . . . . . . . . . . . . . 13 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 10.1. Puzzle Header . . . . . . . . . . . . . . . . . . . . . . 14 72 10.2. 419 Response . . . . . . . . . . . . . . . . . . . . . . . 14 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 74 12. Appendix A: Test Vectors . . . . . . . . . . . . . . . . . . . 15 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 77 13.2. Informational References . . . . . . . . . . . . . . . . . 28 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 Intellectual Property and Copyright Statements . . . . . . . . . . 29 81 1. Introduction 83 The SPAM prevention problem is complex and will require many 84 techniques working in combination to balance reducing SPAM to 85 acceptable levels while still fostering efficient communication. The 86 overall problem and various approaches are in [7]. Clearly white 87 lists are a critical part of dealing with SPAM. Any system would 88 first check whether an incoming request for communications was from 89 someone on the white list. The Identity [6] mechanisms are critical 90 for understanding who the caller is and to check whether the caller 91 is on the white list. As well, there still needs to be a way for 92 callers not on the white list to communicate with the user. It is 93 here that this specification becomes relevant. 95 The problem is how to permit contacts from people with no previous 96 relationship to us without receiving undesirable contacts. This 97 draft uses the idea that it may be possible to make undesirable 98 contacts more expensive than desirable ones. 100 Different undesirables are willing to spend different amounts of time 101 and money on contacting their markets. Founders of acquired startups 102 are often contacted by random financial companies offering to help 103 manage the new riches. These companies will send people from New 104 York to San Jose and spend hours talking to this very narrow target 105 market. Clothing retailers will mail glossy catalogues worth $1 106 apiece to houses within the right demographic zip codes. Emails 107 advertising Viagra are sent to random email addresses. As the costs 108 go down, the volume of unsolicited contact goes up. 110 Often people whose contact is desirable are willing to spend much 111 less than some of the undesirables. The student in Fiji who wants to 112 ask about this draft will send an email but probably will not fly 113 here to talk to me. I would like to receive that email. 115 Increasing the cost of contact will reduce both desirable and 116 undesirable contact. My assumption is that the cost should be set 117 very low, so that even a person with a pathetic CPU could still make 118 contact in, say, 10 seconds. Key to this draft is that the receiver 119 can set this cost. This low cost will not stop the financial 120 advisers or the telemarketers, but it might stop the Viagra ads. It 121 would also probably stop a single user from ringing every phone of 122 some residential service provider in a five-second window, before any 123 operator or system can react. Deciding what cost to set constitutes 124 a classic type I/type II error problem, and the receiver gets to 125 choose how to balance these two errors. 127 As is clearly stated in [7], whitelists are the best thing. After 128 that, this is one of the multiple other options that need 129 consideration. 131 In general there are two arguments about why the computation puzzles 132 in this specification will not work. The first is that the bad guys 133 have the most powerful CPUs. This issues was addressed above. The 134 other argument is that bad guys have infinite CPU time through using 135 armies of zombie PCs. The problem with this argument is that the 136 goal is not to block particular bad guys but to reduce the overall 137 number of undesirable messages. This second argument is, however, 138 more worrisome than the first. 140 Assume that some percentage of the world's machines each year get 141 owned and used as zombies. Let's say that a given machine has 1% of 142 having this happen to it in a year, that it sends zombie traffic for 143 24 hours before getting shut down, and that the mechanism described 144 here limits it to ten messages per second: each machine on the 145 internet would receive an average of about one undesirable message 146 per hour. If you assume there are more users than machines, this 147 looks appealing. If message sending technology detects users that 148 are sending lots of messages and shuts them down in less than 24 149 hours, it gets better. It gets better still if you hope for 150 improvements in operating systems or for users to choose them more 151 carefully. The next assumption is hard to model statistically but it 152 is true: the people with the best financial incentives to send 153 undesirable messages do not want to be subject to the legal and 154 reputation problems of using zombies to get their message across. 156 The zombie problem basically comes down to this. If there are a 157 small percentage of machines in the world that are zombies, they do 158 not render this computation puzzle approach useless. If 10% of the 159 machines in the world are zombies, this approach will be useless. 160 This specification does not attempt to deal with how to make the 161 world such that a small percentage of computers are zombies - the is 162 the problem for other work and that work needs to happen for SPAM to 163 be reduced to reasonable level. This specification does assume that 164 the zombie problem is solved to the level where a small percentage of 165 the worlds computers are zombies. 167 Clearly there is a need to be able to initiate SIP communications 168 from very low power, low cost, devices. They will have relatively 169 slow CPUs and their users will be very impatient and only willing to 170 wait a short time to compute the puzzle. On the other hand there 171 will be attackers with very fast computers and possibly many of them. 172 The relative ratio of these speeds and size of the attacker 173 population will determine how effective this approach is. 175 So in summary, white listing is the first and best defense. But for 176 dealing with messages from people with whom we have not previous 177 direct or indirect relationship, another approach is necessary. 178 Puzzles cannot stop all bad messages - that is not the goal - but it 179 can raise the cost of messages and thus decrease the number of times 180 it makes economic sense to send undesirable ones. This approach does 181 assume that bad guys will have more CPU power than good guys and that 182 zombies will still send lots of messages. This approach will simply 183 reduce the number of undesirable messages by some amount that cannot 184 be measured. 186 No one knows if this approach would reduce SPAM noticeably. Right 187 now the only thing that limits the rate at which I can call every SIP 188 phone in the world is proxies getting overloaded. And of course, 189 most SIP phones are not connected to the public internet. The SPAM 190 problem is one reason why many SIP phones are not connected to the 191 public internet. There are some other approaches outlined in [7]. 192 They have different pros and cons, and it is probably necessary to 193 use most of them to ensure SPAM stays at an acceptable level. 195 2. Overview 197 This specification extends RFC 3261 [3] and defines a mechanism for a 198 proxy or UAS to request that a UAC compute the solution to a puzzle. 199 The puzzle is based on finding a value called the pre-image that, 200 when hashed with SHA1 [4], results in a specific value referred to as 201 the image. The goal is for the UAC to find a pre-image that will 202 SHA1 hash to the correct image. The UAS provides a partial pre-image 203 with some of the low order bits set to zero, together with the number 204 of bits in the pre-image that have been set to zero. 206 The UAS provides the puzzle information using a 419 response, and the 207 UAC resubmits the request along with the solution to the puzzle. The 208 high level flow of information is shown below. 210 UAC UAS 211 | Request | 212 |------------------------->| 213 | | 214 | 419 with Puzzle | 215 |<-------------------------| 216 | | 217 | Request with Solution | 218 |------------------------->| 219 | | 221 This specification defines the 419 response code along with a new 222 header, called Puzzle, to carry the puzzle and solution. 224 3. Definitions 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in RFC 2119 [2]. 230 4. Puzzles 232 The normative definition of a puzzle is as follows. A puzzle is four 233 values: an integer number referred to as work, a pre-image string, an 234 image string, and a integer number referred to as value. There MUST 235 exist a value X such that all but the "work" number of low order bits 236 of X match the pre-image string, and the SHA1 hash of the string 237 formed by the concatenation of "z9hG4bK" and X results in a value Y, 238 where the "value" number of low order bits of Y are the same as those 239 bits in the image string. The SHA1 hash is computed as described in 240 RFC 3174 [4]. The value X is the solution to the puzzle. The 'work' 241 number of low order bits of the pre-image MUST be zero. 243 This can all be described more mathematically. The notation low(v,x) 244 returns the first v number of low order bits of the value x, and 245 zero(v,x) returns x with the lowest v number of bits set to zero. 246 The | operator signifies string concatenation. The solution to the 247 puzzle can be considered finding an X such that both the following 248 are true: 250 low( value, image ) = low( value, sha1( "z9hG4bK" | X ) ) 251 zero( work, X ) = zero( work, pre-image ) 253 The pre-image forms a constraint on X. The value of X is the same 254 pre-image, other than the low 'work' bits that are set to zero in the 255 pre-image. The 'value' is the number of bits that match in the 256 solution and is typically set to 160, which is the full size of the 257 SHA1 hash result. 259 The following is a non-normative way for a UAS or proxy to construct 260 a puzzle. The following strings are concatenated: 262 1. a secret that only this device knows. This would typically be a 263 crypto random string of bits; 264 2. the current time 265 3. the URI of the request, the Call-ID, the From tags, and the 266 branch tag for a proxy or the To tag for a UAS. 268 The string is hashed with SHA1 to form the pre-image. The pre-image 269 is appended to the string "z9hG4bK", and the SHA1 hash of this is 270 computed to get the value of the image. A value 'work' indicates how 271 many bits of the pre-image are to be removed. The value 'work' could 272 be a configurable parameter, or it could be dynamically discovered by 273 the software based on how long a hash should take and the speed of 274 the computer it was running on. In the latter case, the resulting 275 software would automatically choose larger values of 'work' as 276 computers get faster. The low order 'work' bits of the pre-image are 277 set to zero. The puzzle consists of the chosen value of 'work', the 278 pre-image (with the low order bits set to zero), the image, and the 279 'value'. The 'value' would typically be set to 160 as this is the 280 size of the SHA1 hash. Since the time was rounded 282 Note: Some implementors have pointed out that this approach requires 283 the UAS to do a SHA1 to compute the puzzle and that this creates 284 extra load on the UAS. On a machine with a proxy that could process 285 about thousand sip transactions per second, the approximate rate of 286 puzzle creation was over one million puzzles per seconds. The work 287 to create a puzzle is trivial compared to the work to receive a sip 288 messages and send the response. The advantage of a puzzle in this 289 form seemed apparent at some time in the past but I can not remember 290 why. Big TODO item to recall why this form was used. This form does 291 allow progressively better solutions to be found with a higher 292 "value" without changing the image string. 294 5. Semantics 296 5.1. UAS Creating Puzzle 298 When a UAS wishes to challenge a request, it MAY create a puzzle, 299 encode this puzzle in a Puzzle header field value, and return the 300 puzzle in a 419 response. 302 5.2. UAC Receiving Puzzle 304 When a UAC receives a 419 response, it needs to look at the 'work' 305 and 'value' requested and decide whether or not to try to solve this 306 puzzle. This decision can be made based on the programmed policy and 307 possibly human input. The UAC should not tackle a puzzle that will 308 take longer than the age of the universe to solve. If the UAC 309 chooses to try to solve the puzzle then it proceeds along the 310 following steps: 312 1. Check that the 'work' bottom bits of the pre-image are all zero. 313 If they are not, this is an invalid puzzle and the 419 response 314 MUST be considered an error response. 316 2. Set Y to low( value, image ). 317 3. Create a loop where X ranges from the value of the pre-image to 318 the value of the pre-image plus 2 raised to power of the 'work'. 319 4. For each interaction through the loop, check if low( value, sha1( 320 "z9hG4bK" | X )) equals Y. If it does, a solution X has been 321 found and the loop can terminate. 323 If the loop terminates without a solution being found, the puzzle was 324 bad and the 419 response MUST be considered as an error response. 326 Once the solution to the puzzle, X, is found, a new request is formed 327 by copying the old request and adding an additional puzzle header 328 field value. The new puzzle header field value MUST have the 'work' 329 set to 0, the pre-image set to the value X, the image set to the 330 value of the image in the original puzzle, and the value parameter 331 set to the same as the value parameter in the original puzzle. Note 332 that if a request was challenged by one proxy and a new request was 333 generated with a solution, and then this request was challenged by a 334 second proxy, a third request would be generated that had two Puzzle 335 header field values. If a UAC, through some out of band mechanism, 336 knows that it will be challenged and what the puzzle will be, it MAY 337 include the appropriate puzzle header field value in the initial 338 request. 340 5.3. Proxy Behavior 342 SIP allows proxies to act as UASs when generating 4xx responses. 343 This same mechanism can be used to allow a proxy to generate the 344 challenge on behalf of a UAS in its domain. 346 Proxies may also act on behalf of the UAC and compute the solution to 347 a puzzle on behalf of the UAC in either a request or a response that 348 passes through the proxy. Typically a proxy would only do this for a 349 UAC that had authenticated to the proxy and for which the proxy had a 350 service relationship. 352 6. Example 354 In this example, we present a communication establishment between two 355 users, Alice (sip:alice@example.com) and Bob (sip:bob@example.net). 356 First, Alice sends an INVITE to Bob. Bob, who wants to make sure that 357 Alice is not a spammer, replies to Alice with a message "419 - Puzzle 358 Required'', indicating that he wants Alice to pass a challenge before 359 establishing a communication. Bob's reply contains a Puzzle that Bob 360 wants Alice to solve. To get the "preImage'' value, Bob generates a 361 random string that he hashes with SHA1. If we define "SHA1'' as the 362 method that hashes a string: 364 preImage = SHA1(random string) 366 To get the "image'', Bob appends the string "z9hG4bK" to his 367 "preImage'', and he hashes this new string with SHA1 again. We can 368 say: 370 image = SHA1 ("z9hG4bK"|preImage) 372 where the "|" operator signifies string concatenation. 374 Bob chooses to fix the value of "value'' to 160, as it is the size 375 (in bits) of the "preImage'' and the "image'' that he's going to send 376 to Alice. As seen before, the value of "work'' determines the 377 difficulty of the problem, and has to be set up depending on the 378 power of Alice's UA. To simplify the problem, let's suppose that Bob 379 chooses to fix "work'' to 15. Before putting these values into the 380 "Puzzle header'' field, Bob saves the value of his "preImage", and 381 applies the method "zero(value, preImage)" to set the "value" bottom 382 bits of "preImage'' to 0. 384 If we assume that Bob has picked the random string 385 "itjjyfdubtpneggrdsaavouy", he has the following values: 387 random string 388 = "itjjyfdubtpneggrdsaavouy" 390 original preImage 391 = SHA1(random string) 392 = "VgVGYixbRg0mdSwTY3YIfCBuYmg=" (base-64 encoded) 393 = "01010110 00000101 01000110 01100010 00101100 01011011 01000110 394 00001101 00100110 01110101 00101100 00010011 01100011 01110110 395 00001000 01111100 00100000 01101110 01100010 01101000" (binary) 397 sent preImage 398 = zero(work, preImage) where work = 15 399 = "VgVGYixbRg0mdSwTY3YIfCBuAAA=" (base-64 encoded) 400 = "01010110 00000101 01000110 01100010 00101100 01011011 01000110 401 00001101 00100110 01110101 00101100 00010011 01100011 01110110 402 00001000 01111100 00100000 01101110 00000000 00000000" (binary) 404 image 405 = SHA1 ("z9hG4bK"|original preImage) 406 = "NhhMQ2l7SE0VBmZFKksUC19ia04=" (base-64 encoded) 408 Then Bob constructs the Puzzle header field, that has this form: 410 Puzzle: work=15; pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; 411 image="NhhMQ2l7SE0VBmZFKksUC19ia04="; value=160 413 At this point Bob answers to Alice's INVITE, with a message "419 414 Puzzle required" containing the "Puzzle header" field that he has 415 just built. When Alice receives this message, she looks at the value 416 of "work" and "value", and in our case she decides to try to solve 417 this puzzle. She decodes the "preImage'' and the "image'' with a 418 base64-decoder. Then she checks that the "work" bottom bits of 419 preImage are set to 0. If it is not the case, she would have to 420 consider the 419 message as an error message. Alice creates a 421 variable Y, set to low(value, image). She creates another variable, 422 X, that will contain the solution, and that is initialized to the 423 preImage that she has read in the "Puzzle header" field. 425 The binary value of X, before starting to search for a solution, is: 427 01010110 00000101 01000110 01100010 00101100 01011011 01000110 428 00001101 00100110 01110101 00101100 00010011 01100011 01110110 429 00001000 01111100 00100000 01101110 00000000 00000000 431 In fact it's the same value as the "preImage'' that Bob has put in 432 the "Puzzle header" field, because Alice has initialized X to this 433 value. This "X" is the start-point of solving the puzzle. 435 Then she starts looping... 437 While low( value, SHA1("z9hG4bK" | X )) doesn't equal Y, she must 438 "increment" X, ie binary add 1 to the bit-representation of X. In 439 other words, if during a given iteration the binary value of X is: 441 01010110 00000101 01000110 01100010 00101100 01011011 01000110 442 00001101 00100110 01110101 00101100 00010011 01100011 01110110 443 00001000 01111100 00100000 01101110 00010010 10010111 445 then Alice has to add 1 to this value, and the new binary value of X 446 must be: 448 01010110 00000101 01000110 01100010 00101100 01011011 01000110 449 00001101 00100110 01110101 00101100 00010011 01100011 01110110 450 00001000 01111100 00100000 01101110 00010010 10011000 452 The maximum number of iterations is "2^work", because Alice has 453 received a "preImage'' with the "work" bottom bits set to 0, and that 454 the biggest solution would can be the "preImage'' with the "work" 455 bottom bits set to 1. This configuration is accessible via "2^work" 456 iterations. 458 If Alice has finished looping without finding a solution, she must 459 consider that the puzzle was invalid, and then consider the "419 460 Puzzle Required" as an error message. 462 If Alice finds an X such as low( value, SHA1("z9hG4bK" | X )) equals 463 Y, she has the solution! She can break out of the loop and build a 464 response for Bob. 466 As a response, Alice will send a copy of her initial request, but she 467 will insert the same "puzzle header field" as the one she has 468 received in the "419 Puzzle Required", except the "work" field that 469 she sets to 0, and the "preImage" field where she puts the solution 470 of the problem. She won't forget to base64-encode her solution, X, 471 before putting it in the "Puzzle header" field. 473 The "Puzzle header" field of Alice's answer has the form: 475 Puzzle: work=0; pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; 476 image="NhhMQ2l7SE0VBmZFKksUC19ia04="; value=160 478 When Bob receives this message, he can compare the "preImage'' value 479 that he has used to build the Puzzle with the "preImage'' value that 480 he can read in the "Puzzle header" field of Alice's answer. 482 If these two values are the same, he can consider that Alice has 483 spent time to solve the puzzle, and that she passed the challenge. 484 So he can accept her initial INVITE request! 486 In conclusion, we saw different messages going between Alice and Bob. 487 Here is a summary of these messages, and the content of the "Puzzle 488 header" field" for messages that use this header: 490 UAC UAS 491 | INVITE | 492 |------------------------->| 493 | | 494 | 419 with Puzzle |Puzzle: work=15; 495 | |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; 496 |<-------------------------|image="NhhMQ2l7SE0VBmZFKksUC19ia04="; 497 | |value=160 498 | | 499 | INVITE with Solution |Puzzle: work=0; 500 | |pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; 501 |------------------------->|image="NhhMQ2l7SE0VBmZFKksUC19ia04="; 502 | |value=160 503 | | 504 | 100 TRYING | 505 |<-------------------------| 506 | | 507 | 180 RINGING | 508 |<-------------------------| 509 | | 510 | 200 OK | 511 |<-------------------------| 512 | | 513 | ACK | 514 |------------------------->| 516 7. Syntax 518 The Puzzle header field carries the puzzle and solution information. 519 It has a parameter called 'work' that has the number of bits of the 520 pre-image that have been set to zero for this puzzle. It has a 521 parameter called 'pre' that carries the pre-image string base64 522 encoded, and a parameter called 'image' that carries the image string 523 base64 encoded. In addition there is a parameter called 'value' that 524 indicates how many bits of the resulting hash will match the 'image' 525 string. The base64 encoding is done as described in RFC 3548 [1]. 527 When the header field value is carrying a solution to a puzzle, the 528 work parameter will be set to zero. 530 Example: 532 Puzzle: work=10; pre="XPokF1n0+NG6iwRcYzeXuETrtDo="; 533 image="XPokF1n0+NG6iwRcYzeXuETrtDo="; value=160 535 The ABNF for the header is: 537 Puzzle = "Puzzle" HCOLON puzzle-parm *(COMMA puzzle-param) 539 puzzle-param = puzzle-bits SEMI puzzle-pre SEMI puzzle-image 540 SEMI puzzle-value *( SEMI generic-param ) 542 puzzle-work = "work=" 1*DIGIT 543 puzzle-value = "value=" 1*DIGIT 544 puzzle-pre = "pre=" quoted-string 545 puzzle-image = "image=" quoted-string 547 This document updates the dreaded Table 2 of RFC 3261 to be: 549 Header field where proxy ACK BYE CAN INV OPT REG 550 ------------ ----- ----- --- --- --- --- --- --- 551 Puzzle amr o o - o o o 553 SUB NOT REF INF UPD PRA 554 --- --- --- --- --- --- 555 o o o o o o 557 8. Open Issues and To Do Items 559 The current mechanism has poor interaction with the HERD forking 560 problem. If several endpoints sent a 419, the proxy would need to 561 aggregate the results and add something like the realm to the 562 challenges to keep them sorted out. Need to add this in next 563 revision. In many cases the solution would work out better if the 564 proxy that was doing the forking applied the policy and did the 419 565 before forking. This approach has the usual HERD problem that if 566 some UAs do a 419, and some UAs don't, the request will only reach 567 the UAs that don't do the 419. 569 What is the transition model here. Not everything is going implement 570 this right away: how to differentiate non-implementers from 571 purposeful non-implementors? Is it realistic to just say no to non- 572 implementors? Especially when you consider that as a PANT 573 replacement there is a general expectation of call success rather 574 than call failure (unlike, say, IN). 576 Need to add a parameter to the puzzle that specifies which hash 577 algorithm to use. 579 Update what happens when a UAS receives a puzzle with an incorrect 580 solution. 582 9. Security Considerations 584 Still TBD. 586 The concatenation with "z9hG4bK" is done so that this mechanism 587 cannot be used as a distributed computation to reverse arbitrary hash 588 values, as that would present a security risk for other hash based 589 security schemes. 591 TODO - Advice on selecting the size of 'work'. 593 There may be ways of using this to effectively perform DOS attacks on 594 system by asking them to solve many puzzles. Need to consider these 595 attacks and make sure that puzzles are only needed to be solved by 596 the device the initiated the requested action. 598 TODO - discuss rational for design of the puzzle 600 Some applications like "reverse 911" (community emergency alert 601 systems that notify all the UAs in a given group or geographic 602 region) would be severely hampered by being challenged with puzzles. 603 These systems will require some other authorization system and SHOULD 604 NOT use this approach. 606 10. IANA Considerations 608 This specification registers a new header and a new response code. 609 IANA is requested to make the following updates in the registry at: 610 http:///www.iana.org/assignments/sip-parameters 612 10.1. Puzzle Header 614 Add the following entry to the header sub-registry. 616 Header Name compact Reference 617 ----------------- ------- --------- 618 Puzzle [RFC-XXXX] 620 10.2. 419 Response 622 Add the following entry to the response code sub-registry under the 623 "Request Failure 4xx" heading. 625 419 Puzzle Required [RFC-XXXX] 627 11. Acknowledgments 629 The test vectors in Appendix A and the example text were provided by 630 Geoffrey Dawirs. This approach was motivated by [5]. Michael Thomas 631 has pointed out some significant problems with this idea and perhaps 632 the whole approach. I have tried to paraphrase some of his concerns 633 into the discussion in this document. Henning Schulzrinne pointed 634 out the important reverse 911 consideration. 636 12. Appendix A: Test Vectors 638 The test vectors were run with 17 different levels of work ranging 639 from 1 to 17. For each level of work three puzzles are created and 640 solved and are labeled TEST 1,2, or 3. 642 Level 1 / 17 --- TEST 1 / 3 643 Random string: gdxvmcdcovpejyrabkxgyqciaxu 644 preImage (base64-encoded): dA0CRElXfnIcdntrKyxmK29HKAA= 646 image (base64-encoded): VjRfVFoFLzFRICRyMS0pOV9cNDc= 648 work=1 649 value=160 650 preImage after zero (base64-encoded): dA0CRElXfnIcdntrKyxmK29HKAA= 652 solution (base64-encoded): dA0CRElXfnIcdntrKyxmK29HKAA= 654 level 1 / 17 --- TEST 2 / 3 655 Random string: vdbfkvjtsutahbzgejiqnii 656 preImage (base64-encoded): Ek8iQC9oLEslA1ljQGsfNGx4PRc= 658 image (base64-encoded): SHddMGEpcjUecGUNbwtFE2Jpfls= 660 work=1 661 value=160 662 preImage after zero (base64-encoded): Ek8iQC9oLEslA1ljQGsfNGx4PRY= 664 solution (base64-encoded): Ek8iQC9oLEslA1ljQGsfNGx4PRc= 666 level 1 / 17 --- TEST 3 / 3 667 Random string: gknevljqdowdehqixzrbnvjjavcco 668 preImage (base64-encoded): AE0hWXEnJUNtbAUgSkc4VVtEQW8= 670 image (base64-encoded): HFpTEh4WMXpBViRmVzEmXDoPeGg= 672 work=1 673 value=160 674 preImage after zero (base64-encoded): AE0hWXEnJUNtbAUgSkc4VVtEQW4= 676 solution (base64-encoded): AE0hWXEnJUNtbAUgSkc4VVtEQW8= 678 level 2 / 17 --- TEST 1 / 3 679 Random string: gcpcerwaprqwfdrpzaqbpgkxbfglw 680 preImage (base64-encoded): UnE7YXFOLGckXDJ6HTBaYH8tMXs= 682 image (base64-encoded): cwRPKT4yBlUnXEw5dRBiHjBiECU= 684 work=2 685 value=160 686 preImage after zero (base64-encoded): UnE7YXFOLGckXDJ6HTBaYH8tMXg= 688 solution (base64-encoded): UnE7YXFOLGckXDJ6HTBaYH8tMXs= 690 level 2 / 17 --- TEST 2 / 3 691 Random string: zeyszfhbfasaedjztugfojwgijdc 692 preImage (base64-encoded): PDonUmxvPAQcLRwVClppQgZRQRo= 694 image (base64-encoded): OQ4+XnQSAUMDc20PeQMaYjxKME0= 696 work=2 697 value=160 698 preImage after zero (base64-encoded): PDonUmxvPAQcLRwVClppQgZRQRg= 700 solution (base64-encoded): PDonUmxvPAQcLRwVClppQgZRQRo= 702 level 2 / 17 --- TEST 3 / 3 703 Random string: wmvpjcjnwkchtyquvsawz 704 preImage (base64-encoded): FCBUD0wmVRFVATxxI3NAXhtZAVk= 706 image (base64-encoded): ZHQ8OxY8DHdgYQ4WNmMkLUdyTA4= 708 work=2 709 value=160 710 preImage after zero (base64-encoded): FCBUD0wmVRFVATxxI3NAXhtZAVg= 712 solution (base64-encoded): FCBUD0wmVRFVATxxI3NAXhtZAVk= 714 level 3 / 17 --- TEST 1 / 3 715 Random string: mwqoaoazhakqsxmujkhjjezkhwvgfz 716 preImage (base64-encoded): Qll6REckHzB9VRQZCHFuZW4UPVM= 718 image (base64-encoded): DUs/bRUcfDViZgtzP1xDKQZ0a18= 720 work=3 721 value=160 722 preImage after zero (base64-encoded): Qll6REckHzB9VRQZCHFuZW4UPVA= 724 solution (base64-encoded): Qll6REckHzB9VRQZCHFuZW4UPVM= 726 level 3 / 17 --- TEST 2 / 3 727 Random string: oepdjqztwxixkpxyagdhykvwwc 728 preImage (base64-encoded): LBZZekRMSU95AE15S15kJU4UJVM= 730 image (base64-encoded): M10xHBI0Ok1gOX80DyUQFSAaNw0= 732 work=3 733 value=160 734 preImage after zero (base64-encoded): LBZZekRMSU95AE15S15kJU4UJVA= 736 solution (base64-encoded): LBZZekRMSU95AE15S15kJU4UJVM= 738 level 3 / 17 --- TEST 3 / 3 739 Random string: slczwdgfazorhwoasymaoepvf 740 preImage (base64-encoded): JRoPcHV5CgMvJ1R7bjYqfyVoFig= 742 image (base64-encoded): PHYgIEsrDRc8EEQBUjAbcBYEHAU= 744 work=3 745 value=160 746 preImage after zero (base64-encoded): JRoPcHV5CgMvJ1R7bjYqfyVoFig= 748 solution (base64-encoded): JRoPcHV5CgMvJ1R7bjYqfyVoFig= 750 level 4 / 17 --- TEST 1 / 3 751 Random string: qgksjhphjligddrspyrc 752 preImage (base64-encoded): U0FaV00YIHx9CyBbO0FSTiw/bXQ= 754 image (base64-encoded): DyV2EwktcWgQPEA+XmwHOT0UYE0= 756 work=4 757 value=160 758 preImage after zero (base64-encoded): U0FaV00YIHx9CyBbO0FSTiw/bXA= 760 solution (base64-encoded): U0FaV00YIHx9CyBbO0FSTiw/bXQ= 762 level 4 / 17 --- TEST 2 / 3 763 Random string: buwdwqyxzhejgbbkbjeqaipaqsbrp 764 preImage (base64-encoded): GwY1Mm02El8kKE9ve15MbllEKkw= 766 image (base64-encoded): WE8IJksYW1oFeBx6WTVaLQR/dhU= 768 work=4 769 value=160 770 preImage after zero (base64-encoded): GwY1Mm02El8kKE9ve15MbllEKkA= 772 solution (base64-encoded): GwY1Mm02El8kKE9ve15MbllEKkw= 774 level 4 / 17 --- TEST 3 / 3 775 Random string: hdxbcrbgodseongcjeownmovmqzny 776 preImage (base64-encoded): UwgDYCgRETIGKhtsZBcTNWoGKyg= 778 image (base64-encoded): fiU0fHsBOFxDFlxnC1FgD2I0HCA= 780 work=4 781 value=160 782 preImage after zero (base64-encoded): UwgDYCgRETIGKhtsZBcTNWoGKyA= 784 solution (base64-encoded): UwgDYCgRETIGKhtsZBcTNWoGKyg= 786 level 5 / 17 --- TEST 1 / 3 787 Random string: anbkdsxaubmulkktrgupv 788 preImage (base64-encoded): AngUeyYuTGQkL3lNHVNIelslJT8= 790 image (base64-encoded): YgQpFS0Wb25SHRtGPR91Un9VUXM= 792 work=5 793 value=160 794 preImage after zero (base64-encoded): AngUeyYuTGQkL3lNHVNIelslJSA= 796 solution (base64-encoded): AngUeyYuTGQkL3lNHVNIelslJT8= 798 level 5 / 17 --- TEST 2 / 3 799 Random string: anrwzqdsobsqibrwfmquabctqna 800 preImage (base64-encoded): aX9wTT1rIVJwG25WMh5MZzsedUQ= 802 image (base64-encoded): QlRNbwQrGVVmPDEPZUASTmUVa2s= 804 work=5 805 value=160 806 preImage after zero (base64-encoded): aX9wTT1rIVJwG25WMh5MZzsedUA= 808 solution (base64-encoded): aX9wTT1rIVJwG25WMh5MZzsedUQ= 810 level 5 / 17 --- TEST 3 / 3 811 Random string: gjnwilitpznhmaidkyloeg 812 preImage (base64-encoded): Mi5eChcsKCUoTVhyfBgQSydhfXo= 814 image (base64-encoded): QV1GCh8mGW1WOWlMdgAERmEzH2M= 815 work=5 816 value=160 817 preImage after zero (base64-encoded): Mi5eChcsKCUoTVhyfBgQSydhfWA= 819 solution (base64-encoded): Mi5eChcsKCUoTVhyfBgQSydhfXo= 821 level 6 / 17 --- TEST 1 / 3 822 Random string: hrvgonrrmphifwrfqcho 823 preImage (base64-encoded): AQ9TTCNgUnU6eDh1CDk8LlYcIE8= 825 image (base64-encoded): Zi5Fcn9MJiFGaXwqbw10cXEXSQA= 827 work=6 828 value=160 829 preImage after zero (base64-encoded): AQ9TTCNgUnU6eDh1CDk8LlYcIEA= 831 solution (base64-encoded): AQ9TTCNgUnU6eDh1CDk8LlYcIE8= 833 level 6 / 17 --- TEST 2 / 3 834 Random string: gcxmhamuasvxfzfljclkuslv 835 preImage (base64-encoded): L3h/YCUDFTVCUndTbB1bDzVWGik= 837 image (base64-encoded): Y1QmWndFXG5fPHNPHE10aDliDBY= 839 work=6 840 value=160 841 preImage after zero (base64-encoded): L3h/YCUDFTVCUndTbB1bDzVWGgA= 843 solution (base64-encoded): L3h/YCUDFTVCUndTbB1bDzVWGik= 845 level 6 / 17 --- TEST 3 / 3 846 Random string: azkroxnsxoasmlalcrjgsfy 847 preImage (base64-encoded): bT09cypeJlMkPGpgRwQMfVYsAS4= 849 image (base64-encoded): NRxzQjh7ClFsWWp5IhoyFxN6aGw= 851 work=6 852 value=160 853 preImage after zero (base64-encoded): bT09cypeJlMkPGpgRwQMfVYsAQA= 855 solution (base64-encoded): bT09cypeJlMkPGpgRwQMfVYsAS4= 857 level 7 / 17 --- TEST 1 / 3 858 Random string: afxoapxwehorxjxczgyokgfllwtmwv 859 preImage (base64-encoded): PEA1J0l9FyVpFR03ITVOciY5TR4= 861 image (base64-encoded): CBspElUeEV4zMEsqHU86PGN0N10= 862 work=7 863 value=160 864 preImage after zero (base64-encoded): PEA1J0l9FyVpFR03ITVOciY5TQA= 866 solution (base64-encoded): PEA1J0l9FyVpFR03ITVOciY5TR4= 868 level 7 / 17 --- TEST 2 / 3 869 Random string: kbycttlwmbuwkgijafwehmxwqoc 870 preImage (base64-encoded): Elx9ZyoGVSUnNAJRSkwdS2o/KiU= 872 image (base64-encoded): KXELayx+CBRvCi8+DWdiFn8rYXs= 874 work=7 875 value=160 876 preImage after zero (base64-encoded): Elx9ZyoGVSUnNAJRSkwdS2o/KgA= 878 solution (base64-encoded): Elx9ZyoGVSUnNAJRSkwdS2o/KiU= 880 level 7 / 17 --- TEST 3 / 3 881 Random string: xdabcoapunmukhnpszrqtb 882 preImage (base64-encoded): IwYALWI4MTRPOwYyDFxLVU8kYjk= 884 image (base64-encoded): CSYOZxU3cQZKRSNrawEIUCMAPAc= 886 work=7 887 value=160 888 preImage after zero (base64-encoded): IwYALWI4MTRPOwYyDFxLVU8kYgA= 890 solution (base64-encoded): IwYALWI4MTRPOwYyDFxLVU8kYjk= 892 level 8 / 17 --- TEST 1 / 3 893 Random string: euztuexgapbmvwzhdnyj 894 preImage (base64-encoded): Xm8xcmdkeW02TWNvBH0XXmU/E0g= 896 image (base64-encoded): AzgIeENNC2UKbx8cdQs7ZBwPLxA= 898 work=8 899 value=160 900 preImage after zero (base64-encoded): Xm8xcmdkeW02TWNvBH0XXmU/EwA= 902 solution (base64-encoded): Xm8xcmdkeW02TWNvBH0XXmU/E0g= 904 level 8 / 17 --- TEST 2 / 3 905 Random string: pgiksjjmwdhfvzqtzmocef 906 preImage (base64-encoded): OhU7BF4gCnQzay5HCl8GGRF7ci8= 908 image (base64-encoded): bjovP2MCQDN9OgZzZ28WTmgZDVY= 909 work=8 910 value=160 911 preImage after zero (base64-encoded): OhU7BF4gCnQzay5HCl8GGRF7cgA= 913 solution (base64-encoded): OhU7BF4gCnQzay5HCl8GGRF7ci8= 915 level 8 / 17 --- TEST 3 / 3 916 Random string: wnbfdqnpgfaccosflhufgcud 917 preImage (base64-encoded): eWw4WDk6T0EkTERJVxJqbngQU04= 919 image (base64-encoded): dUg5JxssUnFZEiVyREMeGxd9Px8= 921 work=8 922 value=160 923 preImage after zero (base64-encoded): eWw4WDk6T0EkTERJVxJqbngQUwA= 925 solution (base64-encoded): eWw4WDk6T0EkTERJVxJqbngQU04= 927 level 9 / 17 --- TEST 1 / 3 928 Random string: mzihxmckhemkrrdxkvhrjo 929 preImage (base64-encoded): GD0cEWh3PiNjGF4BVn8JREJsJGU= 931 image (base64-encoded): DT0MBy01WBxBBRITBksEbXkoOH4= 933 work=9 934 value=160 935 preImage after zero (base64-encoded): GD0cEWh3PiNjGF4BVn8JREJsJAA= 937 solution (base64-encoded): GD0cEWh3PiNjGF4BVn8JREJsJGU= 939 level 9 / 17 --- TEST 2 / 3 940 Random string: cvzkodyvqjhotainrlqvwyuyi 941 preImage (base64-encoded): GDoYYhIwC0AUETRMGG5TdiA3IU8= 943 image (base64-encoded): P1sTfWYbLnA8PBREUkEVXFJLVT4= 945 work=9 946 value=160 947 preImage after zero (base64-encoded): GDoYYhIwC0AUETRMGG5TdiA3IAA= 949 solution (base64-encoded): GDoYYhIwC0AUETRMGG5TdiA3IU8= 951 level 9 / 17 --- TEST 3 / 3 952 Random string: zgjxoxqgohakmrxgqtrhhlyjso 953 preImage (base64-encoded): DWAFYDIRFRMCYE8zS0ppRx40cjM= 955 image (base64-encoded): ADZtDHsif3QMQT4ie1IPeU1LeEA= 956 work=9 957 value=160 958 preImage after zero (base64-encoded): DWAFYDIRFRMCYE8zS0ppRx40cgA= 960 solution (base64-encoded): DWAFYDIRFRMCYE8zS0ppRx40cjM= 962 level 10 / 17 --- TEST 1 / 3 963 Random string: zkirsotmjnjxevjgefwhnojuop 964 preImage (base64-encoded): UgI6BW1VY3FBWwJMDzwrbndeHHQ= 966 image (base64-encoded): KW90XUBWcFY5Fw8FJSoJY1AvUH4= 968 work=10 969 value=160 970 preImage after zero (base64-encoded): UgI6BW1VY3FBWwJMDzwrbndeHAA= 972 solution (base64-encoded): UgI6BW1VY3FBWwJMDzwrbndeHHQ= 974 level 10 / 17 --- TEST 2 / 3 975 Random string: ujgqqxhqvbuvexjqsvaui 976 preImage (base64-encoded): P3xQZVBgcydHW3clE1BndiBaeSk= 978 image (base64-encoded): DGRobH0Qe2xoKFdFYBsIUSNsfnM= 980 work=10 981 value=160 982 preImage after zero (base64-encoded): P3xQZVBgcydHW3clE1BndiBaeAA= 984 solution (base64-encoded): P3xQZVBgcydHW3clE1BndiBaeSk= 986 level 10 / 17 --- TEST 3 / 3 987 Random string: hvrumrohnozihssygzsgppfp 988 preImage (base64-encoded): eC5eAUIvSlVYDwQJFy04PwcmdS8= 990 image (base64-encoded): G3Z4ZQ9lHSJ9Vx4rRVpiLjlMTFA= 992 work=10 993 value=160 994 preImage after zero (base64-encoded): eC5eAUIvSlVYDwQJFy04PwcmdAA= 996 solution (base64-encoded): eC5eAUIvSlVYDwQJFy04PwcmdS8= 998 level 11 / 17 --- TEST 1 / 3 999 Random string: tovdorusdqfovtifyunvpy 1000 preImage (base64-encoded): H2F9HVUgAjINaGANCmdHWVEEZ04= 1002 image (base64-encoded): LE5qbTIcYxRHQCN9NBRPZ1gDGxE= 1003 work=11 1004 value=160 1005 preImage after zero (base64-encoded): H2F9HVUgAjINaGANCmdHWVEEYAA= 1007 solution (base64-encoded): H2F9HVUgAjINaGANCmdHWVEEZ04= 1009 level 11 / 17 --- TEST 2 / 3 1010 Random string: umfktxivqlkczwoceidez 1011 preImage (base64-encoded): elwLLA4PFjUZGGN6PEZwRwUJOVM= 1013 image (base64-encoded): K1d2WR5MXjFRCC04YgIgBl5WAEU= 1015 work=11 1016 value=160 1017 preImage after zero (base64-encoded): elwLLA4PFjUZGGN6PEZwRwUJOAA= 1019 solution (base64-encoded): elwLLA4PFjUZGGN6PEZwRwUJOVM= 1021 level 11 / 17 --- TEST 3 / 3 1022 Random string: nxlbmswquztwldpwokmnqnbcrxkpoo 1023 preImage (base64-encoded): WGgzajJFQx5nVFFsGhURFgxXCk8= 1025 image (base64-encoded): BXQXNH05B3NLLQhlFS0DV3cXUgU= 1027 work=11 1028 value=160 1029 preImage after zero (base64-encoded): WGgzajJFQx5nVFFsGhURFgxXCAA= 1031 solution (base64-encoded): WGgzajJFQx5nVFFsGhURFgxXCk8= 1033 level 12 / 17 --- TEST 1 / 3 1034 Random string: tnqqshsvqxwdattkguseouu 1035 preImage (base64-encoded): amUaNAZCFDd6LkRkNAkMZ118FXc= 1037 image (base64-encoded): KA4fBQ1Ya0Q1UVZSJWcjG1cWIUY= 1039 work=12 1040 value=160 1041 preImage after zero (base64-encoded): amUaNAZCFDd6LkRkNAkMZ118EAA= 1043 solution (base64-encoded): amUaNAZCFDd6LkRkNAkMZ118FXc= 1045 level 12 / 17 --- TEST 2 / 3 1046 Random string: pjzuzvhidheobinckecwlvfl 1047 preImage (base64-encoded): NAliEBMPFiBYOlwPdGldQgEMZkU= 1049 image (base64-encoded): Kgo9IG40RX1MMVELTSMGT1hUVy4= 1050 work=12 1051 value=160 1052 preImage after zero (base64-encoded): NAliEBMPFiBYOlwPdGldQgEMYAA= 1054 solution (base64-encoded): NAliEBMPFiBYOlwPdGldQgEMZkU= 1056 level 12 / 17 --- TEST 3 / 3 1057 Random string: ywctzidwhouvwpzjjvqrkhvlf 1058 preImage (base64-encoded): bHJeC39oe00RRS1OKyICFnMdO2I= 1060 image (base64-encoded): BQJHBiBqVVJ2e29gYy0LaRsLHmM= 1062 work=12 1063 value=160 1064 preImage after zero (base64-encoded): bHJeC39oe00RRS1OKyICFnMdMAA= 1066 solution (base64-encoded): bHJeC39oe00RRS1OKyICFnMdO2I= 1068 level 13 / 17 --- TEST 1 / 3 1069 Random string: arnfaqqzzxqujmpirwfsiktor 1070 preImage (base64-encoded): c2gsSEBzH11yGmlCMBoqKBQeImI= 1072 image (base64-encoded): OUU/Jx8aRANPamhZRT8tOW8qAS8= 1074 work=13 1075 value=160 1076 preImage after zero (base64-encoded): c2gsSEBzH11yGmlCMBoqKBQeIAA= 1078 solution (base64-encoded): c2gsSEBzH11yGmlCMBoqKBQeImI= 1080 level 13 / 17 --- TEST 2 / 3 1081 Random string: lsdnchahbpppnphzmkkcsuoj 1082 preImage (base64-encoded): c1EsT3lOGjgFIWZac0sTKXEKESc= 1084 image (base64-encoded): ORV5eSVTIV5qIV5PS3lTM0sdIWU= 1086 work=13 1087 value=160 1088 preImage after zero (base64-encoded): c1EsT3lOGjgFIWZac0sTKXEKAAA= 1090 solution (base64-encoded): c1EsT3lOGjgFIWZac0sTKXEKESc= 1092 level 13 / 17 --- TEST 3 / 3 1093 Random string: mqlqeaweiupmzjtldlkskbqtmlj 1094 preImage (base64-encoded): HAoxPiE1K3xwbGEIdH5TcwxrOwA= 1096 image (base64-encoded): VVdEekMjRgR/CTZtGFBIIDJaZg4= 1097 work=13 1098 value=160 1099 preImage after zero (base64-encoded): HAoxPiE1K3xwbGEIdH5TcwxrIAA= 1101 solution (base64-encoded): HAoxPiE1K3xwbGEIdH5TcwxrOwA= 1103 level 14 / 17 --- TEST 1 / 3 1104 Random string: bjnbntkkltdlhgvsxptpjq 1105 preImage (base64-encoded): FhcYHQwdJ0giX1EOOBE4S0xHZx4= 1107 image (base64-encoded): MXtOLmtoRWJiIVlKHx4vCDwwMEk= 1109 work=14 1110 value=160 1111 preImage after zero (base64-encoded): FhcYHQwdJ0giX1EOOBE4S0xHQAA= 1113 solution (base64-encoded): FhcYHQwdJ0giX1EOOBE4S0xHZx4= 1115 level 14 / 17 --- TEST 2 / 3 1116 Random string: ukzsazeyuxczkfxibrerffk 1117 preImage (base64-encoded): NFt0WVkjHHhUeDIjfEp0ajJbPXg= 1119 image (base64-encoded): LF9Hcy9nIW9jdjVhPX8mIU5SXx4= 1121 work=14 1122 value=160 1123 preImage after zero (base64-encoded): NFt0WVkjHHhUeDIjfEp0ajJbAAA= 1125 solution (base64-encoded): NFt0WVkjHHhUeDIjfEp0ajJbPXg= 1127 level 14 / 17 --- TEST 3 / 3 1128 Random string: yoagiwgujbfongpncloonmlaztnb 1129 preImage (base64-encoded): HC4maTtxIFcUc39QdTgOHl8tAAQ= 1131 image (base64-encoded): HGkuLj56JTVgeAJ8D1QnVG0AV3Q= 1133 work=14 1134 value=160 1135 preImage after zero (base64-encoded): HC4maTtxIFcUc39QdTgOHl8tAAA= 1137 solution (base64-encoded): HC4maTtxIFcUc39QdTgOHl8tAAQ= 1139 level 15 / 17 --- TEST 1 / 3 1140 Random string: ksuvudvnlwebrotnrszczjyvyrf 1142 preImage (base64-encoded): XHReelpBHk89YxYlWjZ7ejssflg= 1144 image (base64-encoded): bSJOAUdUYnpPWm4uLyUNSzkVaQM= 1145 work=15 1146 value=160 1147 preImage after zero (base64-encoded): XHReelpBHk89YxYlWjZ7ejssAAA= 1149 solution (base64-encoded): XHReelpBHk89YxYlWjZ7ejssflg= 1151 level 15 / 17 --- TEST 2 / 3 1152 Random string: qmgbajbocksfunnusggf 1153 preImage (base64-encoded): H302EGtQfVFrIUI3AlVDX05dJ00= 1155 image (base64-encoded): GnlOakQVBHMKUUYidGUfSkZBWUw= 1157 work=15 1158 value=160 1159 preImage after zero (base64-encoded): H302EGtQfVFrIUI3AlVDX05dAAA= 1161 solution (base64-encoded): H302EGtQfVFrIUI3AlVDX05dJ00= 1163 level 15 / 17 --- TEST 3 / 3 1164 Random string: whmvlwzipmcarouqfqckr 1165 preImage (base64-encoded): VEhCREFNLwhMPiYlYQYMYBgpD3c= 1167 image (base64-encoded): FSBYHmlfdTkXIzRmXmAtS21SQ2Q= 1169 work=15 1170 value=160 1171 preImage after zero (base64-encoded): VEhCREFNLwhMPiYlYQYMYBgpAAA= 1173 solution (base64-encoded): VEhCREFNLwhMPiYlYQYMYBgpD3c= 1175 level 16 / 17 --- TEST 1 / 3 1176 Random string: iallnhuydqzoujkjuumu 1177 preImage (base64-encoded): DlA/dCB3IFlcFmIPKQQTCAB+eGY= 1179 image (base64-encoded): PRcQIjNKUEFXPwhoW11KXygYJxY= 1181 work=16 1182 value=160 1183 preImage after zero (base64-encoded): DlA/dCB3IFlcFmIPKQQTCAB+AAA= 1185 solution (base64-encoded): DlA/dCB3IFlcFmIPKQQTCAB+eGY= 1187 level 16 / 17 --- TEST 2 / 3 1188 Random string: cucykaaltpxnpdfbkwiakdlvjt 1189 preImage (base64-encoded): ABx7YQd/RG1NG1JyCAliFAdOfgE= 1191 image (base64-encoded): Jhc8Y3ZwMTNZM0FHFnApRjszXDc= 1192 work=16 1193 value=160 1194 preImage after zero (base64-encoded): ABx7YQd/RG1NG1JyCAliFAdOAAA= 1196 solution (base64-encoded): ABx7YQd/RG1NG1JyCAliFAdOfgE= 1198 level 16 / 17 --- TEST 3 / 3 1199 Random string: awlssoylwkjdldygglgrn 1200 preImage (base64-encoded): ZyE7fD9wBRlQGgNZSnFhLlMSOAs= 1202 image (base64-encoded): WXcTQ3gRX1xIOkUbAQRQUi5bKy8= 1204 work=16 1205 value=160 1206 preImage after zero (base64-encoded): ZyE7fD9wBRlQGgNZSnFhLlMSAAA= 1208 solution (base64-encoded): ZyE7fD9wBRlQGgNZSnFhLlMSOAs= 1210 level 17 / 17 --- TEST 1 / 3 1211 Random string: ctwlrtmezmjgjpfmeuzeusnzrbk 1212 preImage (base64-encoded): KEEYBVBfFjZeGE9lZS9qbmJuAyU= 1214 image (base64-encoded): IXpbLnMLBTFXfkwdaxYvdEckQ1c= 1216 work=17 1217 value=160 1218 preImage after zero (base64-encoded): KEEYBVBfFjZeGE9lZS9qbmJuAAA= 1220 solution (base64-encoded): KEEYBVBfFjZeGE9lZS9qbmJuAyU= 1222 level 17 / 17 --- TEST 2 / 3 1223 Random string: vggwtxejthimazyoxkfsyeawiber 1224 preImage (base64-encoded): K2RqCBcqcXMBKlNJFncURmhEOiI= 1226 image (base64-encoded): dTFDAwokR1keFwlMIlVsE3sKay8= 1228 work=17 1229 value=160 1230 preImage after zero (base64-encoded): K2RqCBcqcXMBKlNJFncURmhEAAA= 1232 solution (base64-encoded): K2RqCBcqcXMBKlNJFncURmhEOiI= 1234 level 17 / 17 --- TEST 3 / 3 1235 Random string: aocgnkxbjleairqeossghdkoix 1236 preImage (base64-encoded): cCkTaHpsS1RUEmd8MVwEAjg5G1I= 1238 image (base64-encoded): djscbnkvBAFQAjccYkU6F21DMCM= 1239 work=17 1240 value=160 1241 preImage after zero (base64-encoded): cCkTaHpsS1RUEmd8MVwEAjg4AAA= 1243 solution (base64-encoded): cCkTaHpsS1RUEmd8MVwEAjg5G1I= 1245 13. References 1247 13.1. Normative References 1249 [1] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1250 RFC 3548, July 2003. 1252 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1253 Levels", BCP 14, RFC 2119, March 1997. 1255 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1256 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1257 Session Initiation Protocol", RFC 3261, June 2002. 1259 [4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 1260 RFC 3174, September 2001. 1262 13.2. Informational References 1264 [5] Black, A., "http://www.hashcash.org/", February 2005. 1266 [6] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1267 Identity Management in the Session Initiation Protocol (SIP)", 1268 RFC 4474, August 2006. 1270 [7] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", 1271 draft-ietf-sipping-spam-04 (work in progress). 1273 Author's Address 1275 Cullen Jennings 1276 Cisco Systems 1277 170 West Tasman Drive 1278 MS: SJC-21/2 1279 San Jose, CA 95134 1280 USA 1282 Phone: +1 408 421 9990 1283 Email: fluffy@cisco.com 1285 Full Copyright Statement 1287 Copyright (C) The IETF Trust (2007). 1289 This document is subject to the rights, licenses and restrictions 1290 contained in BCP 78, and except as set forth therein, the authors 1291 retain all their rights. 1293 This document and the information contained herein are provided on an 1294 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1295 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1296 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1297 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1298 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1299 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1301 Intellectual Property 1303 The IETF takes no position regarding the validity or scope of any 1304 Intellectual Property Rights or other rights that might be claimed to 1305 pertain to the implementation or use of the technology described in 1306 this document or the extent to which any license under such rights 1307 might or might not be available; nor does it represent that it has 1308 made any independent effort to identify any such rights. Information 1309 on the procedures with respect to rights in RFC documents can be 1310 found in BCP 78 and BCP 79. 1312 Copies of IPR disclosures made to the IETF Secretariat and any 1313 assurances of licenses to be made available, or the result of an 1314 attempt made to obtain a general license or permission for the use of 1315 such proprietary rights by implementers or users of this 1316 specification can be obtained from the IETF on-line IPR repository at 1317 http://www.ietf.org/ipr. 1319 The IETF invites any interested party to bring to its attention any 1320 copyrights, patents or patent applications, or other proprietary 1321 rights that may cover technology that may be required to implement 1322 this standard. Please address the information to the IETF at 1323 ietf-ipr@ietf.org. 1325 Acknowledgment 1327 Funding for the RFC Editor function is provided by the IETF 1328 Administrative Support Activity (IASA).