idnits 2.17.1 draft-ietf-stir-rfc4474bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 30 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 281: '... MUST possess the private key of one...' RFC 2119 keyword, line 283: '...stantiate this role MUST be capable of...' RFC 2119 keyword, line 293: '...authentication service MUST add a Date...' RFC 2119 keyword, line 304: '...tication service MUST extract the iden...' RFC 2119 keyword, line 309: '...tication service MUST extract the host...' (62 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1012 has weird spacing: '... where prox...' == Line 1020 has weird spacing: '... where prox...' == Line 1028 has weird spacing: '... where prox...' -- The document date (October 22, 2014) is 3473 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) == Missing Reference: 'RFC 7375' is mentioned on line 140, but not defined == Unused Reference: 'RFC3280' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: 'RFC4501' is defined on line 1494, 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 informational reference (is this intentional?): RFC 3548 (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 4 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: April 25, 2015 Cisco 6 E. Rescorla 7 RTFM, Inc. 8 October 22, 2014 10 Authenticated Identity Management in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-stir-rfc4474bis-02.txt 14 Abstract 16 The baseline 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 requests. It does so by defining new 21 SIP header fields for conveying a signature used for validating the 22 identity, and for conveying a reference to the credentials of the 23 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 April 25, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview of Operations . . . . . . . . . . . . . . . . . . . 5 62 4. Signature Generation and Validation . . . . . . . . . . . . . 6 63 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 64 4.1.1. Intermediary Authentication Services . . . . . . . . 9 65 4.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 10 66 4.3. Identity within a Dialog and Retargeting . . . . . . . . 12 67 5. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 5.1. Credential Use by the Authentication Service . . . . . . 13 69 5.2. Credential Use by the Verification Service . . . . . . . 14 70 5.3. Handling Identity-Info URIs . . . . . . . . . . . . . . . 14 71 5.4. Credential Systems . . . . . . . . . . . . . . . . . . . 15 72 6. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 16 73 6.1. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 16 74 6.2. Usernames with Domain Names . . . . . . . . . . . . . . . 18 75 7. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 76 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 79 10.1. Handling of digest-string Elements . . . . . . . . . . . 24 80 10.2. Securing the Connection to the Authentication Service . 27 81 10.3. Authorization and Transitional Strategies . . . . . . . 28 82 10.4. Display-Names and Identity . . . . . . . . . . . . . . . 29 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 84 11.1. Header Field Names . . . . . . . . . . . . . . . . . . . 29 85 11.2. Identity-Info Parameters . . . . . . . . . . . . . . . . 29 86 11.3. Identity-Info Algorithm Parameter Values . . . . . . . . 29 87 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 88 13. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 30 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 90 14.1. Normative References . . . . . . . . . . . . . . . . . . 30 91 14.2. Informative References . . . . . . . . . . . . . . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 94 1. Introduction 96 This document provides enhancements to the existing mechanisms for 97 authenticated identity management in the Session Initiation Protocol 98 (SIP, [RFC3261]). An identity, for the purposes of this document, is 99 defined as either a SIP URI, commonly a canonical address-of-record 100 (AoR) employed to reach a user (such as 101 'sip:alice@atlanta.example.com'), or a telephone number, which can be 102 represented as either a TEL URI [RFC3966] or as the user portion of a 103 SIP URI. 105 [RFC3261] stipulates several places within a SIP request where users 106 can express an identity for themselves, primarily the user-populated 107 From header field. However, the recipient of a SIP request has no 108 way to verify that the From header field has been populated 109 appropriately, in the absence of some sort of cryptographic 110 authentication mechanism. This leaves SIP vulnerable to a category 111 of abuses, including impersonation attacks that enable robocalling 112 and related problems as described in [RFC7340]. 114 [RFC3261] specifies a number of security mechanisms that can be 115 employed by SIP user agents (UAs), including Digest, Transport Layer 116 Security (TLS), and S/MIME (implementations may support other 117 security schemes as well). However, few SIP user agents today 118 support the end-user certificates necessary to authenticate 119 themselves (via S/MIME, for example), and furthermore Digest 120 authentication is limited by the fact that the originator and 121 destination must share a prearranged secret. It is desirable for SIP 122 user agents to be able to send requests to destinations with which 123 they have no previous association -- just as in the telephone network 124 today, one can receive a call from someone with whom one has no 125 previous association, and still have a reasonable assurance that the 126 person's displayed calling party number (and/or Caller-ID) is 127 accurate. A cryptographic approach, like the one described in this 128 document, can provide a much stronger and less spoofable assurance of 129 identity than the telephone network provides today. 131 [RFC4474] previously specified a means of signing portions of SIP 132 requests in order to provide that identity assurance. However, RFC 133 4474 was in several ways misaligned with deployment realities (see 134 [I-D.rosenberg-sip-rfc4474-concerns]). Most significantly, RFC 4474 135 did not deal well with telephone numbers as identifiers, despite 136 their enduring use in SIP deployments. RFC 4474 also provided a 137 signature over material that intermediaries in the field commonly 138 altered. This specification therefore revises RFC 4474 in light of 139 recent reconsideration of the problem space to align with the threat 140 model in [RFC 7375]. 142 2. Background 144 The secure operation of many SIP applications and services depends on 145 authorization policies. These policies may be automated, or they may 146 be exercised manually by humans. An example of the latter would be 147 an Internet telephone application that displays the calling party 148 number (and/or Caller-ID) of a caller, which a human may review to 149 make a policy decision before answering a call. An example of the 150 former would be a voicemail service that compares the identity of the 151 caller to a whitelist before determining whether it should allow the 152 caller access to recorded messages. In both of these cases, 153 attackers might attempt to circumvent these authorization policies 154 through impersonation. Since the primary identifier of the sender of 155 a SIP request, the From header field, can be populated arbitrarily by 156 the controller of a user agent, impersonation is very simple today. 157 The mechanism described in this document provides a strong identity 158 system for SIP requests in which authorization policies cannot be 159 circumvented by impersonation. 161 This document proposes an authentication architecture for SIP in 162 which requests are processed by a logical authentication service that 163 may be implemented as part of a user agent or as a proxy server. 164 Once a message has been authenticated, the service then adds new 165 cryptographic information to requests to communicate to other SIP 166 entities that the sending user has been authenticated and its use of 167 the From header field has been authorized. 169 But authorized by whom? Identities are issued to users by 170 authorities. When a new user becomes associated with example.com, 171 the administrator of the SIP service for that domain will issue them 172 an identity in that namespace, such as alice@example.com. Alice may 173 then send REGISTER requests to example.com that make her user agents 174 eligible to receive requests for sip:alice@example.com. In some 175 cases, Alice may be the owner of the domain herself, and may issue 176 herself identities as she chooses. But ultimately, it is the 177 controller of the SIP service at example.com that must be responsible 178 for authorizing the use of names in the example.com domain. 179 Therefore, for the purposes of this specification, the credentials 180 needed to prove a user is authorized to use a particular From header 181 field must ultimately derive from the domain owner: either a user 182 agent gives requests to the domain name owner in order for them to be 183 signed by the domain owner's credentials, or the user agent must 184 possess credentials that prove in some fashion that the domain owner 185 has given the user agent the right to a name. 187 The situation is however more complicated for telephone numbers. 188 Authority over telephone numbers does not correspond directly to 189 Internet domains. While a user could register at a SIP domain with a 190 username that corresponds to a telephone number, any connection 191 between the administrator of that domain and the assignment of 192 telephone numbers is not currently reflected on the Internet. 193 Telephone numbers do not share the domain-scope property described 194 above, as they are dialed without any domain component. This 195 document thus assumes the existence of a separate means of 196 establishing authority over telephone numbers, for cases where the 197 telephone number is the identity of the user. As with SIP URIs, the 198 necessary credentials to prove authority for a name might reside 199 either in the endpoint or at some intermediary. 201 This document specifies a means of sharing a cryptographic assurance 202 of end-user SIP identity in an interdomain or intradomain context. 203 It relies on the authentication service adding to requests a SIP 204 header, the Identity header, which contains that cryptographic 205 assurance. In order to assist in the validation of the Identity 206 header, this specification also describes an Identity-Info header 207 that can be used by the recipient of a request to recover the 208 credentials of the signer. Note that the scope of this document is 209 limited to providing this identity assurance for SIP requests; 210 solving this problem for SIP responses is outside the scope of this 211 work (see [RFC4916]). 213 This specification allows either a user agent or a proxy server to 214 provide the authentication service function and/or to verify 215 identities. To maximize end-to-end security, it is obviously 216 preferable for end-users to acquire their own credentials; if they 217 do, their user agents can act as authentication services. However, 218 for some deployments end-user credentials may be neither practical 219 nor affordable, given the potentially large number of SIP user agents 220 (phones, PCs, laptops, PDAs, gaming devices) that may be employed by 221 a single user. In such environments, synchronizing keying material 222 across multiple devices may be prohobitively complex and require 223 quite a good deal of additional endpoint behavior. Managing several 224 credentials for the various devices could also be burdensome. In 225 these cases, implementation the authentication service at an 226 intermediary may be more practical. This trade-off needs to be 227 understood by implementers of this specification. 229 3. Overview of Operations 231 This section provides an informative (non-normative) high-level 232 overview of the mechanisms described in this document. 234 Imagine a case where Alice, who has the home proxy of example.com and 235 the address-of-record sip:alice@example.com, wants to communicate 236 with Bob at sip:bob@example.org. They have no prior relationship, 237 and Bob implements best practices to prevent impersonation attacks. 239 Alice generates an INVITE and places her identity, in this case her 240 address-of-record, in the From header field of the request. She then 241 sends an INVITE over TLS to an authentication service proxy for the 242 example.com domain. 244 The authentication service authenticates Alice (possibly by sending a 245 Digest authentication challenge) and validates that she is authorized 246 to assert the identity that she populated in the From header field. 247 This value is Alice's AoR, but in other cases it could be some 248 different value that the proxy server has authority over, such as a 249 telephone number. The proxy then computes a hash over some 250 particular headers, including the From header field (and optionally 251 the body) of the message. This hash is signed with the appropriate 252 credential for the identity (example.com, in the 253 sip:alice@example.com case) and inserted in a new header field in the 254 SIP message, the 'Identity' header. 256 The proxy, as the holder of the private key for the example.com 257 domain, is asserting that the originator of this request has been 258 authenticated and that she is authorized to claim the identity that 259 appears in the From header field. The proxy also inserts a companion 260 header field, Identity-Info, that tells Bob how to acquire keying 261 material necessary to validate its credentials (a public key), if he 262 doesn't already have it. 264 When Bob's domain receives the request, it verifies the signature 265 provided in the Identity header, and thus can validate that the 266 authority over the identity in the From header field authenticated 267 the user, and permitted the user to assert that From header field 268 value. This same validation operation may be performed by Bob's user 269 agent server (UAS). As the request has been validated, it is 270 rendered to Bob. If the validation was unsuccessful, some other 271 treatment would be applied by the receiving domain. 273 4. Signature Generation and Validation 275 4.1. Authentication Service Behavior 277 This document specifies a role for SIP entities called an 278 authentication service. The authentication service role can be 279 instantiated by an intermediary such as a proxy server or by a user 280 agent. Any entity that instantiates the authentication service role 281 MUST possess the private key of one or more credentials that can be 282 used to sign for a domain or a telephone number (see Section 5.1). 283 Intermediaries that instantiate this role MUST be capable of 284 authenticating one or more SIP users who can register for that 285 identity. Commonly, this role will be instantiated by a proxy 286 server, since these entities are more likely to have a static 287 hostname, hold corresponding credentials, and have access to SIP 288 registrar capabilities that allow them to authenticate users. It is 289 also possible that the authentication service role might be 290 instantiated by an entity that acts as a redirect server, but that is 291 left as a topic for future work. 293 SIP entities that act as an authentication service MUST add a Date 294 header field to SIP requests if one is not already present (see 295 Section 7 for information on how the Date header field assists 296 verifiers). 298 Entities instantiating the authentication service role perform the 299 following steps, in order, to generate an Identity header for a SIP 300 request: 302 Step 1: 304 The authentication service MUST extract the identity of the sender 305 from the request. The authentication service takes this value from 306 the From header field; this AoR will be referred to here as the 307 'identity field'. If the identity field contains a SIP or SIP Secure 308 (SIPS) URI, and the user portion is not a telephone number, the 309 authentication service MUST extract the hostname portion of the 310 identity field and compare it to the domain(s) for which it is 311 responsible (following the procedures in RFC 3261 [RFC3261], 312 Section 16.4), used by a proxy server to determine the domain(s) for 313 which it is responsible). If the identity field uses the TEL URI 314 scheme [RFC3966], or the identity field is a SIP or SIPS URI with a 315 telephone number in the user portion, the authentication service 316 determines whether or not it is responsible for this telephone 317 number; see Section 6.1 for more information. If the authentication 318 service is not authoritative for the identity in question, it SHOULD 319 process and forward the request normally, but it MUST NOT following 320 the steps below to add an Identity header; see below for more 321 information on authentication service handling of an existing 322 Identity header. [where?] 324 Step 2: 326 The authentication service MUST then determine whether or not the 327 sender of the request is authorized to claim the identity given in 328 the identity field. In order to do so, the authentication service 329 MUST authenticate the sender of the message. Some possible ways in 330 which this authentication might be performed include: 332 If the authentication service is instantiated by a SIP 333 intermediary (proxy server), it may challenge the request with a 334 407 response code using the Digest authentication scheme (or 335 viewing a Proxy-Authentication header sent in the request, which 336 was sent in anticipation of a challenge using cached credentials, 337 as described in RFC 3261 [RFC3261], Section 22.3). Note that if 338 that proxy server is maintaining a TLS connection with the client 339 over which the client had previously authenticated itself using 340 Digest authentication, the identity value obtained from that 341 previous authentication step can be reused without an additional 342 Digest challenge. 344 If the authentication service is instantiated by a SIP user agent, 345 a user agent can be said to authenticate its user on the grounds 346 that the user can provision the user agent with the private key of 347 the credential, or preferably by providing a password that unlocks 348 said private key. 350 Authorization of the use of a particular username or telephone number 351 in the user part of the From header field is a matter of local policy 352 for the authentication service, see Section 5.1 for more information. 354 Note that this check is performed only on the addr-spec in the From 355 header field (e.g., the URI of the sender, like 356 'sip:alice@atlanta.example.com'); it does not convert the display- 357 name portion of the From header field (e.g., 'Alice Atlanta'). 358 Authentication services MAY check and validate the display-name as 359 well, and compare it to a list of acceptable display-names that may 360 be used by the sender; if the display-name does not meet policy 361 constraints, the authentication service MUST return a 403 response 362 code. The reason phrase should indicate the nature of the problem; 363 for example, "Inappropriate Display Name". However, the display-name 364 is not always present, and in many environments the requisite 365 operational procedures for display-name validation may not exist. 366 For more information, see Section 10.4. 368 Step 3: 370 The authentication service SHOULD ensure that any preexisting Date 371 header in the request is accurate. Local policy can dictate 372 precisely how accurate the Date must be; a RECOMMENDED maximum 373 discrepancy of ten minutes will ensure that the request is unlikely 374 to upset any verifiers. If the Date header contains a time different 375 by more than ten minutes from the current time noted by the 376 authentication service, the authentication service SHOULD reject the 377 request. This behavior is not mandatory because a user agent client 378 (UAC) could only exploit the Date header in order to cause a request 379 to fail verification; the Identity header is not intended to provide 380 a source of non-repudiation or a perfect record of when messages are 381 processed. Finally, the authentication service MUST verify that the 382 Date header falls within the validity period of its credential. For 383 more information on the security properties associated with the Date 384 header field value, see Section 7. 386 [TBD: Should consider a lower threshold than ten minutes? With the 387 removal of other elements from the sig, that's a lot of leeway.] 389 Step 4: 391 The authentication service MAY form an identity-reliance signature 392 and add an Identity-Reliance header to the request containing this 393 signature. The Identity-Reliance header provides body security 394 properties that are useful for non-INVITE transactions, and in 395 environments where body security of INVITE transactions is necessary. 396 Details on the generation of this header is provided in Section 7. 397 If the authentication service is adding an Identity-Reliance header, 398 it MUST also add a Content-Length header field to SIP requests if one 399 is not already present; this can help verifiers to double-check that 400 they are hashing exactly as many bytes of message-body as the 401 authentication service when they verify the message. 403 Step 5: 405 The authentication service MUST form the identity signature and add 406 an Identity header to the request containing this signature. After 407 the Identity header has been added to the request, the authentication 408 service MUST also add an Identity-Info header. The Identity-Info 409 header contains a URI from which its credential can be acquired; see 410 Section 5.3 for more on credential acquisition. Details on the 411 syntax of both of these headers are provided in Section 7. 413 Finally, the authentication service MUST forward the message 414 normally. 416 4.1.1. Intermediary Authentication Services 418 In cases where a user agent does not possess its own credentials to 419 sign an Identity header, the user agent can send its request through 420 an intermediary that will provide a signed Identity header based on 421 the contents of the request. This requires, among other things, that 422 intermediaries have some means of authenticating the user agents 423 sending requests. 425 All RFC 3261 [RFC3261] compliant user agents support Digest 426 authentication, which utilizes a shared secret, as a means for 427 authenticating themselves to a SIP registrar. Registration allows a 428 user agent to express that it is an appropriate entity to which 429 requests should be sent for a particular SIP AoR URI (e.g., 430 'sip:alice@atlanta.example.com'). For such SIP URIs, by the 431 definition of identity used in this document, registration proves the 432 identity of the user to a registrar. Similar checks might be 433 performed for telephone numbers as identities. This is of course 434 only one manner in which a domain might determine how a particular 435 user is authorized to populate the From header field; as an aside, 436 for other sorts of URIs in the From (like anonymous URIs), other 437 authorization policies would apply. 439 RFC 3261 [RFC3261] already describes an intermediary architecture 440 very similar to the one proposed in this document in 441 Section 26.3.2.2, in which a user agent authenticates itself to a 442 local proxy server, which in turn authenticates itself to a remote 443 proxy server via mutual TLS, creating a two-link chain of transitive 444 authentication between the originator and the remote domain. While 445 this works well in some architectures, there are a few respects in 446 which this is impractical. For one, transitive trust is inherently 447 weaker than an assertion that can be validated end-to-end. It is 448 possible for SIP requests to cross multiple intermediaries in 449 separate administrative domains, in which case transitive trust 450 becomes even less compelling. 452 This specification assumes that UACs will have an appropriate means 453 to discover an authentication service that can sign with a credential 454 corresponding to the UAC's identity. Most likely, this information 455 will simply be provisioned in UACs. 457 One solution to this problem is to use 'trusted' SIP intermediaries 458 that assert an identity for users in the form of a privileged SIP 459 header. A mechanism for doing so (with the P-Asserted-Identity 460 header) is given in RFC 3325 [RFC3325]. However, this solution 461 allows only hop- by-hop trust between intermediaries, not end-to-end 462 cryptographic authentication, and it assumes a managed network of 463 nodes with strict mutual trust relationships, an assumption that is 464 incompatible with widespread Internet deployment. 466 4.2. Verifier Behavior 468 This document specifies a logical role for SIP entities called a 469 verification service, or verifier. When a verifier receives a SIP 470 message containing an Identity header, it inspects the signature to 471 verify the identity of the sender of the message. Typically, the 472 results of a verification are provided as input to an authorization 473 process that is outside the scope of this document. If an Identity 474 header is not present in a request, and one is required by local 475 policy (for example, based on a per-sending-domain policy, or a per- 476 sending-user policy), then a 428 'Use Identity Header' response MUST 477 be sent. 479 In order to verify the identity of the sender of a message, an entity 480 acting as a verifier MUST perform the following steps, in the order 481 here specified. 483 Step 1: 485 In order to determine whether the signature for the URI in the From 486 header field value should be over the entire URI or just a 487 canonicalized telephone number, the verification service must follow 488 the process described in Section 6.1. That section also describes 489 the procedures the verification service must follow to determine if 490 the signer is authoritative for a telephone number. For domains, the 491 verifier MUST follow the process described in Section 6.2 to 492 determine if the signer is authoritative for the URI in the From 493 header field. 495 Step 2: 497 The verifier must first ensure that it possesses the proper keying 498 material to validate the signature in the Identity header field. See 499 Section 5.2 for more information on these procedures. 501 Step 3: 503 The verifier MUST verify the signature in the Identity header field, 504 following the procedures for generating the hashed digest-string 505 described in Section 7. If a verifier determines that the signature 506 on the message does not correspond to the reconstructed digest- 507 string, then a 438 'Invalid Identity Header' response MUST be 508 returned. 510 Step 4: 512 If the request contains an Identity-Reliance header, the verifier 513 SHOULD verify the signature in the Identity-Reliance header field, 514 following the procedures for generating the hashed reliance-digest- 515 string described in Section 7. If a verifier determines that the 516 signature on the message does not correspond to the reconstructed 517 digest-string, then a 438 'Invalid Identity Header' response SHOULD 518 be returned. 520 Step 5: 522 The verifier MUST validate the Date header in the manner described in 523 Section 10.1; recipients that wish to verify Identity signatures MUST 524 support all of the operations described there. It must furthermore 525 ensure that the value of the Date header falls within the validity 526 period of the credential used to sign the Identity header. 528 4.3. Identity within a Dialog and Retargeting 530 The mechanism in this document provides a signature over the URI in 531 the To header field value in order to allow recipient policy to 532 detect replay attacks where a request originally sent to one 533 recipient is forwarded to another, unrelated recipient by an 534 attacker. The recipient of a request may compare the To header field 535 value to their own identity in order to determine whether or not the 536 identity information in this call might have been replayed. 537 Retargeting, however, complicates this evaluation. 539 Retargeting is broadly defined as the alteration of the Request-URI 540 by intermediaries. More specifically, retargeting replaces the 541 original target URI with one that corresponds to a different user, 542 potentially a user that would not be not authorized to register under 543 the original target URI. By this definition, retargeting does not 544 include translation of the Request-URI to a contact address of an 545 endpoint that has registered under the original target URI. 547 When a request is retargeted, it may reach a SIP endpoint whose user 548 is not identified by the URI designated in the To header field value. 549 This can cause complications for securing requests sent in the 550 backwards direction in a dialog; while this is not in the scope of 551 impersonation protection for this document, some considerations are 552 given here for future work that attempts to tackle that problem by 553 building on this mechanism. In the absence of "from-change" option 554 provided in [RFC4916], the value in the To header field of a dialog- 555 forming request is used as the From header field of requests sent in 556 the backwards direction during the dialog, and is accordingly the 557 header that would be signed by an authentication service for requests 558 sent in the backwards direction. But in retargeting cases, if the 559 URI in the From header does not identify the sender of the request in 560 the backwards direction, then clearly it would be inappropriate to 561 provide an Identity signature over that From header. As specified 562 above, if the authentication service is not responsible for the 563 domain in the From header field of the request, it MUST NOT add an 564 Identity header to the request, and it should process/forward the 565 request normally. 567 Any means of anticipating retargeting, and so on, is outside the 568 scope of this document, and likely to have equal applicability to 569 response identity as it does to requests in the backwards direction 570 within a dialog. Consequently, no special guidance is given for 571 implementers here regarding the 'connected party' problem; 572 authentication service behavior is unchanged if retargeting has 573 occurred for a dialog-forming request. Ultimately, the 574 authentication service provides an Identity header for requests in 575 the backwards dialog when the user is authorized to assert the 576 identity given in the From header field, and if they are not, an 577 Identity header is not provided. 579 For further information on the problems of response identity see 580 [I-D.peterson-sipping-retarget]. 582 5. Credentials 584 5.1. Credential Use by the Authentication Service 586 In order to act as an authentication service, a SIP entity must have 587 access to the private keying material of one or more credentials that 588 cover URIs, domain names or telephone numbers. These credentials may 589 represent authority over only a single name (such as 590 alice@example.com), an entire domain (such as example.com), or 591 potentially a set of domains. Similarly, a credential may represent 592 authority over a single telephone number or a range of telephone 593 numbers. The way that the scope of a credential is expressed is 594 specific to the credential mechanism. 596 Authorization of the use of a particular username or telephone number 597 in the user part of the From header field is a matter of local policy 598 for the authentication service, one that depends greatly on the 599 manner in which authentication is performed. For non-telephone 600 number user parts, one policy might be as follows: the username given 601 in the 'username' parameter of the Proxy-Authorization header MUST 602 correspond exactly to the username in the From header field of the 603 SIP message. However, there are many cases in which this is too 604 limiting or inappropriate; a realm might use 'username' parameters in 605 Proxy-Authorization that do not correspond to the user-portion of SIP 606 From headers, or a user might manage multiple accounts in the same 607 administrative domain. In this latter case, a domain might maintain 608 a mapping between the values in the 'username' parameter of Proxy- 609 Authorization and a set of one or more SIP URIs that might 610 legitimately be asserted for that 'username'. For example, the 611 username can correspond to the 'private identity' as defined in Third 612 Generation Partnership Project (3GPP), in which case the From header 613 field can contain any one of the public identities associated with 614 this private identity. In this instance, another policy might be as 615 follows: the URI in the From header field MUST correspond exactly to 616 one of the mapped URIs associated with the 'username' given in the 617 Proxy-Authorization header. This is a suitable approach for 618 telephone numbers in particular. Various exceptions to such policies 619 might arise for cases like anonymity; if the AoR asserted in the From 620 header field uses a form like 'sip:anonymous@example.com', then the 621 'example.com' proxy should authenticate that the user is a valid user 622 in the domain and insert the signature over the From header field as 623 usual. 625 5.2. Credential Use by the Verification Service 627 In order to act as a verification service, a SIP entity must have a 628 way to acquire and retain credentials for authorities over particular 629 URIs, domain names and/or telephone numbers. The Identity-Info 630 header (as described in the next section) is supported by all 631 verification service implementations to create a baseline means of 632 credential acquisition. Provided that the credential used to sign a 633 message is not previously known to the verifier, SIP entities SHOULD 634 discover this credential by dereferencing the Identity-Info header, 635 unless they have some more efficient implementation-specific way of 636 acquiring certificates. If the URI scheme in the Identity-Info 637 header cannot be dereferenced, then a 436 'Bad Identity-Info' 638 response MUST be returned. 640 Verification service implementations supporting this specification 641 SHOULD have some means of retaining credentials (in accordance with 642 normal practices for credential lifetimes and revocation) in order to 643 prevent themselves from needlessly downloading the same credential 644 every time a request from the same identity is received. Credentials 645 cached in this manner max be indexed in accordance with local policy: 646 for example, by their scope, or the URI given in the Identity-Info 647 header field value. Further consideration of how to cache 648 credentials is deferred to the credential mechanisms. 650 5.3. Handling Identity-Info URIs 652 An Identity-Info header MUST contain a URI which dereferences to a 653 resource which contains the public key components of the credential 654 used by the authentication service to sign a request. Much as is the 655 case with the trust anchor(s) required for deployments of this 656 specification, it is essential that a URI in the Identity-Info header 657 be dereferencable by any entity that could plausibly receive the 658 request. For common cases, this means that the URI must be 659 dereferencable by any entity on the public Internet. In constrained 660 deployment environments, a service private to the environment might 661 be used instead. 663 Beyond providing a means of accessing credentials for an identity, 664 the Identity-Info header further services a means of differentiating 665 which particular credential was used to sign a request, when there 666 are potentially multiple authorities eligible to sign. For example, 667 imagine a case where a domain implements the authentication service 668 role for example.com, and a user agent belonging to Alice has 669 acquired a credential for alice@example.com. Either would be 670 eligible to sign a SIP request from alice@example.com. Verification 671 services however need a means to differentiate which one performed 672 the signature. The Identity-Info header performs that function. 674 If the optional "canon" parameter is present, it contains the result 675 of the number canonicalization process performed by the 676 authentication service (see Section 6.1) on the identity in the From. 677 This value is provided purely informationally as an optimization for 678 the verification service. The verification service MAY compute its 679 own canonicalization of the number and compare this to the value in 680 the "canon" parameter before performing any cryptographic functions 681 in order to ascertain whether or not the two ends agree on the 682 canonical number form. 684 5.4. Credential Systems 686 This document makes no specific recommendation for the use of any 687 credential system. Today, there are two primary credential systems 688 in place for proving ownership of domain names: certificates (e.g., 689 X.509 v3, see [RFC5280]) and the domain name system itself (e.g., 690 DANE, see [RFC6698]). It is envisioned that either could be used in 691 the SIP context: an Identity-Info header could for example give an 692 HTTP URL of the form 'application/pkix-cert' pointing to a 693 certificate (following the conventions of [RFC2585]). The Identity- 694 Info headers may use the DNS URL scheme (see [RFC4501]( to indicate 695 keys in the DNS. 697 While no comparable public credentials exist for telephone numbers, 698 either approach could be applied to telephone numbers. A credential 699 system based on certificates is given in 700 [I-D.peterson-stir-certificates]. One based on the domain name 701 system is given in [I-D.kaplan-stir-cider]. 703 In order for a credential system to work with this mechanism, its 704 specification must detail: 706 which URIs schemes the credential will use in the Identity-Info 707 header, and any special procedures required to dereference the 708 URIs 710 how the verifier can learn the scope of the credential. 712 any special procedures required to extract keying material from 713 the resources designated by the URI 715 any algorithms that would appear in the Identity-Info "alg" 716 parameter other than 'rsa-sha256.' Note that per the IANA 717 Considerations of RFC 4474, new algorithms can only be specified 718 by Standards Action. 720 SIP entities cannot reliably predict where SIP requests will 721 terminate. When choosing a credential scheme for deployments of this 722 specification, it is therefore essential that the trust anchor(s) for 723 credentials be widely trusted, or that deployments restrict the use 724 of this mechanism to environments where the reliance on particular 725 trust anchors is assured by business arrangements or similar 726 constraints. 728 Note that credential systems must address key lifecycle management 729 concerns: were a domain to change the credential available at the 730 Identity-Info URI before a verifier evaluates a request signed by an 731 authentication service, this would cause obvious verifier failures. 732 When a rollover occurs, authentication services SHOULD thus provide 733 new Identity-Info URIs for each new credential, and SHOULD continue 734 to make older key acquisition URIs available for a duration longer 735 than the plausible lifetime of a SIP message (an hour would most 736 likely suffice). 738 6. Identity Types 740 6.1. Telephone Numbers 742 Since many SIP applications provide a Voice over IP (VoIP) service, 743 telephone numbers are commonly used as identities in SIP deployments. 744 In order for telephone numbers to be used with the mechanism 745 described in this document, authentication services must enroll with 746 an authority that issues credentials for telephone numbers or 747 telephone number ranges, and verification services must trust the 748 authority employed by the authentication service that signs a 749 request. Enrollment procedures and credential management are outside 750 the scope of this document. 752 Given the existence of such authorities, authentication and 753 verification services must identify when a request should be signed 754 by an authority for a telephone number, and when it should be signed 755 by an authority for a domain. Telephone numbers most commonly appear 756 in SIP header field values in the username portion of a SIP URI 757 (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). The user 758 part of that URI conforms to the syntax of the TEL URI scheme (RFC 759 3966 [RFC3966]). It is also possible for a TEL URI to appear in the 760 SIP To or From header field outside the context of a SIP or SIPS URI 761 (e.g., 'tel:+17005551008'). In both of these cases, it's clear that 762 the signer must have authority over the telephone number, not the 763 domain name of the SIP URI. It is also possible, however, for 764 requests to contain a URI like 'sip:7005551000@chicago.example.com'. 765 It may be non-trivial for a service to ascertain in this case whether 766 the URI contains a telephone number or not. 768 To address this problem, the authentication service and verification 769 service both must perform the following canonicalization procedure on 770 any SIP URI they inspect which contains a wholly numeric user part. 771 Note that the same procedures are followed for creating the canonical 772 form of URIs found in both the From and To header field values. 774 First, implementations must assess if the user-portion of the URI 775 constitutes a telephone number. In some environments, numbers 776 will be explicitly labeled by the use of TEL URIs or the 777 'user=phone' parameter, or implicitly by the presence of the '+' 778 indicator at the start of the user-portion. Absent these 779 indications, if there are numbers present in the user-portion, 780 implementations may also detect that the user-portion of the URI 781 contains a telephone number by determining whether or not those 782 numbers would be dialable or routable in the local environment -- 783 bearing in mind that the telephone number may be a valid E.164 784 number, a nationally-specific number, or even a private branch 785 exchange number. 787 Once an implementation has identified a telephone number, it must 788 construct a number string. Implementations MUST drop any leading 789 +'s, any internal dashes, parentheses or other non-numeric 790 characters, excepting only the leading "#" or "*" keys used in 791 some special service numbers (typically, these will appear only in 792 the To header field value). This MUST result in an ASCII string 793 limited to "#", "*" and digits without whitespace or visual 794 separators. 796 Next, an implementation must assess if the number string is a 797 valid, globally-routable number with a leading country code. If 798 not, implementations SHOULD convert the number into E.164 format, 799 adding a country code if necessary; this may involve transforming 800 the number from a dial string (see RFC3966 [RFC3966]), removing 801 any national or international dialing prefixes or performing 802 similar procedures. It is only in the case that an implementation 803 cannot determine how to convert the number to a globally-routable 804 format that this step may be skipped. 806 In some cases, further transformations MAY be made in accordance 807 with specific policies used within the local domain. For example, 808 one domain may only use local number formatting and need to 809 convert all To/From user portions to E.164 by prepending country- 810 code and region code digits; another domain might prefix usernames 811 with trunk- routing codes and need to remove the prefix. 813 The resulting canonical number string will be used as input to the 814 hash calculation during signing and verifying processes. 816 The ABNF of this number string is: 818 tn-spec = [ "#" / "*" ] 1*DIGIT 820 If the result of this procedure forms a complete telephone number, 821 that number is used for the purpose of creating and signing the 822 digest-string by both the authentication service and verification 823 service. Optionally, the entity instantiating the authentication 824 service function MAY alter the telephone numbers that appear in the 825 To and From header field values, converting them to this format. The 826 authentication service MAY also add the result of the 827 canonicalization process of the From header field value to the 828 "canon" parameter of the Identity-Info header. If the result of the 829 canonicalization of the From header field value does not form a 830 complete telephone number, the authentication service and 831 verification service should treat the entire URI as a SIP URI, and 832 apply a domain signature per the procedures in Section 6.2. 834 In the longer term, it is possible that some directory or other 835 discovery mechanism may provide a way to determine which 836 administrative domain is responsible for a telephone number, and this 837 may aid in the signing and verification of SIP identities that 838 contain telephone numbers. This is a subject for future work. 840 6.2. Usernames with Domain Names 842 When a verifier processes a request containing an Identity-Info 843 header with a domain signature, it must compare the domain portion of 844 the URI in the From header field of the request with the domain name 845 that is the subject of the credential acquired from the Identity-Info 846 header. While this might seem that this should be a straightforward 847 process, it is complicated by two deployment realities. In the first 848 place, credentials have varying ways of describing their subjects, 849 and may indeed have multiple subjects, especially in 'virtual 850 hosting' cases where multiple domains are managed by a single 851 application. Secondly, some SIP services may delegate SIP functions 852 to a subordinate domain and utilize the procedures in RFC 3263 853 [RFC3263] that allow requests for, say, 'example.com' to be routed to 854 'sip.example.com'. As a result, a user with the AoR 855 'sip:jon@example.com' may process requests through a host like 856 'sip.example.com', and it may be that latter host that acts as an 857 authentication service. 859 To meet the second of these problems, a domain that deploys an 860 authentication service on a subordinate host MUST be willing to 861 supply that host with the private keying material associated with a 862 credential whose subject is a domain name that corresponds to the 863 domain portion of the AoRs that the domain distributes to users. 864 Note that this corresponds to the comparable case of routing inbound 865 SIP requests to a domain. When the NAPTR and SRV procedures of RFC 866 3263 are used to direct requests to a domain name other than the 867 domain in the original Request-URI (e.g., for 'sip:jon@example.com', 868 the corresponding SRV records point to the service 869 'sip1.example.org'), the client expects that the certificate passed 870 back in any TLS exchange with that host will correspond exactly with 871 the domain of the original Request-URI, not the domain name of the 872 host. Consequently, in order to make inbound routing to such SIP 873 services work, a domain administrator must similarly be willing to 874 share the domain's private key with the service. This design 875 decision was made to compensate for the insecurity of the DNS, and it 876 makes certain potential approaches to DNS-based 'virtual hosting' 877 unsecurable for SIP in environments where domain administrators are 878 unwilling to share keys with hosting services. 880 A verifier MUST evaluate the correspondence between the user's 881 identity and the signing credential by following the procedures 882 defined in RFC 2818 [RFC2818], Section 3.1. While RFC 2818 [RFC2818] 883 deals with the use of HTTP in TLS and is specific to certificates, 884 the procedures described are applicable to verifying identity if one 885 substitutes the "hostname of the server" in HTTP for the domain 886 portion of the user's identity in the From header field of a SIP 887 request with an Identity header. 889 7. Header Syntax 891 This document specifies three SIP headers: Identity, Identity- 892 Reliance and Identity- Info. Each of these headers can appear only 893 once in a SIP request; Identity-Reliance is OPTIONAL, while Identity 894 and Identity-Info are REQUIRED for securing requests with this 895 specification. The grammar for these three headers is (following the 896 ABNF [RFC4234] in RFC 3261 [RFC3261]): 898 Identity = "Identity" HCOLON signed-identity-digest 899 signed-identity-digest = LDQUOT 32LHEX RDQUOT 901 Identity-Reliance = "Identity-Reliance" HCOLON signed-identity-reliance-digest 902 signed-identity-reliance-digest = LDQUOT 32LHEX RDQUOT 904 Identity-Info = "Identity-Info" HCOLON ident-info 905 *( SEMI ident-info-params ) 906 ident-info = LAQUOT absoluteURI RAQUOT 907 ident-info-params = ident-info-alg / canonical-str / ident-info-extension 908 ident-info-alg = "alg" EQUAL token 909 canonical-str = "canon" EQUAL tn-spec 910 ident-info-extension = generic-param 911 The signed-identity-reliance-digest is a signed hash of a canonical 912 string generated from certain components of a SIP request. Creating 913 this hash and the Identity-Reliance header field to contain it is 914 OPTIONAL, and its usage is a matter of local policy for 915 authentication services. To create the contents of the signed- 916 identity-reliance-digest, the following element of a SIP message MUST 917 be placed in a bit-exact string: 919 The body content of the message with the bits exactly as they are 920 in the message (in the ABNF for SIP, the message-body). This 921 includes all components of multipart message bodies. Note that 922 the message-body does NOT include the CRLF separating the SIP 923 headers from the message-body, but does include everything that 924 follows that CRLF. 926 The signed-identity-digest is a signed hash of a canonical string 927 generated from certain components of a SIP request. To create the 928 contents of the signed-identity-digest, the following elements of a 929 SIP message MUST be placed in a bit-exact string in the order 930 specified here, separated by a vertical line, "|" or %x7C, character: 932 First, the identity. If the user part of the AoR in the From 933 header field of the request contains a telephone number, then the 934 canonicalization of that number goes into the first slot (see 935 Section 6.1). Otherwise, the first slot contains the AoR of the 936 UA sending the message, or addr-spec of the From header field. 938 Second, the target. If the user part of the AoR in the To header 939 field of the request contains a telephone number, then the 940 canonicalization of that number goes into the second slot (see 941 Section 6.1). Otherwise, the second slot contains the addr-spec 942 component of the To header field, which is the AoR to which the 943 request is being sent. 945 Third, the request method. 947 Fourth, the Date header field, with exactly one space each for 948 each SP and the weekday and month items case set as shown in the 949 BNF of RFC 3261 [RFC3261]. RFC 3261 specifies that the BNF for 950 weekday and month is a choice amongst a set of tokens. The RFC 951 4234 [RFC4234] rules for the BNF specify that tokens are case 952 sensitive. However, when used to construct the canonical string 953 defined here, the first letter of each week and month MUST be 954 capitalized, and the remaining two letters must be lowercase. 955 This matches the capitalization provided in the definition of each 956 token. All requests that use the Identity mechanism MUST contain 957 a Date header. 959 Fifth, if the request contains an SDP message body, and if that 960 SDP contains an "a=fingerprint" attribute, the value of the 961 attribute. The attribute value consists of all characters 962 following the colon after "a=fingerprint" including the algorithm 963 description and hexadecimal key representation, any whitespace, 964 carriage returns, and "/" line break indicators. If the SDP body 965 contains no "a=fingerprint" attribute, the fifth element MUST be 966 empty, containing no whitespace, resulting in a "||" in the 967 signed-identity-digest. 969 Sixth, the Identity-Reliance header field value, if there is an 970 Identity-Reliance field in the request. If the message has no 971 body, or no Identity-Reliance header, then the fifth slot will be 972 empty, and the final "|" will not be followed by any additional 973 characters. 975 For more information on the security properties of these headers, and 976 why their inclusion mitigates replay attacks, see Section 10 and 977 [RFC3893]. The precise formulation of this digest-string is, 978 therefore (following the ABNF[RFC4234] in RFC 3261 [RFC3261]): 980 digest-string = ( addr-spec / tn-spec ) "|" ( addr-spec / tn-spec ) "|" 981 Method "|" SIP-date "|" [ sdp-fingerprint ] "|" [ signed-identity-reliance-digest ] 983 sdp-fingerprint = byte-string 985 For the definition of 'tn-spec' see Section 6.1. 987 After the digest-string or reliance-digest-string is formed, each 988 MUST be hashed and signed with the certificate of authority over the 989 identity. The hashing and signing algorithm is specified by the 990 'alg' parameter of the Identity-Info header (see below for more 991 information on Identity-Info header parameters). This document 992 defines only one value for the 'alg' parameter: 'rsa-sha256'; further 993 values MUST be defined in a Standards Track RFC, see Section 14.7 for 994 more information. All implementations of this specification MUST 995 support 'rsa-sha256'. When the 'rsa-sha256' algorithm is specified 996 in the 'alg' parameter of Identity-Info, the hash and signature MUST 997 be generated as follows: compute the results of signing this string 998 with sha1WithRSAEncryption as described in RFC 3370 [RFC3370] and 999 base64 encode the results as specified in RFC 3548 [RFC3548]. A 1000 2048-bit or longer RSA key MUST be used. The result of the digest- 1001 string hash is placed in the Identity header field; the optional 1002 reliance-digest-string hash goes in the Identity-Reliance header. 1003 For detailed examples of the usage of this algorithm, see Section 8. 1005 The 'absoluteURI' portion of the Identity-Info header MUST contain a 1006 URI; see Section 5.3 for more on choosing how to advertise 1007 credentials through Identity-Info. 1009 This document adds (or amends) the following entries to Table 2 of 1010 RFC 3261 [RFC3261] (this repeats the registrations of RFC4474): 1012 Header field where proxy ACK BYE CAN INV OPT REG 1013 ------------ ----- ----- --- --- --- --- --- --- 1014 Identity R a o o - o o o 1016 SUB NOT REF INF UPD PRA 1017 --- --- --- --- --- --- 1018 o o o o o o 1020 Header field where proxy ACK BYE CAN INV OPT REG 1021 ------------ ----- ----- --- --- --- --- --- --- 1022 Identity-Info R a o o - o o o 1024 SUB NOT REF INF UPD PRA 1025 --- --- --- --- --- --- 1026 o o o o o o 1028 Header field where proxy ACK BYE CAN INV OPT REG 1029 ------------ ----- ----- --- --- --- --- --- --- 1030 Identity-Reliance R a o o - o o o 1032 SUB NOT REF INF UPD PRA 1033 --- --- --- --- --- --- 1034 o o o o o o 1036 Note, in the table above, that this mechanism does not protect the 1037 CANCEL method. The CANCEL method cannot be challenged, because it is 1038 hop-by-hop, and accordingly authentication service behavior for 1039 CANCEL would be significantly limited. The Identity and Identity- 1040 Info header MUST NOT appear in CANCEL. Note as well that the use of 1041 Identity with REGISTER is consequently a subject for future study, 1042 although it is left as optional here for forward-compatibility 1043 reasons. 1045 8. Examples 1047 9. Privacy Considerations 1049 The purpose of this mechanism is to provide a strong identification 1050 of the originator of a SIP request, specifically a cryptographic 1051 assurance that the URI given in the From header field value can 1052 legitimately be claimed by the originator. This URI may contain a 1053 variety of personally identifying information, including the name of 1054 a human being, their place of work or service provider, and possibly 1055 further details. The intrinsic privacy risks associated with that 1056 URI are, however, no different from those of baseline SIP. Per the 1057 guidance in [RFC6973], implementors should make users aware of the 1058 privacy trade-off of providing secure identity. 1060 The identity mechanism presented in this document is compatible with 1061 the standard SIP practices for privacy described in RFC 3323 1062 [RFC3323]. A SIP proxy server can act both as a privacy service and 1063 as an authentication service. Since a user agent can provide any 1064 From header field value that the authentication service is willing to 1065 authorize, there is no reason why private SIP URIs that contain 1066 legitimate domains (e.g., sip:anonymous@example.com) cannot be signed 1067 by an authentication service. The construction of the Identity 1068 header is the same for private URIs as it is for any other sort of 1069 URIs. 1071 Note, however, that for using anonymous SIP URIs, an authentication 1072 service must possess a certificate corresponding to the host portion 1073 of the addr-spec of the From header field of the request; 1074 accordingly, using domains like 'anonymous.invalid' will not be 1075 possible for privacy services that also act as authentication 1076 services. The assurance offered by the usage of anonymous URIs with 1077 a valid domain portion is "this is a known user in my domain that I 1078 have authenticated, but I am keeping its identity private". The use 1079 of the domain 'anonymous.invalid' entails that no corresponding 1080 authority for the domain can exist, and as a consequence, 1081 authentication service functions are meaningless. 1083 RFC 3325 [RFC3325] defines the "id" priv-value token, which is 1084 specific to the P-Asserted-Identity header. The sort of assertion 1085 provided by the P-Asserted-Identity header is very different from the 1086 Identity header presented in this document. It contains additional 1087 information about the sender of a message that may go beyond what 1088 appears in the From header field; P-Asserted-Identity holds a 1089 definitive identity for the sender that is somehow known to a closed 1090 network of intermediaries that presumably the network will use this 1091 identity for billing or security purposes. The danger of this 1092 network-specific information leaking outside of the closed network 1093 motivated the "id" priv-value token. The "id" priv-value token has 1094 no implications for the Identity header, and privacy services MUST 1095 NOT remove the Identity header when a priv-value of "id" appears in a 1096 Privacy header. 1098 Finally, note that unlike RFC 3325 [RFC3325], the mechanism described 1099 in this specification adds no information to SIP requests that has 1100 privacy implications. 1102 10. Security Considerations 1104 10.1. Handling of digest-string Elements 1106 This document describes a mechanism that provides a signature over 1107 the Date header field, and either the whole or part of the To and 1108 From header fields of SIP requests, as well as optional protections 1109 for the message body. While a signature over the From header field 1110 would be sufficient to secure a URI alone, the additional headers 1111 provide replay protection and reference integrity necessary to make 1112 sure that the Identity header will not be replayed in cut-and-paste 1113 attacks. In general, the considerations related to the security of 1114 these headers are the same as those given in RFC 3261 [RFC3261] for 1115 including headers in tunneled 'message/sip' MIME bodies (see 1116 Section 23 in particular). The following section details the 1117 individual security properties obtained by including each of these 1118 header fields within the signature; collectively, this set of header 1119 fields provides the necessary properties to prevent impersonation. 1121 The From header field indicates the identity of the sender of the 1122 message, and the SIP address-of-record URI, or an embedded telephone 1123 number, in the From header field is the identity of a SIP user, for 1124 the purposes of this document. The To header field provides the 1125 identity of the SIP user that this request targets. Providing the To 1126 header field in the Identity signature serves two purposes: first, it 1127 prevents cut-and-paste attacks in which an Identity header from 1128 legitimate request for one user is cut-and-pasted into a request for 1129 a different user; second, it preserves the starting URI scheme of the 1130 request, which helps prevent downgrade attacks against the use of 1131 SIPS. 1133 The Date header field provides replay protection, as described in RFC 1134 3261 [RFC3261], Section 23.4.2. Implementations of this 1135 specification MUST NOT deem valid a request with an outdated Date 1136 header field (the RECOMMENDED interval is that the Date header must 1137 indicate a time within 3600 seconds of the receipt of a message). 1138 The result of this is that if an Identity header is replayed within 1139 the Date interval, verifiers will recognize that it is invalid; if an 1140 Identity header is replayed after the Date interval, verifiers will 1141 recognize that it is invalid because the Date is stale. 1143 Without the method, an INVITE request could be cut- and-pasted by an 1144 attacker and transformed into a MESSAGE request without changing any 1145 fields covered by the Identity header, and moreover requests within a 1146 certain transaction could be replayed in potentially confusing or 1147 malicious ways. 1149 RFC4474 originally had protections for the Contact, Call-ID and CSeq. 1150 These are removed from RFC4474bis. The absence of these header 1151 values creates some opportunities for determined attackers to 1152 impersonate based on cut-and-paste attacks; however, the absence of 1153 these headers does not seem impactful to preventing the simple 1154 unauthorized claiming of a From header field value, which is the 1155 primary scope of the current document. 1157 It might seem attractive to provide a signature over some of the 1158 information present in the Via header field value(s). For example, 1159 without a signature over the sent-by field of the topmost Via header, 1160 an attacker could remove that Via header and insert its own in a cut- 1161 and-paste attack, which would cause all responses to the request to 1162 be routed to a host of the attacker's choosing. However, a signature 1163 over the topmost Via header does not prevent attacks of this nature, 1164 since the attacker could leave the topmost Via intact and merely 1165 insert a new Via header field directly after it, which would cause 1166 responses to be routed to the attacker's host "on their way" to the 1167 valid host, which has exactly the same end result. Although it is 1168 possible that an intermediary-based authentication service could 1169 guarantee that no Via hops are inserted between the sending user 1170 agent and the authentication service, it could not prevent an 1171 attacker from adding a Via hop after the authentication service, and 1172 thereby preempting responses. It is necessary for the proper 1173 operation of SIP for subsequent intermediaries to be capable of 1174 inserting such Via header fields, and thus it cannot be prevented. 1175 As such, though it is desirable, securing Via is not possible through 1176 the sort of identity mechanism described in this document; the best 1177 known practice for securing Via is the use of SIPS. 1179 When signing a request that contains a fingerprint of keying material 1180 in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a 1181 signature over that fingerprint. This signature prevents certain 1182 classes of impersonation attacks in which an attacker forwards or 1183 cut-and-pastes a legitimate request: although the target of the 1184 attack may accept the request, the attacker will be unable to 1185 exchange media with the target as they will not possess a key 1186 corresponding to the fingerprint. For example there are some baiting 1187 attacks (where the attacker receives a request from the target and 1188 reoriginates it to a third party) that might not be prevented by only 1189 a signature over the From, To and Date, but could be prevented by 1190 securing a fingerprint for DTLS-SRTP. While this is a different form 1191 of interpretation than is commonly needed for robocalling, ultimately 1192 there is little purpose in establishing the identity of the user that 1193 originated a SIP request if this assurance is not coupled with a 1194 comparable assurance over the contents of the subsequent 1195 communication. This signature also, per [RFC7258], reduces the 1196 potential for passive monitoring attacks against the SIP media. In 1197 environments where DTLS-SRTP is unsupported, however, this mechanism 1198 is not exercised and no protections are provided. 1200 This mechanism also provides an optional full signature over the 1201 bodies of SIP requests. This can help to protect non-INVITE 1202 transactions such as MESSAGE or NOTIFY, as well as INVITEs in those 1203 environments where intermediaries do not change SDP. Note, however, 1204 that this is not perfect end-to-end security. The authentication 1205 service itself, when instantiated at an intermediary, could 1206 conceivably change the body (and SIP headers, for that matter) before 1207 providing a signature. Thus, while this mechanism reduces the chance 1208 that a replayer or man-in-the-middle will modify bodies, it does not 1209 eliminate it entirely. Since it is a foundational assumption of this 1210 mechanism that the users trust their local domain to vouch for their 1211 security, they must also trust the service not to violate the 1212 integrity of their message without good reason. 1214 In the end analysis, the Identity, Identity-Reliance and Identity- 1215 Info headers cannot protect themselves. Any attacker could remove 1216 these headers from a SIP request, and modify the request arbitrarily 1217 afterwards. However, this mechanism is not intended to protect 1218 requests from men-in-the- middle who interfere with SIP messages; it 1219 is intended only to provide a way that the originators of SIP 1220 requests can prove that they are who they claim to be. At best, by 1221 stripping identity information from a request, a man-in-the-middle 1222 could make it impossible to distinguish any illegitimate messages he 1223 would like to send from those messages sent by an authorized user. 1224 However, it requires a considerably greater amount of energy to mount 1225 such an attack than it does to mount trivial impersonations by just 1226 copying someone else's From header field. This mechanism provides a 1227 way that an authorized user can provide a definitive assurance of his 1228 identity that an unauthorized user, an impersonator, cannot. 1230 One additional respect in which the Identity-Info header cannot 1231 protect itself is the 'alg' parameter. The 'alg' parameter is not 1232 included in the digest-string, and accordingly, a man-in-the-middle 1233 might attempt to modify the 'alg' parameter. Once again, it is 1234 important to note that preventing men-in-the-middle is not the 1235 primary impetus for this mechanism. Moreover, changing the 'alg' 1236 would at worst result in some sort of bid-down attack, and at best 1237 cause a failure in the verifier. Note that only one valid 'alg' 1238 parameter is defined in this document and that thus there is 1239 currently no weaker algorithm to which the mechanism can be bid down. 1240 'alg' has been incorporated into this mechanism for forward- 1241 compatibility reasons in case the current algorithm exhibits 1242 weaknesses, and requires swift replacement, in the future. 1244 10.2. Securing the Connection to the Authentication Service 1246 In the absence of user agent-based authentication services, the 1247 assurance provided by this mechanism is strongest when a user agent 1248 forms a direct connection, preferably one secured by TLS, to an 1249 intermediary-based authentication service. The reasons for this are 1250 twofold: 1252 If a user does not receive a certificate from the authentication 1253 service over this TLS connection that corresponds to the expected 1254 domain (especially when the user receives a challenge via a 1255 mechanism such as Digest), then it is possible that a rogue server 1256 is attempting to pose as an authentication service for a domain 1257 that it does not control, possibly in an attempt to collect shared 1258 secrets for that domain. A similar practice could be used for 1259 telephone numbers, though the application of certificates for 1260 telephone numbers to TLS is left as a matter for future study. 1262 Without TLS, the various header field values and the body of the 1263 request will not have integrity protection when the request 1264 arrives at an authentication service. Accordingly, a prior 1265 legitimate or illegitimate intermediary could modify the message 1266 arbitrarily. 1268 Of these two concerns, the first is most material to the intended 1269 scope of this mechanism. This mechanism is intended to prevent 1270 impersonation attacks, not man-in-the-middle attacks; integrity over 1271 the header and bodies is provided by this mechanism only to prevent 1272 replay attacks. However, it is possible that applications relying on 1273 the presence of the Identity header could leverage this integrity 1274 protection, especially body integrity, for services other than replay 1275 protection. 1277 Accordingly, direct TLS connections SHOULD be used between the UAC 1278 and the authentication service whenever possible. The opportunistic 1279 nature of this mechanism, however, makes it very difficult to 1280 constrain UAC behavior, and moreover there will be some deployment 1281 architectures where a direct connection is simply infeasible and the 1282 UAC cannot act as an authentication service itself. Accordingly, 1283 when a direct connection and TLS are not possible, a UAC should use 1284 the SIPS mechanism, Digest 'auth-int' for body integrity, or both 1285 when it can. The ultimate decision to add an Identity header to a 1286 request lies with the authentication service, of course; domain 1287 policy must identify those cases where the UAC's security association 1288 with the authentication service is too weak. 1290 10.3. Authorization and Transitional Strategies 1292 Ultimately, the worth of an assurance provided by an Identity header 1293 is limited by the security practices of the authentication service 1294 that issues the assurance. Relying on an Identity header generated 1295 by a remote administrative domain assumes that the issuing domain 1296 uses recommended administrative practices to authenticate its users. 1297 However, it is possible that some authentication services will 1298 implement policies that effectively make users unaccountable (e.g., 1299 ones that accept unauthenticated registrations from arbitrary users). 1300 The value of an Identity header from such authentication services is 1301 questionable. While there is no magic way for a verifier to 1302 distinguish "good" from "bad" signers by inspecting a SIP request, it 1303 is expected that further work in authorization practices could be 1304 built on top of this identity solution; without such an identity 1305 solution, many promising approaches to authorization policy are 1306 impossible. That much said, it is RECOMMENDED that authentication 1307 services based on proxy servers employ strong authentication 1308 practices. 1310 One cannot expect the Identity and Identity-Info headers to be 1311 supported by every SIP entity overnight. This leaves the verifier in 1312 a compromising position; when it receives a request from a given SIP 1313 user, how can it know whether or not the sender's domain supports 1314 Identity? In the absence of ubiquitous support for identity, some 1315 transitional strategies are necessary. 1317 A verifier could remember when it receives a request from a domain 1318 or telephone number that uses Identity, and in the future, view 1319 messages received from that sources without Identity headers with 1320 skepticism. 1322 A verifier could consult some sort of directory that indications 1323 whether a given caller should have a signed identity. There are a 1324 number of potential ways in which this could be implemented. This 1325 is left as a subject for future work. 1327 In the long term, some sort of identity mechanism, either the one 1328 documented in this specification or a successor, must become 1329 mandatory-to-use for the SIP protocol; that is the only way to 1330 guarantee that this protection can always be expected by verifiers. 1332 Finally, it is worth noting that the presence or absence of the 1333 Identity headers cannot be the sole factor in making an authorization 1334 decision. Permissions might be granted to a message on the basis of 1335 the specific verified Identity or really on any other aspect of a SIP 1336 request. Authorization policies are outside the scope of this 1337 specification, but this specification advises any future 1338 authorization work not to assume that messages with valid Identity 1339 headers are always good. 1341 10.4. Display-Names and Identity 1343 As a matter of interface design, SIP user agents might render the 1344 display-name portion of the From header field of a caller as the 1345 identity of the caller; there is a significant precedent in email 1346 user interfaces for this practice. Securing the display-name 1347 component of the From header field value is outside the scope of this 1348 document, but may be the subject of future work. 1350 11. IANA Considerations 1352 This document relies on the headers and response codes defined in RFC 1353 4474. It also retains the requirements for the specification of new 1354 algorithms or headers related to the mechanisms described in that 1355 document. 1357 11.1. Header Field Names 1359 This document specifies one new SIP header called Identity-Reliance. 1360 Its syntax is given in Section 7. This header is defined by the 1361 following information, which has been added to the header sub- 1362 registry under http://www.iana.org/assignments/sip-parameters 1364 Header Name: Identity-Reliance 1365 Compact Form: N/A 1367 11.2. Identity-Info Parameters 1369 The IANA has already created a registry for Identity-Info headers 1370 parameters. This specification defines a new value called "canon" as 1371 defined in Section 5.3. 1373 11.3. Identity-Info Algorithm Parameter Values 1375 The IANA has already created a registry for Identity-Info 'alg' 1376 parameter values. This registry is to be prepopulated with a single 1377 entry for a value called 'rsa-sha256', which describes the algorithm 1378 used to create the signature that appears in the Identity header. 1379 Registry entries must contain the name of the 'alg' parameter value 1380 and the specification in which the value is described. New values 1381 for the 'alg' parameter may be defined only in Standards Track RFCs. 1383 RFC4474 defined the 'rsa-sha1' value for this registry. That value 1384 is hereby deprecated, and should be treated as such. It is not 1385 believed that any implementations are making use of this value. 1387 Future specifications may consider elliptical curves for smaller key 1388 sizes. 1390 12. Acknowledgments 1392 The authors would like to thank Stephen Kent, Brian Rosen, Alex 1393 Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin 1394 Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, 1395 Pierce Gorman, David Schwartz, Philippe Fouquart, Michael Hamer, 1396 Henning Schulzrinne, and Richard Barnes for their comments. 1398 13. Changes from RFC4474 1400 The following are salient changes from the original RFC 4474: 1402 Generalized the credential mechanism; credential enrollment and 1403 acquisition is now outside the scope of this document 1405 Reduced the scope of the Identity signature to remove CSeq, Call- 1406 ID, Contact, and the message body 1408 Added any DTLS-SRTP fingerprint in SDP as a mandatory element of 1409 the digest-string 1411 Added the Identity-Reliance header 1413 Deprecated 'rsa-sha1' in favor of new baseline signing algorithm 1415 14. References 1417 14.1. Normative References 1419 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1421 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1422 A., Peterson, J., Sparks, R., Handley, M., and E. 1423 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1424 June 2002. 1426 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1427 Protocol (SIP): Locating SIP Servers", RFC 3263, June 1428 2002. 1430 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1431 X.509 Public Key Infrastructure Certificate and 1432 Certificate Revocation List (CRL) Profile", RFC 3280, 1433 April 2002. 1435 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1436 Algorithms", RFC 3370, August 2002. 1438 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 1439 3966, December 2004. 1441 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1442 Housley, R., and W. Polk, "Internet X.509 Public Key 1443 Infrastructure Certificate and Certificate Revocation List 1444 (CRL) Profile", RFC 5280, May 2008. 1446 14.2. Informative References 1448 [I-D.kaplan-stir-cider] 1449 Kaplan, H., "A proposal for Caller Identity in a DNS-based 1450 Entrusted Registry (CIDER)", draft-kaplan-stir-cider-00 1451 (work in progress), July 2013. 1453 [I-D.peterson-sipping-retarget] 1454 Peterson, J., "Retargeting and Security in SIP: A 1455 Framework and Requirements", draft-peterson-sipping- 1456 retarget-00 (work in progress), February 2005. 1458 [I-D.peterson-stir-certificates] 1459 Peterson, J. and S. Turner, "Secure Telephone Identity 1460 Credentials: Certificates", draft-peterson-stir- 1461 certificates-00 (work in progress), February 2014. 1463 [I-D.rosenberg-sip-rfc4474-concerns] 1464 Rosenberg, J., "Concerns around the Applicability of RFC 1465 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 1466 progress), February 2008. 1468 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1469 Infrastructure Operational Protocols: FTP and HTTP", RFC 1470 2585, May 1999. 1472 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1473 Initiation Protocol (SIP)", RFC 3323, November 2002. 1475 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1476 Extensions to the Session Initiation Protocol (SIP) for 1477 Asserted Identity within Trusted Networks", RFC 3325, 1478 November 2002. 1480 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1481 Encodings", RFC 3548, July 2003. 1483 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1484 Authenticated Identity Body (AIB) Format", RFC 3893, 1485 September 2004. 1487 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1488 Specifications: ABNF", RFC 4234, October 2005. 1490 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1491 Authenticated Identity Management in the Session 1492 Initiation Protocol (SIP)", RFC 4474, August 2006. 1494 [RFC4501] Josefsson, S., "Domain Name System Uniform Resource 1495 Identifiers", RFC 4501, May 2006. 1497 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1498 Protocol (SIP)", RFC 4916, June 2007. 1500 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1501 for Establishing a Secure Real-time Transport Protocol 1502 (SRTP) Security Context Using Datagram Transport Layer 1503 Security (DTLS)", RFC 5763, May 2010. 1505 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1506 of Named Entities (DANE) Transport Layer Security (TLS) 1507 Protocol: TLSA", RFC 6698, August 2012. 1509 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1510 Morris, J., Hansen, M., and R. Smith, "Privacy 1511 Considerations for Internet Protocols", RFC 6973, July 1512 2013. 1514 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1515 Attack", BCP 188, RFC 7258, May 2014. 1517 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1518 Telephone Identity Problem Statement and Requirements", 1519 RFC 7340, September 2014. 1521 Authors' Addresses 1523 Jon Peterson 1524 Neustar, Inc. 1525 1800 Sutter St Suite 570 1526 Concord, CA 94520 1527 US 1529 Email: jon.peterson@neustar.biz 1531 Cullen Jennings 1532 Cisco 1533 400 3rd Avenue SW, Suite 350 1534 Calgary, AB T2P 4H2 1535 Canada 1537 Email: fluffy@iii.ca 1539 Eric Rescorla 1540 RTFM, Inc. 1541 2064 Edgewood Drive 1542 Palo Alto, CA 94303 1543 USA 1545 Phone: +1 650 678 2350 1546 Email: ekr@rtfm.com