idnits 2.17.1 draft-jennings-dispatch-rfc4474bis-00.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 938 has weird spacing: '... where prox...' == Line 946 has weird spacing: '... where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2013) is 3975 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) -- Looks like a reference, but probably isn't: '12' on line 436 -- Looks like a reference, but probably isn't: '15' on line 694 -- Looks like a reference, but probably isn't: '6' on line 818 -- Looks like a reference, but probably isn't: '1' on line 819 -- Looks like a reference, but probably isn't: '14' on line 1281 == Unused Reference: 'I-D.cooper-iab-secure-origin-00' is defined on line 1852, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-sipping-retarget' is defined on line 1863, but no explicit reference was found in the text == Unused Reference: 'RFC3761' is defined on line 1894, but no explicit reference was found in the text == Unused Reference: 'RFC4475' is defined on line 1905, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-02) exists of draft-peterson-secure-origin-ps-00 -- No information found for draft-rescorla-callerid-fallback - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 11 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 4 Intended status: Standards Track C. Jennings 5 Expires: November 30, 2013 Cisco 6 E.K. Rescorla 7 RTFM, Inc. 8 May 29, 2013 10 Authenticated Identity Management in the Session Initiation Protocol 11 (SIP) 12 draft-jennings-dispatch-rfc4474bis-00 14 Abstract 16 The existing security mechanisms in the Session Initiation Protocol 17 (SIP) are inadequate for cryptographically assuring the identity of 18 the end users that originate SIP requests, especially in an 19 interdomain context. This document defines a mechanism for securely 20 identifying originators of SIP messages. It does so by defining two 21 new SIP header fields, Identity, for conveying a signature used for 22 validating the identity, and Identity-Info, for conveying a reference 23 to the certificate of the signer. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 30, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Scope of Proposed Changes . . . . . . . . . . . . . . . . . . 5 73 2.1. Changes to the Identity-Info Header . . . . . . . . . . . 5 74 2.2. Changes to the Identity Header . . . . . . . . . . . . . 6 75 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Overview of Operations . . . . . . . . . . . . . . . . . . . 10 79 7. Authentication Service Behavior . . . . . . . . . . . . . . . 11 80 7.1. Identity within a Dialog and Retargeting . . . . . . . . 14 81 8. Verifier Behavior . . . . . . . . . . . . . . . . . . . . . . 15 82 9. Considerations for User Agent . . . . . . . . . . . . . . . . 16 83 10. Considerations for Proxy Servers . . . . . . . . . . . . . . 17 84 11. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 85 12. Compliance Tests and Examples . . . . . . . . . . . . . . . . 21 86 12.1. Identity-Info with a Singlepart MIME body . . . . . . . 21 87 12.2. Identity for a Request with No MIME Body or Contact . . 24 88 13. Identity and the TEL URI Scheme . . . . . . . . . . . . . . . 27 89 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 90 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 15.1. Handling of digest-string Elements . . . . . . . . . . . 29 92 15.2. Display-Names and Identity . . . . . . . . . . . . . . . 32 93 15.3. Securing the Connection to the Authentication Service . 33 94 15.4. Domain Names and Subordination . . . . . . . . . . . . . 34 95 15.5. Authorization and Transitional Strategies . . . . . . . 35 96 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 97 16.1. Header Field Names . . . . . . . . . . . . . . . . . . . 37 98 16.2. 428 'Use Identity Header' Response Code . . . . . . . . 37 99 16.3. 436 'Bad Identity-Info' Response Code . . . . . . . . . 37 100 16.4. 437 'Unsupported Certificate' Response Code . . . . . . 38 101 16.5. 438 'Invalid Identity Header' Response Code . . . . . . 38 102 16.6. Identity-Info Parameters . . . . . . . . . . . . . . . . 38 103 16.7. Identity-Info Algorithm Parameter Values . . . . . . . . 38 104 16.8. Acknowledgements . . . . . . . . . . . . . . . . . . . . 39 105 16.9. Original RFC 4474 Requirements . . . . . . . . . . . . . 39 106 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 107 17.1. Normative References . . . . . . . . . . . . . . . . . . 39 108 17.2. Informative References . . . . . . . . . . . . . . . . . 40 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 111 1. Preamble 113 The sip-identity drafts that lead to RFC 4474 [RFC4474] were first 114 published in 2002. Since that point many things have changed that 115 impact that design. 117 o The DNS root has been signed. 119 o SPAM continues to be a problem. 121 o A clearer understanding has evolved of the use of B2BUAs including 122 standardization such as the STRAW WG. 124 o Multipart MIME has failed as a SIP extension mechanism. 126 o Widespread identity providers such as Facebook have emerged. 128 o Techniques for non-carrier entities to verify phone numbers and 129 then use them for addressing (such as Apple's iMessage) have been 130 shown to be commercially feasible. 132 o Substantial portions of commercial, government, and personal voice 133 communications rely on SIP at some stage in the communications. 135 o The cost of operating large databases has fallen and outsourced 136 versions of these databases have become cheaply available. 138 o Extensive experience and user research has improved our 139 understanding of how to present security information to users. 141 o The world is in the a huge transition to mobile devices. Even the 142 most limited modern mobile devices have user interface and 143 computational capabilities that greatly exceed a 2002-era SIP 144 phone. 146 The authors believe that the confluence of changing technology, the 147 evolution of mobile devices and internet, and a political will to 148 change make this the right time to consider an expansion of the scope 149 of 4474 to solve the following problems: 151 o Assert strong identity for domain scoped names such as 152 alice@example.com 154 o Assert strong identity for E.164 numbers such as +1 408 555-1212 156 o Provide organization attributes such as "this is a Bank". 158 o Work for calls crossing even the most adverse networks such as the 159 PSTN. 161 o Provide reliable information about who is calling before the call 162 is answered to help stop SPAM. 164 o Provide reliable information about who you are talking to. 166 o Work with evolving non SIP based communications systems such as 167 WebRTC. 169 We believe it is possible to solve all of these in a way that is 170 commercially viable, deployable, and provides a delightful user 171 experience. 173 The core problem in a global identity system with delegated names is 174 understanding who is authorized to make assertions about a given 175 name. The proposal is to solve that problem with a two pronged 176 approach. 178 First have responsibility for a number delegated down from the root 179 in a series of delegation sub delegation towards the user. For 180 example, the North American number operator may assign a portion of 181 the +1 space to a service provider. That service provider may assign 182 a sub space to a company and that company may assign a number to a 183 user. At each level of delegation, cryptographic credentials could 184 be provided that allow the user to prove the space was delegated to 185 them given some common trust root. This approach is referred to as 186 "delegation" and effectively works from the top down. 188 The other prong to solving the problem is called "claims" and works 189 via a bottom up approach. The end user of a number basically claims 190 it and some trusted system validates this claim. The validation may 191 be as simple as sending a SMS to the number or more complicated such 192 as the VIPR system. 194 The delegation approach creates an easier user experience but is 195 harder to deploy from a business incentive point of view so our 196 approach is to do both and work down from the top and up from the 197 bottom with a meet in the middle approach to coverage of the full 198 name space. 200 User agents that have a credential (whether of the delegation or 201 claim variety) for a name can create two types of assertions: replay 202 assertions and reliance assertions. These two assertion are signed 203 over a different set of the call information and protect against 204 different types of attacks. Some networks might modify the signaling 205 in ways that impact one of these assertions but not the other. 207 The assertions are passed from the caller to the callee for 208 verification. This can be done by either passing the assertion along 209 with the signaling, or alternatively passing it through a web based 210 Call Detail Service (CDS) where the caller saves the assertion on the 211 Call Detail Service and the callee retrieves it from the Call Detail 212 Service service. There are some call signaling environments, such as 213 when a call passes through the PSTN, where it is not possible to 214 transfer the assertion in the call signaling path. The Call Detail 215 Service is in place to make things work in this environment thought 216 some privacy information around who is calling who is reveled to the 217 Call Detail Service service. An outline for this design is described 218 in [I-D.rescorla-callerid-fallback]. 220 2. Scope of Proposed Changes 222 2.1. Changes to the Identity-Info Header 224 Currently, RFC4474 restricts the subject of the certificate to a 225 domain name, and accordingly the RFC4474 Identity-Info header 226 contains a URI which designates a certificate whose subject (more 227 precisely, subjectAltName) must correspond to the domain of the URI 228 in the From header field value of the SIP request. Per the analysis 229 in [I-D.peterson-secure-origin-ps], we propose to relax this to allow 230 designating an alternative authority for telephone numbers, when 231 telephone numbers appear in the From header field value. 233 These changes will allow the Identity-Info URI to point to the 234 certificate with authority over the calling telephone number. A 235 verification service will therefore authorize a SIP request when the 236 telephone number in the From header field value agrees with the 237 subject of the certificate. Verification services must of course 238 trust the certificate authority that issued the certificate in 239 question. To implement this change to the Identity-Info header, we 240 must allow for two possibilities for the conveyance of a telephone 241 number in a request: appearing within a tel URI or appearing as the 242 user portion of a SIP URI. Therefore, we must prescribe verification 243 service behind in the case where the From header field value URI 244 contains a telephone user part followed by a domain -- which should 245 the verification service expect to find in a certificate? 247 There are also a few other potential changes within the scope of a 248 revision to the Identity-Info header. We might consider implementing 249 enough flexibility in the URI to allow a model more like the IdP 250 model described in [I-D.rescorla-rtcweb-generic-idp]; this could be 251 useful as RTCWeb sees increasing deployment. We also should consider 252 any implications of the signing of the DNSSEC root and the DANE 253 specifications to the existing Identity-Info uses with domain name. 254 At a high level, it is not expected that the proposed changes will 255 radically alter the semantics of Identity-Info. 257 Although deployment of RFC4474 to date has been essentially non- 258 existent, we will during this revision process consider any realistic 259 backwards compatibility concerns. 261 2.2. Changes to the Identity Header 263 Per the analysis in [I-D.peterson-secure-origin-ps], we propose to 264 change the signature mechanism that RFC44474 specified for the 265 Identity header: in particular, to replace this signature mechanism 266 with one that is more likely to survive end-to-end in SIP networks 267 where intermediaries act as back-to-back user agents rather than 268 proxy servers. 270 To accomplish this, we propose creating two distinct signatures 271 within SIP requests: a replay assurance and a reliance assurance. 272 The replay assurance prevents impersonation attacks by providing a 273 signature over the From header field value and certain other headers 274 which will allow a verification service to detect a cut-and-paste 275 attack. The reliance assurance protects against men-in-the-middle 276 unilaterally changing other parameters of the call: these include the 277 target of future requests (Contact header field) and the entirely of 278 the SDP, including the target IP address and ports which, if 279 unprotected, can allow a man-in-the-middle to impersonate an intended 280 listener. Verification services behavior would change to allow them 281 to decide, based on their configuration in a deployment environment, 282 whether the replay assurance alone can realistically survive network 283 transit, or if the reliance assurance should be available. 285 There are a number of ways to implement this change to the signature 286 in the Identity header field. One possibility is to design two new 287 headers, which we might call "Identity-Reliance" and "Identity- 288 Replay" with the reliance signature being over a canonical 289 representation of the reliance field and then the Identity-Replay 290 header covering the From header field value, other headers needed for 291 replay protection, and well as the contents of the Identity-Reliance 292 header. It might also be possible to preserve the existing Identity 293 header as the reliance header. There are however several similar 294 alternatives we might consider, and some analysis will be required to 295 identify the best option. 297 In order to preserve critical security parameters even in adverse 298 network conditions, the replay assurance integrity protection must 299 always cover security parameters of the SDP required to negotiate 300 media-level security. There may be other exception cases, or 301 extensibility mechanisms, worth considering here. In cases where the 302 From header field value of a SIP request contains a SIP URI with a 303 telephone number user part, we will also consider replay assurance 304 canonicalizations that do not cover the domain portion of the URI. 306 We will furthermore give due consideration to changes in SIP 307 architecture and deployment since the publication of RFC4474, 308 including the ongoing work in the STRAW working group. 310 As with Identity-Info, any necessary consideration will be given to 311 backwards compatibility of the Identity header. 313 3. Introduction 315 This document provides enhancements to the existing mechanisms for 316 authenticated identity management in the Session Initiation Protocol 317 (SIP, RFC 3261 [RFC3261]). An identity, for the purposes of this 318 document, is defined as a SIP URI, commonly a canonical address-of- 319 record (AoR) employed to reach a user (such as 320 'sip:alice@atlanta.example.com'). 322 RFC 3261 [RFC3261] stipulates several places within a SIP request 323 where a user can express an identity for themselves, notably the 324 user-populated From header field. However, the recipient of a SIP 325 request has no way to verify that the From header field has been 326 populated appropriately, in the absence of some sort of cryptographic 327 authentication mechanism. 329 RFC 3261 [RFC3261] specifies a number of security mechanisms that can 330 be employed by SIP user agents (UAs), including Digest, Transport 331 Layer Security (TLS), and S/MIME (implementations may support other 332 security schemes as well). However, few SIP user agents today 333 support the end-user certificates necessary to authenticate 334 themselves (via S/MIME, for example), and furthermore Digest 335 authentication is limited by the fact that the originator and 336 destination must share a prearranged secret. It is desirable for SIP 337 user agents to be able to send requests to destinations with which 338 they have no previous association -- just as in the telephone network 339 today, one can receive a call from someone with whom one has no 340 previous association, and still have a reasonable assurance that the 341 person's displayed Caller-ID is accurate. A cryptographic approach, 342 like the one described in this document, can probably provide a much 343 stronger and less spoofable assurance of identity than the telephone 344 network provides today. 346 4. Terminology 348 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 349 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 350 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 351 described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 353 5. Background 355 The usage of many SIP applications and services is governed by 356 authorization policies. These policies may be automated, or they may 357 be applied manually by humans. An example of the latter would be an 358 Internet telephone application that displays the Caller-ID of a 359 caller, which a human may review before answering a call. An example 360 of the former would be a presence service that compares the identity 362 of potential subscribers to a whitelist before determining whether it 363 should accept or reject the subscription. In both of these cases, 364 attackers might attempt to circumvent these authorization policies 365 through impersonation. Since the primary identifier of the sender of 366 a SIP request, the From header field, can be populated arbitrarily by 367 the controller of a user agent, impersonation is very simple today. 368 The mechanism described in this document aspires to provide a strong 369 identity system for SIP in which authorization policies cannot be 370 circumvented by impersonation. 372 All RFC 3261 [RFC3261] compliant user agents support Digest 373 authentication, which utilizes a shared secret, as a means for 374 authenticating themselves to a SIP registrar. Registration allows a 375 user agent to express that it is an appropriate entity to which 376 requests should be sent for a particular SIP AoR URI (e.g., 377 'sip:alice@atlanta.example.com'). 379 By the definition of identity used in this document, registration is 380 a proof of the identity of the user to a registrar. However, the 381 credentials with which a user agent proves its identity to a 382 registrar cannot be validated by just any user agent or proxy server 383 -- these credentials are only shared between the user agent and their 384 domain administrator. So this shared secret does not immediately 385 help a user to authenticate to a wide range of recipients. 387 Recipients require a means of determining whether or not the 'return 388 address' identity of a non-REGISTER request (i.e., the From header 389 field value) has legitimately been asserted. 391 The AoR URI used for registration is also the URI with which a UA 392 commonly populates the From header field of requests in order to 393 provide a 'return address' identity to recipients. From an 394 authorization perspective, if you can prove you are eligible to 395 register in a domain under a particular AoR, you can prove you can 396 legitimately receive requests for that AoR, and accordingly, when you 397 place that AoR in the From header field of a SIP request other than a 398 registration (like an INVITE), you are providing a 'return address' 399 where you can legitimately be reached. In other words, if you are 400 authorized to receive requests for that 'return address', logically, 401 it follows that you are also authorized to assert that 'return 402 address' in your From header field. This is of course only one 403 manner in which a domain might determine how a particular user is 404 authorized to populate the From header field; as an aside, for other 405 sorts of URIs in the From (like anonymous URIs), other authorization 406 policies would apply. 408 Ideally, then, SIP user agents should have some way of proving to 409 recipients of SIP requests that their local domain has authenticated 410 them and authorized the population of the From header field. This 411 document proposes a mediated authentication architecture for SIP in 412 which requests are sent to a server in the user's local domain, which 413 authenticates such requests (using the same practices by which the 414 domain would authenticate REGISTER requests). Once a message has 415 been authenticated, the local domain then needs some way to 416 communicate to other SIP entities that the sending user has been 417 authenticated and its use of the From header field has been 418 authorized. This document addresses how that imprimatur of 419 authentication can be shared. 421 RFC 3261 [RFC3261] already describes an architecture very similar to 422 this in Section 26.3.2.2, in which a user agent authenticates itself 423 to a local proxy server, which in turn authenticates itself to a 424 remote proxy server via mutual TLS, creating a two-link chain of 425 transitive authentication between the originator and the remote 426 domain. While this works well in some architectures, there are a few 427 respects in which this is impractical. For one, transitive trust is 428 inherently weaker than an assertion that can be validated end-to-end. 429 It is possible for SIP requests to cross multiple intermediaries in 430 separate administrative domains, in which case transitive trust 431 becomes even less compelling. 433 One solution to this problem is to use 'trusted' SIP intermediaries 434 that assert an identity for users in the form of a privileged SIP 435 header. A mechanism for doing so (with the P-Asserted-Identity 436 header) is given in [12]. However, this solution allows only hop- 437 by-hop trust between intermediaries, not end-to-end cryptographic 438 authentication, and it assumes a managed network of nodes with strict 439 mutual trust relationships, an assumption that is incompatible with 440 widespread Internet deployment. 442 Accordingly, this document specifies a means of sharing a 443 cryptographic assurance of end-user SIP identity in an interdomain or 444 intradomain context that is based on the concept of an 445 'authentication service' and a new SIP header, the Identity header. 446 Note that the scope of this document is limited to providing this 447 identity assurance for SIP requests; solving this problem for SIP 448 responses is more complicated and is a subject for future work. 450 This specification allows either a user agent or a proxy server to 451 provide identity services and to verify identities. To maximize end- 452 to-end security, it is obviously preferable for end-users to acquire 453 their own certificates and corresponding private keys; if they do, 454 they can act as an authentication service. However, end- user 455 certificates may be neither practical nor affordable, given the 456 difficulties of establishing a Public Key Infrastructure (PKI) that 457 extends to end-users, and moreover, given the potentially large 458 number of SIP user agents (phones, PCs, laptops, PDAs, gaming 459 devices) that may be employed by a single user. In such 460 environments, synchronizing keying material across multiple devices 461 may be very complex and requires quite a good deal of additional 462 endpoint behavior. Managing several certificates for the various 463 devices is also quite problematic and unpopular with users. 464 Accordingly, in the initial use of this mechanism, it is likely that 465 intermediaries will instantiate the authentication service role. 467 6. Overview of Operations 469 This section provides an informative (non-normative) high-level 470 overview of the mechanisms described in this document. 472 Imagine the case where Alice, who has the home proxy of example.com 473 and the address-of-record sip:alice@example.com, wants to communicate 474 with sip:bob@example.org. 476 Alice generates an INVITE and places her identity in the From header 477 field of the request. She then sends an INVITE over TLS to an 478 authentication service proxy for her domain. 480 The authentication service authenticates Alice (possibly by sending a 481 Digest authentication challenge) and validates that she is authorized 482 to assert the identity that is populated in the From header field. 484 This value may be Alice's AoR, or it may be some other value that the 485 policy of the proxy server permits her to use. It then computes a 486 hash over some particular headers, including the From header field 487 and the bodies in the message. This hash is signed with the 488 certificate for the domain (example.com, in Alice's case) and 489 inserted in a new header field in the SIP message, the 'Identity' 490 header. 492 The proxy, as the holder of the private key of its domain, is 493 asserting that the originator of this request has been authenticated 494 and that she is authorized to claim the identity (the SIP address- 495 of-record) that appears in the From header field. The proxy also 496 inserts a companion header field, Identity-Info, that tells Bob how 497 to acquire its certificate, if he doesn't already have it. 499 When Bob's domain receives the request, it verifies the signature 500 provided in the Identity header, and thus can validate that the 501 domain indicated by the host portion of the AoR in the From header 502 field authenticated the user, and permitted the user to assert that 503 From header field value. This same validation operation may be 504 performed by Bob's user agent server (UAS). 506 7. Authentication Service Behavior 508 This document defines a new role for SIP entities called an 509 authentication service. The authentication service role can be 510 instantiated by a proxy server or a user agent. Any entity that 511 instantiates the authentication service role MUST possess the private 512 key of a domain certificate. Intermediaries that instantiate this 513 role MUST be capable of authenticating one or more SIP users that can 514 register in that domain. Commonly, this role will be instantiated by 515 a proxy server, since these entities are more likely to have a static 516 hostname, hold a corresponding certificate, and have access to SIP 517 registrar capabilities that allow them to authenticate users in their 518 domain. It is also possible that the authentication service role 519 might be instantiated by an entity that acts as a redirect server, 520 but that is left as a topic for future work. 522 SIP entities that act as an authentication service MUST add a Date 523 header field to SIP requests if one is not already present (see 524 Section 11 for information on how the Date header field assists 525 verifiers). Similarly, authentication services MUST add a Content- 526 Length header field to SIP requests if one is not already present; 527 this can help verifiers to double-check that they are hashing exactly 528 as many bytes of message-body as the authentication service when they 529 verify the message. 531 Entities instantiating the authentication service role perform the 532 following steps, in order, to generate an Identity header for a SIP 533 request: 535 Step 1: 537 The authentication service MUST extract the identity of the sender 538 from the request. The authentication service takes this value from 539 the From header field; this AoR will be referred to here as the 540 'identity field'. If the identity field contains a SIP or SIP Secure 541 (SIPS) URI, the authentication service MUST extract the hostname 542 portion of the identity field and compare it to the domain(s) for 543 which it is responsible (following the procedures in RFC 3261 544 [RFC3261], Section 16.4), used by a proxy server to determine the 545 domain(s) for which it is responsible). If the identity field uses 546 the TEL URI scheme, the policy of the authentication service 547 determines whether or not it is responsible for this identity; see 548 Section 13 for more information. If the authentication service is 549 not responsible for the identity in question, it SHOULD process and 550 forward the request normally, but it MUST NOT add an Identity header; 551 see below for more information on authentication service handling of 552 an existing Identity header. 554 Step 2: 556 The authentication service MUST determine whether or not the sender 557 of the request is authorized to claim the identity given in the 558 identity field. In order to do so, the authentication service MUST 559 authenticate the sender of the message. Some possible ways in which 560 this authentication might be performed include: 562 If the authentication service is instantiated by a SIP 563 intermediary (proxy server), it may challenge the request with a 564 407 response code using the Digest authentication scheme (or 565 viewing a Proxy-Authentication header sent in the request, which 566 was sent in anticipation of a challenge using cached credentials, 567 as described in RFC 3261 [RFC3261], Section 22.3). Note that if 568 that proxy server is maintaining a TLS connection with the client 569 over which the client had previously authenticated itself using 570 Digest authentication, the identity value obtained from that 571 previous authentication step can be reused without an additional 572 Digest challenge. 574 If the authentication service is instantiated by a SIP user agent, 575 a user agent can be said to authenticate its user on the grounds 576 that the user can provision the user agent with the private key of 577 the domain, or preferably by providing a password that unlocks 578 said private key. 580 Authorization of the use of a particular username in the From header 581 field is a matter of local policy for the authentication service, one 582 that depends greatly on the manner in which authentication is 583 performed. For example, one policy might be as follows: the username 584 given in the 'username' parameter of the Proxy-Authorization header 585 MUST correspond exactly to the username in the From header field of 586 the SIP message. However, there are many cases in which this is too 587 limiting or inappropriate; a realm might use 'username' parameters in 588 Proxy-Authorization that do not correspond to the user-portion of SIP 589 From headers, or a user might manage multiple accounts in the same 590 administrative domain. In this latter case, a domain might maintain 591 a mapping between the values in the 'username' parameter of Proxy- 592 Authorization and a set of one or more SIP URIs that might 593 legitimately be asserted for that 'username'. For example, the 594 username can correspond to the 'private identity' as defined in Third 595 Generation Partnership Project (3GPP), in which case the From header 596 field can contain any one of the public identities associated with 597 this private identity. In this instance, another policy might be as 598 follows: the URI in the From header field MUST correspond exactly to 599 one of the mapped URIs associated with the 'username' given in the 600 Proxy-Authorization header. Various exceptions to such policies 601 might arise for cases like anonymity; if the AoR asserted in the From 602 header field uses a form like 'sip:anonymous@example.com', then the 603 'example.com' proxy should authenticate that the user is a valid user 604 in the domain and insert the signature over the From header field as 605 usual. 607 Note that this check is performed on the addr-spec in the From header 608 field (e.g., the URI of the sender, like 609 'sip:alice@atlanta.example.com'); it does not convert the display- 610 name portion of the From header field (e.g., 'Alice Atlanta'). 611 Authentication services MAY check and validate the display-name as 612 well, and compare it to a list of acceptable display-names that may 613 be used by the sender; if the display-name does not meet policy 614 constraints, the authentication service MUST return a 403 response 615 code. The reason phrase should indicate the nature of the problem; 616 for example, "Inappropriate Display Name". However, the display-name 617 is not always present, and in many environments the requisite 618 operational procedures for display-name validation may not exist. 619 For more information, see Section 15.2. 621 Step 3: 623 The authentication service SHOULD ensure that any preexisting Date 624 header in the request is accurate. Local policy can dictate 625 precisely how accurate the Date must be; a RECOMMENDED maximum 626 discrepancy of ten minutes will ensure that the request is unlikely 627 to upset any verifiers. If the Date header contains a time different 628 by more than ten minutes from the current time noted by the 629 authentication service, the authentication service SHOULD reject the 630 request. This behavior is not mandatory because a user agent client 631 (UAC) could only exploit the Date header in order to cause a request 632 to fail verification; the Identity header is not intended to provide 633 a source of non-repudiation or a perfect record of when messages are 634 processed. Finally, the authentication service MUST verify that the 635 Date header falls within the validity period of its certificate. For 636 more information on the security properties associated with the Date 637 header field value, see Section 11. 639 Step 4: 641 The authentication service MUST form the identity signature and add 642 an Identity header to the request containing this signature. After 643 the Identity header has been added to the request, the authentication 644 service MUST also add an Identity-Info header. The Identity-Info 645 header contains a URI from which its certificate can be acquired. 646 Details on the generation of both of these headers are provided in 647 Section 11. 649 Finally, the authentication service MUST forward the message 650 normally. 652 7.1. Identity within a Dialog and Retargeting 654 Retargeting is broadly defined as the alteration of the Request-URI 655 by intermediaries. More specifically, retargeting supplants the 656 original target URI with one that corresponds to a different user, a 657 user that is not authorized to register under the original target 658 URI. By this definition, retargeting does not include translation of 659 the Request-URI to a contact address of an endpoint that has 660 registered under the original target URI, for example. 662 When a dialog-forming request is retargeted, this can cause a few 663 wrinkles for the Identity mechanism when it is applied to requests 664 sent in the backwards direction within a dialog. This section 665 provides some non-normative considerations related to this case. 667 When a request is retargeted, it may reach a SIP endpoint whose user 668 is not identified by the URI designated in the To header field value. 669 The value in the To header field of a dialog-forming request is used 670 as the From header field of requests sent in the backwards direction 671 during the dialog, and is accordingly the header that would be signed 672 by an authentication service for requests sent in the backwards 673 direction. In retargeting cases, if the URI in the From header does 674 not identify the sender of the request in the backwards direction, 675 then clearly it would be inappropriate to provide an Identity 676 signature over that From header. As specified above, if the 677 authentication service is not responsible for the domain in the From 678 header field of the request, it MUST NOT add an Identity header to 679 the request, and it should process/forward the request normally. 681 Any means of anticipating retargeting, and so on, is outside the 682 scope of this document, and likely to have equal applicability to 683 response identity as it does to requests in the backwards direction 684 within a dialog. Consequently, no special guidance is given for 685 implementers here regarding the 'connected party' problem; 686 authentication service behavior is unchanged if retargeting has 687 occurred for a dialog-forming request. Ultimately, the 688 authentication service provides an Identity header for requests in 689 the backwards dialog when the user is authorized to assert the 690 identity given in the From header field, and if they are not, an 691 Identity header is not provided. 693 For further information on the problems of response identity and the 694 potential solution spaces, see [15]. 696 8. Verifier Behavior 698 This document introduces a new logical role for SIP entities called a 699 server. When a verifier receives a SIP message containing an 700 Identity header, it may inspect the signature to verify the identity 701 of the sender of the message. Typically, the results of a 702 verification are provided as input to an authorization process that 703 is outside the scope of this document. If an Identity header is not 704 present in a request, and one is required by local policy (for 705 example, based on a per-sending-domain policy, or a per-sending-user 706 policy), then a 428 'Use Identity Header' response MUST be sent. 708 In order to verify the identity of the sender of a message, an entity 709 acting as a verifier MUST perform the following steps, in the order 710 here specified. 712 Step 1: 714 The verifier MUST acquire the certificate for the signing domain. 715 Implementations supporting this specification SHOULD have some means 716 of retaining domain certificates (in accordance with normal practices 717 for certificate lifetimes and revocation) in order to prevent 718 themselves from needlessly downloading the same certificate every 719 time a request from the same domain is received. Certificates cached 720 in this manner should be indexed by the URI given in the Identity- 721 Info header field value. 723 Provided that the domain certificate used to sign this message is not 724 previously known to the verifier, SIP entities SHOULD discover this 725 certificate by dereferencing the Identity-Info header, unless they 726 have some more efficient implementation-specific way of acquiring 727 certificates for that domain. If the URI scheme in the Identity-Info 728 header cannot be dereferenced, then a 436 'Bad Identity-Info' 729 response MUST be returned. The verifier processes this certificate 730 in the usual ways, including checking that it has not expired, that 731 the chain is valid back to a trusted certification authority (CA), 732 and that it does not appear on revocation lists. Once the 733 certificate is acquired, it MUST be validated following the 734 procedures in RFC 3280 [RFC3280]. If the certificate cannot be 735 validated (it is self-signed and untrusted, or signed by an untrusted 736 or unknown certificate authority, expired, or revoked), the verifier 737 MUST send a 437 'Unsupported Certificate' response. 739 Step 2: 741 The verifier MUST follow the process described in Section 15.4 to 742 determine if the signer is authoritative for the URI in the From 743 header field. 745 Step 3: 747 The verifier MUST verify the signature in the Identity header field, 748 following the procedures for generating the hashed digest-string 749 described in Section 11. If a verifier determines that the signature 750 on the message does not correspond to the reconstructed digest- 751 string, then a 438 'Invalid Identity Header' response MUST be 752 returned. 754 Step 4: 756 The verifier MUST validate the Date, Contact, and Call-ID headers in 757 the manner described in Section 15.1; recipients that wish to verify 758 Identity signatures MUST support all of the operations described 759 there. It must furthermore ensure that the value of the Date header 760 falls within the validity period of the certificate whose 761 corresponding private key was used to sign the Identity header. 763 9. Considerations for User Agent 765 This mechanism can be applied opportunistically to existing SIP 766 deployments; accordingly, it requires no change to SIP user agent 767 behavior in order for it to be effective. However, because this 768 mechanism does not provide integrity protection between the UAC and 769 the authentication service, a UAC SHOULD implement some means of 770 providing this integrity. TLS would be one such mechanism, which is 771 attractive because it MUST be supported by SIP proxy servers, but is 772 potentially problematic because it is a hop-by-hop mechanism. See 773 Section 15.3 for more information about securing the channel between 774 the UAC and the authentication service. 776 When a UAC sends a request, it MUST accurately populate the From 777 header field with a value corresponding to an identity that it 778 believes it is authorized to claim. In a request, it MUST set the 779 URI portion of its From header to match a SIP, SIPS, or TEL URI AoR 780 that it is authorized to use in the domain (including anonymous URIs, 781 as described in RFC 3323 [RFC3323]). In general, UACs SHOULD NOT use 782 the TEL URI form in the From header field (see Section 13). 784 Note that this document defines a number of new 4xx response codes. 785 If user agents support these response codes, they will be able to 786 respond intelligently to Identity-based error conditions. 788 The UAC MUST also be capable of sending requests, including mid-call 789 requests, through an 'outbound' proxy (the authentication service). 790 The best way to accomplish this is using pre-loaded Route headers and 791 loose routing. For a given domain, if an entity that can instantiate 792 the authentication service role is not in the path of dialog-forming 793 requests, identity for mid-dialog requests in the backwards direction 794 cannot be provided. 796 As a recipient of a request, a user agent that can verify signed 797 identities should also support an appropriate user interface to 798 render the validity of identity to a user. User agent 799 implementations SHOULD differentiate signed From header field values 800 from unsigned From header field values when rendering to an end-user 801 the identity of the sender of a request. 803 10. Considerations for Proxy Servers 805 Domain policy may require proxy servers to inspect and verify the 806 identity provided in SIP requests. A proxy server may wish to 807 ascertain the identity of the sender of the message to provide spam 808 prevention or call control services. Even if a proxy server does not 809 act as an authentication service, it MAY validate the Identity header 810 before it makes a forwarding decision for a request. Proxy servers 811 MUST NOT remove or modify an existing Identity or Identity-Info 812 header in a request. 814 11. Header Syntax 816 This document specifies two new SIP headers: Identity and Identity- 817 Info. Each of these headers can appear only once in a SIP message. 818 The grammar for these two headers is (following the ABNF [6] in RFC 819 3261 [1]): 821 Identity = "Identity" HCOLON signed-identity-digest 822 signed-identity-digest = LDQUOT 32LHEX RDQUOT 824 Identity-Info = "Identity-Info" HCOLON ident-info 825 *( SEMI ident-info-params ) 826 ident-info = LAQUOT absoluteURI RAQUOT 827 ident-info-params = ident-info-alg / ident-info-extension 828 ident-info-alg = "alg" EQUAL token 829 ident-info-extension = generic-param 831 The signed-identity-digest is a signed hash of a canonical string 832 generated from certain components of a SIP request. To create the 833 contents of the signed-identity-digest, the following elements of a 834 SIP message MUST be placed in a bit-exact string in the order 835 specified here, separated by a vertical line, "|" or %x7C, character: 837 The AoR of the UA sending the message, or addr-spec of the From 838 header field (referred to occasionally here as the 'identity 839 field'). 841 The addr-spec component of the To header field, which is the AoR 842 to which the request is being sent. 844 The callid from Call-Id header field. 846 The digit (1*DIGIT) and method (method) portions from CSeq header 847 field, separated by a single space (ABNF SP, or %x20). Note that 848 the CSeq header field allows linear whitespace (LWS) rather than 849 SP to separate the digit and method portions, and thus the CSeq 850 header field may need to be transformed in order to be 851 canonicalized. The authentication service MUST strip leading 852 zeros from the 'digit' portion of the Cseq before generating the 853 digest-string. 855 The Date header field, with exactly one space each for each SP and 856 the weekday and month items case set as shown in BNF in RFC 3261 857 [RFC3261]. RFC 3261 specifies that the BNF for weekday and month 858 is a choice amongst a set of tokens. The RFC 2234 [RFC2234] rules 859 for the BNF specify that tokens are case sensitive. However, when 860 used to construct the canonical string defined here, the first 861 letter of each week and month MUST be capitalized, and the 862 remaining two letters must be lowercase. This matches the 863 capitalization provided in the definition of each token. All 864 requests that use the Identity mechanism MUST contain a Date 865 header. 867 The addr-spec component of the Contact header field value. If the 868 request does not contain a Contact header, this field MUST be 869 empty (i.e., there will be no whitespace between the fourth and 870 fifth "|" characters in the canonical string). 872 The body content of the message with the bits exactly as they are 873 in the Message (in the ABNF for SIP, the message-body). This 874 includes all components of multipart message bodies. Note that 875 the message-body does NOT include the CRLF separating the SIP 876 headers from the message-body, but does include everything that 877 follows that CRLF. If the message has no body, then message-body 878 will be empty, and the final "|" will not be followed by any 879 additional characters. 881 For more information on the security properties of these headers, and 882 why their inclusion mitigates replay attacks, see Section 15 and 883 [RFC3893]. The precise formulation of this digest-string is, 884 therefore (following the ABNF[RFC4234] in RFC 3261 [RFC3261]): 886 digest-string = addr-spec "|" addr-spec "|" callid "|" 887 1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|" 888 message-body 890 Note again that the first addr-spec MUST be taken from the From 891 header field value, the second addr-spec MUST be taken from the To 892 header field value, and the third addr-spec MUST be taken from the 893 Contact header field value, provided the Contact header is present in 894 the request. 896 After the digest-string is formed, it MUST be hashed and signed with 897 the certificate for the domain. The hashing and signing algorithm is 898 specified by the 'alg' parameter of the Identity-Info header (see 899 below for more information on Identity-Info header parameters). This 900 document defines only one value for the 'alg' parameter: 'rsa-sha1'; 901 further values MUST be defined in a Standards Track RFC, see 902 Section 14.7 for more information. All implementations of this 903 specification MUST support 'rsa-sha1'. When the 'rsa-sha1' algorithm 904 is specified in the 'alg' parameter of Identity-Info, the hash and 905 signature MUST be generated as follows: compute the results of 906 signing this string with sha1WithRSAEncryption as described in RFC 907 3370 [RFC3370] and base64 encode the results as specified in RFC 3548 909 [RFC3548]. A 1024-bit or longer RSA key MUST be used. The result is 910 placed in the Identity header field. For detailed examples of the 911 usage of this algorithm, see Section 12. 913 The 'absoluteURI' portion of the Identity-Info header MUST contain a 914 URI which dereferences to a resource containing the certificate of 915 the authentication service. All implementations of this 916 specification MUST support the use of HTTP and HTTPS URIs in the 917 Identity-Info header. Such HTTP and HTTPS URIs MUST follow the 918 conventions of RFC 2585 [RFC2585], and for those URIs the indicated 919 resource MUST be of the form 'application/pkix-cert' described in 920 that specification. Note that this introduces key lifecycle 921 management concerns; were a domain to change the key available at the 922 Identity-Info URI before a verifier evaluates a request signed by an 923 authentication service, this would cause obvious verifier failures. 924 When a rollover occurs, authentication services SHOULD thus provide 925 new Identity-Info URIs for each new certificate, and SHOULD continue 926 to make older key acquisition URIs available for a duration longer 927 than the plausible lifetime of a SIP message (an hour would most 928 likely suffice). 930 The Identity-Info header field MUST contain an 'alg' parameter. No 931 other parameters are defined for the Identity-Info header in this 932 document. Future Standards Track RFCs may define additional 933 Identity-Info header parameters. 935 This document adds the following entries to Table 2 of RFC 3261 936 [RFC3261]: 938 Header field where proxy ACK BYE CAN INV OPT REG 939 ------------ ----- ----- --- --- --- --- --- --- 940 Identity R a o o - o o o 942 SUB NOT REF INF UPD PRA 943 --- --- --- --- --- --- 944 o o o o o o 946 Header field where proxy ACK BYE CAN INV OPT REG 947 ------------ ----- ----- --- --- --- --- --- --- 948 Identity-Info R a o o - o o o 950 SUB NOT REF INF UPD PRA 951 --- --- --- --- --- --- 952 o o o o o o 954 Note, in the table above, that this mechanism does not protect the 955 CANCEL method. The CANCEL method cannot be challenged, because it is 956 hop-by-hop, and accordingly authentication service behavior for 957 CANCEL would be significantly limited. Note as well that the 958 REGISTER method uses Contact header fields in very unusual ways that 959 complicate its applicability to this mechanism, and the use of 960 Identity with REGISTER is consequently a subject for future study, 961 although it is left as optional here for forward-compatibility 962 reasons. The Identity and Identity-Info header MUST NOT appear in 963 CANCEL. 965 12. Compliance Tests and Examples 967 The examples in this section illustrate the use of the Identity 968 header in the context of a SIP transaction. Implementers are advised 969 to verify their compliance with the specification against the 970 following criteria: 972 Implementations of the authentication service role MUST generate 973 identical base64 identity strings to the ones shown in the 974 Identity headers in these examples when presented with the source 975 message and utilizing the appropriate supplied private key for the 976 domain in question. 978 Implementations of the verifier role MUST correctly validate the 979 given messages containing the Identity header when utilizing the 980 supplied certificates (with the caveat about self-signed 981 certificates below). 983 Note that the following examples use self-signed certificates, rather 984 than certificates issued by a recognized certificate authority. The 985 use of self-signed certificates for this mechanism is NOT 986 RECOMMENDED, and it appears here only for illustrative purposes. 987 Therefore, in compliance testing, implementations of verifiers SHOULD 988 generate appropriate warnings about the use of self-signed 989 certificates. Also, the example certificates in this section have 990 placed their domain name subject in the subjectAltName field; in 991 practice, certificate authorities may place domain names in other 992 locations in the certificate (see Section 15.4 for more information). 994 Note that all examples in this section use the 'rsa-sha1' algorithm. 996 Bit-exact reference files for these messages and their various 997 transformations are supplied in Appendix B. 999 12.1. Identity-Info with a Singlepart MIME body 1000 Consider the following private key and certificate pair assigned to 1001 'atlanta.example.com' (rendered in OpenSSL format). 1003 -----BEGIN RSA PRIVATE KEY----- 1004 MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO 1005 aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc 1006 IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB 1007 AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt 1008 PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw 1009 +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30 1010 tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H 1011 0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 1012 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C 1013 DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r 1014 xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU 1015 6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK 1016 Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk 1017 -----END RSA PRIVATE KEY----- 1019 -----BEGIN CERTIFICATE----- 1020 MIIC3TCCAkagAwIBAgIBADANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEL 1021 MAkGA1UECAwCR0ExEDAOBgNVBAcMB0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAa 1022 BgNVBAMME2F0bGFudGEuZXhhbXBsZS5jb20wHhcNMDUxMDI0MDYzNjA2WhcNMDYx 1023 MDI0MDYzNjA2WjBZMQswCQYDVQQGEwJVUzELMAkGA1UECAwCR0ExEDAOBgNVBAcM 1024 B0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAaBgNVBAMME2F0bGFudGEuZXhhbXBs 1025 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM88wG0dWg+RdX5nqOrU 1026 uyB9MQtVanLYFVR98kw8fTosvRwlJA5oh5XMiiPNa2lq4HsjKVkqUCMHl/jb21G6 1027 hSJ50LAwspuVYCpm3p4dakI1knuU41wgTCeaHacBxwqTzcun9Ufe2ABL/jcNChfa 1028 yd2diH6DznbY/PCDsQZaynPPAgMBAAGjgbQwgbEwHQYDVR0OBBYEFNmU/MrbVYcE 1029 KDr/20WISrG1j1rNMIGBBgNVHSMEejB4gBTZlPzK21WHBCg6/9tFiEqxtY9azaFd 1030 pFswWTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkdBMRAwDgYDVQQHDAdBdGxhbnRh 1031 MQ0wCwYDVQQKDARJRVRGMRwwGgYDVQQDDBNhdGxhbnRhLmV4YW1wbGUuY29tggEA 1032 MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADdQYtswBDmTSTq0mt211 1033 7alm/XGFrb2zdbU0vorxRdOZ04qMyrIpXG1LEmnEOgcocyrXRBvq5p6WbZAcEQk0 1034 DsE3Ve0Nc8x9nmvljW7GsMGFCnCuo4ODTf/1lGdVr9DeCzcj10YUQ3MRemDMXhY2 1035 CtDisLWl7SXOORcZAi1oU9w= 1036 -----END CERTIFICATE----- 1038 A user of atlanta.example.com, Alice, wants to send an INVITE to 1039 bob@biloxi.example.org. She therefore creates the following INVITE 1040 request, which she forwards to the atlanta.example.org proxy server 1041 that instantiates the authentication service role: 1043 INVITE sip:bob@biloxi.example.org SIP/2.0 1044 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 1045 To: Bob 1046 From: Alice ;tag=1928301774 1047 Call-ID: a84b4c76e66710 1048 CSeq: 314159 INVITE 1049 Max-Forwards: 70 1050 Date: Thu, 21 Feb 2002 13:02:03 GMT 1051 Contact: 1052 Content-Type: application/sdp 1053 Content-Length: 147 1055 v=0 1056 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 1057 s=Session SDP 1058 c=IN IP4 pc33.atlanta.example.com 1059 t=0 0 1060 m=audio 49172 RTP/AVP 0 1061 a=rtpmap:0 PCMU/8000 1063 When the authentication service receives the INVITE, it authenticates 1064 Alice by sending a 407 response. As a result, Alice adds an 1065 Authorization header to her request, and resends to the 1066 atlanta.example.com authentication service. Now that the service is 1067 sure of Alice's identity, it calculates an Identity header for the 1068 request. The canonical string over which the identity signature will 1069 be generated is the following (note that the first line wraps because 1070 of RFC editorial conventions): 1072 sip:alice@atlanta.example.com|sip:bob@biloxi.example.org| 1073 a84b4c76e66710|314159 INVITE|Thu, 21 Feb 2002 13:02:03 GMT| 1074 sip:alice@pc33.atlanta.example.com|v=0 1075 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 1076 s=Session SDP 1077 c=IN IP4 pc33.atlanta.example.com 1078 t=0 0 1080 m=audio 49172 RTP/AVP 0 1081 a=rtpmap:0 PCMU/8000 1083 The resulting signature (sha1WithRsaEncryption) using the private RSA 1084 key given above, with base64 encoding, is the following: 1086 ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa 1087 ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn 1088 FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U= 1090 Accordingly, the atlanta.example.com authentication service will 1091 create an Identity header containing that base64 signature string 1092 (175 bytes). It will also add an HTTPS URL where its certificate is 1093 made available. With those two headers added, the message looks like 1094 the following: 1096 INVITE sip:bob@biloxi.example.org SIP/2.0 1097 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 1098 To: Bob 1099 From: Alice ;tag=1928301774 1100 Call-ID: a84b4c76e66710 1101 CSeq: 314159 INVITE 1102 Max-Forwards: 70 1103 Date: Thu, 21 Feb 2002 13:02:03 GMT 1104 Contact: 1105 Identity: 1106 "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa 1107 ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn 1108 FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" 1109 Identity-Info: ;alg=rsa-sha1 1110 Content-Type: application/sdp 1111 Content-Length: 147 1112 v=0 1113 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 1114 s=Session SDP 1115 c=IN IP4 pc33.atlanta.example.com 1116 t=0 0 1117 m=audio 49172 RTP/AVP 0 1118 a=rtpmap:0 PCMU/8000 1120 atlanta.example.com then forwards the request normally. When Bob 1121 receives the request, if he does not already know the certificate of 1122 atlanta.example.com, he dereferences the URL in the Identity-Info 1123 header to acquire the certificate. Bob then generates the same 1124 canonical string given above, from the same headers of the SIP 1125 request. Using this canonical string, the signed digest in the 1126 Identity header, and the certificate discovered by dereferencing the 1128 Identity-Info header, Bob can verify that the given set of headers 1129 and the message body have not been modified. 1131 12.2. Identity for a Request with No MIME Body or Contact 1133 Consider the following private key and certificate pair assigned to 1134 "biloxi.example.org". 1136 -----BEGIN RSA PRIVATE KEY----- 1137 MIICXgIBAAKBgQC/obBYLRMPjskrAqWOiGPAUxI3/m2ti7ix4caqCTAuFX5cLegQ 1138 7nmquLOHfIhxVIqT2f06UA0lOo2NVofK9G7MTkVbVNiyAlLYUDEj7XWLDICf3ZHL 1139 6Fr/+CF7wrQ9r4kv7XiJKxodVCCd/DhCT9Gp+VDoe8HymqOW/KsneriyIwIDAQAB 1140 AoGBAJ7fsFIKXKkjWgj8ksGOthS3Sn19xPSCyEdBxfEm2Pj7/Nzzeli/PcOaic0k 1141 JALBcnqN2fHEeIGK/9xUBxTufgQYVJqvyHERs6rXX/iT4Ynm9t1905EiQ9ZpHsrI 1142 /AMMUYA1QrGgAIHvZLVLzq+9KLDEZ+HQbuCLJXF+6bl0Eb5BAkEA636oMANp0Qa3 1143 mYWEQ2utmGsYxkXSfyBb18TCOwCty0ndBR24zyOJF2NbZS98Lz+Ga25hfIGw/JHK 1144 nD9bOE88UwJBANBRSpd4bmS+m48R/13tRESAtHqydNinX0kS/RhwHr7mkHTU3k/M 1145 FxQtx34I3GKzaZxMn0A66KS9v/SHdnF+ePECQQCGe7QshyZ8uitLPtZDclCWhEKH 1146 qAQHmUEZvUF2VHLrbukLLOgHUrHNa24cILv4d3yaCVUetymNcuyTwhKj24wFAkAO 1147 z/jx1EplN3hwL+NsllZoWI58uvu7/Aq2c3czqaVGBbb317sHCYgKk0bAG3kwO3mi 1148 93/LXWT1cdiYVpmBcHDBAkEAmpgkFj+xZu5gWASY5ujv+FCMP0WwaH5hTnXu+tKe 1149 PJ3d2IJZKxGnl6itKRN7GeRh9PSK0kZSqGFeVrvsJ4Nopg== 1150 -----END RSA PRIVATE KEY----- 1152 -----BEGIN CERTIFICATE----- 1153 MIIC1jCCAj+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJVUzEL 1154 MAkGA1UECAwCTVMxDzANBgNVBAcMBkJpbG94aTENMAsGA1UECgwESUVURjEbMBkG 1155 A1UEAwwSYmlsb3hpLmV4YW1wbGUuY29tMB4XDTA1MTAyNDA2NDAyNloXDTA2MTAy 1156 NDA2NDAyNlowVzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAk1TMQ8wDQYDVQQHDAZC 1157 aWxveGkxDTALBgNVBAoMBElFVEYxGzAZBgNVBAMMEmJpbG94aS5leGFtcGxlLmNv 1158 bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv6GwWC0TD47JKwKljohjwFMS 1159 N/5trYu4seHGqgkwLhV+XC3oEO55qrizh3yIcVSKk9n9OlANJTqNjVaHyvRuzE5F 1160 W1TYsgJS2FAxI+11iwyAn92Ry+ha//ghe8K0Pa+JL+14iSsaHVQgnfw4Qk/RqflQ 1161 6HvB8pqjlvyrJ3q4siMCAwEAAaOBsTCBrjAdBgNVHQ4EFgQU0Z+RL47W/APDtc5B 1162 fSoQXuEFE/wwfwYDVR0jBHgwdoAU0Z+RL47W/APDtc5BfSoQXuEFE/yhW6RZMFcx 1163 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJNUzEPMA0GA1UEBwwGQmlsb3hpMQ0wCwYD 1164 VQQKDARJRVRGMRswGQYDVQQDDBJiaWxveGkuZXhhbXBsZS5jb22CAQAwDAYDVR0T 1165 BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBiyKHIt8TXfGNfpnJXi5jCizOxmY8Y 1166 gln8tyPFaeyq95TGcvTCWzdoBLVpBD+fpRWrX/II5sE6VHbbAPjjVmKbZwzQAtpp 1167 P2Fauj28t94ZeDHN2vqzjfnHjCO24kG3Juf2T80ilp9YHcDwxjUFrt86UnlC+yid 1168 yaTeusW5Gu7v1g== 1169 -----END CERTIFICATE----- 1171 Bob (bob@biloxi.example.org) now wants to send a BYE request to Alice 1172 at the end of the dialog initiated in the previous example. He 1173 therefore creates the following BYE request, which he forwards to the 1174 'biloxi.example.org' proxy server that instantiates the 1175 authentication service role: 1177 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 1178 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 1179 Max-Forwards: 70 1180 From: Bob ;tag=a6c85cf 1181 To: Alice ;tag=1928301774 1182 Call-ID: a84b4c76e66710 1183 CSeq: 231 BYE 1184 Content-Length: 0 1186 When the authentication service receives the BYE, it authenticates 1187 Bob by sending a 407 response. As a result, Bob adds an 1188 Authorization header to his request, and resends to the 1189 biloxi.example.org authentication service. Now that the service is 1190 sure of Bob's identity, it prepares to calculate an Identity header 1191 for the request. Note that this request does not have a Date header 1192 field. Accordingly, the biloxi.example.org will add a Date header to 1193 the request before calculating the identity signature. If the 1194 Content-Length header were not present, the authentication service 1195 would add it as well. The baseline message is thus: 1197 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 1198 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 1199 Max-Forwards: 70 1200 From: Bob ;tag=a6c85cf 1201 To: Alice ;tag=1928301774 1202 Date: Thu, 21 Feb 2002 14:19:51 GMT 1203 Call-ID: a84b4c76e66710 1204 CSeq: 231 BYE 1205 Content-Length: 0 1207 Also note that this request contains no Contact header field. 1208 Accordingly, biloxi.example.org will place no value in the canonical 1209 string for the addr-spec of the Contact address. Also note that 1210 there is no message body, and accordingly, the signature string will 1211 terminate, in this case, with two vertical bars. The canonical 1212 string over which the identity signature will be generated is the 1213 following (note that the first line wraps because of RFC editorial 1214 conventions): 1216 sip:bob@biloxi.example.org|sip:alice@atlanta.example.com| 1217 a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT|| 1219 The resulting signature (sha1WithRsaEncryption) using the private RSA 1220 key given above for biloxi.example.org, with base64 encoding, is the 1221 following: 1223 sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 1224 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 1225 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs= 1226 Accordingly, the biloxi.example.org authentication service will 1227 create an Identity header containing that base64 signature string. 1228 It will also add an HTTPS URL where its certificate is made 1229 available. With those two headers added, the message looks like the 1230 following: 1232 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 1233 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 1234 Max-Forwards: 70 1235 From: Bob ;tag=a6c85cf 1236 To: Alice ;tag=1928301774 1237 Date: Thu, 21 Feb 2002 14:19:51 GMT 1238 Call-ID: a84b4c76e66710 1239 CSeq: 231 BYE 1240 Identity: 1241 "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 1242 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 1243 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=" 1244 Identity-Info: ;alg=rsa-sha1 1245 Content-Length: 0 1247 biloxi.example.org then forwards the request normally. 1249 13. Identity and the TEL URI Scheme 1251 Since many SIP applications provide a Voice over IP (VoIP) service, 1252 telephone numbers are commonly used as identities in SIP deployments. 1253 In the majority of cases, this is not problematic for the identity 1254 mechanism described in this document. Telephone numbers commonly 1255 appear in the username portion of a SIP URI (e.g., 1256 'sip:+17005551008@chicago.example.com;user=phone'). That username 1257 conforms to the syntax of the TEL URI scheme (RFC 3966 [RFC3966]). 1258 For this sort of SIP address-of-record, chicago.example.com is the 1259 appropriate signatory. 1261 It is also possible for a TEL URI to appear in the SIP To or From 1262 header field outside the context of a SIP or SIPS URI (e.g., 1263 'tel:+17005551008'). In this case, it is much less clear which 1264 signatory is appropriate for the identity. Fortunately for the 1265 identity mechanism, this form of the TEL URI is more common for the 1266 To header field and Request-URI in SIP than in the From header field, 1267 since the UAC has no option but to provide a TEL URI alone when the 1268 remote domain to which a request is sent is unknown. The local 1269 domain, however, is usually known by the UAC, and accordingly it can 1270 form a proper From header field containing a SIP URI with a username 1271 in TEL URI form. Implementations that intend to send their requests 1272 through an authentication service SHOULD put telephone numbers in the 1273 From header field into SIP or SIPS URIs whenever possible. 1275 If the local domain is unknown to a UAC formulating a request, it 1276 most likely will not be able to locate an authentication service for 1277 its request, and therefore the question of providing identity in 1278 these cases is somewhat moot. However, an authentication service MAY 1279 sign a request containing a TEL URI in the From header field. This 1280 is permitted in this specification strictly for forward compatibility 1281 purposes. In the longer-term, it is possible that ENUM [14] may 1282 provide a way to determine which administrative domain is responsible 1283 for a telephone number, and this may aid in the signing and 1284 verification of SIP identities that contain telephone numbers. This 1285 is a subject for future work. 1287 14. Privacy Considerations 1289 The identity mechanism presented in this document is compatible with 1290 the standard SIP practices for privacy described in RFC 3323 1291 [RFC3323]. A SIP proxy server can act both as a privacy service and 1292 as an authentication service. Since a user agent can provide any 1293 From header field value that the authentication service is willing to 1294 authorize, there is no reason why private SIP URIs that contain 1295 legitimate domains (e.g., sip:anonymous@example.com) cannot be signed 1296 by an authentication service. The construction of the Identity 1297 header is the same for private URIs as it is for any other sort of 1298 URIs. 1300 Note, however, that an authentication service must possess a 1301 certificate corresponding to the host portion of the addr-spec of the 1302 From header field of any request that it signs; accordingly, using 1303 domains like 'anonymous.invalid' will not be possible for privacy 1304 services that also act as authentication services. The assurance 1305 offered by the usage of anonymous URIs with a valid domain portion is 1306 "this is a known user in my domain that I have authenticated, but I 1307 am keeping its identity private". The use of the domain 1308 'anonymous.invalid' entails that no corresponding authority for the 1309 domain can exist, and as a consequence, authentication service 1310 functions are meaningless. 1312 The "header" level of privacy described in RFC 3323 [RFC3323] 1313 requests that a privacy service alter the Contact header field value 1314 of a SIP message. Since the Contact header field is protected by the 1315 signature in an Identity header, privacy services cannot be applied 1316 after authentication services without a resulting integrity 1317 violation. 1319 RFC 3325 [RFC3325] defines the "id" priv-value token, which is 1320 specific to the P-Asserted-Identity header. The sort of assertion 1321 provided by the P-Asserted-Identity header is very different from the 1322 Identity header presented in this document. It contains additional 1323 information about the sender of a message that may go beyond what 1324 appears in the From header field; P-Asserted-Identity holds a 1325 definitive identity for the sender that is somehow known to a closed 1326 network of intermediaries that presumably the network will use this 1327 identity for billing or security purposes. The danger of this 1328 network-specific information leaking outside of the closed network 1329 motivated the "id" priv-value token. The "id" priv-value token has 1330 no implications for the Identity header, and privacy services MUST 1331 NOT remove the Identity header when a priv-value of "id" appears in a 1332 Privacy header. 1334 Finally, note that unlike RFC 3325 [RFC3325], the mechanism described 1335 in this specification adds no information to SIP requests that has 1336 privacy implications. 1338 15. Security Considerations 1340 15.1. Handling of digest-string Elements 1342 This document describes a mechanism that provides a signature over 1343 the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP 1344 requests. While a signature over the From header field would be 1345 sufficient to secure a URI alone, the additional headers provide 1346 replay protection and reference integrity necessary to make sure that 1347 the Identity header will not be used in cut-and-paste attacks. In 1348 general, the considerations related to the security of these headers 1349 are the same as those given in RFC 3261 [RFC3261] for including 1350 headers in tunneled 'message/sip' MIME bodies (see Section 23 in 1351 particular). The following section details the individual security 1352 properties obtained by including each of these header fields within 1353 the signature; collectively, this set of header fields provides the 1354 necessary properties to prevent impersonation. 1356 The From header field indicates the identity of the sender of the 1357 message, and the SIP address-of-record URI in the From header field 1358 is the identity of a SIP user, for the purposes of this document. 1359 The To header field provides the identity of the SIP user that this 1360 request targets. Providing the To header field in the Identity 1361 signature serves two purposes: first, it prevents cut-and-paste 1362 attacks in which an Identity header from legitimate request for one 1363 user is cut-and-pasted into a request for a different user; second, 1364 it preserves the starting URI scheme of the request, which helps 1365 prevent downgrade attacks against the use of SIPS. 1367 The Date and Contact headers provide reference integrity and replay 1368 protection, as described in RFC 3261 [RFC3261], Section 23.4.2. 1369 Implementations of this specification MUST NOT deem valid a request 1370 with an outdated Date header field (the RECOMMENDED interval is that 1371 the Date header must indicate a time within 3600 seconds of the 1372 receipt of a message). Implementations MUST also record Call-IDs 1373 received in valid requests containing an Identity header, and MUST 1374 remember those Call-IDs for at least the duration of a single Date 1375 interval (i.e., commonly 3600 seconds). Because a SIP-compliant UA 1376 never generates the same Call-ID twice, verifiers can use the Call-ID 1377 to recognize cut-and-paste attacks; the Call-ID serves as a nonce. 1378 The result of this is that if an Identity header is replayed within 1379 the Date interval, verifiers will recognize that it is invalid 1380 because of a Call-ID duplication; if an Identity header is replayed 1381 after the Date interval, verifiers will recognize that it is invalid 1382 because the Date is stale. The CSeq header field contains a numbered 1383 identifier for the transaction, and the name of the method of the 1384 request; without this information, an INVITE request could be cut- 1385 and-pasted by an attacker and transformed into a BYE request without 1386 changing any fields covered by the Identity header, and moreover 1387 requests within a certain transaction could be replayed in 1388 potentially confusing or malicious ways. 1390 The Contact header field is included to tie the Identity header to a 1391 particular user agent instance that generated the request. Were an 1392 active attacker to intercept a request containing an Identity header, 1393 and cut-and-paste the Identity header field into its own request 1394 (reusing the From, To, Contact, Date, and Call-ID fields that appear 1395 in the original message), the attacker would not be eligible to 1396 receive SIP requests from the called user agent, since those requests 1397 are routed to the URI identified in the Contact header field. 1398 However, the Contact header is only included in dialog-forming 1399 requests, so it does not provide this protection in all cases. 1401 It might seem attractive to provide a signature over some of the 1402 information present in the Via header field value(s). For example, 1403 without a signature over the sent-by field of the topmost Via header, 1404 an attacker could remove that Via header and insert its own in a cut- 1405 and-paste attack, which would cause all responses to the request to 1406 be routed to a host of the attacker's choosing. However, a signature 1407 over the topmost Via header does not prevent attacks of this nature, 1408 since the attacker could leave the topmost Via intact and merely 1409 insert a new Via header field directly after it, which would cause 1410 responses to be routed to the attacker's host "on their way" to the 1411 valid host, which has exactly the same end result. Although it is 1412 possible that an intermediary-based authentication service could 1413 guarantee that no Via hops are inserted between the sending user 1414 agent and the authentication service, it could not prevent an 1415 attacker from adding a Via hop after the authentication service, and 1416 thereby preempting responses. It is necessary for the proper 1417 operation of SIP for subsequent intermediaries to be capable of 1418 inserting such Via header fields, and thus it cannot be prevented. 1419 As such, though it is desirable, securing Via is not possible through 1420 the sort of identity mechanism described in this document; the best 1421 known practice for securing Via is the use of SIPS. 1423 This mechanism also provides a signature over the bodies of SIP 1424 requests. The most important reason for doing so is to protect 1425 Session Description Protocol (SDP) bodies carried in SIP requests. 1426 There is little purpose in establishing the identity of the user that 1427 originated a SIP request if this assurance is not coupled with a 1428 comparable assurance over the media descriptors. Note, however, that 1429 this is not perfect end-to-end security. The authentication service 1430 itself, when instantiated at a intermediary, could conceivably change 1431 the SDP (and SIP headers, for that matter) before providing a 1432 signature. Thus, while this mechanism reduces the chance that a 1433 replayer or man-in-the-middle will modify SDP, it does not eliminate 1434 it entirely. Since it is a foundational assumption of this mechanism 1435 that the users trust their local domain to vouch for their security, 1436 they must also trust the service not to violate the integrity of 1437 their message without good reason. Note that RFC 3261 [RFC3261], 1438 Section 16.6 states that SIP proxy servers "MUST NOT add to, modify, 1439 or remove the message body." 1441 In the end analysis, the Identity and Identity-Info headers cannot 1442 protect themselves. Any attacker could remove these headers from a 1443 SIP request, and modify the request arbitrarily afterwards. However, 1444 this mechanism is not intended to protect requests from men-in-the- 1445 middle who interfere with SIP messages; it is intended only to 1446 provide a way that SIP users can prove definitively that they are who 1447 they claim to be. At best, by stripping identity information from a 1448 request, a man-in-the-middle could make it impossible to distinguish 1449 any illegitimate messages he would like to send from those messages 1450 sent by an authorized user. However, it requires a considerably 1451 greater amount of energy to mount such an attack than it does to 1452 mount trivial impersonations by just copying someone else's From 1453 header field. This mechanism provides a way that an authorized user 1454 can provide a definitive assurance of his identity that an 1455 unauthorized user, an impersonator, cannot. 1457 One additional respect in which the Identity-Info header cannot 1458 protect itself is the 'alg' parameter. The 'alg' parameter is not 1459 included in the digest-string, and accordingly, a man-in-the-middle 1460 might attempt to modify the 'alg' parameter. However, it is 1461 important to note that preventing men-in-the-middle is not the 1462 primary impetus for this mechanism. Moreover, changing the 'alg' 1464 would at worst result in some sort of bid-down attack, and at best 1465 cause a failure in the verifier. Note that only one valid 'alg' 1466 parameter is defined in this document and that thus there is 1467 currently no weaker algorithm to which the mechanism can be bid down. 1468 'alg' has been incorporated into this mechanism for forward- 1469 compatibility reasons in case the current algorithm exhibits 1470 weaknesses, and requires swift replacement, in the future. 1472 15.2. Display-Names and Identity 1474 As a matter of interface design, SIP user agents might render the 1475 display-name portion of the From header field of a caller as the 1476 identity of the caller; there is a significant precedent in email 1477 user interfaces for this practice. As such, it might seem that the 1478 lack of a signature over the display-name is a significant omission. 1480 However, there are several important senses in which a signature over 1481 the display-name does not prevent impersonation. In the first place, 1482 a particular display-name, like "Jon Peterson", is not unique in the 1483 world; many users in different administrative domains might 1484 legitimately claim that name. Furthermore, enrollment practices for 1485 SIP-based services might have a difficult time discerning the 1486 legitimate display-name for a user; it is safe to assume that 1487 impersonators will be capable of creating SIP accounts with arbitrary 1488 display-names. The same situation prevails in email today. Note 1489 that an impersonator who attempted to replay a message with an 1490 Identity header, changing only the display-name in the From header 1491 field, would be detected by the other replay protection mechanisms 1492 described in Section 15.1. 1494 Of course, an authentication service can enforce policies about the 1495 display-name even if the display-name is not signed. The exact 1496 mechanics for creating and operationalizing such policies is outside 1497 the scope of this document. The effect of this policy would not be 1498 to prevent impersonation of a particular unique identifier like a SIP 1499 URI (since display-names are not unique identifiers), but to allow a 1500 domain to manage the claims made by its users. If such policies are 1501 enforced, users would not be free to claim any display-name of their 1502 choosing. In the absence of a signature, man-in-the-middle attackers 1503 could conceivably alter the display-names in a request with impunity. 1504 Note that the scope of this specification is impersonation attacks, 1505 however, and that a man-in-the-middle might also strip the Identity 1506 and Identity-Info headers from a message. 1508 There are many environments in which policies regarding the display- 1509 name aren't feasible. Distributing bit-exact and internationalizable 1510 display-names to end-users as part of the enrollment or registration 1511 process would require mechanisms that are not explored in this 1513 document. In the absence of policy enforcement regarding domain 1514 names, there are conceivably attacks that an adversary could mount 1515 against SIP systems that rely too heavily on the display-name in 1516 their user interface, but this argues for intelligent interface 1517 design, not changes to the mechanisms. Relying on a non-unique 1518 identifier for identity would ultimately result in a weak mechanism. 1520 15.3. Securing the Connection to the Authentication Service 1522 The assurance provided by this mechanism is strongest when a user 1523 agent forms a direct connection, preferably one secured by TLS, to an 1524 intermediary-based authentication service. The reasons for this are 1525 twofold: 1527 If a user does not receive a certificate from the authentication 1528 service over this TLS connection that corresponds to the expected 1529 domain (especially when the user receives a challenge via a 1530 mechanism such as Digest), then it is possible that a rogue server 1531 is attempting to pose as an authentication service for a domain 1532 that it does not control, possibly in an attempt to collect shared 1533 secrets for that domain. 1535 Without TLS, the various header field values and the body of the 1536 request will not have integrity protection when the request 1537 arrives at an authentication service. Accordingly, a prior 1538 legitimate or illegitimate intermediary could modify the message 1539 arbitrarily. 1541 Of these two concerns, the first is most material to the intended 1542 scope of this mechanism. This mechanism is intended to prevent 1543 impersonation attacks, not man-in-the-middle attacks; integrity over 1544 the header and bodies is provided by this mechanism only to prevent 1545 replay attacks. However, it is possible that applications relying on 1546 the presence of the Identity header could leverage this integrity 1547 protection, especially body integrity, for services other than replay 1548 protection. 1550 Accordingly, direct TLS connections SHOULD be used between the UAC 1551 and the authentication service whenever possible. The opportunistic 1552 nature of this mechanism, however, makes it very difficult to 1553 constrain UAC behavior, and moreover there will be some deployment 1554 architectures where a direct connection is simply infeasible and the 1555 UAC cannot act as an authentication service itself. Accordingly, 1556 when a direct connection and TLS are not possible, a UAC should use 1557 the SIPS mechanism, Digest 'auth-int' for body integrity, or both 1558 when it can. The ultimate decision to add an Identity header to a 1559 request lies with the authentication service, of course; domain 1560 policy must identify those cases where the UAC's security association 1561 with the authentication service is too weak. 1563 15.4. Domain Names and Subordination 1565 When a verifier processes a request containing an Identity-Info 1566 header, it must compare the domain portion of the URI in the From 1567 header field of the request with the domain name that is the subject 1568 of the certificate acquired from the Identity-Info header. While it 1569 might seem that this should be a straightforward process, it is 1570 complicated by two deployment realities. In the first place, 1571 certificates have varying ways of describing their subjects, and may 1572 indeed have multiple subjects, especially in 'virtual hosting' cases 1573 where multiple domains are managed by a single application. 1574 Secondly, some SIP services may delegate SIP functions to a 1575 subordinate domain and utilize the procedures in RFC 3263 [RFC3263] 1576 that allow requests for, say, 'example.com' to be routed to 1577 'sip.example.com'. As a result, a user with the AoR 1578 'sip:jon@example.com' may process its requests through a host like 1579 'sip.example.com', and it may be that latter host that acts as an 1580 authentication service. 1582 To meet the second of these problems, a domain that deploys an 1583 authentication service on a subordinate host MUST be willing to 1584 supply that host with the private keying material associated with a 1585 certificate whose subject is a domain name that corresponds to the 1586 domain portion of the AoRs that the domain distributes to users. 1587 Note that this corresponds to the comparable case of routing inbound 1588 SIP requests to a domain. When the NAPTR and SRV procedures of RFC 1589 3263 are used to direct requests to a domain name other than the 1590 domain in the original Request-URI (e.g., for 'sip:jon@example.com', 1591 the corresponding SRV records point to the service 1592 'sip1.example.org'), the client expects that the certificate passed 1593 back in any TLS exchange with that host will correspond exactly with 1594 the domain of the original Request-URI, not the domain name of the 1595 host. Consequently, in order to make inbound routing to such SIP 1596 services work, a domain administrator must similarly be willing to 1597 share the domain's private key with the service. This design 1598 decision was made to compensate for the insecurity of the DNS, and it 1599 makes certain potential approaches to DNS-based 'virtual hosting' 1600 unsecurable for SIP in environments where domain administrators are 1601 unwilling to share keys with hosting services. 1603 A verifier MUST evaluate the correspondence between the user's 1604 identity and the signing certificate by following the procedures 1605 defined in RFC 2818 [RFC2818], Section 3.1. While RFC 2818 [RFC2818] 1606 deals with the use of HTTP in TLS, the procedures described are 1607 applicable to verifying identity if one substitutes the "hostname of 1608 the server" in HTTP for the domain portion of the user's identity in 1609 the From header field of a SIP request with an Identity header. 1611 Because the domain certificates that can be used by authentication 1612 services need to assert only the hostname of the authentication 1613 service, existing certificate authorities can provide adequate 1614 certificates for this mechanism. However, not all proxy servers and 1615 user agents will be able to support the root certificates of all 1616 certificate authorities, and moreover there are some significant 1617 differences in the policies by which certificate authorities issue 1618 their certificates. This document makes no recommendations for the 1619 usage of particular certificate authorities, nor does it describe any 1620 particular policies that certificate authorities should follow, but 1621 it is anticipated that operational experience will create de facto 1622 standards for authentication services. Some federations of service 1623 providers, for example, might only trust certificates that have been 1624 provided by a certificate authority operated by the federation. It 1625 is strongly RECOMMENDED that self-signed domain certificates should 1626 not be trusted by verifiers, unless some previous key exchange has 1627 justified such trust. 1629 For further information on certificate security and practices, see 1630 RFC 3280 [RFC3280]. The Security Considerations of RFC 3280 1631 [RFC3280] are applicable to this document. 1633 15.5. Authorization and Transitional Strategies 1635 Ultimately, the worth of an assurance provided by an Identity header 1636 is limited by the security practices of the domain that issues the 1637 assurance. Relying on an Identity header generated by a remote 1638 administrative domain assumes that the issuing domain used its 1639 administrative practices to authenticate its users. However, it is 1640 possible that some domains will implement policies that effectively 1641 make users unaccountable (e.g., ones that accept unauthenticated 1642 registrations from arbitrary users). The value of an Identity header 1643 from such domains is questionable. While there is no magic way for a 1644 verifier to distinguish "good" from "bad" domains by inspecting a SIP 1645 request, it is expected that further work in authorization practices 1646 could be built on top of this identity solution; without such an 1647 identity solution, many promising approaches to authorization policy 1648 are impossible. That much said, it is RECOMMENDED that 1649 authentication services based on proxy servers employ strong 1650 authentication practices such as token-based identifiers. 1652 One cannot expect the Identity and Identity-Info headers to be 1653 supported by every SIP entity overnight. This leaves the verifier in 1654 a compromising position; when it receives a request from a given SIP 1655 user, how can it know whether or not the sender's domain supports 1656 Identity? In the absence of ubiquitous support for identity, some 1657 transitional strategies are necessary. 1659 A verifier could remember when it receives a request from a domain 1660 that uses Identity, and in the future, view messages received from 1661 that domain without Identity headers with skepticism. 1663 A verifier could query the domain through some sort of callback 1664 system to determine whether or not it is running an authentication 1665 service. There are a number of potential ways in which this could 1666 be implemented; use of the SIP OPTIONS method is one possibility. 1667 This is left as a subject for future work. 1669 In the long term, some sort of identity mechanism, either the one 1670 documented in this specification or a successor, must become 1671 mandatory-to-use for the SIP protocol; that is the only way to 1672 guarantee that this protection can always be expected by verifiers. 1674 Finally, it is worth noting that the presence or absence of the 1675 Identity headers cannot be the sole factor in making an authorization 1676 decision. Permissions might be granted to a message on the basis of 1677 the specific verified Identity or really on any other aspect of a SIP 1678 request. Authorization policies are outside the scope of this 1679 specification, but this specification advises any future 1680 authorization work not to assume that messages with valid Identity 1681 headers are always good. 1683 16. IANA Considerations 1684 This document requests changes to the header and response-code sub- 1685 registries of the SIP parameters IANA registry, and requests the 1686 creation of two new registries for parameters for the Identity-Info 1687 header. 1689 16.1. Header Field Names 1691 This document specifies two new SIP headers: Identity and Identity- 1692 Info. Their syntax is given in Section 11. These headers are 1693 defined by the following information, which has been added to the 1694 header sub-registry under http://www.iana.org/assignments/sip- 1695 parameters 1697 Header Name: Identity 1698 Compact Form: y 1699 Header Name: Identity-Info 1700 Compact Form: n 1702 16.2. 428 'Use Identity Header' Response Code 1704 This document registers a new SIP response code, which is described 1705 in Section 8. It is sent when a verifier receives a SIP request that 1706 lacks an Identity header in order to indicate that the request should 1707 be re-sent with an Identity header. This response code is defined by 1708 the following information, which has been added to the method and 1709 response-code sub-registry under http://www.iana.org/assignments/sip- 1710 parameters 1712 Response Code Number: 428 1713 Default Reason Phrase: Use Identity Header 1715 16.3. 436 'Bad Identity-Info' Response Code 1717 This document registers a new SIP response code, which is described 1718 in Section 8. It is used when the Identity-Info header contains a 1719 URI that cannot be dereferenced by the verifier (either the URI 1720 scheme is unsupported by the verifier, or the resource designated by 1721 the URI is otherwise unavailable). This response code is defined by 1722 the following information, which has been added to the method and 1723 response-code sub-registry under http://www.iana.org/assignments/sip- 1724 parameters 1726 Response Code Number: 436 1727 Default Reason Phrase: Bad Identity-Info 1729 16.4. 437 'Unsupported Certificate' Response Code 1731 This document registers a new SIP response code, which is described 1732 in Section 8. It is used when the verifier cannot validate the 1733 certificate referenced by the URI of the Identity-Info header, 1734 because, for example, the certificate is self-signed, or signed by a 1735 root certificate authority for whom the verifier does not possess a 1736 root certificate. This response code is defined by the following 1737 information, which has been added to the method and response-code 1738 sub-registry under http://www.iana.org/assignments/sip-parameters 1740 Response Code Number: 437 1741 Default Reason Phrase: Unsupported Certificate 1743 16.5. 438 'Invalid Identity Header' Response Code 1745 This document registers a new SIP response code, which is described 1746 in Section 8. It is used when the verifier receives a message with 1747 an Identity signature that does not correspond to the digest-string 1748 calculated by the verifier. This response code is defined by the 1749 following information, which has been added to the method and 1750 response-code sub-registry under http://www.iana.org/assignments/sip- 1751 parameters 1753 Response Code Number: 438 1754 Default Reason Phrase: Invalid Identity Header 1756 16.6. Identity-Info Parameters 1758 The IANA has created a new registry for Identity-Info headers. This 1759 registry is to be prepopulated with a single entry for a parameter 1760 called 'alg', which describes the algorithm used to create the 1761 signature that appears in the Identity header. Registry entries must 1762 contain the name of the parameter and the specification in which the 1763 parameter is defined. New parameters for the Identity-Info header 1764 may be defined only in Standards Track RFCs. 1766 16.7. Identity-Info Algorithm Parameter Values 1768 The IANA has created a new registry for Identity-Info 'alg' parameter 1769 values. This registry is to be prepopulated with a single entry for 1770 a value called 'rsa-sha1', which describes the algorithm used to 1771 create the signature that appears in the Identity header. Registry 1772 entries must contain the name of the 'alg' parameter value and the 1773 specification in which the value is described. New values for the 1774 'alg' parameter may be defined only in Standards Track RFCs. 1776 16.8. Acknowledgements 1778 The authors would like to thank 1780 16.9. Original RFC 4474 Requirements 1782 The following requirements were crafted throughout the development of 1783 the mechanism described in this document. They are preserved here 1784 for historical reasons. 1786 The mechanism must allow a UAC or a proxy server to provide a 1787 strong cryptographic identity assurance in a request that can be 1788 verified by a proxy server or UAS. 1790 User agents that receive identity assurances must be able to 1791 validate these assurances without performing any network lookup. 1793 User agents that hold certificates on behalf of their user must be 1794 capable of adding this identity assurance to requests. 1796 Proxy servers that hold certificates on behalf of their domain 1797 must be capable of adding this identity assurance to requests; a 1798 UAC is not required to support this mechanism in order for an 1799 identity assurance to be added to a request in this fashion. 1801 The mechanism must prevent replay of the identity assurance by an 1802 attacker. 1804 In order to provide full replay protection, the mechanism must be 1805 capable of protecting the integrity of SIP message bodies (to 1806 ensure that media offers and answers are linked to the signaling 1807 identity). 1809 It must be possible for a user to have multiple AoRs (i.e., 1810 accounts or aliases) that it is authorized to use within a domain, 1811 and for the UAC to assert one identity while authenticating itself 1812 as another, related, identity, as permitted by the local policy of 1813 the domain. 1815 17. References 1817 17.1. Normative References 1819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1820 Requirement Levels", BCP 14, RFC 2119, March 1997. 1822 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1824 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1825 A., Peterson, J., Sparks, R., Handley, M., and E. 1826 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1827 June 2002. 1829 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1830 X.509 Public Key Infrastructure Certificate and 1831 Certificate Revocation List (CRL) Profile", RFC 3280, 1832 April 2002. 1834 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1835 Initiation Protocol (SIP)", RFC 3323, November 2002. 1837 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1838 Algorithms", RFC 3370, August 2002. 1840 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1841 Encodings", RFC 3548, July 2003. 1843 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1844 Authenticated Identity Body (AIB) Format", RFC 3893, 1845 September 2004. 1847 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1848 Specifications: ABNF", RFC 4234, October 2005. 1850 17.2. Informative References 1852 [I-D.cooper-iab-secure-origin-00] 1853 Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, 1854 "Secure Call Origin Identification", draft-cooper-iab- 1855 secure-origin-00 (work in progress), November 2012. 1857 [I-D.peterson-secure-origin-ps] 1858 Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1859 Origin Identification: Problem Statement, Requirements, 1860 and Roadmap", draft-peterson-secure-origin-ps-00 (work in 1861 progress), May 2013. 1863 [I-D.peterson-sipping-retarget] 1864 Peterson, J., "Retargeting and Security in SIP: A 1865 Framework and Requirements", draft-peterson-sipping- 1866 retarget-00 (work in progress), February 2005. 1868 [I-D.rescorla-callerid-fallback] 1869 Rescorla, E.K., "Secure Caller-ID Fallback Mode", draft- 1870 rescorla-callerid-fallback-00 (work in progress), May 1871 2013. 1873 [I-D.rescorla-rtcweb-generic-idp] 1874 Rescorla, E., "RTCWEB Generic Identity Provider 1875 Interface", draft-rescorla-rtcweb-generic-idp-01 (work in 1876 progress), March 2012. 1878 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1879 Specifications: ABNF", RFC 2234, November 1997. 1881 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1882 Infrastructure Operational Protocols: FTP and HTTP", RFC 1883 2585, May 1999. 1885 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1886 Protocol (SIP): Locating SIP Servers", RFC 3263, June 1887 2002. 1889 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1890 Extensions to the Session Initiation Protocol (SIP) for 1891 Asserted Identity within Trusted Networks", RFC 3325, 1892 November 2002. 1894 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1895 Resource Identifiers (URI) Dynamic Delegation Discovery 1896 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1898 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 1899 3966, December 2004. 1901 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1902 Authenticated Identity Management in the Session 1903 Initiation Protocol (SIP)", RFC 4474, August 2006. 1905 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 1906 and H. Schulzrinne, "Session Initiation Protocol (SIP) 1907 Torture Test Messages", RFC 4475, May 2006. 1909 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 1910 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 1911 April 1 2013. 1913 Authors' Addresses 1915 Jon Peterson 1916 NeuStar 1918 Email: jon.peterson@neustar.biz 1919 Cullen Jennings 1920 Cisco 1921 400 3rd Avenue SW, Suite 350 1922 Calgary, AB T2P 4H2 1923 Canada 1925 Email: fluffy@iii.ca 1927 Eric Rescorla 1928 RTFM, Inc. 1929 2064 Edgewood Drive 1930 Palo Alto, CA 94303 1931 USA 1933 Phone: +1 650 678 2350 1934 Email: ekr@rtfm.com