idnits 2.17.1 draft-petithuguenin-vipr-pvp-04.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 date (March 12, 2012) is 4421 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 2434 (Obsoleted by RFC 5226) ** 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-02 ** Downref: Normative reference to an Informational draft: draft-jennings-vipr-overview (ref. 'VIPR-OVERVIEW') -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VIPR M. Petit-Huguenin 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track J. Rosenberg 5 Expires: September 13, 2012 jdrosen.net 6 C. Jennings 7 Cisco 8 March 12, 2012 10 The Public Switched Telephone Network (PSTN) Validation Protocol (PVP) 11 draft-petithuguenin-vipr-pvp-04 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 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 13, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The Wrong Way . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. EKE Protocols . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 64 6. Username and Password Algorithms . . . . . . . . . . . . . . . 15 65 7. Originating Node Procedures . . . . . . . . . . . . . . . . . 17 66 7.1. Establishing a Connection . . . . . . . . . . . . . . . . 17 67 7.2. Constructing a Username and Password . . . . . . . . . . . 17 68 7.2.1. Method A . . . . . . . . . . . . . . . . . . . . . . . 17 69 7.2.2. Method B . . . . . . . . . . . . . . . . . . . . . . . 21 70 7.3. Requesting Validation . . . . . . . . . . . . . . . . . . 22 71 8. Terminating Node Procedures . . . . . . . . . . . . . . . . . 23 72 8.1. Waiting for SRP-TLS . . . . . . . . . . . . . . . . . . . 23 73 8.2. Receiving Validation Requests . . . . . . . . . . . . . . 25 74 9. Syntax Details . . . . . . . . . . . . . . . . . . . . . . . . 26 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 76 10.1. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . 27 77 10.2. Forward Routing Assumptions . . . . . . . . . . . . . . . 27 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 79 11.1. PVP Method Registry . . . . . . . . . . . . . . . . . . . 27 80 11.2. Registration Process . . . . . . . . . . . . . . . . . . . 27 81 11.3. Initial PVP Method Registry . . . . . . . . . . . . . . . 28 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 85 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 86 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 30 87 A.1. Modifications between vipr-04 and vipr-03 . . . . . . . . 30 88 A.2. Modifications between vipr-03 and vipr-02 . . . . . . . . 31 89 A.3. Modifications between vipr-02 and vipr-01 . . . . . . . . 31 90 A.4. Modifications between vipr-01 and vipr-00 . . . . . . . . 31 91 A.5. Modifications between vipr-00 and dispatch-03 . . . . . . 31 92 A.6. Modifications between dispatch-03 and dispatch-02 . . . . 31 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 95 1. Introduction 97 The validation protocol is the key security mechanism in ViPR. It is 98 used to couple together PSTN calls with IP destinations based on 99 shared knowledge of a PSTN call. This document relies heavily on the 100 concepts and terminology defined in [VIPR-OVERVIEW] and will not make 101 sense if you have not read that document first. 103 The protocol assumes that two enterprises, the originating one 104 (enterprise O) initiates a call on the PSTN to an E.164 number 105 ECALLED that terminates on the terminating enterprise (enterprise T). 106 Each enterprise has a ViPR server, acting as a P2P node. The node in 107 enterprise O is PO, and the node in enterprise T is PT. This PSTN 108 call completes successfully, and knowledge of this call is known to 109 PO and PT. Later on, PO will query the P2P network with number 110 ECALLED. It comes back with a Node-ID PCAND for a node. At this 111 time, PO can't know for sure that PCAND is in fact PT. All it knows 112 is that some node, PCAND, wrote an entry into the DHT claiming that 113 it was the owner of number ECALLED. The objective of the protocol is 114 for PO to determine that node PCAND can legitimately claim ownership 115 of number ECALLED, by demonstrating knowledge of the previous PSTN 116 call. It demonstrates that knowledge by demonstrating it knows the 117 start time, stop timer, and possibly caller ID for the PSTN call made 118 previously. 120 /-----------\ 121 /// \\\ 122 || || 123 | ViPR \ 124 || DHT ||\ 125 X\\ /// \ 126 / \-----------/ \ 127 ---------/- ----\------ 128 /// \\\ /// \\\ 129 // \\ // \\ 130 | |///---\\\ | | 131 | Enterprise O | PSTN | Enterprise T | 132 | |\\\---/// | | 133 \\ // \\ // 134 \\\ /// \\\ /// 135 -----+----- ------+---- 136 +---+----+ +---+----+ 137 | Phone O| |Phone T | 138 +--------+ +--------+ 140 Figure 102: Validation Model 142 If node PCAND can demonstrate such knowledge, then enterprise O can 143 assume that node PCAND had in fact received the call, which could 144 only have happened if it had knowledge of the call to number ECALLED, 145 which could only have happened if PCAND is in enterprise T, and thus 146 it is PT. This is because PSTN routing is assumed to be "secure", in 147 that, if someone calls some number through the PSTN, it will in fact 148 reach a terminating line (whether it be analog, PRI, or other) which 149 is the rightful "owner" of that number. If enterprise T was not the 150 owner of the number, if would not have received the call, would not 151 know its start/stop/caller ID, not be able to provide that 152 information to PT, and not be able to satisfy the knowledge proof. 153 This basic approach is shown in Figure 102. 155 A first question commonly asked is, why not just do regular 156 authentication? What if we give each node a certificate, and then 157 have the nodes authenticate each other? The answer is that a 158 certificate certifies that a particular node belongs to a domain - 159 for example, that node PT is part of example.com. A certificate does 160 not assert that, not only is PT example.com, but example.com owns the 161 following phone numbers. Therefore simple certificate authentication 162 does not provide any guarantee over ownership of phone numbers. 164 In principle, it might be possible to ask certificate authorities, 165 such as Verisign, to assert just that. However, traditionally, 166 certificate authorities have been extremely hesitant to certify much 167 at all. The reason is, the certifier needs to be able to assure that 168 the information is correct. How can a certifier like Verisign verify 169 that, in fact, a particular enterprise owns phone numbers? It could 170 make a few test calls, perhaps, to check if they look right. 171 However, these test calls are disruptive to users that own the 172 numbers (since their phones will ring!). If the test calls are done 173 for a subset of the numbers, it is not secure. If the certifier 174 simply required, as part of the business agreement, that the 175 enterprises provided correct information, the certifier might avoid 176 legal liability, but the legitimacy of the service will be 177 compromised and customers will stop using it. Furthermore, it has 178 proven incredibly hard to do this kind of certification worldwide 179 with a single certificate authority. 181 ViPR has, as a goal, to work anywhere in the world and do guarantee 182 correct call routing with five nines of reliability. Consequently, 183 traditional certificates and authentication do not work. It turns 184 out to be quite hard to design a secure version of this validation 185 protocol. To demonstrate this, we will walk through some initial 186 attempts at it, and show how they fail. 188 2. The Wrong Way 190 The first attempt one might make is the following. PO takes the 191 caller ID for the call, ECALLING and called number ECALLED for the 192 call, and sends them to candidate node PCAND. These two identifiers 193 - the called number E and the caller ID, form a unique handle that 194 can be used to identify the call in question. Node PCAND looks at 195 all of the ViPR Call Records (VCRs) of the calls over the last 48 196 hours, and takes those with the given called party number and calling 197 party number. If there is more than one match, the most recent one 198 is used. We now have a unique call. 200 Now, node PCAND demonstrates knowledge of this call by handing back 201 the start and stop times for this call in a message back to PO. This 202 approach is shown in Figure 103. 204 Po Pt 205 | | 206 | | 207 | | 208 |Tell me start+stop 209 |------------->| 210 | | 211 | | 212 | |Retrieve records 213 | | 214 | | 215 | | 216 |start and stop| 217 |<-------------| 218 | | 219 | | 220 | | 221 | | 223 Figure 103: Incorrect Validation Protocol: Take 1 225 Unfortunately, this method has a major problem, shown in Figure 104. 227 Po Pbad Pt DHT 228 | | | | 229 | | | | 230 | | | | 231 | |I own Ecalled | | 232 | |---------------------------->| 233 | | | | 234 | | | | 235 | | |I own Ecalled | 236 | | |------------->| 237 | | | | 238 | | | | 239 |Who owns Ecalled? | | 240 |------------------------------------------->| 241 | | | | 242 | | | | 243 |Pbad and Pt | | | 244 |<-------------------------------------------| 245 | | | | 246 | | | | 247 |Tell me start+stop | | 248 |------------->| | | 249 | | | | 250 | | | | 251 | |Tell me start+stop | 252 | |------------->| | 253 | | | | 254 | | | | 255 | | |Retrieve records 256 | | | | 257 | | | | 258 | | | | 259 | |start+stop | | 260 | |<-------------| | 261 | | | | 262 | | | | 263 |start+stop | | | 264 |<-------------| | | 265 | | | | 266 | | | | 267 | | | | 268 | | | | 270 Figure 104: Attack for Incorrect Validation Protocol 272 Consider an attacker BadGuy PBAD. PBAD joins the P2P network, and 273 advertises a number prefix they do NOT own, but which is owned by 274 enterprise T and node PT. Now, when PO queries the DHT with number 275 ECALLED, it comes back with two results - the one from PBAD and the 276 one from node PT. Details of querying the DHT are provided in 277 [VIPR-RELOAD-USAGE]. It begins validation procedures with both. 278 PBAD will now be asked to show the start and stop times for the call, 279 given ECALLED and ECALLING. It doesn't know that information. 280 However, node PT does. So now, PBAD, acting as if it where the 281 originating party, begins the validation protocol with node PT. It 282 passes the calling and called numbers sent by PO. PT finds a match 283 and returns the call start and stop times to PBAD. PBAD, in turn, 284 relays them back to PO. They are correct, and as a consequence, PO 285 has just validated PBAD! 287 Typically, the first response to this is, "Well the problem is, you 288 let two separate people write the same number into the DHT. Why 289 don't you make sure on the right one is allowed to write it in?". 290 That is not possible, since there is no mechanism by which an 291 arbitrary node in the DHT can determine who is the rightful owner of 292 this number. "OK", the reader responds, "So instead, why don't you 293 define a rule that says, if there are two entries in the DHT for a 294 particular number, consider this an attack and don't try to validate 295 the number". That would prevent the attack above. However, it 296 introduces a Denial of service attack. An attacker can pick a target 297 number, write it into the DHT, and prevent successful validation from 298 happening towards that number. They can't misroute calls, but they 299 can stop ViPR from working for targeted numbers. That is not 300 acceptable. ViPR has to be immune from attacks like this; it should 301 not be possible, through simple means such as configuration, for an 302 attacker to cause a targeted number to never be validated. 304 One might be tempted to add a signature over the call start and stop 305 times, but it does not help. BadGuy can just resign them and relay 306 them on. 308 In essence, this simple approach is like a login protocol where the 309 client sends the password in the clear. Such mechanisms have serious 310 security problems. 312 Realizing the similarities between the validation protocol and a 313 login protocol, a next attempt would be to use a much more secure 314 login mechanism - digest authentication. To do this, domain O takes 315 the called number E and the caller ID, and send them to node P. Node 316 P treats these as a "username" of sorts - an index to find a single 317 matching call. The start time and stop times of the call become the 318 "password". Enterprise O also sends a big random number - a nonce - 319 to node P. Node P then takes the random number, takes the password, 320 hashes them together, and sends back the hash. All of this is done 321 over a TLS connection between enterprise O and node P. Digest over 322 TLS is very secure, so surely this must be secure too, right? Wrong! 324 It is not. Indeed it is susceptible to EXACTLY the same attack 325 described previously. This is shown in Figure 105. 327 Po Pbad Pt DHT 328 | | | | 329 | | | | 330 | | | | 331 | |I own Ecalled | | 332 | |---------------------------->| 333 | | | | 334 | | | | 335 | | |I own Ecalled | 336 | | |------------->| 337 | | | | 338 | | | | 339 |Who owns Ecalled? | | 340 |------------------------------------------->| 341 | | | | 342 | | | | 343 |Pbad and Pt | | | 344 |<-------------------------------------------| 345 | | | | 346 | | | | 347 |TLS | | | 348 |------------->| | | 349 | | | | 350 | | | | 351 |Login user=Ecaller+Ecalled | | 352 |------------->| | | 353 | | | | 354 | | | | 355 | |Login user=Ecaller+Ecalled | 356 | |------------->| | 357 | | | | 358 | | | | 359 | | |Retrieve records 360 | | | | 361 | | | | 362 | | | | 363 | |Digest response | 364 | |<-------------| | 365 | | | | 366 | | | | 367 |Digest response | | 368 |<-------------| | | 369 | | | | 370 | | | | 371 | | | | 372 | | | | 373 Figure 105: Trying Digest for Validation 375 In a similar attack, PBAD could pick a random called number it is 376 interested in, query the P2P network for it, find node PT. Then, 377 provide node PT the number ECALLED to attack, and ECALLING, assuming 378 it can guess a likely caller ID. It then takes the received digest 379 response, and goes through every possible start/stop time over the 380 last 24 hours, running them through the hash function. When the hash 381 produces a match, the PBAD has just found a full VCR for node PT. It 382 can then write into the DHT using number E as a key, pointing to 383 itself, and satisfy validation requests against it, without even 384 needing to ask node P again. Our first attempt is susceptible to 385 this attack too. 387 The problem here is that the call start and stop times have "low 388 entropy" - they are not very random and are easily guessable, just 389 like a poorly chosen password. 391 What we really want to do here is have a "login" protocol that 392 creates a secure connection between a client and a server, where we 393 use the called number and caller ID as a "username" to identify a 394 PSTN call, and then use the start and stop times as a "password". 395 But our login protocol has to have some key features: 397 1. Someone posing as a server, but which does not have the username 398 and password, cannot determine the username and password easily 399 as a consequence of an authentication operation started by a 400 valid client, aside from successfully guessing in the one attempt 401 it is given on each connection attempt. 402 2. Someone posing as a client, but which does not have the username 403 and password, cannot determine the username and password as a 404 consequence of an authentication operation started against a 405 valid server, aside from guessing in the one attempt it is given 406 on each TLS connection attempt. 407 3. An active MITM, who is explicitly on the path of the exchanges 408 and has visibility and the ability to modify messages, cannot 409 obtain the shared secret, nor can it observe or modify 410 information passed between the client and real server. 411 4. It is impossible for a passive observer to view the exchange and 412 obtain the shared secret or any of the material that is 413 exchanged. 414 5. It is impossible for a rogue client or rogue server to 415 participate in a login with a legitimate peer, and then take the 416 messages exchanged, and run an offline dictionary attack to work 417 through every possible combination of start and stop times. 418 Fortunately, these properties are provided by a class of password 419 authentication protocols called Encrypted Key Exchange or EKE 420 protocols. 422 3. EKE Protocols 424 EKE protocols were proposed in 1992 by Steve Bellovin. Since their 425 proposal, numerous variations have been defined. One of them, the 426 Secure Remote Password protocol, was standardized by the IETF in RFC 427 2945 [RFC2945]. A TLS mode of SRP was later defined in RFC 5054 428 [RFC5054]. It is the latter protocol which is actually used by ViPR. 429 A high level overview of EKE protocols is shown in Figure 106. Alice 430 and Bob share a shared secret P. Alice generates a public/private 431 keypair. She then takes her public key, and encrypts it using her 432 password as a symmetric encryption key. She sends this encrypted key 433 to Bob. Bob, who shares the password, uses it as a symmetric key and 434 decrypts the message, obtaining Alice's new public key. Bob then 435 constructs a big random number R, which is to be used as a session 436 key. Bob then encrypts R with the public key he just got from Alice, 437 and sends that to Alice. Now, Alice, using her public key, decrypts 438 the message and obtains the session key R. 440 Alice Bob 441 | | 442 | | 443 | | 444 |Bob knows P | 445 | | 446 | | 447 | | 448 |Generate PUB+PRIV | 449 | | 450 | | 451 | | 452 |E(PUB,P) | 453 |----------------------->| 454 | | 455 | | 456 | |decrypt with P, get PUB 457 | | 458 | | 459 | | 460 | |create session key R 461 | | 462 | | 463 | | 464 |E(R,PUB) | 465 |<-----------------------| 466 | | 467 | | 468 |decrypt with PUB, get R | 469 | | 470 | | 471 | | 472 |shares R with Bob | 473 | | 474 | | 475 | | 476 | | 477 | | 479 Figure 106: High Level EKE Model 481 At this point Alice and Bob share a session key R which can be used 482 for authentication (by having Alice and Bob prove to each other that 483 they have the same value for R) or for encrypting data back and 484 forth. How does this help? Consider our man-in-the-middle attack 485 again, in Figure 107. Once again, Alice shares a password with 486 legitimate user Bob. However, she begins the "login" process with 487 BadGuy. She passes E(PUB,P) to BadGuy. BadGuy doesn't know P, so he 488 can't decrypt the message. More importantly, he can't run through 489 each possible password P and decrypt the message. If he did, he 490 wouldn't be able to tell if he got it right, since PUB appears 491 random; the decryption process would produce a random string of bits 492 whether it was successful or not. So for now, BadGuy can only pass 493 it on. BadGuy now intercepts E(R,PUB). Now, BadGuy can try the 494 following. He can run through each P, decrypt E(PUB,R), obtain PUB. 495 However, since we are using asymmetric encryption (i.e., public key 496 encryption), even with PUB he cannot DECRYPT E(R,PUB)! BadGuy does 497 not have the private key, which he needs to decrypt. Given a public 498 key, he cannot guess the private key either. That is how public/ 499 private keying systems work. That is the secret here to making this 500 work. So, once again, BadGuy has no choice but to pass the message 501 on. Now, Alice and Bob share R but it is unknown to BadGuy. Bob now 502 takes his Node-ID, encrypts it with R, and sends to Alice. Once 503 again, BadGuy doesn't have R and can't get it, so he has no choice 504 but to pass it on. Alice decrypts this Node-ID with R, and now knows 505 that she is actually talking to Bob - since she has Bob's Node-ID. 506 Other data can be substituted for the Node-ID, and indeed this is 507 what happens in the actual validation protocol. 509 Alice Bad Bob 510 | | | 511 | | | 512 | | | 513 |Bob knows P | | 514 | | | 515 | | | 516 | | | 517 |Generate PUB+PRIV | | 518 | | | 519 | | | 520 | | | 521 |E(PUB,P) | | 522 |------------------>| | 523 | | | 524 | | | 525 | |E(PUB,P) | 526 | |------------------>| 527 | | | 528 | | | 529 | | |decrypt w P, get PUB 530 | | | 531 | | | 532 | | | 533 | | |create session key R 534 | | | 535 | | | 536 | | | 537 | |E(R,PUB) | 538 | |<------------------| 539 | | | 540 | | | 541 |E(R,PUB) | | 542 |<------------------| | 543 | | | 544 | | | 545 |decrypt with PUB, get R | 546 | | | 547 | | | 548 | | | 549 |shares R with Bob | | 550 | | | 551 | | | 552 | | | 553 | |E(Bob PeerID, R) | 554 | |<------------------| 555 | | | 556 | | | 557 |E(Bob PeerID, R) | | 558 |<------------------| | 559 | | | 560 | | | 561 | | | 562 | | | 564 Figure 107: Attacking EKE Protocols 566 However, the main point of this exercise is to demonstrate that EKE 567 protocols have the desired properties. 569 4. Terminology 571 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 572 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 573 document are to be interpreted as described in [RFC2119]. 575 5. Protocol Overview 577 The validation protocol begins with the following assumptions: 579 1. Node PO wishes to validate with node PCAND, and has its Node-ID 580 (which it obtained via the DHT) and VServiceID (which it also 581 obtained via the DHT Fetch). 582 2. Node PO and PCAND have a series of call records over the last 48 583 hours, uploaded by their call agents. Each call record contains 584 an E.164 calling and called party number, and a start and stop 585 time in NTP time. On the terminating side, each call record is 586 also associated with a VServiceID. 587 3. Node PO is seeking to validate a call to called number ECALLED 588 with caller ID ECALLING. 590 The validation protocol operates by having the originating node make 591 a series of attempts to connect to, and "login" to the terminating 592 node. Each "login" attempt consists of establishment of a TCP 593 connection, and then execution of TLS-SRP procedures over that 594 connection. TLS-SRP[RFC5054] relies on a shared secret - in the form 595 of a username and password - in order to secure the connection. In 596 ViPR, the username and password are constructed by using information 597 from a target VCR along with the VServiceID learned from the DHT. 598 The "username", instead of identifying a user, identifies a 599 (hopefully) unique VCR shared between the originating and terminating 600 nodes. The "password" is constructed from the VCR such that it 601 knowledge of the information is unique to knowledge of the VCR 602 itself. 604 Unfortunately, it is difficult to construct usernames and passwords 605 that always uniquely identify a VCR. To deal with this, the 606 validation protocol requires the originator to construct a series of 607 usernames and passwords against a series of different nodes and their 608 corresponding IP addresses and ports, and then run through them until 609 a connection is securely established. 611 6. Username and Password Algorithms 613 ViPR provides two different algorithms for mapping from a particular 614 VCR to a username and password: 616 1. Method A: This method makes use of the called party and calling 617 party number to form the username, and the start and stop times 618 of the call to form the password. 619 2. Method B: This method makes use of the called party number, 620 along with a point in time in the middle of the call, as the 621 username, and then the start and stop times to form the password. 623 The originating node will first try validations with method A, and if 624 those all fail, then try with method B. The method itself, along with 625 necessary information on how to use the method, is encoded into the 626 username itself. The format of the username is (using ABNF 627 [RFC4234]): 629 username = method-a / method-b / future-method 630 future-method = method ":" method-data 631 method = private-method / experimental-method / standard-method 632 private-method = "p-" 1*(alphanum / "-" / ".") 633 experimental-method = "x-" 1*(alphanum / "-" / ".") 634 standard-method = 1*(alphanum / "-" / ".") 635 ; Cannot start with "p-" or "x-" 636 method-data = 1*(alphanum / method-unreserved) 638 method-a = "a:" vserviceid orig-number terminating-number 639 rounding-time 640 method-b = "b:" vserviceid terminating-number timekey rounding-time 642 vserviceid = "vs=" 1*32HEXDIG ";" 643 orig-number = "op=$2a$" 1*2DIGIT "$" 1*(alphanum / "/" / ".") ";" 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 Because having the originating number in clear in the username would 654 create some privacy issues (see [I-D.procter-vipr-privacy-concerns]), 655 it is first hashed using a bcrypt hash [1]. 657 Examples include (the first example is split in 3 lines for 658 formatting purpose): 660 a:vs=7f5a8630b6365bf2; 661 op=$2a$10$uhNBlMT5O063n5/YMlg3Y.xTmZuHMeAFbSxhwSacX87aujFxPvoxG; 662 tp=+14085553084;r=1000; 663 b:vs=7f5a8630b6365bf2;tp=+14085553084;tk=172636364.133622;r=1000; 665 Both methods use a rounding factor R. This is used to round the start 666 and stop times in the password to a specific nearest multiple of R 667 (which is in milliseconds). This rounding is done because the 668 passwords need to be bit exact and we need to compensate for 669 different measured values. 671 If we will fallback to method B (which works more often), why have 672 both? There are two answers: 674 1. The caller ID mechanism (method A) will work, and the non-caller 675 ID (method B) won't work, for numbers like 8xx. 676 2. Method A has much higher entropy (see analysis in Section 10.1). 677 Validating with it provides greater confidence in the validity of 678 the number. In this phase, nothing is done with this 679 "confidence". However, in later phases, it is anticipated that 680 low-confidence numbers will require multiple validations for 681 different calls to occur before they are trusted. To allow for 682 this feature to be added later, validation with both methods must 683 be present in the initial release. 685 The sections below detail precisely how these are constructed. 687 7. Originating Node Procedures 689 Most of the work for validation is on the side of the originator. It 690 establishes connections and performs a series of validation checks. 692 7.1. Establishing a Connection 694 The first step in the process is to establish a TCP connection to 695 PCAND. To do that, PO sends a RELOAD AppAttach message targeted 696 towards PCAND, using the Application-ID defined in 697 [VIPR-RELOAD-USAGE]. Once connected, TLS-SRP is run over the 698 connection. 700 7.2. Constructing a Username and Password 702 When a terminating node receives a username in a format it doesn't 703 understand, it fails the validation. This allows for graceful 704 upgrade to new mechanisms in the future. 706 7.2.1. Method A 708 The PO examines the VCR it is using for validation. It extracts the 709 called party numbers which is E.164 based. It also extracts the 710 calling number, which is hashed with bcrypt hash and extract the salt 711 and the number of rounds from it. This VCR will have been uploaded 712 at a previous point in time. PO then examines the VCRs posted in the 713 time since this one was uploaded, and looks for any more recent VCRs 714 with the same called party numbers and a calling party number which, 715 when hashed with the salt and the number of rounds, is equals to the 716 has extracted, regardless of VService. If it finds one or more, it 717 takes the most recent one (as measured by its end time). If it finds 718 no more recent, it uses the VCR which triggered the validation in the 719 first place. 721 Why do this? This deals with the following case. User A calls user 722 B, causing a VCR to be uploaded. The originating node sets a timer, 723 which fires 12 hours later. However, within that 12 hour period, A 724 called B again. If node A provides the caller ID and called party 725 numbers as the "key" to select a VCR, it will match multiple records 726 over the past day. We need to pick one, so the most recent is always 727 used. This requires the originating node to know and use the most 728 recent VCR. Furthermore, we must choose the most recent VCR 729 regardless of its VService, because the originating Upload VCRs are 730 sent using an arbitrary VService. Thus, the more recent call may 731 have been done using a different VService than the one which 732 triggered the validation. Since the actual Vservices are not common 733 between originating and terminating sides, we must choose the VCR on 734 the originating side regardless of VService. The username is 735 constructed by using the syntax for method A described above. The 736 calling party number is set to "op", and the called party number is 737 set to "tp", and "r" is the value of Tr as an integral number of 738 milliseconds. The VServiceID learned from the dictionary entry is 739 used as the value of "vs". 741 This username will select the identical VCR at the terminating node, 742 under the following conditions: 744 1. PT is aware of all calls made to the called party number. This 745 property is true so long as each incoming number is handled by a 746 single call agent within a domain, and furthermore, the VCR for 747 calls to that number is always posted to a ViPR server which 748 advertises that number into the DHT. These properties are 749 readily met by ViPR for typical single user numbers. For 8xx 750 numbers, which are translated within the PSTN and may route to a 751 multiplicity of non-8xx numbers, it is more difficult. ViPR will 752 only work with 8xx numbers if all calls to those numbers get sent 753 to agents which share the same ViPR server. 754 2. PO is aware of all calls made to the called party number with the 755 given caller ID. This property can be hard to meet. If the 756 caller ID for a call is set to the number of the calling phone, 757 and all VCRs made from that phone are posted to the same ViPR 758 server, that server will know about all calls made by the domain 759 with the given DID in the caller ID. However, in domains that 760 set the PSTN caller ID to the attendant line number, it is 761 possible that there would be two separate agents, each utilizing 762 different ViPR servers. A user in each agent calls the same 763 number, and the same PSTN caller ID is used. However, one ViPR 764 server knows about one of the calls, and a different ViPR server 765 knows about the other call. However, PT knows about both. In 766 that case, validation from one of the ViPR servers will fail, and 767 from the other, succeed. 769 3. There were no calls on the PSTN to the called party which spoofed 770 the caller ID to match the caller ID used by the valid 771 enterprise. In that case, PT will have a VCR for a call with a 772 matching calling/called party number, but this VCR is unknown to 773 PO since the call was not actually made by the originating 774 enterprise. This attack is described in more detail in XXXX. 776 Next, the password is selected. The password is basically the start 777 and stop times for the call. However, the SRP protocol requires a 778 bit exact agreement on the password. Unfortunately, the calling and 779 called parties will not have the same values for the start and stop 780 times, for several reasons: 782 1. The call start time at the originating and terminating ends will 783 differ by the propagation delay of the call acceptance message 784 through the PSTN. This can be several hundreds of milliseconds. 785 2. The clocks at the originating and terminating ends may not be 786 synchronized, which can also introduce different values for the 787 start and stop times. 788 3. The call termination time at the originating and terminating ends 789 will also differ by the propagation time; this propagation time 790 may in fact be different for the call acceptance and termination. 792 It is also important to note that agreement on a call acceptance and 793 termination time assumes an explicit signaling message is sent for 794 these two events. In the case of analog FXO ports, there is no 795 signaling at all, and consequently, these points in time cannot be 796 measured. It is possible to agree upon other call characteristics 797 when analog lines are in use, but they have much worse accuracy and 798 consequently much, much lower entropy. For this reason, this 799 specification of ViPR only works in telephony systems with explicit 800 messaging for call acceptance and termination, which includes PRI, 801 SS7, BRI, analog trunks with answer and disconnect supervision, and 802 CAS trunks. 804 To deal with these inaccuracies in timing, the start and stop times 805 need to be rounded. Let Tr be the rounding interval, so that each 806 time is rounded to the value of N*Tr for integral N, such that N*Tr 807 is less than the start or stop time, and (N+1)*Tr is greater than it. 808 In other words, "round down". If Tr=1 second, this would round down 809 to the nearest second. 811 Unfortunately, rounding doesn't fully help. Lets say that the 812 difference between the start times on the originating and terminating 813 nodes is delta. We can still have different values for the start 814 time if one side rounds to one value, and the other side to a 815 different value. If delta=100ms and Tr=1s, consider a start time of 816 10.08 seconds on one side, and 9.98 on the other side. One side will 817 round to 10 seconds and the other to nine seconds. The probability 818 of this happening is approximately delta/Tr. We could just make Tr 819 really large to compensate, but this reduces the entropy of the 820 system (see below). 822 To deal with this, the originating node will actually compute FOUR 823 different passwords. For the start time and stop time both, the 824 originating node will round down as follows. Let T be the time in 825 question. Let N be the value such that N*Tr <= T < (N+1)*Tr. In 826 other words, N*Tr is the nearest round-down value, and (N+1)*Tr is 827 the nearest round up. Let T1 and T2 be the two rounded values of T. 828 We have: 830 if (T >= ((2N+1)/2) * Tr) then: 831 T1 = N*Tr 832 T2 = (N+1)*Tr 833 if (T < ((2N+1)/2) * Tr) then: 834 T1 = N*Tr 835 T2 = (N-1)*Tr 837 In other words, if T is in the top half of the rounding interval, we 838 try the rounded values above and below. If T is in the bottom half, 839 we try the rounded values below, and below again. Pictorially: 841 [[TBD]] 843 Figure 108: Rounding mechanism for validation protocol 845 These are tried in the following sequence: 847 1. Try Tstart-1 and Tend-1. 848 2. Try Tstart-2 and Tend-1. 849 3. Try Tstart-1 and Tend-2. 850 4. Try Tstart-2 and Tend-2. 852 For example, if the originating side has a start time of 10.08 and a 853 stop time of 30.87, the four start and stop times with Tr=1s are: 855 +-------+------+ 856 | Start | Stop | 857 +-------+------+ 858 | 10 | 30 | 859 | 9 | 30 | 860 | 10 | 31 | 861 | 9 | 31 | 862 +-------+------+ 864 Each of these times is represented in 64 bit NTP time (Tr can be 865 configured to less than 1s in which case there will be non-zero 866 values in the least significant 32 bits). Each password is then 867 computed by taking the 64 bit start time, followed by the 64 bit end 868 time, resulting in a 128 bit word. This word is base64 encoded to 869 produce an ASCII string representation of 21 characters. To perform 870 the caller ID based validation, the SRP-TLS procedure is done four 871 times, once with each of the four username/password combinations (of 872 course the username is identical in all four cases). As long as 873 delta is less than Tr/2, one of this is guaranteed to work. 875 7.2.2. Method B 877 Unfortunately, in many cases caller ID cannot be used as an 878 identifier for the VCR. This is because: 880 1. CallerID is frequently suppressed in the PSTN, and not delivered. 881 This is especially true in international cases. 882 2. CallerID is sometimes munged by the PSTN, and delivered, but with 883 a different value than was sent by the originator. This happens 884 in certain arbitrage interexchange carriers. 886 Consequently, if no caller ID was delivered at all, the terminating 887 side will not have a matching record. In that case, it informs the 888 calling side that it should abort and revert to method B. If munged, 889 it will also abort for the same reason. 891 If the caller ID attempt aborts, PO now tries a different approach. 892 In this approach, the "username" is the combination of the called 893 party number and a point during the call, selected at random. The 894 password is equal to the start and stop times of the call. This 895 method uses the method-tag "B" in the username. 897 Unlike method A, with method B, the VCR which triggered the 898 validation is used, regardless of whether there were other, more 899 recent, calls to the same calledparty number! This is because, in 900 method B (unlike method A), the time itself is used as a key to 901 select a VCR. Furthermore, using a more recent VCR does not interact 902 properly with multi-tenancy. The called number and point during that 903 call will select an identical VCR on the terminating side if the 904 following conditions are met: 906 1. For the called party number, there was not more than one call in 907 progress made to that number at the same time. This is generally 908 true for numbers for a single user; typically there is only one 909 active call at a time. Of course, it is possible a user receives 910 a call, and then gets another. It then puts the first on hold 911 while the second call is taken. In these cases, it is possible 912 that the "username" will select a different VCR on PT, in which 913 case the validation fails. More troubling are numbers 914 representing call centers, conference bridges, 8xx numbers, and 915 attendant numbers, all of which frequently have multiple calls in 916 progress to them at the same time. As a consequence, for these 917 types of called numbers, validation is typically only going to 918 work if caller ID is delivered. Fortunately, 8xx numbers are 919 only national in the first place, so it is likely that this will 920 work. 921 2. PO is aware of all calls made from within its enterprise to 922 ECALLED. This can fail if there are multiple ViPR servers 923 serving different agents, and a call is made from one agent, sent 924 to one ViPR server, and a call to that same number is made on a 925 different agent, send to a different ViPR server. As in the 926 caller ID case, this will still be OK in many cases - the 927 validation from one ViPR server succeeds, the other fails. 928 3. PT is aware of all calls made to ECALLED. The same caveats as 929 described above for the caller ID mechanism apply. PO takes the 930 VCR, and chooses a time Tkey which is uniformly distributed 931 between Tstart+Tr and Tstop-Tr. The usage of the Tr here is to 932 make sure that Tkey is squarely inside of the call start and stop 933 for PT as well. Note that, because Tkey is not a password, it is 934 sent in the clear and does not need to be rounded. 936 The username encodes the called party number, Tkey, the DHT, and the 937 VServiceID learned from the DHT query. The password is computed 938 identically to method A. 940 7.3. Requesting Validation 942 Once the SRP-TLS connection is up, data is exchanged. This is done 943 through a single VAP transaction initiated by PO. This transaction 944 is only VAP in the sense that it utilizes the basic syntax (the 945 header and TLV attribute structure), and its request/response model. 946 Other than that, it is effectively a different protocol - the 947 validation protocol. 949 PO sends a VAP request with method ValExchange (0x00d). It contains 950 one attribute, Domain. The originating ViPR server obtains this 951 domain by looking at the VService of the VCR that was eventually used 952 for the validation. Note that, in cases where the VCR which 953 triggered the validation, is different than the one actually used for 954 validation (because a more recent VCR to the same number was found), 955 it is important to use the VService associated with the VCR which was 956 actually used for validation, and NOT the VService associated with 957 the VCR which triggered the attempt. Multi-tenancy does not work 958 properly without this. The domain from the VService is placed into 959 the message. This is basically the domain name of the originating 960 enterprise. It is included since it is needed by PT to compute the 961 ticket. 963 PO will then receive a response. If it never receives a response 964 within a timeout, it considers the validation to have failed, and 965 continues to the next choice. If it receives any kind of error 966 response, including a rejection due to a blacklisted domain, it 967 considers validation to have failed, and continues to the next 968 choice. If it is a success response, it will contain one attribute - 969 ServiceContent, which contains a ValInfo XML object. ValInfo is an 970 XML object which contains the SIP URIs and an optional ticket. The 971 ViPR server must parse the ValInfo XML object and perform 972 verification on it to avoid attacks. The following checks are done: 974 1. Extract the element. This will contain a single number. 975 That value is compared with the E.164 called party number which 976 was just validated. If they do not match, this is a potential 977 attack, and the XML is discarded and the ViPR server acts as if 978 validation failed. However it does not generate an alarm. 979 2. Remove any extensions to the XML which are not supported by the 980 ViPR server (no extensions defined, so in this version, any 981 elements except for the , , s and their 982 embedded are removed. 983 3. If there is no element and no element in the XML 984 object, it means that the PVP server can not provide these 985 elements yet because not enough entropy was accumulated. The PVP 986 client MUST stop trying new methods. 987 4. Verify that the element contains a single element, 988 . 989 5. Verify that the SIP URI is not larger than 614 characters, 990 contains a domain name that is a valid set of domain name 991 characters, contains a user part that is a valid set of 992 characters, if it contains maddr, that the maddr is a valid 993 domain or IP and less than 255 characters, and if there is a 994 port, it is within 0-65535. This is for security purposes; to 995 make sure a malicious ViPR server on the terminating side cannot 996 send invalid URI and attack the call agent. 997 6. Verify that each SIP URI contains the same domain name. Once the 998 checks and fixes are done, the patched XML is passed to 999 subscribers in a Notify as described in [VIPR-VAP]. 1001 8. Terminating Node Procedures 1003 8.1. Waiting for SRP-TLS 1005 PT will wait for an AppAttach request on the Application-ID defined 1006 in [VIPR-RELOAD-USAGE] and the connection is established, it begins 1007 waiting for SRP-TLS. The TLS messaging will provide PT with a 1008 username. 1010 It parses the username and determines the method. If the value of 1011 the method is not "a" or "b", this is a new method not supported by 1012 the node. The SRP-TLS procedures should be failed. If the method is 1013 "a", it is the caller ID mechanism. The called number, calling 1014 number, VService, and rounding time are extracted. PT then searches 1015 through its VCRs over the last 48 hours for one with a matching 1016 called number and caller ID and VService whose VServiceID matches the 1017 one from the username: 1019 1. If none are found, PT proceeds with the SRP-TLS exchange, but 1020 using a fake username and password. This will cause the 1021 validation to eventually fail. 1022 2. If one is found, it is used. 1023 3. If more than one is found, the one with the most recent end time 1024 is used. 1026 The start and stop times from the selected VCR are taken. Using the 1027 value of Tr from the username, both times are rounded down to the 1028 nearest multiple of Tr. Note that, this rounding is different than 1029 the one used on the originating side. The values are ALWAYS rounded 1030 down. So if the stop time is 10.99 and Tr is one second, the rounded 1031 down value of 10 is used. The start and stop times are then 1032 represented as 64 bit NTP times (after rounding), concatenated, and 1033 base64ed to produce a 21 character password. This is the password 1034 used with SRP-TLS. 1036 Note that, the originating node will try up to four different 1037 password combinations. One of these should work, the others will 1038 cause SRP-TLS to fail due to differing shared secrets. However, it 1039 is the job of the originator to perform these four; to the 1040 terminating node, they are four separate attempts. Processing of 1041 SRP-TLS login attempts is stateless on the terminating side. This 1042 means that each attempt is treated independently by PT. It performs 1043 identical processing on each SRP-TLS attempt - examine the username, 1044 find a matching VCR, extract password, and fail the attempt or 1045 continue to success. The originating side has the main burden of 1046 sequencing through the various mechanisms. 1048 If the method is "b", PT uses the extracted called party ID and a 1049 time in the middle of the call. It searches through all VCR records 1050 whose called number matches and whose VServiceID matches, and of 1051 those, takes the ones where Tkey is between Tstart and Tstop. Of 1052 those, if more than one match, the one with the most recent Tstop is 1053 used. Tstart and Tstop for that VCR are extracted, and converted to 1054 a password just as is done for the PO. The resulting SRP-TLS 1055 procedure will then either succeed or fail. Note that, if a domain 1056 has multiple Vservices that contain the same number, there will be 1057 multiple VCRs for calls to that number, and there will be multiple 1058 validation attempts, one for each of the Vservices. 1060 Note that there could be multiple successful validations coming from 1061 different domains for one specific VCR, so VCRs should not be removed 1062 before the end of the 48 hours period. This can happen when a 1063 calling domain uses a PSTN provider that is itself VIPR enabled. 1065 8.2. Receiving Validation Requests 1067 PT listens for incoming VAP/validation requests once the TLS 1068 connection is up. It rejects anything but a ValExchange method with 1069 a 400 response. This allows for future extensibility of the 1070 validation protocol. If the request was ValExchange, it extracts the 1071 domain name. This will be something like "example.com". PT knows 1072 the VCR against which validation succeeded. That VCR is associated 1073 with a VService. The ViPR server checks the domain in the 1074 ValExchange request against the black/white list associated with that 1075 VService. If no VService is currently active, the ValExchange is 1076 rejected with a 403. If there is one active, and if the domain 1077 appears on the black list, or does not appear in the white list, the 1078 ViPR server rejects the ValExchange request with a 403 error 1079 response, indicating that this domain is not allowed to call. 1081 If the domain was in the whitelist or not in the blacklist, or there 1082 was no whitelist/blacklist, PT constructs a successful response to 1083 the ValExchange request. It contains one attribute: ServiceContent. 1084 It has a ValInfo XML object, which contains a number, and optionaly a 1085 ticket and a series of routes. 1087 PT then check if there is enough entropy accumulated for this domain 1088 and this number by checking an internal database. If entropy has 1089 already been stored by a previous validation, it is added to the 1090 entropy provided by this new validation. If the new total, or the 1091 entropy provided by this validation, is higher than the threshold 1092 configured in PT, then a route and ticket will be sent as described 1093 in the following paragraphs. If the new total is lower than the 1094 threshold, then it is stored in the internal database and the 1095 ServiceContent returned contains no ticket and no route. 1097 The number is always the E.164 number which was just validated, 1098 including the plus sign. Note that this will also appear in the 1099 ticket. The route element is the sequence of route elements for each 1100 instance associated with the vservice. 1102 Details of the ticket are provided in [VIPR-SIP-ANTISPAM] but the 1103 ticket attribute is constructed as follows: 1105 1. A ticket unique ID TLV is created, containing a randomly chosen 1106 128 bit value as the ticket ID. That is the first TLV in the 1107 ticket. 1108 2. A salt TLV is created, containing a random 32 bit value. This is 1109 the second TLV in the ticket. 1110 3. The validity has the start time set using the current time as the 1111 start time, and the current time + the ticket lifetime as the end 1112 time. The ticket lifetime is a per-DHT configurable parameter. 1113 The terminating ViPR server will have performed the validation 1114 using a particular VService; the DHT for that VService is used to 1115 find the right value for this parameter. 1116 4. Number: This is the terminating number, in E.164 format, which 1117 was just validated. 1118 5. Granting node: this is set to one of the Node-IDs associated 1119 with this ViPR server. Any will do. 1120 6. Granting domain: This value is taken from the domain part of the 1121 SIP URI associated with the VService in which the validated VCR 1122 was found. 1123 7. Granted-To domain: This is formed using the Domain sent in the 1124 ValExchange request. 1125 8. Epoch: This is the current epoch associated with the password. 1126 9. Integrity: Using the current password, this is computed from the 1127 rest of the Ticket. 1129 The resulting sequence of TLVs is base64 encoded and that is placed 1130 into the ticket element in the ServiceContent attribute in the 1131 ValExchange response. 1133 9. Syntax Details 1135 This section enumerates the methods and attributes used by PVP. 1137 The methods and their corresponding method values, are: 1139 Method Value 1140 ------ ------ 1141 ValExchange 0x00d 1143 Figure 1: PVP Methods 1145 The attribute names and corresponding types are: 1147 Attribute Name Type 1148 -------------- ---- 1149 Domain 0x3001 1151 Figure 2: PVP Attributes 1153 10. Security Considerations 1155 [[This section is mostly missing and needs to be done.]] 1157 10.1. Entropy 1159 [[The entropy obtained in the information from the PSTN calls 1160 significantly impacts the security of this protocol. This section 1161 needs to provide an analysis of how much entropy actually exists in 1162 this information.]] 1164 [[Defines the worst case of conference calls and resulting entropy]] 1166 10.2. Forward Routing Assumptions 1168 [[Discuss forward routing security in PSTN and explain how this 1169 protocol is reliant on that.]] 1171 11. IANA Considerations 1173 11.1. PVP Method Registry 1175 IANA shall establish and maintain a "PVP Method" Registry, listing 1176 the following information: 1178 o Method tag: A string uniquely defining a method. This string 1179 cannot use a "p-" or "x-" prefix. 1180 o Defining publication: The RFC used to define the PVP method, as 1181 defined in the registration process below. 1183 11.2. Registration Process 1185 Private PVP methods starts with "p-" (e.g. "p-fingerprint"). Private 1186 methods MUST be only used inside a specific domain and MUST NOT be 1187 registered. 1189 Experimental PVP methods starts with "x-" followed by a domain name 1190 owned by the entity describing this method, with the domain name 1191 reversed (e.g. "x-com.example.fingerprint"). Experimental methods 1192 can be used between domains, MAY BE registered, but implementers use 1193 them at their own risk. 1195 All other PVP methods MUST be registered based on the "specification 1196 required" option defined in [RFC2434], with the further stipulation 1197 that the "specification" is an RFC of any category. 1199 The defining RFC MUST clearly identify and describe, for each tag 1200 being registered: 1202 o Selectors: A list of name-values used to find the matching call 1203 record on the terminating side. 1204 o Selectors usage: A text describing how the selectors are 1205 processed on the terminating side, especially what to do when 1206 multiple call records match the selectors. 1207 o Parameters: A list of name-values that are used to guide the PVP 1208 processing. 1209 o Secret: The secret data that is used to verify that the VCRs on 1210 both side match. 1211 o Secret usage: A text describing how the secret data is generated, 1212 especially when one call record can generate multiple different 1213 secrets. 1214 o Priority: The priority assigned to this method which an unsigned 1215 integer between -32768 and +32767. The priority for a new method 1216 MUST be the median of the priority of the method that will be 1217 selected immediately before and the priority of the method that 1218 will be selected immediately after this method, using the minimum 1219 and maximum values if there no lower or higher methods. Multiple 1220 methods can share the same priority to mean that there is no 1221 specific order to try them. 1222 o Replacement: The name of an experimental method that this new 1223 method optionally replaces. An implementation supporting both the 1224 experimental and standard method and processing a VipRRegistration 1225 record containing both MUST NOT try the experimental method. The 1226 text MUST also indicates the date after which implementation will 1227 stop using the experimental method. 1228 o The entropy accumulated when this method succeeds. 1229 o Interoperability considerations. 1230 o Security considerations. 1231 o Privacy considerations. 1233 11.3. Initial PVP Method Registry 1235 IANA shall populate the initial PVP Method Registry with the 1236 following methods: 1238 +--------+---------+ 1239 | Method | RFC | 1240 +--------+---------+ 1241 | a | RFCXXXX | 1242 | b | RFCXXXX | 1243 +--------+---------+ 1245 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 1246 this specification.]] 1248 12. Acknowledgements 1250 Thanks to Patrice Bruno for his comments, suggestions and questions 1251 that helped to improve this document. 1253 This document was improved by the input from the VIPR Design Team: 1255 Mary Barnes 1256 Daryl Malas 1257 Hakim Mehmood 1258 Muthu Arul Mozhi Perumal 1259 Jon Peterson 1260 Marc Petit-Huguenin 1261 Michael Procter 1262 John Ward 1263 Dean Willis 1265 This document was written with the xml2rfc tool described in 1266 [RFC2629]. 1268 13. References 1270 13.1. Normative References 1272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1273 Requirement Levels", BCP 14, RFC 2119, March 1997. 1275 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1276 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1277 October 1998. 1279 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1280 Specifications: ABNF", RFC 4234, October 2005. 1282 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1283 "Using the Secure Remote Password (SRP) Protocol for TLS 1284 Authentication", RFC 5054, November 2007. 1286 [VIPR-OVERVIEW] 1287 Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 1288 Huguenin, "Verification Involving PSTN Reachability: 1289 Requirements and Architecture Overview", 1290 draft-jennings-vipr-overview-02 (work in progress), 1291 September 2011. 1293 [VIPR-VAP] 1294 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 1295 "Verification Involving PSTN Reachability: The ViPR Access 1296 Protocol (VAP)", draft-jennings-vipr-vap-02 (work in 1297 progress), March 2012. 1299 [VIPR-SIP-ANTISPAM] 1300 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, 1301 "Session Initiation Protocol (SIP) Extensions for Blocking 1302 VoIP Spam Using PSTN Validation", 1303 draft-petithuguenin-vipr-sip-antispam-03 (work in 1304 progress), January 2012. 1306 [VIPR-RELOAD-USAGE] 1307 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, "A 1308 Usage of Resource Location and Discovery (RELOAD) for 1309 Public Switched Telephone Network (PSTN) Verification", 1310 draft-petithuguenin-vipr-reload-usage-04 (work in 1311 progress), March 2012. 1313 13.2. Informative References 1315 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1316 June 1999. 1318 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 1319 RFC 2945, September 2000. 1321 [I-D.procter-vipr-privacy-concerns] 1322 Procter, M., "Privacy Concerns relating to the PSTN 1323 Validation Protocol (PVP)", 1324 draft-procter-vipr-privacy-concerns-00 (work in progress), 1325 October 2011. 1327 URIs 1329 [1] 1331 Appendix A. Release notes 1333 This section must be removed before publication as an RFC. 1335 A.1. Modifications between vipr-04 and vipr-03 1337 o Add entropy processing. 1338 o Private methods do not need the reversed domain. 1339 o Updated the BNF to permit experimental and private methods. 1341 o Updated the BNF to permit multiple characters, digits and "-" "." 1342 symbols in method names. 1343 o Added section in RFC defining a new method to migration mechanism 1344 between experimental and standard methods. 1345 o Added privacy section in RFC defining a new method. 1347 A.2. Modifications between vipr-03 and vipr-02 1349 o Added IANA registration sections. 1351 A.3. Modifications between vipr-02 and vipr-01 1353 o The Calling number is method "a" is now hashed with the bcrypt 1354 hash. 1356 A.4. Modifications between vipr-01 and vipr-00 1358 o Added text explaining that VCRs should not be removed before the 1359 end of the 48 hours delay. 1360 o Inserted Terminology section. 1361 o Fixed the timekey ABNF. 1362 o Specified that rounding-time cannot be equal to 0. 1364 A.5. Modifications between vipr-00 and dispatch-03 1366 o Moved to new Working Group. 1368 A.6. Modifications between dispatch-03 and dispatch-02 1370 o Nits. 1371 o Shorter I-Ds references. 1372 o Removed sentence saying that Tkey is converted to base64. 1373 o Added ValExchange method and Domain attribute definitions. 1374 o Fixed the last sentence of 7.2 - the ticket goes into the ticket 1375 element in the ServiceContent attribute. 1376 o Expanded first usage of VCR initialism. 1377 o Replaced any insteance of peerID by Node-ID. 1378 o Rewrote the ABNF. 1380 Authors' Addresses 1382 Marc Petit-Huguenin 1383 Unaffiliated 1385 Email: petithug@acm.org 1386 Jonathan Rosenberg 1387 jdrosen.net 1388 Monmouth, NJ 1389 US 1391 Email: jdrosen@jdrosen.net 1392 URI: http://www.jdrosen.net 1394 Cullen Jennings 1395 Cisco 1396 170 West Tasman Drive 1397 San Jose, CA 95134 1398 USA 1400 Phone: +1 408 421-9990 1401 Email: fluffy@cisco.com