idnits 2.17.1 draft-petithuguenin-vipr-pvp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 12, 2011) is 4696 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) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Downref: Normative reference to an Informational RFC: RFC 5054 == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-00 ** Downref: Normative reference to an Informational draft: draft-jennings-vipr-overview (ref. 'VIPR-OVERVIEW') == Outdated reference: A later version (-02) exists of draft-jennings-vipr-vap-00 == Outdated reference: A later version (-03) exists of draft-petithuguenin-vipr-sip-antispam-01 == Outdated reference: A later version (-04) exists of draft-petithuguenin-vipr-reload-usage-01 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VIPR J. Rosenberg 3 Internet-Draft jdrosen.net 4 Intended status: Standards Track C. Jennings 5 Expires: December 14, 2011 Cisco 6 M. Petit-Huguenin 7 Stonyfish 8 June 12, 2011 10 The Public Switched Telephone Network (PSTN) Validation Protocol (PVP) 11 draft-petithuguenin-vipr-pvp-01 13 Abstract 15 One of the main challenges in inter-domain federation of Session 16 Initiation Protocol (SIP) calls is that many domains continue to 17 utilize phone numbers, and not email-style SIP URI. Consequently, a 18 mechanism is needed that enables secure mappings from phone numbers 19 to domains. The main technical challenge in doing this securely is 20 to verify that the domain in question truly is the "owner" of the 21 phone number. This specification defines the PSTN Validation 22 Protocol (PVP), which can be used by a domain to verify this 23 ownership by means of a forward routability check in the PSTN. 25 Legal 27 This documents and the information contained therein are provided on 28 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 29 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 30 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 31 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 32 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 33 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 34 FOR A PARTICULAR PURPOSE. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 14, 2011. 53 Copyright Notice 55 Copyright (c) 2011 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. The Wrong Way . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. EKE Protocols . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 15 75 6. Username and Password Algorithms . . . . . . . . . . . . . . . 16 76 7. Originating Node Procedures . . . . . . . . . . . . . . . . . 18 77 7.1. Establishing a Connection . . . . . . . . . . . . . . . . 18 78 7.2. Constructing a Username and Password . . . . . . . . . . . 18 79 7.2.1. Method A . . . . . . . . . . . . . . . . . . . . . . . 18 80 7.2.2. Method B . . . . . . . . . . . . . . . . . . . . . . . 22 81 7.3. Requesting Validation . . . . . . . . . . . . . . . . . . 23 82 8. Terminating Node Procedures . . . . . . . . . . . . . . . . . 24 83 8.1. Waiting for SRP-TLS . . . . . . . . . . . . . . . . . . . 24 84 8.2. Receiving Validation Requests . . . . . . . . . . . . . . 26 85 9. Syntax Details . . . . . . . . . . . . . . . . . . . . . . . . 27 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 87 10.1. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 10.2. Forward Routing Assumptions . . . . . . . . . . . . . . . 28 89 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 93 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 94 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 29 95 A.1. Modifications between vipr-01 and vipr-00 . . . . . . . . 29 96 A.2. Modifications between vipr-00 and dispatch-03 . . . . . . 29 97 A.3. Modifications between dispatch-03 and dispatch-02 . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 100 1. Introduction 102 The validation protocol is the key security mechanism in ViPR. It is 103 used to couple together PSTN calls with IP destinations based on 104 shared knowledge of a PSTN call. This document relies heavily on the 105 concepts and terminology defined in [VIPR-OVERVIEW] and will not make 106 sense if you have not read that document first. 108 The protocol assumes that two enterprises, the originating one 109 (enterprise O) initiates a call on the PSTN to an E.164 number 110 ECALLED that terminates on the terminating enterprise (enterprise T). 111 Each enterprise has a ViPR server, acting as a P2P node. The node in 112 enterprise O is PO, and the node in enterprise T is PT. This PSTN 113 call completes successfully, and knowledge of this call is known to 114 PO and PT. Later on, PO will query the P2P network with number 115 ECALLED. It comes back with a Node-ID PCAND for a node. At this 116 time, PO can't know for sure that PCAND is in fact PT. All it knows 117 is that some node, PCAND, wrote an entry into the DHT claiming that 118 it was the owner of number ECALLED. The objective of the protocol is 119 for PO to determine that node PCAND can legitimately claim ownership 120 of number ECALLED, by demonstrating knowledge of the previous PSTN 121 call. It demonstrates that knowledge by demonstrating it knows the 122 start time, stop timer, and possibly caller ID for the PSTN call made 123 previously. 125 /-----------\ 126 /// \\\ 127 || || 128 | ViPR \ 129 || DHT ||\ 130 X\\ /// \ 131 / \-----------/ \ 132 ---------/- ----\------ 133 /// \\\ /// \\\ 134 // \\ // \\ 135 | |///---\\\ | | 136 | Enterprise O | PSTN | Enterprise T | 137 | |\\\---/// | | 138 \\ // \\ // 139 \\\ /// \\\ /// 140 -----+----- ------+---- 141 +---+----+ +---+----+ 142 | Phone O| |Phone T | 143 +--------+ +--------+ 145 Figure 102: Validation Model 147 If node PCAND can demonstrate such knowledge, then enterprise O can 148 assume that node PCAND had in fact received the call, which could 149 only have happened if it had knowledge of the call to number ECALLED, 150 which could only have happened if PCAND is in enterprise T, and thus 151 it is PT. This is because PSTN routing is assumed to be "secure", in 152 that, if someone calls some number through the PSTN, it will in fact 153 reach a terminating line (whether it be analog, PRI, or other) which 154 is the rightful "owner" of that number. If enterprise T was not the 155 owner of the number, if would not have received the call, would not 156 know its start/stop/caller ID, not be able to provide that 157 information to PT, and not be able to satisfy the knowledge proof. 158 This basic approach is shown in Figure 102. 160 A first question commonly asked is, why not just do regular 161 authentication? What if we give each node a certificate, and then 162 have the nodes authenticate each other? The answer is that a 163 certificate certifies that a particular node belongs to a domain - 164 for example, that node PT is part of example.com. A certificate does 165 not assert that, not only is PT example.com, but example.com owns the 166 following phone numbers. Therefore simple certificate authentication 167 does not provide any guarantee over ownership of phone numbers. 169 In principle, it might be possible to ask certificate authorities, 170 such as Verisign, to assert just that. However, traditionally, 171 certificate authorities have been extremely hesitant to certify much 172 at all. The reason is, the certifier needs to be able to assure that 173 the information is correct. How can a certifier like Verisign verify 174 that, in fact, a particular enterprise owns phone numbers? It could 175 make a few test calls, perhaps, to check if they look right. 176 However, these test calls are disruptive to users that own the 177 numbers (since their phones will ring!). If the test calls are done 178 for a subset of the numbers, it is not secure. If the certifier 179 simply required, as part of the business agreement, that the 180 enterprises provided correct information, the certifier might avoid 181 legal liability, but the legitimacy of the service will be 182 compromised and customers will stop using it. Furthermore, it has 183 proven incredibly hard to do this kind of certification worldwide 184 with a single certificate authority. 186 ViPR has, as a goal, to work anywhere in the world and do guarantee 187 correct call routing with five nines of reliability. Consequently, 188 traditional certificates and authentication do not work. It turns 189 out to be quite hard to design a secure version of this validation 190 protocol. To demonstrate this, we will walk through some initial 191 attempts at it, and show how they fail. 193 2. The Wrong Way 195 The first attempt one might make is the following. PO takes the 196 caller ID for the call, ECALLING and called number ECALLED for the 197 call, and sends them to candidate node PCAND. These two identifiers 198 - the called number E and the caller ID, form a unique handle that 199 can be used to identify the call in question. Node PCAND looks at 200 all of the ViPR Call Records (VCRs) of the calls over the last 48 201 hours, and takes those with the given called party number and calling 202 party number. If there is more than one match, the most recent one 203 is used. We now have a unique call. 205 Now, node PCAND demonstrates knowledge of this call by handing back 206 the start and stop times for this call in a message back to PO. This 207 approach is shown in Figure 103. 209 Po Pt 210 | | 211 | | 212 | | 213 |Tell me start+stop 214 |------------->| 215 | | 216 | | 217 | |Retrieve records 218 | | 219 | | 220 | | 221 |start and stop| 222 |<-------------| 223 | | 224 | | 225 | | 226 | | 228 Figure 103: Incorrect Validation Protocol: Take 1 230 Unfortunately, this method has a major problem, shown in Figure 104. 232 Po Pbad Pt DHT 233 | | | | 234 | | | | 235 | | | | 236 | |I own Ecalled | | 237 | |---------------------------->| 238 | | | | 239 | | | | 240 | | |I own Ecalled | 241 | | |------------->| 242 | | | | 243 | | | | 244 |Who owns Ecalled? | | 245 |------------------------------------------->| 246 | | | | 247 | | | | 248 |Pbad and Pt | | | 249 |<-------------------------------------------| 250 | | | | 251 | | | | 252 |Tell me start+stop | | 253 |------------->| | | 254 | | | | 255 | | | | 256 | |Tell me start+stop | 257 | |------------->| | 258 | | | | 259 | | | | 260 | | |Retrieve records 261 | | | | 262 | | | | 263 | | | | 264 | |start+stop | | 265 | |<-------------| | 266 | | | | 267 | | | | 268 |start+stop | | | 269 |<-------------| | | 270 | | | | 271 | | | | 272 | | | | 273 | | | | 275 Figure 104: Attack for Incorrect Validation Protocol 277 Consider an attacker BadGuy PBAD. PBAD joins the P2P network, and 278 advertises a number prefix they do NOT own, but which is owned by 279 enterprise T and node PT. Now, when PO queries the DHT with number 280 ECALLED, it comes back with two results - the one from PBAD and the 281 one from node PT. Details of querying the DHT are provided in 282 [VIPR-RELOAD-USAGE]. It begins validation procedures with both. 283 PBAD will now be asked to show the start and stop times for the call, 284 given ECALLED and ECALLING. It doesn't know that information. 285 However, node PT does. So now, PBAD, acting as if it where the 286 originating party, begins the validation protocol with node PT. It 287 passes the calling and called numbers sent by PO. PT finds a match 288 and returns the call start and stop times to PBAD. PBAD, in turn, 289 relays them back to PO. They are correct, and as a consequence, PO 290 has just validated PBAD! 292 Typically, the first response to this is, "Well the problem is, you 293 let two separate people write the same number into the DHT. Why 294 don't you make sure on the right one is allowed to write it in?". 295 That is not possible, since there is no mechanism by which an 296 arbitrary node in the DHT can determine who is the rightful owner of 297 this number. "OK", the reader responds, "So instead, why don't you 298 define a rule that says, if there are two entries in the DHT for a 299 particular number, consider this an attack and don't try to validate 300 the number". That would prevent the attack above. However, it 301 introduces a Denial of service attack. An attacker can pick a target 302 number, write it into the DHT, and prevent successful validation from 303 happening towards that number. They can't misroute calls, but they 304 can stop ViPR from working for targeted numbers. That is not 305 acceptable. ViPR has to be immune from attacks like this; it should 306 not be possible, through simple means such as configuration, for an 307 attacker to cause a targeted number to never be validated. 309 One might be tempted to add a signature over the call start and stop 310 times, but it does not help. BadGuy can just resign them and relay 311 them on. 313 In essence, this simple approach is like a login protocol where the 314 client sends the password in the clear. Such mechanisms have serious 315 security problems. 317 Realizing the similarities between the validation protocol and a 318 login protocol, a next attempt would be to use a much more secure 319 login mechanism - digest authentication. To do this, domain O takes 320 the called number E and the caller ID, and send them to node P. Node 321 P treats these as a "username" of sorts - an index to find a single 322 matching call. The start time and stop times of the call become the 323 "password". Enterprise O also sends a big random number - a nonce - 324 to node P. Node P then takes the random number, takes the password, 325 hashes them together, and sends back the hash. All of this is done 326 over a TLS connection between enterprise O and node P. Digest over 327 TLS is very secure, so surely this must be secure too, right? Wrong! 329 It is not. Indeed it is susceptible to EXACTLY the same attack 330 described previously. This is shown in Figure 105. 332 Po Pbad Pt DHT 333 | | | | 334 | | | | 335 | | | | 336 | |I own Ecalled | | 337 | |---------------------------->| 338 | | | | 339 | | | | 340 | | |I own Ecalled | 341 | | |------------->| 342 | | | | 343 | | | | 344 |Who owns Ecalled? | | 345 |------------------------------------------->| 346 | | | | 347 | | | | 348 |Pbad and Pt | | | 349 |<-------------------------------------------| 350 | | | | 351 | | | | 352 |TLS | | | 353 |------------->| | | 354 | | | | 355 | | | | 356 |Login user=Ecaller+Ecalled | | 357 |------------->| | | 358 | | | | 359 | | | | 360 | |Login user=Ecaller+Ecalled | 361 | |------------->| | 362 | | | | 363 | | | | 364 | | |Retrieve records 365 | | | | 366 | | | | 367 | | | | 368 | |Digest response | 369 | |<-------------| | 370 | | | | 371 | | | | 372 |Digest response | | 373 |<-------------| | | 374 | | | | 375 | | | | 376 | | | | 377 | | | | 378 Figure 105: Trying Digest for Validation 380 In a similar attack, PBAD could pick a random called number it is 381 interested in, query the P2P network for it, find node PT. Then, 382 provide node PT the number ECALLED to attack, and ECALLING, assuming 383 it can guess a likely caller ID. It then takes the received digest 384 response, and goes through every possible start/stop time over the 385 last 24 hours, running them through the hash function. When the hash 386 produces a match, the PBAD has just found a full VCR for node PT. It 387 can then write into the DHT using number E as a key, pointing to 388 itself, and satisfy validation requests against it, without even 389 needing to ask node P again. Our first attempt is susceptible to 390 this attack too. 392 The problem here is that the call start and stop times have "low 393 entropy" - they are not very random and are easily guessable, just 394 like a poorly chosen password. 396 What we really want to do here is have a "login" protocol that 397 creates a secure connection between a client and a server, where we 398 use the called number and caller ID as a "username" to identify a 399 PSTN call, and then use the start and stop times as a "password". 400 But our login protocol has to have some key features: 401 1. Someone posing as a server, but which does not have the username 402 and password, cannot determine the username and password easily 403 as a consequence of an authentication operation started by a 404 valid client, aside from successfully guessing in the one attempt 405 it is given on each connection attempt. 406 2. Someone posing as a client, but which does not have the username 407 and password, cannot determine the username and password as a 408 consequence of an authentication operation started against a 409 valid server, aside from guessing in the one attempt it is given 410 on each TLS connection attempt. 411 3. An active MITM, who is explicitly on the path of the exchanges 412 and has visibility and the ability to modify messages, cannot 413 obtain the shared secret, nor can it observe or modify 414 information passed between the client and real server. 415 4. It is impossible for a passive observer to view the exchange and 416 obtain the shared secret or any of the material that is 417 exchanged. 418 5. It is impossible for a rogue client or rogue server to 419 participate in a login with a legitimate peer, and then take the 420 messages exchanged, and run an offline dictionary attack to work 421 through every possible combination of start and stop times. 422 Fortunately, these properties are provided by a class of password 423 authentication protocols called Encrypted Key Exchange or EKE 424 protocols. 426 3. EKE Protocols 428 EKE protocols were proposed in 1992 by Steve Bellovin. Since their 429 proposal, numerous variations have been defined. One of them, the 430 Secure Remote Password protocol, was standardized by the IETF in RFC 431 2945 [RFC2945]. A TLS mode of SRP was later defined in RFC 5054 432 [RFC5054]. It is the latter protocol which is actually used by ViPR. 433 A high level overview of EKE protocols is shown in Figure 106. Alice 434 and Bob share a shared secret P. Alice generates a public/private 435 keypair. She then takes her public key, and encrypts it using her 436 password as a symmetric encryption key. She sends this encrypted key 437 to Bob. Bob, who shares the password, uses it as a symmetric key and 438 decrypts the message, obtaining Alice's new public key. Bob then 439 constructs a big random number R, which is to be used as a session 440 key. Bob then encrypts R with the public key he just got from Alice, 441 and sends that to Alice. Now, Alice, using her public key, decrypts 442 the message and obtains the session key R. 444 Alice Bob 445 | | 446 | | 447 | | 448 |Bob knows P | 449 | | 450 | | 451 | | 452 |Generate PUB+PRIV | 453 | | 454 | | 455 | | 456 |E(PUB,P) | 457 |----------------------->| 458 | | 459 | | 460 | |decrypt with P, get PUB 461 | | 462 | | 463 | | 464 | |create session key R 465 | | 466 | | 467 | | 468 |E(R,PUB) | 469 |<-----------------------| 470 | | 471 | | 472 |decrypt with PUB, get R | 473 | | 474 | | 475 | | 476 |shares R with Bob | 477 | | 478 | | 479 | | 480 | | 481 | | 483 Figure 106: High Level EKE Model 485 At this point Alice and Bob share a session key R which can be used 486 for authentication (by having Alice and Bob prove to each other that 487 they have the same value for R) or for encrypting data back and 488 forth. How does this help? Consider our man-in-the-middle attack 489 again, in Figure 107. Once again, Alice shares a password with 490 legitimate user Bob. However, she begins the "login" process with 491 BadGuy. She passes E(PUB,P) to BadGuy. BadGuy doesn't know P, so he 492 can't decrypt the message. More importantly, he can't run through 493 each possible password P and decrypt the message. If he did, he 494 wouldn't be able to tell if he got it right, since PUB appears 495 random; the decryption process would produce a random string of bits 496 whether it was successful or not. So for now, BadGuy can only pass 497 it on. BadGuy now intercepts E(R,PUB). Now, BadGuy can try the 498 following. He can run through each P, decrypt E(PUB,R), obtain PUB. 499 However, since we are using asymmetric encryption (i.e., public key 500 encryption), even with PUB he cannot DECRYPT E(R,PUB)! BadGuy does 501 not have the private key, which he needs to decrypt. Given a public 502 key, he cannot guess the private key either. That is how public/ 503 private keying systems work. That is the secret here to making this 504 work. So, once again, BadGuy has no choice but to pass the message 505 on. Now, Alice and Bob share R but it is unknown to BadGuy. Bob now 506 takes his Node-ID, encrypts it with R, and sends to Alice. Once 507 again, BadGuy doesn't have R and can't get it, so he has no choice 508 but to pass it on. Alice decrypts this Node-ID with R, and now knows 509 that she is actually talking to Bob - since she has Bob's Node-ID. 510 Other data can be substituted for the Node-ID, and indeed this is 511 what happens in the actual validation protocol. 513 Alice Bad Bob 514 | | | 515 | | | 516 | | | 517 |Bob knows P | | 518 | | | 519 | | | 520 | | | 521 |Generate PUB+PRIV | | 522 | | | 523 | | | 524 | | | 525 |E(PUB,P) | | 526 |------------------>| | 527 | | | 528 | | | 529 | |E(PUB,P) | 530 | |------------------>| 531 | | | 532 | | | 533 | | |decrypt w P, get PUB 534 | | | 535 | | | 536 | | | 537 | | |create session key R 538 | | | 539 | | | 540 | | | 541 | |E(R,PUB) | 542 | |<------------------| 543 | | | 544 | | | 545 |E(R,PUB) | | 546 |<------------------| | 547 | | | 548 | | | 549 |decrypt with PUB, get R | 550 | | | 551 | | | 552 | | | 553 |shares R with Bob | | 554 | | | 555 | | | 556 | | | 557 | |E(Bob PeerID, R) | 558 | |<------------------| 559 | | | 560 | | | 561 |E(Bob PeerID, R) | | 562 |<------------------| | 563 | | | 564 | | | 565 | | | 566 | | | 568 Figure 107: Attacking EKE Protocols 570 However, the main point of this exercise is to demonstrate that EKE 571 protocols have the desired properties. 573 4. Terminology 575 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 576 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 577 document are to be interpreted as described in [RFC2119]. 579 5. Protocol Overview 581 The validation protocol begins with the following assumptions: 583 1. Node PO wishes to validate with node PCAND, and has its Node-ID 584 (which it obtained via the DHT) and VServiceID (which it also 585 obtained via the DHT Fetch). 586 2. Node PO and PCAND have a series of call records over the last 48 587 hours, uploaded by their call agents. Each call record contains 588 an E.164 calling and called party number, and a start and stop 589 time in NTP time. On the terminating side, each call record is 590 also associated with a VServiceID. 591 3. Node PO is seeking to validate a call to called number ECALLED 592 with caller ID ECALLING. 594 The validation protocol operates by having the originating node make 595 a series of attempts to connect to, and "login" to the terminating 596 node. Each "login" attempt consists of establishment of a TCP 597 connection, and then execution of TLS-SRP procedures over that 598 connection. TLS-SRP[RFC5054] relies on a shared secret - in the form 599 of a username and password - in order to secure the connection. In 600 ViPR, the username and password are constructed by using information 601 from a target VCR along with the VServiceID learned from the DHT. 602 The "username", instead of identifying a user, identifies a 603 (hopefully) unique VCR shared between the originating and terminating 604 nodes. The "password" is constructed from the VCR such that it 605 knowledge of the information is unique to knowledge of the VCR 606 itself. 608 Unfortunately, it is difficult to construct usernames and passwords 609 that always uniquely identify a VCR. To deal with this, the 610 validation protocol requires the originator to construct a series of 611 usernames and passwords against a series of different nodes and their 612 corresponding IP addresses and ports, and then run through them until 613 a connection is securely established. 615 6. Username and Password Algorithms 617 ViPR provides two different algorithms for mapping from a particular 618 VCR to a username and password: 620 1. Method A: This method makes use of the called party and calling 621 party number to form the username, and the start and stop times 622 of the call to form the password. 623 2. Method B: This method makes use of the called party number, 624 along with a point in time in the middle of the call, as the 625 username, and then the start and stop times to form the password. 627 The originating node will first try validations with method A, and if 628 those all fail, then try with method B. The method itself, along with 629 necessary information on how to use the method, is encoded into the 630 username itself. The format of the username is (using ABNF 631 [RFC4234]): 633 username = method-a / method-b / future-method 634 future-method = method ":" method-data 635 method = 1ALPHA 636 method-data = 1*(alphanum / method-unreserved) 638 method-a = "a:" vserviceid originating-number terminating-number 639 rounding-time 640 method-b = "b:" vserviceid terminating-number timekey rounding-time 642 vserviceid = "vs=" 1*32HEXDIG ";" 643 originating-number = "op=+" 1*15DIGIT ";" 644 terminating-number = "tp=+" 1*15DIGIT ";" 645 timekey = "tk=" 1*10DIGIT "." 1*10DIGIT ";" 646 rounding-time = "r=" 1*6DIGIT ";" ; Cannot be equal to 0 648 This format starts with the method, followed by a colon, followed by 649 a sequence of characters that are specific to the method. Both 650 methods a and b rely on conveyance of information attributes that 651 make up the username. Each attribute follows a specific format. 653 Examples include: 655 a:vs=7f5a8630b6365bf2;op=+17325552496;tp=+14085553084;r=1000; 656 b:vs=7f5a8630b6365bf2;tp=+14085553084;tk=172636364.133622;r=1000; 658 Both methods use a rounding factor R. This is used to round the start 659 and stop times in the password to a specific nearest multiple of R 660 (which is in milliseconds). This rounding is done because the 661 passwords need to be bit exact and we need to compensate for 662 different measured values. 664 If we will fallback to method B (which works more often), why have 665 both? There are two answers: 667 1. The caller ID mechanism (method A) will work, and the non-caller 668 ID (method B) won't work, for numbers like 8xx. 669 2. Method A has much higher entropy (see analysis in Section 10.1). 670 Validating with it provides greater confidence in the validity of 671 the number. In this phase, nothing is done with this 672 "confidence". However, in later phases, it is anticipated that 673 low-confidence numbers will require multiple validations for 674 different calls to occur before they are trusted. To allow for 675 this feature to be added later, validation with both methods must 676 be present in the initial release. 678 The sections below detail precisely how these are constructed. 680 7. Originating Node Procedures 682 Most of the work for validation is on the side of the originator. It 683 establishes connections and performs a series of validation checks. 685 7.1. Establishing a Connection 687 The first step in the process is to establish a TCP connection to 688 PCAND. To do that, PO sends a RELOAD AppAttach message targeted 689 towards PCAND, using the Application-ID defined in 690 [VIPR-RELOAD-USAGE]. Once connected, TLS-SRP is run over the 691 connection. 693 7.2. Constructing a Username and Password 695 When a terminating node receives a username in a format it doesn't 696 understand, it fails the validation. This allows for graceful 697 upgrade to new mechanisms in the future. 699 7.2.1. Method A 701 The PO examines the VCR it is using for validation. It extracts the 702 calling and called party numbers, both of which are E.164 based. 703 This VCR will have been uploaded at a previous point in time. PO 704 then examines the VCRs posted in the time since this one was 705 uploaded, and looks for any more recent VCRs with the same calling 706 and called party numbers regardless of VService. If it finds one or 707 more, it takes the most recent one (as measured by its end time). If 708 it finds no more recent, it uses the VCR which triggered the 709 validation in the first place. 711 Why do this? This deals with the following case. User A calls user 712 B, causing a VCR to be uploaded. The originating node sets a timer, 713 which fires 12 hours later. However, within that 12 hour period, A 714 called B again. If node A provides the caller ID and called party 715 numbers as the "key" to select a VCR, it will match multiple records 716 over the past day. We need to pick one, so the most recent is always 717 used. This requires the originating node to know and use the most 718 recent VCR. Furthermore, we must choose the most recent VCR 719 regardless of its VService, because the originating Upload VCRs are 720 sent using an arbitrary VService. Thus, the more recent call may 721 have been done using a different VService than the one which 722 triggered the validation. Since the actual Vservices are not common 723 between originating and terminating sides, we must choose the VCR on 724 the originating side regardless of VService. The username is 725 constructed by using the syntax for method A described above. The 726 calling party number is set to "op", and the called party number is 727 set to "tp", and "r" is the value of Tr as an integral number of 728 milliseconds. The VServiceID learned from the dictionary entry is 729 used as the value of "vs". 731 This username will select the identical VCR at the terminating node, 732 under the following conditions: 734 1. PT is aware of all calls made to the called party number. This 735 property is true so long as each incoming number is handled by a 736 single call agent within a domain, and furthermore, the VCR for 737 calls to that number is always posted to a ViPR server which 738 advertises that number into the DHT. These properties are 739 readily met by ViPR for typical single user numbers. For 8xx 740 numbers, which are translated within the PSTN and may route to a 741 multiplicity of non-8xx numbers, it is more difficult. ViPR will 742 only work with 8xx numbers if all calls to those numbers get sent 743 to agents which share the same ViPR server. 744 2. PO is aware of all calls made to the called party number with the 745 given caller ID. This property can be hard to meet. If the 746 caller ID for a call is set to the number of the calling phone, 747 and all VCRs made from that phone are posted to the same ViPR 748 server, that server will know about all calls made by the domain 749 with the given DID in the caller ID. However, in domains that 750 set the PSTN caller ID to the attendant line number, it is 751 possible that there would be two separate agents, each utilizing 752 different ViPR servers. A user in each agent calls the same 753 number, and the same PSTN caller ID is used. However, one ViPR 754 server knows about one of the calls, and a different ViPR server 755 knows about the other call. However, PT knows about both. In 756 that case, validation from one of the ViPR servers will fail, and 757 from the other, succeed. 758 3. There were no calls on the PSTN to the called party which spoofed 759 the caller ID to match the caller ID used by the valid 760 enterprise. In that case, PT will have a VCR for a call with a 761 matching calling/called party number, but this VCR is unknown to 762 PO since the call was not actually made by the originating 763 enterprise. This attack is described in more detail in XXXX. 765 Next, the password is selected. The password is basically the start 766 and stop times for the call. However, the SRP protocol requires a 767 bit exact agreement on the password. Unfortunately, the calling and 768 called parties will not have the same values for the start and stop 769 times, for several reasons: 771 1. The call start time at the originating and terminating ends will 772 differ by the propagation delay of the call acceptance message 773 through the PSTN. This can be several hundreds of milliseconds. 774 2. The clocks at the originating and terminating ends may not be 775 synchronized, which can also introduce different values for the 776 start and stop times. 777 3. The call termination time at the originating and terminating ends 778 will also differ by the propagation time; this propagation time 779 may in fact be different for the call acceptance and termination. 781 It is also important to note that agreement on a call acceptance and 782 termination time assumes an explicit signaling message is sent for 783 these two events. In the case of analog FXO ports, there is no 784 signaling at all, and consequently, these points in time cannot be 785 measured. It is possible to agree upon other call characteristics 786 when analog lines are in use, but they have much worse accuracy and 787 consequently much, much lower entropy. For this reason, this 788 specification of ViPR only works in telephony systems with explicit 789 messaging for call acceptance and termination, which includes PRI, 790 SS7, BRI, analog trunks with answer and disconnect supervision, and 791 CAS trunks. 793 To deal with these inaccuracies in timing, the start and stop times 794 need to be rounded. Let Tr be the rounding interval, so that each 795 time is rounded to the value of N*Tr for integral N, such that N*Tr 796 is less than the start or stop time, and (N+1)*Tr is greater than it. 797 In other words, "round down". If Tr=1 second, this would round down 798 to the nearest second. 800 Unfortunately, rounding doesn't fully help. Lets say that the 801 difference between the start times on the originating and terminating 802 nodes is delta. We can still have different values for the start 803 time if one side rounds to one value, and the other side to a 804 different value. If delta=100ms and Tr=1s, consider a start time of 805 10.08 seconds on one side, and 9.98 on the other side. One side will 806 round to 10 seconds and the other to nine seconds. The probability 807 of this happening is approximately delta/Tr. We could just make Tr 808 really large to compensate, but this reduces the entropy of the 809 system (see below). 811 To deal with this, the originating node will actually compute FOUR 812 different passwords. For the start time and stop time both, the 813 originating node will round down as follows. Let T be the time in 814 question. Let N be the value such that N*Tr <= T < (N+1)*Tr. In 815 other words, N*Tr is the nearest round-down value, and (N+1)*Tr is 816 the nearest round up. Let T1 and T2 be the two rounded values of T. 817 We have: 819 if (T >= ((2N+1)/2) * Tr) then: 820 T1 = N*Tr 821 T2 = (N+1)*Tr 822 if (T < ((2N+1)/2) * Tr) then: 823 T1 = N*Tr 824 T2 = (N-1)*Tr 826 In other words, if T is in the top half of the rounding interval, we 827 try the rounded values above and below. If T is in the bottom half, 828 we try the rounded values below, and below again. Pictorially: 830 [[TBD]] 832 Figure 108: Rounding mechanism for validation protocol 834 These are tried in the following sequence: 836 1. Try Tstart-1 and Tend-1. 837 2. Try Tstart-2 and Tend-1. 838 3. Try Tstart-1 and Tend-2. 839 4. Try Tstart-2 and Tend-2. 841 For example, if the originating side has a start time of 10.08 and a 842 stop time of 30.87, the four start and stop times with Tr=1s are: 844 +-------+------+ 845 | Start | Stop | 846 +-------+------+ 847 | 10 | 30 | 848 | 9 | 30 | 849 | 10 | 31 | 850 | 9 | 31 | 851 +-------+------+ 853 Each of these times is represented in 64 bit NTP time (Tr can be 854 configured to less than 1s in which case there will be non-zero 855 values in the least significant 32 bits). Each password is then 856 computed by taking the 64 bit start time, followed by the 64 bit end 857 time, resulting in a 128 bit word. This word is base64 encoded to 858 produce an ASCII string representation of 21 characters. To perform 859 the caller ID based validation, the SRP-TLS procedure is done four 860 times, once with each of the four username/password combinations (of 861 course the username is identical in all four cases). As long as 862 delta is less than Tr/2, one of this is guaranteed to work. 864 7.2.2. Method B 866 Unfortunately, in many cases caller ID cannot be used as an 867 identifier for the VCR. This is because: 869 1. CallerID is frequently suppressed in the PSTN, and not delivered. 870 This is especially true in international cases. 871 2. CallerID is sometimes munged by the PSTN, and delivered, but with 872 a different value than was sent by the originator. This happens 873 in certain arbitrage interexchange carriers. 875 Consequently, if no caller ID was delivered at all, the terminating 876 side will not have a matching record. In that case, it informs the 877 calling side that it should abort and revert to method B. If munged, 878 it will also abort for the same reason. 880 If the caller ID attempt aborts, PO now tries a different approach. 881 In this approach, the "username" is the combination of the called 882 party number and a point during the call, selected at random. The 883 password is equal to the start and stop times of the call. This 884 method uses the method-tag "B" in the username. 886 Unlike method A, with method B, the VCR which triggered the 887 validation is used, regardless of whether there were other, more 888 recent, calls to the same calledparty number! This is because, in 889 method B (unlike method A), the time itself is used as a key to 890 select a VCR. Furthermore, using a more recent VCR does not interact 891 properly with multi-tenancy. The called number and point during that 892 call will select an identical VCR on the terminating side if the 893 following conditions are met: 895 1. For the called party number, there was not more than one call in 896 progress made to that number at the same time. This is generally 897 true for numbers for a single user; typically there is only one 898 active call at a time. Of course, it is possible a user receives 899 a call, and then gets another. It then puts the first on hold 900 while the second call is taken. In these cases, it is possible 901 that the "username" will select a different VCR on PT, in which 902 case the validation fails. More troubling are numbers 903 representing call centers, conference bridges, 8xx numbers, and 904 attendant numbers, all of which frequently have multiple calls in 905 progress to them at the same time. As a consequence, for these 906 types of called numbers, validation is typically only going to 907 work if caller ID is delivered. Fortunately, 8xx numbers are 908 only national in the first place, so it is likely that this will 909 work. 911 2. PO is aware of all calls made from within its enterprise to 912 ECALLED. This can fail if there are multiple ViPR servers 913 serving different agents, and a call is made from one agent, sent 914 to one ViPR server, and a call to that same number is made on a 915 different agent, send to a different ViPR server. As in the 916 caller ID case, this will still be OK in many cases - the 917 validation from one ViPR server succeeds, the other fails. 918 3. PT is aware of all calls made to ECALLED. The same caveats as 919 described above for the caller ID mechanism apply. PO takes the 920 VCR, and chooses a time Tkey which is uniformly distributed 921 between Tstart+Tr and Tstop-Tr. The usage of the Tr here is to 922 make sure that Tkey is squarely inside of the call start and stop 923 for PT as well. Note that, because Tkey is not a password, it is 924 sent in the clear and does not need to be rounded. 926 The username encodes the called party number, Tkey, the DHT, and the 927 VServiceID learned from the DHT query. The password is computed 928 identically to method A. 930 7.3. Requesting Validation 932 Once the SRP-TLS connection is up, data is exchanged. This is done 933 through a single VAP transaction initiated by PO. This transaction 934 is only VAP in the sense that it utilizes the basic syntax (the 935 header and TLV attribute structure), and its request/response model. 936 Other than that, it is effectively a different protocol - the 937 validation protocol. 939 PO sends a VAP request with method ValExchange (0x00d). It contains 940 one attribute, Domain. The originating ViPR server obtains this 941 domain by looking at the VService of the VCR that was eventually used 942 for the validation. Note that, in cases where the VCR which 943 triggered the validation, is different than the one actually used for 944 validation (because a more recent VCR to the same number was found), 945 it is important to use the VService associated with the VCR which was 946 actually used for validation, and NOT the VService associated with 947 the VCR which triggered the attempt. Multi-tenancy does not work 948 properly without this. The domain from the VService is placed into 949 the message. This is basically the domain name of the originating 950 enterprise. It is included since it is needed by PT to compute the 951 ticket. 953 PO will then receive a response. If it never receives a response 954 within a timeout, it considers the validation to have failed, and 955 continues to the next choice. If it receives any kind of error 956 response, including a rejection due to a blacklisted domain, it 957 considers validation to have failed, and continues to the next 958 choice. If it is a success response, it will contain one attribute - 959 ServiceContent, which contains a ValInfo XML object. ValInfo is an 960 XML object which contains the SIP URIs and the ticket. The ViPR 961 server must parse the ValInfo XML object and perform verification on 962 it to avoid attacks. The following checks are done: 964 1. Extract the element. This will contain a single number. 965 That value is compared with the E.164 called party number which 966 was just validated. If they do not match, this is a potential 967 attack, and the XML is discarded and the ViPR server acts as if 968 validation failed. However it does not generate an alarm. 969 2. Remove any extensions to the XML which are not supported by the 970 ViPR server (no extensions defined, so in this version, any 971 elements except for the , , s and their 972 embedded are removed. 973 3. Verify that the element contains a single element, 974 . 975 4. Verify that the SIP URI is not larger than 614 characters, 976 contains a domain name that is a valid set of domain name 977 characters, contains a user part that is a valid set of 978 characters, if it contains maddr, that the maddr is a valid 979 domain or IP and less than 255 characters, and if there is a 980 port, it is within 0-65535. This is for security purposes; to 981 make sure a malicious ViPR server on the terminating side cannot 982 send invalid URI and attack the call agent. 983 5. Verify that each SIP URI contains the same domain name. Once the 984 checks and fixes are done, the patched XML is passed to 985 subscribers in a Notify as described in [VIPR-VAP]. 987 8. Terminating Node Procedures 989 8.1. Waiting for SRP-TLS 991 PT will wait for an AppAttach request on the Application-ID defined 992 in [VIPR-RELOAD-USAGE] and the connection is established, it begins 993 waiting for SRP-TLS. The TLS messaging will provide PT with a 994 username. 996 It parses the username and determines the method. If the value of 997 the method is not "a" or "b", this is a new method not supported by 998 the node. The SRP-TLS procedures should be failed. If the method is 999 "a", it is the caller ID mechanism. The called number, calling 1000 number, VService, and rounding time are extracted. PT then searches 1001 through its VCRs over the last 48 hours for one with a matching 1002 called number and caller ID and VService whose VServiceID matches the 1003 one from the username: 1005 1. If none are found, PT proceeds with the SRP-TLS exchange, but 1006 using a fake username and password. This will cause the 1007 validation to eventually fail. 1008 2. If one is found, it is used. 1009 3. If more than one is found, the one with the most recent end time 1010 is used. 1012 The start and stop times from the selected VCR are taken. Using the 1013 value of Tr from the username, both times are rounded down to the 1014 nearest multiple of Tr. Note that, this rounding is different than 1015 the one used on the originating side. The values are ALWAYS rounded 1016 down. So if the stop time is 10.99 and Tr is one second, the rounded 1017 down value of 10 is used. The start and stop times are then 1018 represented as 64 bit NTP times (after rounding), concatenated, and 1019 base64ed to produce a 21 character password. This is the password 1020 used with SRP-TLS. 1022 Note that, the originating node will try up to four different 1023 password combinations. One of these should work, the others will 1024 cause SRP-TLS to fail due to differing shared secrets. However, it 1025 is the job of the originator to perform these four; to the 1026 terminating node, they are four separate attempts. Processing of 1027 SRP-TLS login attempts is stateless on the terminating side. This 1028 means that each attempt is treated independently by PT. It performs 1029 identical processing on each SRP-TLS attempt - examine the username, 1030 find a matching VCR, extract password, and fail the attempt or 1031 continue to success. The originating side has the main burden of 1032 sequencing through the various mechanisms. 1034 If the method is "b", PT uses the extracted called party ID and a 1035 time in the middle of the call. It searches through all VCR records 1036 whose called number matches and whose VServiceID matches, and of 1037 those, takes the ones where Tkey is between Tstart and Tstop. Of 1038 those, if more than one match, the one with the most recent Tstop is 1039 used. Tstart and Tstop for that VCR are extracted, and converted to 1040 a password just as is done for the PO. The resulting SRP-TLS 1041 procedure will then either succeed or fail. Note that, if a domain 1042 has multiple Vservices that contain the same number, there will be 1043 multiple VCRs for calls to that number, and there will be multiple 1044 validation attempts, one for each of the Vservices. 1046 Note that there could be multiple successful validations coming from 1047 different domains for one specific VCR, so VCRs should not be removed 1048 before the end of the 48 hours period. This can happen when a 1049 calling domain uses a PSTN provider that is itself VIPR enabled. 1051 8.2. Receiving Validation Requests 1053 PT listens for incoming VAP/validation requests once the TLS 1054 connection is up. It rejects anything but a ValExchange method with 1055 a 400 response. This allows for future extensibility of the 1056 validation protocol. If the request was ValExchange, it extracts the 1057 domain name. This will be something like "example.com". PT knows 1058 the VCR against which validation succeeded. That VCR is associated 1059 with a VService. The ViPR server checks the domain in the 1060 ValExchange request against the black/white list associated with that 1061 VService. If no VService is currently active, the ValExchange is 1062 rejected with a 403. If there is one active, and if the domain 1063 appears on the black list, or does not appear in the white list, the 1064 ViPR server rejects the ValExchange request with a 403 error 1065 response, indicating that this domain is not allowed to call. 1067 If the domain was in the whitelist or not in the blacklist, or there 1068 was no whitelist/blacklist, PT constructs a successful response to 1069 the ValExchange request. It contains one attribute: ServiceContent. 1070 It has a ValInfo XML object, which contains a number, a ticket, and a 1071 series of routes. 1073 The number is always the E.164 number which was just validated, 1074 including the plus sign. Note that this will also appear in the 1075 ticket. The route element is the sequence of route elements for each 1076 instance associated with the vservice. 1078 Details of the ticker are provided in [VIPR-SIP-ANTISPAM] but the 1079 ticket attribute is constructed as follows: 1080 1. A ticket unique ID TLV is created, containing a randomly chosen 1081 128 bit value as the ticket ID. That is the first TLV in the 1082 ticket. 1083 2. A salt TLV is created, containing a random 32 bit value. This is 1084 the second TLV in the ticket. 1085 3. The validity has the start time set using the current time as the 1086 start time, and the current time + the ticket lifetime as the end 1087 time. The ticket lifetime is a per-DHT configurable parameter. 1088 The terminating ViPR server will have performed the validation 1089 using a particular VService; the DHT for that VService is used to 1090 find the right value for this parameter. 1091 4. Number: This is the terminating number, in E.164 format, which 1092 was just validated. 1093 5. Granting node: this is set to one of the Node-IDs associated 1094 with this ViPR server. Any will do. 1095 6. Granting domain: This value is taken from the domain part of the 1096 SIP URI associated with the VService in which the validated VCR 1097 was found. 1099 7. Granted-To domain: This is formed using the Domain sent in the 1100 ValExchange request. 1101 8. Epoch: This is the current epoch associated with the password. 1102 9. Integrity: Using the current password, this is computed from the 1103 rest of the Ticket. 1105 The resulting sequence of TLVs is base64 encoded and that is placed 1106 into the ticket element in the ServiceContent attribute in the 1107 ValExchange response. 1109 9. Syntax Details 1111 This section enumerates the methods and attributes used by PVP. 1113 The methods and their corresponding method values, are: 1115 Method Value 1116 ------ ------ 1117 ValExchange 0x00d 1119 Figure 1: PVP Methods 1121 The attribute names and corresponding types are: 1123 Attribute Name Type 1124 -------------- ---- 1125 Domain 0x3001 1127 Figure 2: PVP Attributes 1129 10. Security Considerations 1131 [[This section is mostly missing and needs to be done.]] 1133 10.1. Entropy 1135 [[The entropy obtained in the information from the PSTN calls 1136 significantly impacts the security of this protocol. This section 1137 needs to provide an analysis of how much entropy actually exists in 1138 this information.]] 1140 [[Defines the worst case of conference calls and resulting entropy]] 1142 [[Describe the idea of doing multiple validations to aggregate 1143 entropy]] 1145 10.2. Forward Routing Assumptions 1147 [[Discuss forward routing security in PSTN and explain how this 1148 protocol is reliant on that.]] 1150 11. IANA Considerations 1152 [[TBD Define ports used.]] 1154 12. Acknowledgements 1156 Thanks to Patrice Bruno for his comments, suggestions and questions 1157 that helped to improve this document. 1159 13. References 1161 13.1. Normative References 1163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1164 Requirement Levels", BCP 14, RFC 2119, March 1997. 1166 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1167 Specifications: ABNF", RFC 4234, October 2005. 1169 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1170 "Using the Secure Remote Password (SRP) Protocol for TLS 1171 Authentication", RFC 5054, November 2007. 1173 [VIPR-OVERVIEW] 1174 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 1175 "Verification Involving PSTN Reachability: Requirements 1176 and Architecture Overview", 1177 draft-jennings-vipr-overview-00 (work in progress), 1178 April 2011. 1180 [VIPR-VAP] 1181 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 1182 "Verification Involving PSTN Reachability: The ViPR Access 1183 Protocol (VAP)", draft-jennings-vipr-vap-00 (work in 1184 progress), April 2011. 1186 [VIPR-SIP-ANTISPAM] 1187 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 1188 "Session Initiation Protocol (SIP) Extensions for Blocking 1189 VoIP Spam Using PSTN Validation", 1190 draft-petithuguenin-vipr-sip-antispam-01 (work in 1191 progress), June 2011. 1193 [VIPR-RELOAD-USAGE] 1194 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "A 1195 Usage of Resource Location and Discovery (RELOAD) for 1196 Public Switched Telephone Network (PSTN) Verification", 1197 draft-petithuguenin-vipr-reload-usage-01 (work in 1198 progress), June 2011. 1200 13.2. Informative References 1202 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 1203 RFC 2945, September 2000. 1205 Appendix A. Release notes 1207 This section must be removed before publication as an RFC. 1209 A.1. Modifications between vipr-01 and vipr-00 1211 o Added text explaining that VCRs should not be removed before the 1212 end of the 48 hours delay. 1213 o Inserted Terminology section. 1214 o Fixed the timekey ABNF. 1215 o Specified that rounding-time cannot be equal to 0. 1217 A.2. Modifications between vipr-00 and dispatch-03 1219 o Moved to new Working Group. 1221 A.3. Modifications between dispatch-03 and dispatch-02 1223 o Nits. 1224 o Shorter I-Ds references. 1225 o Removed sentence saying that Tkey is converted to base64. 1226 o Added ValExchange method and Domain attribute definitions. 1227 o Fixed the last sentence of 7.2 - the ticket goes into the ticket 1228 element in the ServiceContent attribute. 1229 o Expanded first usage of VCR initialism. 1230 o Replaced any insteance of peerID by Node-ID. 1231 o Rewrote the ABNF. 1233 Authors' Addresses 1235 Jonathan Rosenberg 1236 jdrosen.net 1237 Monmouth, NJ 1238 US 1240 Email: jdrosen@jdrosen.net 1241 URI: http://www.jdrosen.net 1243 Cullen Jennings 1244 Cisco 1245 170 West Tasman Drive 1246 San Jose, CA 95134 1247 USA 1249 Phone: +1 408 421-9990 1250 Email: fluffy@cisco.com 1252 Marc Petit-Huguenin 1253 Stonyfish 1255 Email: marc@stonyfish.com