idnits 2.17.00 (12 Aug 2021) /tmp/idnits59200/draft-schwartz-sip-e164-ownership-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 493. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5205 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '4' is defined on line 371, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 378, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 408, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4474 (ref. '3') (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 4871 (ref. '4') (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 3761 (ref. '6') (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-01) exists of draft-elwell-sip-e164-problem-statement-00 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-03 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP D. Schwartz 3 Internet-Draft XConnect 4 Intended status: Informational H. Kaplan 5 Expires: August 21, 2008 Acme Packet 6 K. Darilion 7 enum.at 8 H. Tschofenig 9 Nokia Siemens Networks 10 February 18, 2008 12 E.164 Ownership Problem Statement 13 draft-schwartz-sip-e164-ownership-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 21, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 When a call travels end-to-end relayed from the PSTN to SIP then 47 problems occur with E.164 number ownership. Additionally, there are 48 security challenges when the PSTN-VoIP gateway has to authenticate 49 and authorize the calling party. Without addressing these two 50 aspects the overall security story is weak or non-existent. This 51 document aims to investigate these two aspect; it does, however, not 52 investigate current E.164 number handling with RFC 4474 ("SIP 53 Identity"). Such an analysis is provided by other documents already. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The End-to-End Picture . . . . . . . . . . . . . . . . . . . . 3 63 4. Authenticating and Authorizing the Calling Party Identity . . 5 65 5. Verifying Ownership: What does it mean? . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 10.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 Intellectual Property and Copyright Statements . . . . . . . . . . 11 82 1. Introduction 84 RFC 4474 [3] defines a mechanism whereby an authentication service 85 asserts the identity of a SIP UAC and determines whether he or she is 86 authorized to use that identity. The authentication service then 87 computes a hash over some particular headers, including the From 88 header field and the bodies in the message. This hash is signed with 89 the certificate for the domain and inserted in the 'Identity' header 90 field in the SIP message. The proxy also inserts a companion header 91 field, Identity-Info, that tells the verifying party how to acquire 92 its certificate, in case it is not yet known already. 94 When the verifier receives the SIP message, it verifies the signature 95 provided in the Identity header, and thus can determine whether the 96 domain indicated by the host portion of the AoR in the From header 97 field authenticated the user, and permitted the user to assert that 98 From header field value. 100 The use of phone numbers with SIP was introduced with the TEL URL 101 scheme [5] whereby domain names were not used with the phone numbers. 102 SIP URIs always have domain names. In SIP [2], a translation between 103 SIP URIs and TEL URLs is described: when translating from a SIP URI 104 to a TEL URL, the domain name from the SIP URI is simply dropped. 105 When translating in the other direction (or simply generating a SIP 106 URI from an E.164 number [13]) it is not clear how to populate the 107 domain name. 109 When SIP Identity [3] is applied to E.164 numbers then there is the 110 question what the identity assertion actually means. Additionally, 111 the usage of the domain for an E.164 number causes problems, as 112 described in [7]. This document will, however, not focus on this 113 aspect. Instead, we investigate the overall end-to-end security 114 story and the ownership problem for E.164 numbers. 116 2. Terminology 118 In this document, several words are used to signify the requirements 119 of the specification. These words are often capitalized. The key 120 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 121 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 122 are to be interpreted as described in [1]. 124 3. The End-to-End Picture 126 Consider Figure 1 where two end points, Bob and Joe, initiate calls 127 to Alice. Alice is using an IP-based phone and the same is true for 128 Joe. The call of Joe and Bob towards Alice traverse the PSTN; Bob is 129 using a PSTN phone and the call enters the Internet via a PSTN/VoIP 130 gateway. Joe's call traverses the PSTN, for example, because Joe's 131 VoIP provider does not have a peering agreement with the called party 132 domain and uses the PSTN as a way to interconnect VoIP networks. 133 This is a common way of interacting between VoIP providers today. 135 -------- 136 //// \\\\ 137 +->| PSTN |--+ 138 | | | | 139 | \\\\ //// | 140 | -------- | 141 | ^ | 142 | | v 143 | | +----+-------+ 144 +---+------+ | |PSTN / VoIP | +-----+ 145 |PSTN Phone| | |Gateway | |SIP | 146 |of Bob | | +----+-------+ |UA | 147 +----------+ | | |Alice| 148 | Invite +-----+ 149 | | ^ 150 | V | 151 +----------+-+ +-------------+ Invite 152 |VoIP / PSTN | |VoIP | | 153 |Gateway | |Service | Invite +-------+ 154 +----------+-+ |Provider(s) |----------->+ | 155 ^ +-------------+ | | 156 | |Verif. | 157 | |Service| 158 +---------+ | | | 159 |IP-based | | +-------+ 160 |SIP Phone| | |---------| 161 |of Joe | | called 162 +---------+ | party 163 | | domain 164 | ----- 165 | //// \\\\ 166 | / \ 167 | | | 168 +---->| IP-based | 169 | Network | 170 \ / 171 \\\\ //// 172 ----- 174 Figure 1: PSTN to SIP Communication 176 Figure 1 raises two important questions: 178 1. How does the authentication service (for example an entity that 179 is co-located with the PSTN/VoIP gateway) authenticate and 180 authorize the calling party? 181 2. How does the verification service determine ownership of an E.164 182 number? 184 Section 4 investigates the first question in more detail whereas 185 Section 5 addresses the second question. 187 4. Authenticating and Authorizing the Calling Party Identity 189 RFC 4474 rightfully makes some important assumptions about the 190 behavior of the authentication service that contribute significantly 191 to the security of the overall system. While some assumptions seem 192 to be obvious for SIP usage, they are less obvious when considering 193 them in relationship with a PSTN interworking. Section 4 of [3] 194 says: 196 "The authentication service authenticates Alice (possibly by 197 sending a Digest authentication challenge) and validates that she 198 is authorized to assert the identity that is populated in the From 199 header field. This value may be Alice's AoR, or it may be some 200 other value that the policy of the proxy server permits her to 201 use. 203 ... 205 The proxy, as the holder of the private key of its domain, is 206 asserting that the originator of this request has been 207 authenticated and that she is authorized to claim the identity 208 (the SIP address- of-record) that appears in the From header 209 field. " 211 The crutial question therefore is: In the generic case is the 212 authentication service able to authenticate the caller-ID used in the 213 PSTN and to authorize it's usage? 215 There are problems with this step: 217 1. The PSTN builds on a walled garden with a chain-of-trust security 218 model. This is "nice" as long as the participating parties are 219 indeed honest. Unfortunately, this is not true anymore (and has 220 not been the case for a long time already) [add-references-to- 221 examples]. Caller-ID spoofing is common and even transit 222 providers are not trustworthy either. 224 2. A call originated on the PSTN is often times routed to a PSTN/ 225 VoIP gateway. That PSTN gateway is operated by the owner of the 226 called number, rather than the owner of the calling number. 228 5. Verifying Ownership: What does it mean? 230 Imagine a verification service at Alice's VoIP provider network 231 receives a SIP message with an 'Identity' and an 'Identity-Info' 232 header. 234 How would this verification service determine whether the signer of 235 the message is indeed authorized to claim ownership? 237 Ownership is an artificial construct but one could compare it with an 238 oracle that returns the name of a domain when asked who is 239 authoritative for using a particular E.164 number. 241 There are various owership verification steps that got used in the 242 IETF within other protocols. RFC 4474 [3], for example, uses the 243 following verification step for SIP URIs: 245 "6. Verifier Behavior 247 Step 2: 249 The verifier MUST follow the process described in Section 13.4 to 250 determine if the signer is authoritative for the URI in the From 251 header field. 253 13.4. Domain Names and Subordination 255 When a verifier processes a request containing an Identity-Info 256 header, it must compare the domain portion of the URI in the From 257 header field of the request with the domain name that is the 258 subject of the certificate acquired from the Identity-Info 259 header." 261 This is a concept of referential integrity where information of the 262 protocol (in this case the identity) is matched against information 263 from the certificate. Still, the signer and the verifier need to 264 have a trust anchor in common. There are additional aspects about 265 the detailed matching procedure that are described in Section 13.4 of 266 [3]. 268 Unfortunately, this simple authorization check cannot be used with 269 E.164 numbers because of the missing domain concept in the identifier 270 itself and because of number portability. 272 A couple of other ownership approaches have been used in IETF 273 protocols. A few examples below: 275 Return Routability Check: A form of check is to exploit the 276 topological properties of identifier routing and the possible 277 placements of adversaries with respect to a certain message 278 interaction. RRT and various other forms fall into that category. 279 An example can be found in [9]. 281 Authorization Certificates: 283 A form of check is to use authorization certificates. The basic 284 idea is that one would trust the entity that creates the 285 authorization certificate (most likely in a hierarchical form) 286 then you also trust its content. SIP-SAML (see [8]) and [12] 287 belong to this category. When the identity of the certificate is 288 constructed in a suitable way then together with a delegated 289 signing the same effect could be accomplished. 291 Distributed Databases: 293 Another form of mechanism is to use an out-of-band database 294 lookup, for example using the DNS, in order to verify that the 295 entity which uses the private key for creating the SIP Identity 296 header is authorized to attach the corresponding public key to the 297 this distributed database. The identity would be used for the 298 lookup to the database and the security of the system relies on 299 ensuring that only those entities add the public key that are also 300 owner of the corresponding E.164 number. An example of such an 301 approach can be found in [15]. The usage of TRIP [11] (with 302 extensions with information about E.164 numbers that are 303 authorized for usage by a specific provider) has been discussed as 304 well. 306 Cryptographic Addresses and Hash Chains: 308 These mechanisms utilize a temporal property by creating a binding 309 between the public key (or values from a hash chain) and the 310 identity be verified by re-computing the hash value and by 311 comparing the hash with the identifier. These mechanisms have 312 found some excitment with protocol work at lower layers (see, for 313 example, [10]). 315 It is quite obvious that each mechanism has different scalability, 316 security and deployment properties. 318 6. Security Considerations 320 With the work on this subject it is important to keep two quotes in 321 mind: 323 o "The security of a system is as good as the weakest link." 324 o "If you think cryptography is the solution to your problem, you 325 don't know what your problem is." --- Roger Needham 327 We are still in an early phase to properly understand the problem 328 domain even though there are a couple of TECHNICAL solution proposals 329 available to address the ownership question. These technical 330 approaches do, however, not help when there is no deployment 331 incentives. These approaches also do not help with the security of 332 the overall system when the identity of the calling party cannot be 333 verified by the authentication service. 335 As such, it is too early to conclusively argue that an RFC 4474 alike 336 authentication service should actually attempt to offer a solution 337 for E.164 numbers even though they are heavily used in today's 338 networks. 340 7. Contributors 342 We would like to thank the following individuals for their 343 contributions to this document: 344 o Dan Wing 345 o John Elwell 346 o Kai Fischer 348 8. IANA Considerations 350 There are no IANA considerations with this document. 352 9. Acknowledgments 354 Add your name here. 356 10. References 358 10.1. Normative References 360 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 361 Levels", BCP 14, RFC 2119, March 1997. 363 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 364 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 365 Session Initiation Protocol", RFC 3261, June 2002. 367 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 368 Identity Management in the Session Initiation Protocol (SIP)", 369 RFC 4474, August 2006. 371 [4] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and 372 M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", 373 RFC 4871, May 2007. 375 [5] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 376 December 2004. 378 [6] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 379 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 380 Application (ENUM)", RFC 3761, April 2004. 382 10.2. Informative References 384 [7] Elwell, J., "SIP E.164 Problem Statement", 385 draft-elwell-sip-e164-problem-statement-00 (work in progress), 386 February 2008. 388 [8] Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 389 Sicker, "SIP SAML Profile and Binding", draft-ietf-sip-saml-03 390 (work in progress), November 2007. 392 [9] Wing, D., "SIP E.164 Return Routability Check (RRC)", 393 draft-wing-sip-e164-rrc-01 (work in progress), February 2008. 395 [10] Aura, T., "Cryptographically Generated Addresses (CGA)", 396 RFC 3972, March 2005. 398 [11] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing 399 over IP (TRIP)", RFC 3219, January 2002. 401 [12] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On 402 the Use of Stream Control Transmission Protocol (SCTP) with 403 IPsec", RFC 3554, July 2003. 405 [13] ITU-T, "The international public telecommunication numbering 406 plan", Recommendation E.164, May 1997. 408 [14] Peterson, J., "A Privacy Mechanism for the Session Initiation 409 Protocol (SIP)", RFC 3323, November 2002. 411 [15] Darilion, K., "E.164 Ownership using Public Keys stored in 412 ENUM", Info draft-darilion-sip-e164-enum-00.txt, Feb 2008. 414 Authors' Addresses 416 David Schwartz 417 XConnect 418 Malcha Technology Park 419 Jerusalem, 96951 420 Israel 422 Email: dschwartz@xconnect.net 424 Hadriel Kaplan 425 Acme Packet 426 71 Third Ave. 427 Burlington, MA 01803 428 USA 430 Phone: 431 Fax: 432 Email: hkaplan@acmepacket.com 433 URI: 435 Klaus Darilion 436 enum.at GmbH 437 Karlsplatz 1/9 438 Wien A-1010 439 Austria 441 Phone: +43 1 5056416 36 442 Email: klaus.darilion@enum.at 443 URI: http://www.enum.at/ 445 Hannes Tschofenig 446 Nokia Siemens Networks 447 Linnoitustie 6 448 Espoo 02600 449 Finland 451 Phone: +358 (50) 4871445 452 Email: Hannes.Tschofenig@gmx.net 453 URI: http://www.tschofenig.com 455 Full Copyright Statement 457 Copyright (C) The IETF Trust (2008). 459 This document is subject to the rights, licenses and restrictions 460 contained in BCP 78, and except as set forth therein, the authors 461 retain all their rights. 463 This document and the information contained herein are provided on an 464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 466 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 467 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 468 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 471 Intellectual Property 473 The IETF takes no position regarding the validity or scope of any 474 Intellectual Property Rights or other rights that might be claimed to 475 pertain to the implementation or use of the technology described in 476 this document or the extent to which any license under such rights 477 might or might not be available; nor does it represent that it has 478 made any independent effort to identify any such rights. Information 479 on the procedures with respect to rights in RFC documents can be 480 found in BCP 78 and BCP 79. 482 Copies of IPR disclosures made to the IETF Secretariat and any 483 assurances of licenses to be made available, or the result of an 484 attempt made to obtain a general license or permission for the use of 485 such proprietary rights by implementers or users of this 486 specification can be obtained from the IETF on-line IPR repository at 487 http://www.ietf.org/ipr. 489 The IETF invites any interested party to bring to its attention any 490 copyrights, patents or patent applications, or other proprietary 491 rights that may cover technology that may be required to implement 492 this standard. Please address the information to the IETF at 493 ietf-ipr@ietf.org. 495 Acknowledgment 497 Funding for the RFC Editor function is provided by the IETF 498 Administrative Support Activity (IASA).