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