idnits 2.17.00 (12 Aug 2021) /tmp/idnits14196/draft-ietf-stir-problem-statement-02.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 (January 13, 2014) is 3050 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 996, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1039, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '1') (Obsoleted by RFC 8224) -- Duplicate reference: RFC3261, mentioned in '3', was also mentioned in '2'. == Outdated reference: draft-ietf-straw-b2bua-loop-detection has been published as RFC 7332 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational H. Schulzrinne 5 Expires: July 17, 2014 Columbia University 6 H. Tschofenig 7 Nokia Siemens Networks 8 January 13, 2014 10 Secure Telephone Identity Problem Statement 11 draft-ietf-stir-problem-statement-02.txt 13 Abstract 15 Over the past decade, Voice over IP (VoIP) systems based on SIP have 16 replaced many traditional telephony deployments. Interworking VoIP 17 systems with the traditional telephone network has reduced the 18 overall security of calling party number and Caller ID assurances by 19 granting attackers new and inexpensive tools to impersonate or 20 obscure calling party numbers when orchestrating bulk commercial 21 calling schemes, hacking voicemail boxes or even circumventing multi- 22 factor authentication systems trusted by banks. Despite previous 23 attempts to provide a secure assurance of the origin of SIP 24 communications, we still lack of effective standards for identifying 25 the calling party in a VoIP session. This document examines the 26 reasons why providing identity for telephone numbers on the Internet 27 has proven so difficult, and shows how changes in the last decade may 28 provide us with new strategies for attaching a secure identity to SIP 29 sessions. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 17, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. VoIP-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 6 70 4.2. IP-PSTN-IP Call . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. PSTN-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 8 72 4.4. VoIP-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 9 73 4.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 10 74 4.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 11 75 5. Limitations of Current Solutions . . . . . . . . . . . . . . 11 76 5.1. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 12 77 5.2. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 14 78 5.3. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 6. Environmental Changes . . . . . . . . . . . . . . . . . . . . 19 80 6.1. Shift to Mobile Communication . . . . . . . . . . . . . . 19 81 6.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 19 82 6.3. Public Key Infrastructure Developments . . . . . . . . . 20 83 6.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 20 84 6.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 20 85 6.6. Relationship with Number Assignment and Management . . . 21 86 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 21 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 11. Informative References . . . . . . . . . . . . . . . . . . . 23 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 In many communication architectures that allow users to communicate 96 with other users, the need for identifying the originating party that 97 initiates a call or a messaging interaction arises. The desire for 98 identifying the communication parties in the end-to-end communication 99 attempt derives from the need to implement authorization policies (to 100 grant or reject call attempts) but has also been utilized for 101 charging. While there are a number of ways to enable identification 102 this functionality has been provided by the Session Initiation 103 Protocol (SIP) [2] by using two main types of approaches, namely 104 using P-Asserted-Identity (PAI) [5] and SIP Identity [1], which are 105 described in more detail in Section 5. The goal of these mechanisms 106 is to validate that originator of a call is authorized to claim an 107 originating identifier. Protocols, like XMPP, use mechanisms that 108 are conceptually similar to those offered by SIP. 110 Although solutions have been standardized, it turns out that the 111 current deployment situation is unsatisfactory and, even worse, there 112 is little indication that it will be improved in the future. In [11] 113 we illustrate what challenges arise. In particular, interworking 114 with different communication architectures (e.g., SIP, PSTN, XMPP, 115 RTCWeb) or other forms of mediation breaks the end-to-end semantic of 116 the communication interaction and destroys any identification 117 capabilities. Furthermore, the use of different identifiers (e.g., 118 E.164 numbers vs. SIP URIs) creates challenges for determining who is 119 able to claim "ownership" for a specific identifier; although domain- 120 based identifiers (sip:user@example.com) might use certificate or 121 DNS-related approaches to determine who is able to claim "ownership" 122 of the URI, telephone numbers do not yet have any similar mechanism 123 defined. 125 After the publication of the PAI and SIP Identity specifications 126 various further attempts have been made to tackle the topic but 127 unfortunately with little success. The complexity resides in the 128 deployment situation and the long list of (often conflicting) 129 requirements. A number of years have passed since the last attempts 130 were made to improve the situation and we therefore believe it is 131 time to give it another try. With this document we would like to 132 start an attempt to develop a common understanding of the problem 133 statement as well as requirements to develop a vision on how to 134 advance the state of the art and to initiate technical work to enable 135 secure call origin identification. 137 2. Problem Statement 139 In the classical public-switched telephone network, a limited number 140 of carriers trusted each other, without any cryptographic validation, 141 to provide accurate caller origination information. In some cases, 142 national telecommunication regulation codified these obligations. 143 This model worked as long as the number of entities was relatively 144 small, easily identified (e.g., through the concept of certificated 145 carriers) and subject to effective legal sanctions in case of 146 misbehavior. However, for some time, these assumptions have no 147 longer held true. For example, entities that are not traditional 148 telecommunication carriers, possibly located outside the country 149 whose country code they are using, can act as voice service 150 providers. While in the past, there was a clear distinction between 151 customers and service providers, VoIP service providers can now 152 easily act as customers, originating and transit providers. The 153 problem is moreover not limited to voice communications, as growth in 154 text messaging has made it another vector for bulk unsolicited 155 commercial messaging relying on impersonation of a source telephone 156 number (sometimes a short code). For telephony, Caller ID spoofing 157 has become common, with a small subset of entities either ignoring 158 abuse of their services or willingly serving to enable fraud and 159 other illegal behavior. 161 For example, recently, enterprises and public safety organizations 162 [17] have been subjected to telephony denial-of-service attacks. In 163 this case, an individual claiming to represent a collections company 164 for payday loans starts the extortion scheme with a phone call to an 165 organization. Failing to get payment from an individual or 166 organization, the criminal organization launches a barrage of phone 167 calls, with spoofed numbers, preventing the targeted organization 168 from receiving legitimate phone calls. Other boiler-room 169 organizations use number spoofing to place illegal "robocalls" 170 (automated telemarketing, see, for example, the FCC webpage [18] on 171 this topic). Robocalls is a problem that has been recognized already 172 by various regulators, for example the Federal Tde Commission (FTC) 173 recently organized a robocall competition to solicit ideas for 174 creating solutions that will block illegal robocalls [19]. Criminals 175 may also use number spoofing to impersonate banks or bank customers 176 to gain access to information or financial accounts. 178 In general, number spoofing is used in two ways, impersonation and 179 anonymization. For impersonation, the attacker pretends to be a 180 specific individual. Impersonation can be used for pretexting, where 181 the attacker obtains information about the individual impersonated, 182 activates credit cards or for harassment, e.g., by causing utility 183 services to be disconnected, take-out food to be delivered, or by 184 causing police to respond to a non-existing hostage situation 185 ("swatting", see [21]). Some voicemail systems can be set up so that 186 they grant access to stored messages without a password, relying 187 solely on the caller identity. As an example, the News International 188 phone-hacking scandal [20] has also gained a lot of press attention 189 where employees of the newspaper were accused of engaging in phone 190 hacking by utilizing Caller ID spoofing to get access to a voicemail. 191 For numbers where the caller has suppressed textual caller 192 identification, number spoofing can be used to retrieve this 193 information, stored in the so-called Calling Name (CNAM) database. 194 For anonymization, the caller does not necessarily care whether the 195 number is in service, or who it is assigned to, and may switch 196 rapidly and possibly randomly between numbers. Anonymization 197 facilitates automated illegal telemarketing or telephony denial-of- 198 service attacks, as described above, as it makes it difficult to 199 identify perpetators and craft policies to block them. It also makes 200 tracing such calls much more labor-intensive, as each such call has 201 to be identified in each transit carrier hop-by-hop, based on 202 destination number and time of call. 204 It is insufficient to simply outlaw all spoofing of originating 205 telephone numbers, because the entities spoofing numbers are already 206 committing other crimes and thus unlikely to be deterred by legal 207 sanctions. Secure origin identification should prevent impersonation 208 and, to a lesser extent, anonymization. However, if numbers are easy 209 and cheap to obtain, and if the organizations assigning identifiers 210 cannot or will not establish the true corporate or individual 211 identity of the entity requesting such identifiers, robocallers will 212 still be able to switch between many different identities. 214 The problem space is further complicated by a number of use cases 215 where entities in the telephone network legitimately send calls on 216 behalf of others, including "Find-Me/Follow-Me" services. 217 Ultimately, any SIP entity can receive an INVITE and forward it any 218 other entity, and the recipient of a forwarded message has little 219 means to ascertain which recipient a call should legitimately target. 220 Also, in some cases, third parties may need to temporarily use the 221 identity of another individual or organization, with full consent of 222 the "owner" of the identifier. For example: 224 The doctor's office: Physicians calling their patients using their 225 cell phones would like to replace their mobile phone number with 226 the number of their office to avoid being called back by patients 227 on their personal phone. 229 Call centers: Call centers operate on behalf of companies and the 230 called party expects to see the Caller ID of the company, not the 231 call center. 233 3. Terminology 235 The following terms are defined in this document: 237 In-band Identity Conveyance: In-band conveyance is the presence of 238 call origin identification information conveyed within the control 239 plane protocol(s) setting up a call. Any in-band solution must 240 accommodate prevalence of in-band intermdiaries such as B2BUAs. 242 Out-of-Band Identity Verification: Out-of-band verification 243 determines whether the telephone number used by the calling party 244 actually exists, whether the calling entity is entitled to use the 245 number and whether a call has recently been made from this phone 246 number. This approach is needed because the in-band technique 247 does not work in all cases, as when certain intermediaries are 248 involved or due to interworking with PSTN networks. 250 Authority Delegation Infrastructure: This functionality defines how 251 existing authority over telephone numbers are used in number 252 portability and delegation cases. It also describes how the 253 existing numbering infrastructure is re-used to maintain the 254 lifecycle of number assignments. 256 Canonical Telephone Number: In order for either in-band conveyance 257 or out-of-band verification to work, entities in this architecture 258 must be able to canonicalize telephone numbers to arrive at a 259 common syntactical form. 261 4. Use Cases 263 In order to explain the requirements and other design assumptions we 264 will explain some of the scenarios that need to be supported by any 265 solution. To reduce clutter, the figures do not show call routing 266 elements, such as SIP proxies, of voice or text service providers. 267 We generally assume that the PSTN component of any call path cannot 268 be altered. 270 4.1. VoIP-to-VoIP Call 272 For the IP-to-IP communication case, a group of service providers 273 that offer interconnected VoIP service exchange calls using SIP end- 274 to-end, but may also deliver some calls via circuit-switched 275 facilities, as described in separate use cases below. These service 276 providers use telephone numbers as source and destination 277 identifiers, either as the user component of a SIP URI (e.g., 278 sip:12125551234@example.com) or as a tel URI [8]. 280 As illustrated in Figure 1, if Alice calls Bob, the call will use SIP 281 end-to-end. (The call may or may not traverse the Internet.) 283 +------------+ 284 | IP-based | 285 | SIP Phone |<--+ 286 | of Bob | | 287 |+19175551234| | 288 +------------+ | 289 | 290 +------------+ | 291 | IP-based | | 292 | SIP Phone | ------------ 293 | of Alice | / | \ 294 |+12121234567| // | \\ 295 +------------+ // ,' \\\ 296 | /// / ----- 297 | //// ,' \\\\ 298 | / ,' \ 299 | | ,' | 300 +---->|......: IP-based | 301 | Network | 302 \ / 303 \\\\ //// 304 ------------------------- 306 Figure 1: VoIP-to-VoIP Call. 308 4.2. IP-PSTN-IP Call 310 Frequently, two VoIP-based service providers are not directly 311 connected by VoIP and use TDM circuits to exchange calls, leading to 312 the IP-PSTN-IP use case. In this use case, Dan's VSP is not a member 313 of the interconnect federation Alice's and Bob's VSP belongs to. As 314 far as Alice is concerned Dan is not accessible via IP and the PSTN 315 is used as an interconnection network. Figure 2 shows the resulting 316 exchange. 318 -------- 319 //// \\\\ 320 +--- >| PSTN | 321 | | | 322 | \\\\ //// 323 | -------- 324 | | 325 | | 326 | | 327 +------------+ +--+----+ | 328 | IP-based | | PSTN | | 329 | SIP Phone | --+ VoIP +- v 330 | of Alice | / | GW | \ +---+---+ 331 |+12121234567| // `''''''' \\| PSTN | 332 +------------+ // | \+ VoIP + 333 | /// | | GW |\ 334 | //// | `'''''''\\ +------------+ 335 | / | | \ | IP-based | 336 | | | | | | Phone | 337 +---->|---------------+ +------|---->| of Dan | 338 | | |+12039994321| 339 \ IP-based / +------------+ 340 \\\\ Network //// 341 ------------------------- 343 Figure 2: IP-PSTN-IP Call. 345 Note: A B2BUA/Session Border Controller (SBC) exhibits behavior that 346 looks similar to this scenario since the original call content would, 347 in the worst case, be re-created on the call origination side. 349 4.3. PSTN-to-VoIP Call 351 Consider Figure 3 where Carl is using a PSTN phone and initiates a 352 call to Alice. Alice is using a VoIP-based phone. The call of Carl 353 traverses the PSTN and enters the Internet via a PSTN/VoIP gateway. 354 This gateway attaches some identity information to the call, for 355 example based on the information it had received through the PSTN, if 356 available. 358 -------- 359 //// \\\\ 360 +->| PSTN |--+ 361 | | | | 362 | \\\\ //// | 363 | -------- | 364 | | 365 | v 366 | +----+-------+ 367 +---+------+ |PSTN / VoIP | +-----+ 368 |PSTN Phone| |Gateway | |SIP | 369 |of Carl | +----+-------+ |UA | 370 +----------+ | |Alice| 371 Invite +-----+ 372 | ^ 373 V | 374 +---------------+ Invite 375 |VoIP | | 376 |Interconnection| Invite +-------+ 377 |Provider(s) |----------->+ | 378 +---------------+ |Alice's| 379 |VSP | 380 | | 381 +-------+ 383 Figure 3: PSTN-to-VoIP Call. 385 4.4. VoIP-to-PSTN Call 387 Consider Figure 4 where Alice calls Carl. Carl uses a PSTN phone and 388 Alice an IP-based phone. When Alice initiates the call the E.164 389 number needs to get translated to a SIP URI and subsequently to an IP 390 address. The call of Alice traverses her VoIP provider where the 391 call origin identification information is added. It then hits the 392 PSTN/VoIP gateway. It is desirable that the gateway verify that 393 Alice can claim the E.164 number she is using before it populates the 394 corresponding calling party number field in telephone network 395 signaling. Carl's phone must be able to verify that it is receiving 396 a legitimate call from the calling party number it will render to 397 Carl. 399 +-------+ +-----+ -C 400 |PSTN | |SIP | |a 401 |Phone |<----------------+ |UA | |l 402 |of Carl| | |Alice| |l 403 +-------+ | +-----+ |i 404 --------------------------- | |n 405 //// \\\\ | |g 406 | PSTN | Invite | 407 | | | |P 408 \\\\ //// | |a 409 --------------------------- | |r 410 ^ | |t 411 | v |y 412 +------------+ +--------+| 413 |PSTN / VoIP |<--Invite----|VoIP ||D 414 |Gateway | |Service ||o 415 +------------+ |Provider||m 416 |of Alice||a 417 +--------+|i 418 -n 420 Figure 4: IP-to-PSTN Call. 422 4.5. PSTN-VoIP-PSTN Call 424 Consider Figure 5 where Carl calls Alice. Both users have PSTN 425 phones but interconnection between the two PSTN networks is 426 accomplished via an IP network. Consequently, Carl's operator uses a 427 PSTN-to-VoIP gateway to route the call via an IP network to a gateway 428 to break out into the PSTN again. 430 +----------+ 431 |PSTN Phone| 432 -------- |of Alice | 433 //// \\\\ +----------+ 434 +->| PSTN |------+ ^ 435 | | | | | 436 | \\\\ //// | | 437 | -------- | -------- 438 | v //// \\\\ 439 | ,-------+ | PSTN | 440 | |PSTN | | | 441 +---+------+ __|VoIP GW|_ \\\\ //// 442 |PSTN Phone| / '`''''''' \ -------- 443 |of Carl | // | \\ ^ 444 +----------+ // | \\\ | 445 /// -. Invite ----- | 446 //// `-. \\\\ | 447 / `.. \ | 448 | IP-based `._ ,--+----+ 449 | Network `.....>|VoIP | 450 | |PSTN GW| 451 \ '`''''''' 452 \\\\ //// 453 ------------------------- 455 Figure 5: PSTN-VoIP-PSTN Call. 457 4.6. PSTN-to-PSTN Call 459 For the "legacy" case of a PSTN-to-PSTN call, otherwise beyond 460 improvement, we may be able to use out-of-band IP connectivity at 461 both the originating and terminating carrier to validate the call 462 information. 464 5. Limitations of Current Solutions 466 From the inception of SIP, the From header field value has held an 467 arbitrary user-supplied identity, much like the From header field 468 value of an SMTP email message. During work on [2], efforts began to 469 provide a secure origin for SIP requests as an extension to SIP. The 470 so-called "short term" solution, the P-Asserted-Identity header 471 described in [5], is deployed fairly widely, even though it is 472 limited to closed trusted networks where end-user devices cannot 473 alter or inspect SIP messages and offers no cryptographic validation. 474 As P-Asserted-Identity is used increasingly across multiple networks, 475 it cannot offer any protection against identity spoofing by 476 intermediaries or entities that allow untrusted entities to set the P 477 -Asserted-Identity information. An overview of addressing spam in 478 SIP, and explaining how it differs from simiilar problems with email, 479 appeared in [9]. 481 Subsequent efforts to prevent calling origin identity spoofing in SIP 482 include the SIP Identity effort (the "long term" identity solution) 483 [1] and Verification Involving PSTN Reachability (VIPR) [15]. SIP 484 Identity attaches a new header field to SIP requests containing a 485 signature over the From header field value combined with other 486 message components to prevent replay attacks. SIP Identity is meant 487 both to prevent originating calls with spoofed From headers and 488 intermediaries, such as SIP proxies, from launching man-in-the-middle 489 attacks to alter calls passing through. The VIPR architecture 490 attacked a broader range of problems relating to spam, routing and 491 identity with a new infrastructure for managing rendezvous and 492 security, which operated alongside of SIP deployments. 494 As we will describe in more detail below, both SIP Identity and VIPR 495 suffer from serious limitations that have prevented their deployment 496 at significant scale, but they may still offer ideas and protocol 497 building blocks for a solution. 499 5.1. P-Asserted-Identity 501 The P-Asserted-Identity header field of SIP [5] provides a way for 502 trusted network entities to share with one another an authoritative 503 identifier for the originator of a call. The value of P-Asserted- 504 Identity cannot be populated by a user, though if a user wants to 505 suggest an identity to the trusted network, a separate header (P 506 -Preferred-Identity) enables them to do so. The features of the P 507 -Asserted-Identity header evolved as part of a broader effort to 508 reach parity with traditional telephone network signaling mechanisms 509 for selectively sharing and restricting presentation of the calling 510 party number at the user level, while still allowing core network 511 elements to know the identity of the user for abuse prevention and 512 accounting. 514 In order for P-Asserted-Identity to have these properties, it 515 requires the existence of a trust domain as described in [4]. Any 516 entity in the trust domain may add a P-Asserted-Identity header to a 517 SIP message, and any entity in the trust domain may forward a message 518 with a P-Asserted-Identity header to any other entity in the trust 519 domain. If a trusted entity forwards a SIP request to an untrusted 520 entity, however, the P-Asserted-Identity header must first be 521 removed; most sorts of end user devices are outside trust domains. 522 Sending a P-Asserted-Identity request to an untrusted entity could 523 leak potentially private information, such as the network-asserted 524 calling party number in a case where a caller has requested 525 presentation restriction. This concept of a trust domain is modeled 526 on the trusted network of devices that operate the traditional 527 telephone network. 529 P-Asserted-Identity has been very successful in telephone replacement 530 deployments of SIP. It is an extremely simple in-band mechanism, 531 requiring no cryptographic operations. Since it is so reminiscent of 532 legacy mechanisms in the traditional telephone network, and it 533 interworks so seamlessly with those protocols, it has naturally been 534 favored by providers comfortable with these operating principles. 536 In practice, a trust domain exhibits many of the same merits and 537 flaws as the traditional telephone network when it comes to securing 538 a calling party number. Any trusted entity may provide P-Asserted- 539 Identity, and a recipient of a SIP message has no direct assurance of 540 who generated the P-Asserted-Identity header field value: all trust 541 is transitive. Trust domains are dictated by business arrangements 542 more than by security standards, and thus the level of assurance of P 543 -Asserted-Identity is only as good as the least trustworthy member of 544 a trust domain. Since the contents of P-Asserted-Identity are not 545 intended for consumption by end users, end users must trust that 546 their service provider participates in an appropriate trust domain, 547 as there will be no direct evidence of the trust domain in SIP 548 signaling that end user devices receive. Since the mechanism is so 549 closely modeled on the traditional telephone network, it is unlikely 550 to provide a higher level of security than that. 552 Since [5] was written, the whole notion of P- headers intended for 553 use in private SIP domains has also been deprecated (see [10], 554 largely because of overwhelming evidence that these headers were 555 being used outside of private contexts and leaking into the public 556 Internet. It is unclear how many deployments that make use of P 557 -Asserted-Identity in fact conform with the Spec-T requirements of 558 RFC3324. 560 P-Asserted-Identity also complicates the question of which URI should 561 be presented to a user when a call is received. Per RFC3261, SIP 562 user agents would render the contents of the From header field to a 563 user when receiving an INVITE request, but what if the P-Asserted- 564 Identity contains a more trustworthy URI, and presentation is not 565 restricted? Subsequent proposals have suggested additional header 566 fields to carry different forms of identity related to the caller, 567 including billing identities. As the calling identities in a SIP 568 request proliferate, the question of how to select one to render to 569 the end user becomes more difficult to answer. 571 5.2. SIP Identity 573 The SIP Identity mechanism [1] provided two header fields for 574 securing identity information in SIP requests: the Identity and 575 Identity-Info header fields. Architecturally, the SIP Identity 576 mechanism assumes a classic "SIP trapezoid" deployment in which an 577 authentication service, acting on behalf of the originator of a SIP 578 request, attaches identity information to the request which provides 579 partial integrity protection; a verification service acting on behalf 580 of the recipient validates the integrity of the request when it is 581 received. 583 The Identity header field value contains a signature over a hash of 584 selected elements of a SIP request, including several header field 585 values (most significantly, the From header field value) and the 586 entirety of the body of the request. The set of header field values 587 was chosen specifically to prevent cut-and-paste attacks; it requires 588 the verification service to retain some state to guard against 589 replays. The signature over the body of a request has different 590 properties for different SIP methods, but all prevent tampering by 591 man-in-the-middle attacks. For a SIP MESSAGE request, for example, 592 the signature over the body covers the actual message conveyed by the 593 request: it is pointless to guarantee the source of a request if a 594 man-in-the-middle can change the content of the message, as in that 595 case the message content is created by an attacker. Similar threats 596 exist against the SIP NOTIFY method. For a SIP INVITE request, a 597 signature over the SDP body is intended to prevent a man-in-the- 598 middle from changing properties of the media stream, including the IP 599 address and port to which media should be sent, as this provides a 600 means for the man-in-the-middle to direct session media to resource 601 that the originator did not specify, and thus to impersonate an 602 intended listener. 604 The Identity-Info header field value contains a URI designating the 605 location of the certificate corresponding to the private key that 606 signed the hash in the Identity header. That certificate could be 607 passed by-value along with the SIP request, in which case a "cid" URI 608 appears in Identity-Info, or by-reference, for example when the 609 Identity-Info header field value has the URL of a service that 610 delivers the certificate. [1] imposes further constraints governing 611 the subject of that certificate: namely, that it must cover the 612 domain name indicated in the domain component of the URI in the From 613 header field value of the request. 615 The SIP Identity mechanism, however, has two fundamental limitations 616 that have precluded its deployment: first, that it provides Identity 617 only for domain names rather than other identifiers; second, that it 618 does not tolerate intermediaries that alter the bodies, or certain 619 header fields, of SIP requests. 621 As deployed, SIP predominantly mimics the structures of the telephone 622 network, and thus uses telephone numbers as identifiers. Telephone 623 numbers in the From header field value of a SIP request may appear as 624 the user part of a SIP URI, or alternatively in an independent tel 625 URI. The certificate designated by the Identity-Info header field as 626 specified, however, corresponds only to the domain portion of a SIP 627 URI in the From header field. As such, [1] does not have any 628 provision to identify the assignee of a telephone number. While it 629 could be the case that the domain name portion of a SIP URI signifies 630 a carrier (like "att.com") to whom numbers are assigned, the SIP 631 Identity mechanism provides no assurance that a number is assigned to 632 any carrier. For a tel URI, moreover, it is unclear in [1] what 633 entity should hold a corresponding certificate. A caller may not 634 want to reveal the identity of its service provider to the callee, 635 and may thus prefer tel URIs in the From header field. 637 This lack of authority gives rise to a whole class of SIP identity 638 problems when dealing with telephone numbers, as is explored in [13]. 639 That document shows how the Identity header of a SIP request 640 targeting a telephone number (embedded in a SIP URI) could be dropped 641 by an intermediate domain, which then modifies and resigns the 642 request, all without alerting the verification service: the 643 verification service has no way of knowing which original domain 644 signed the request. Provided that the local authentication service 645 is complicit, an originator can claim virtually any telephone number, 646 impersonating any chosen Caller ID from the perspective of the 647 verifier. Both of these attacks are rooted in the inability of the 648 verification service to ascertain a specific certificate that is 649 authoritative for a telephone number. 651 As deployed, SIP is moreover highly mediated, and mediated in ways 652 that [2] did not anticipate. As request routing commonly depends on 653 policies dissimilar to [16], requests transit multiple intermediate 654 domains to reach a destination; some forms of intermediaries in those 655 domains may effectively re-initiate the session. 657 One of the main reasons that SIP deployments mimic the PSTN 658 architecture is because the requirement for interconnection with the 659 PSTN remains paramount: a call may originate in SIP and terminate on 660 the PSTN, or vice versa; and worse still, a PSTN-to-PSTN call may 661 transit a SIP network in the middle, or vice versa. This necessarily 662 reduces SIP's feature set to the least common dominator of the 663 telephone network, and mandates support for telephone numbers as a 664 primary calling identifier. 666 Interworking with non-SIP networks makes end-to-end identity 667 problematic. When a PSTN gateway sends a call to a SIP network, it 668 creates the INVITE request anew, regardless of whether a previous leg 669 of the call originated in a SIP network that later dropped the call 670 to the PSTN. As these gateways are not necessarily operated by 671 entities that have any relationship to the number assignee, it is 672 unclear how they could provide an identity signature that a verifier 673 should trust. Moreover, how could the gateway know that the calling 674 party number it receives from the PSTN is actually authentic? And 675 when a gateway receives a call via SIP and terminates a call to the 676 PSTN, how can that gateway verify that a telephone number in the From 677 header field value is authentic, before it presents that number as 678 the calling party number in the PSTN? 680 Similarly, some SIP networks deploy intermediaries that act as back- 681 to-back user agents (B2BUAs), typically in order to provide policy or 682 interworking functions at network boundaries (hence the nickname 683 "Session Border Controller"). These functions range from topology 684 hiding, to alterations necessary to interoperate successfully with 685 particular SIP implementations, to simple network address translation 686 from private address space. To achieve these aims, these entities 687 modify SIP INVITE requests in transit, potentially changing the From, 688 Contact and Call-ID header field values, as well as aspects of the 689 SDP, including especially the IP addresses and ports associated with 690 media. Consequently, a SIP request exiting a B2BUA has no necessary 691 relationship to the original request received by the B2BUA, much like 692 a request exiting a PSTN gateway has no necessary relationship to any 693 SIP request in a pre-PSTN leg of the call. An Identity signature 694 provided for the original INVITE has no bearing on the post-B2BUA 695 INVITE, and, were the B2BUA to preserve the original Identity header, 696 any verification service would detect a violation of the integrity 697 protection. 699 The SIP community has long been aware of these problems with [1] in 700 practical deployments. Some have therefore proposed weakening the 701 security constraints of [1] so that at least some deployments of 702 B2BUAs will be compatible with integrity protection of SIP requests. 703 However, such solutions do not address one key problem identified 704 above: the lack of any clear authority for telephone numbers, and the 705 fact that some INVITE requests are generated by intermediaries rather 706 than endpoints. Removing the signature over the SDP from the 707 Identity header will not, for example, make it any clearer how a PSTN 708 gateway should assert identity in an INVITE request. 710 5.3. VIPR 712 Verification Involving PSTN Reachability (VIPR) directly attacks the 713 twin problems of identifying number assignees on the Internet and 714 coping with intermediaries that may modify signaling. To address the 715 first problem, VIPR relies on the PSTN itself: it discovers which 716 endpoints on the Internet are reachable via a particular PSTN number 717 by calling the number on the PSTN to determine whom a call to that 718 number will reach. As VIPR-enabled Internet endpoints associated 719 with PSTN numbers are discovered, VIPR provides a rendez-vous service 720 that allows the endpoints of a call to form an out-of-band connection 721 over the Internet; this connection allows the endpoints to exchange 722 information that secures future communications and permits direct, 723 unmediated SIP connections. 725 VIPR provides these services within a fairly narrow scope of 726 applicability. Its seminal use case is the enterprise IP PBX, a 727 device that has both PSTN connectivity and Internet connectivity, 728 which serves a set of local users with telephone numbers; after a 729 PSTN call has connected successfully and then ended, the PBX searches 730 a distributed hash-table to see if any VIPR-compatible devices have 731 advertised themselves as a route for the unfamiliar number on the 732 Internet. If advertisements exist, the originating PBX then 733 initiates a verification process to determine whether the entity 734 claiming to be the assignee of the unfamiliar number in fact received 735 the successful call: this involves verifying details such as the 736 start and stop times of the call. If the destination verifies 737 successfully, the originating PBX provisions a local database with a 738 route for that telephone number to the URI provided by the proven 739 destination. The destination moreover gives a token to the 740 originator that can be inserted in future call setup messages to 741 authenticate the source of future communications. 743 Through this mechanism, the VIPR system provides a suite of 744 properties, ones that go well beyond merely securing the origins of 745 communications. It also provides a routing system which dynamically 746 discovers mappings between telephone numbers and URIs, effectively 747 building an ad hoc ENUM database in every VIPR implementation. The 748 tokens exchanged over the out-of-band connection established by VIPR 749 moreover provide an authorization mechanism for accepting calls over 750 the Internet that significantly reduces the potential for spam. 751 Because the token can act as a nonce due to the presence of this out- 752 of-band connectivity, the VIPR token is less susceptible to cut-and- 753 paste attacks and thus needs to cover with its signature far less of 754 a SIP request. 756 Due to its narrow scope of applicability, and the details of its 757 implementation, VIPR has some significant limitations. The most 758 salient for the purposes of this document is that it only has bearing 759 on repeated communications between entities: it has no solution to 760 the classic "robocall" problem, where the target typically receives a 761 call from a number that has never called before. All of VIPR's 762 strengths in establishing identity and spam prevention kick in only 763 after an initial PSTN call has been completed, and subsequent 764 attempts at communication begin. Every VIPR-compliant entity 765 moreover maintains its own stateful database of previous contacts and 766 authorizations, which lends itself to more aggregators like IP PBXs 767 that may front for thousands of users than to individual phones. 768 That database must be refreshed by periodic PSTN calls to determine 769 that control over the number has not shifted to some other entity; 770 figuring out when data has grown stale is one the challenges of the 771 architecture. As VIPR requires compliant implementations to operate 772 both a PSTN interface and an IP interface, it has little apparent 773 applicability to ordinary desktop PCs or similar devices with no 774 ability to place direct PSTN calls. 776 The distributed hash table also creates a new attack surface for 777 impersonation. Attackers who want to pose as the owners of telephone 778 numbers can advertise themselves as routes to a number in the hash 779 table. VIPR has no inherent restriction on the number of entities 780 that may advertise themselves as routes for a number, and thus an 781 originator may find multiple advertisements for a number on the DHT 782 even when an attack is not in progress. As for attackers, even if 783 they cannot successfully verify themselves to the originators of 784 calls (because they lack the call detail information), they may learn 785 from those verification attempts which VIPR entities recently placed 786 calls to the target number: it may be that this information is all 787 the attacker hopes to glean. The fact that advertisements and 788 verifications are public results from the public nature of the DHT 789 that VIPR creates. The public DHT prevents any centralized control, 790 or attempts to impede communications, but those come at the cost of 791 apparently unavoidable privacy losses. 793 Because of these limitations, VIPR, much like SIP Identity, has had 794 little impact in the marketplace. Ultimately, VIPR's utility as an 795 identity mechanism is limited by its reliance on the PSTN, especially 796 its need for an initial PSTN call to complete before any of VIPR's 797 benefits can be realized, and by the drawbacks of the highly-public 798 exchanges requires to create the out-of-band connection between VIPR 799 entities. As such, there is no obvious solution to providing secure 800 origin services for SIP on the Internet today. 802 6. Environmental Changes 804 6.1. Shift to Mobile Communication 806 In the years since [1] was conceived, there have been a number of 807 fundamental shifts in the communications marketplace. The most 808 transformative has been the precipitous rise of mobile smart phones, 809 which are now arguably the dominant communications device in the 810 developed world. Smart phones have both a PSTN and an IP interface, 811 as well as an SMS and MMS capabilities. This suite of tools suggests 812 that some of the techniques proposed by VIPR could be adapted to the 813 smart phone environment. The installed base of smart phones is 814 moreover highly upgradable, and permits rapid adoption out-of-band 815 rendezvous services for smart phones that circumvent the PSTN. 816 Mobile messaging services that use telephone numbers as identities 817 allow smart phone users to send text messages to one another over the 818 Internet rather than over the PSTN. Like VIPR, such services create 819 an out-of-band connection over the Internet between smart phones; 820 unlike VIPR, the rendezvous service is provided by a trusted 821 centralized database rather than by a DHT, and it is the centralized 822 database that effectively verifies and asserts the telephone number 823 of the sender of a message. While such messaging services are 824 specific to the users of the specific service, it seems clear that 825 similar databases could be provided by neutral third parties in a 826 position to coordinate between endpoints. 828 6.2. Failure of Public ENUM 830 At the time [1] was written, the hopes for establishing a certificate 831 authority for telephone numbers on the Internet largely rested on 832 public ENUM deployment. The e164.arpa DNS tree established for ENUM 833 could have grown to include certificates for telephone numbers or at 834 least for number ranges. It is now clear however that public ENUM as 835 originally envisioned has little prospect for adoption. That said, 836 some national authorities for telephone numbers are migrating their 837 provisioning services to the Internet, and issuing credentials that 838 express authority for telephone numbers to secure those services. 839 These new authorities for numbers could provide to the public 840 Internet the necessary signatory authority for securing calling 841 partys' numbers. While these systems are far from universal, the 842 authors of this draft believe that a solution devised for the North 843 American Numbering Plan could have applicability to other country 844 codes. 846 6.3. Public Key Infrastructure Developments 848 Also, there have been a number of recent high-profile compromises of 849 web certificate authorities. The presence of numerous (in some 850 cases, of hundreds) of trusted certificate authorities in modern web 851 browsers has become a significant security liability. As [1] relied 852 on web certificate authorities, this too provides new lessons for any 853 work on revising [1]: namely, that innovations like DANE [6] that 854 designate a specific certificate preferred by the owner of a DNS name 855 could greatly improve the security of a SIP identity mechanism; and 856 moreover, that when architecting new certificate authorities for 857 telephone numbers, we should be wary of excessive pluralism. While a 858 chain of delegation with a progressively narrowing scope of authority 859 (e.g., from a regulatory entity to a carrier to a reseller to an end 860 user) is needed to reflect operational practices, there is no need to 861 have multiple roots, or peer entities that both claim authority for 862 the same telephone number or number range. 864 6.4. Pervasive Nature of B2BUA Deployments 866 Given the prevalence of established B2BUA deployments, we may have a 867 further opportunity to review the elements signed by [1] and to 868 decide on the value of alternative signature mechanisms. Separating 869 the elements necessary for (a) securing the From header field value 870 and preventing replays, from (b) the elements necessary to prevent 871 men-in-the-middle from tampering with messages, may also yield a 872 strategy for identity that will be practicable in some highly 873 mediated networks. Solutions in this space must however remain 874 mindful of the requirements for securing cryptographic material 875 necessary to support DTLS-SRTP or future security mechanisms. 877 6.5. Stickiness of Deployed Infrastructure 879 One thing that has not changed, and is not likely to change in the 880 future, is the transitive nature of trust in the PSTN. When a call 881 from the PSTN arrives at a SIP gateway with a calling party number, 882 the gateway will have little chance of determining whether the 883 originator of the call was authorized to claim that calling party 884 number. Due to roaming and countless other factors, calls on the 885 PSTN may emerge from administrative domains that were not assigned 886 the originating number. This use case will remain the most difficult 887 to tackle for an identity system, and may prove beyond repair. It 888 does however seem that with the changes in the solution space, and a 889 better understanding of the limits of [1] and VIPR, we are today in a 890 position to reexamine the problem space and find solutions that can 891 have a significant impact on the secure origins problem. 893 6.6. Relationship with Number Assignment and Management 895 Currently, telephone numbers are typically managed in a loose 896 delegation hierarchy. For example, a national regulatory agency may 897 task a private, neutral entity with administering numbering 898 resources, such as area codes, and a similar entity with assigning 899 number blocks to carriers and other authorized entities, who in turn 900 then assign numbers to customers. Resellers with looser regulatory 901 obligations can complicate the picture, and in many cases it is 902 difficult to distinguish the roles of enterprises from carriers. In 903 many countries, individual numbers are portable between carriers, at 904 least within the same technology (e.g., wireline-to-wireline). 905 Separate databases manage the mapping of numbers to switch 906 identifiers, companies and textual caller ID information. 908 As the PSTN transitions to using VoIP technologies, new assignment 909 policies and management mechanisms are likely to emerge. For 910 example, it has been proposed that geography could play a smaller 911 role in number assignments, and that individual numbers are assigned 912 to end users directly rather than only to service providers, or that 913 the assignment of numbers does not depend on providing actual call 914 delivery services. 916 Databases today already map telephone numbers to entities that have 917 been assigned the number, e.g., through the LERG (originally, Local 918 Exchange Routing Guide) in the United States. Thus, the transition 919 to IP-based networks may offer an opportunity to integrate 920 cryptographic bindings between numbers or number ranges and service 921 providers into databases. 923 7. Requirements 925 This section describes the high level requirements of the effort: 927 Generation: Intermediaries as well as end system must be able to 928 generate the source identity information. 930 Validation: Intermediaries as well as end system must be able to 931 validate the source identity information. 933 Usability: Any validation mechanism must work without human 934 intervention, e.g., CAPTCHA-like mechanisms. 936 Deployability: Must survive transition of the call to the PSTN and 937 the presence of B2BUAs. 939 Reflecting existing authority: Must stage credentials on existing 940 national-level number delegations, without assuming the need for 941 an international golden root on the Internet. 943 Accommodating current practices: Must allow number portability among 944 carriers and must support legitimate usage of number spoofing 945 (doctor's office and call centers) 947 Minimal payload overhead: Must lead to minimal expansion of SIP 948 headers fields to avoid fragmentation in deployments that use UDP. 950 Efficiency: Must minimize RTTs for any network lookups and minimize 951 any necessary cryptographic operations. 953 Privacy: Any out-of-band validation protocol must not allows third 954 parties to learn what numbers have been called by a specific 955 caller. 957 Some requirements specifically outside the scope of the effort 958 include: 960 Display name: This effort does not consider how the display name of 961 the caller might be validated. 963 Response authentication: This effort only considers the problem of 964 providing secure telephone identity for requests, not for 965 responses to requests; no solution is here proposed for the 966 problem of determining to which number a call has connected. 968 8. Acknowledgments 970 We would like to thank Fernando Mousinho, David Frankel, Penn Pfautz, 971 Mike Hammer, Dan York, Andrew Allen, Philippe Fouquart, Hadriel 972 Kaplan, Richard Shockey, Russ Housley, Alissa Cooper, Bernard Aboba, 973 Sean Turner, Brian Rosen, Eric Burger, and Eric Rescorla for their 974 discussion input that lead to this document. 976 9. IANA Considerations 978 This memo includes no request to IANA. 980 10. Security Considerations 982 This document is about improving the security of call origin 983 identification. 985 11. Informative References 987 [1] Peterson, J. and C. Jennings, "Enhancements for 988 Authenticated Identity Management in the Session 989 Initiation Protocol (SIP)", RFC 4474, August 2006. 991 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 992 A., Peterson, J., Sparks, R., Handley, M., and E. 993 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 994 June 2002. 996 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 997 A., Peterson, J., Sparks, R., Handley, M., and E. 998 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 999 June 2002. 1001 [4] Watson, M., "Short Term Requirements for Network Asserted 1002 Identity", RFC 3324, November 2002. 1004 [5] Jennings, C., Peterson, J., and M. Watson, "Private 1005 Extensions to the Session Initiation Protocol (SIP) for 1006 Asserted Identity within Trusted Networks", RFC 3325, 1007 November 2002. 1009 [6] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1010 of Named Entities (DANE) Transport Layer Security (TLS) 1011 Protocol: TLSA", RFC 6698, August 2012. 1013 [7] Elwell, J., "Connected Identity in the Session Initiation 1014 Protocol (SIP)", RFC 4916, June 2007. 1016 [8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 1017 3966, December 2004. 1019 [9] Rosenberg, J. and C. Jennings, "The Session Initiation 1020 Protocol (SIP) and Spam", RFC 5039, January 2008. 1022 [10] Peterson, J., Jennings, C., and R. Sparks, "Change Process 1023 for the Session Initiation Protocol (SIP) and the Real- 1024 time Applications and Infrastructure Area", BCP 67, RFC 1025 5727, March 2010. 1027 [11] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, 1028 "Secure Call Origin Identification", draft-cooper-iab- 1029 secure-origin-00 (work in progress), November 2012. 1031 [12] Peterson, J., "Retargeting and Security in SIP: A 1032 Framework and Requirements", draft-peterson-sipping- 1033 retarget-00 (work in progress), February 2005. 1035 [13] Rosenberg, J., "Concerns around the Applicability of RFC 1036 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 1037 progress), February 2008. 1039 [14] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for 1040 Session Initiation Protocol (SIP) Back-to- Back User 1041 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-03 1042 (work in progress), December 2013. 1044 [15] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 1045 Huguenin, "Verification Involving PSTN Reachability: 1046 Requirements and Architecture Overview", draft-jennings- 1047 vipr-overview-06 (work in progress), December 2013. 1049 [16] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1050 Protocol (SIP): Locating SIP Servers", RFC 3263, June 1051 2002. 1053 [17] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on 1054 Public Emergency Networks", URL: 1055 http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos- 1056 extortion-attacks-on-public-emergency-networks/, Apr 2013. 1058 [18] FCC, , "Robocalls", URL: 1059 http://www.fcc.gov/guides/robocalls, Apr 2013. 1061 [19] FTC, , "FTC Robocall Challenge", URL: 1062 http://robocall.challenge.gov/, Apr 2013. 1064 [20] Wikipedia, , "News International phone hacking scandal", 1065 URL: http://en.wikipedia.org/wiki/ 1066 News_International_phone_hacking_scandal, Apr 2013. 1068 [21] Wikipedia, , "Don't Make the Call: The New Phenomenon of 1069 'Swatting'", URL: http://www.fbi.gov/news/stories/2008/ 1070 february/swatting020408, Feb 2008. 1072 Authors' Addresses 1073 Jon Peterson 1074 Neustar, Inc. 1075 1800 Sutter St Suite 570 1076 Concord, CA 94520 1077 US 1079 Email: jon.peterson@neustar.biz 1081 Henning Schulzrinne 1082 Columbia University 1083 Department of Computer Science 1084 450 Computer Science Building 1085 New York, NY 10027 1086 US 1088 Phone: +1 212 939 7004 1089 Email: hgs+ecrit@cs.columbia.edu 1090 URI: http://www.cs.columbia.edu 1092 Hannes Tschofenig 1093 Nokia Siemens Networks 1094 Linnoitustie 6 1095 Espoo 02600 1096 Finland 1098 Phone: +358 (50) 4871445 1099 Email: Hannes.Tschofenig@gmx.net 1100 URI: http://www.tschofenig.priv.at