idnits 2.17.1 draft-ietf-stir-rfc4474bis-05.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 5 instances of too long lines in the document, the longest one being 6 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 286: '... MUST possess the private key of one...' RFC 2119 keyword, line 288: '...stantiate this role MUST be capable of...' RFC 2119 keyword, line 311: '... MUST extract the hostname portion o...' RFC 2119 keyword, line 319: '... number MUST then follow the canonic...' RFC 2119 keyword, line 321: '... in question, it SHOULD process and fo...' (65 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2015) is 3140 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) == Unused Reference: 'RFC3280' is defined on line 1430, 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) == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-02 -- 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 (~~), 3 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: March 17, 2016 Cisco 6 E. Rescorla 7 RTFM, Inc. 8 September 14, 2015 10 Authenticated Identity Management in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-stir-rfc4474bis-05.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 March 17, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 6 62 4. Signature Generation and Validation . . . . . . . . . . . . . 7 63 4.1. Authentication Service Behavior . . . . . . . . . . . . . 7 64 4.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 9 65 5. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.1. Credential Use by the Authentication Service . . . . . . 11 67 5.2. Credential Use by the Verification Service . . . . . . . 12 68 5.3. Handling Identity-Info URIs . . . . . . . . . . . . . . . 13 69 5.4. Credential Systems . . . . . . . . . . . . . . . . . . . 13 70 6. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 14 71 6.1. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 14 72 6.1.1. Canonicalization Procedures . . . . . . . . . . . . . 15 73 6.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . 17 74 7. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 75 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 20 76 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 78 10.1. Protected Request Fields . . . . . . . . . . . . . . . . 23 79 10.1.1. Protection of the To Header and Retargeting . . . . 24 80 10.2. Unprotected Request Fields . . . . . . . . . . . . . . . 25 81 10.3. Malicious Removal of Identity Headers . . . . . . . . . 26 82 10.4. Securing the Connection to the Authentication Service . 26 83 10.5. Authorization and Transitional Strategies . . . . . . . 27 84 10.6. Display-Names and Identity . . . . . . . . . . . . . . . 29 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 86 11.1. Header Field Names . . . . . . . . . . . . . . . . . . . 29 87 11.2. Identity-Info Parameters . . . . . . . . . . . . . . . . 29 88 11.3. Identity-Info Algorithm Parameter Values . . . . . . . . 29 89 11.4. Identity-Extension Names . . . . . . . . . . . . . . . . 30 90 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 91 13. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 30 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 14.1. Normative References . . . . . . . . . . . . . . . . . . 30 94 14.2. Informative References . . . . . . . . . . . . . . . . . 31 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 97 1. Introduction 99 This document provides enhancements to the existing mechanisms for 100 authenticated identity management in the Session Initiation Protocol 101 (SIP, [RFC3261]). An identity, for the purposes of this document, is 102 defined as either a SIP URI, commonly a canonical address-of-record 103 (AoR) employed to reach a user (such as 104 'sip:alice@atlanta.example.com'), or a telephone number, which can be 105 represented as either a TEL URI [RFC3966] or as the user portion of a 106 SIP URI. 108 [RFC3261] stipulates several places within a SIP request where users 109 can express an identity for themselves, primarily the user-populated 110 From header field. However, the recipient of a SIP request has no 111 way to verify that the From header field has been populated 112 appropriately, in the absence of some sort of cryptographic 113 authentication mechanism. This leaves SIP vulnerable to a category 114 of abuses, including impersonation attacks that enable robocalling 115 and related problems as described in [RFC7340]. 117 [RFC3261] specifies a number of security mechanisms that can be 118 employed by SIP user agents (UAs), including Digest, Transport Layer 119 Security (TLS), and S/MIME (implementations may support other 120 security schemes as well). However, few SIP user agents today 121 support the end-user certificates necessary to authenticate 122 themselves (via S/MIME, for example), and furthermore Digest 123 authentication is limited by the fact that the originator and 124 destination must share a prearranged secret. It is desirable for SIP 125 user agents to be able to send requests to destinations with which 126 they have no previous association. A cryptographic approach, like 127 the one described in this document, can provide a much stronger and 128 less spoofable assurance of identity than the Caller ID services that 129 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 [RFC7375]. 142 2. Background 144 Per [RFC7340], a key enabler of problems such as robocalling, 145 voicemail hacking, and swatting lies in an attacker's ability to 146 impersonate someone else. This secure operation of most SIP 147 applications and services depends on authorizing the source of 148 communications as it is represented in a SIP request. Such 149 authorization policies can be automated or be a part of human 150 operation of SIP devices. An example of the latter would be an 151 Internet telephone application that displays the calling party number 152 (and/or Caller-ID) of a caller, which a human may review to make a 153 policy decision before answering a call. An example of the former 154 would be a voicemail service that compares the identity of the caller 155 to a whitelist before determining whether it should allow the caller 156 access to recorded messages. In both of these cases, attackers might 157 attempt to circumvent these authorization policies through 158 impersonation. Since the primary identifier of the sender of a SIP 159 request, the From header field, can be populated arbitrarily by the 160 controller of a user agent, impersonation is very simple today. The 161 mechanism described in this document provides a strong identity 162 system for detecting attempted impersonation in SIP requests. 164 This identity architecture for SIP depends on a logical 165 "authentication service" which processes and signs requests; it may 166 be implemented either as part of a user agent or as a proxy server. 167 Once the sender of the message has been authenticated, the service 168 then adds new cryptographic information to requests to communicate to 169 other SIP entities that the sending user has been authenticated and 170 its claim of a particular identity has been authorized. A 171 "verification service" on the receiving end then validates this 172 signature and enables policy decisions to be made based on the 173 results of the verification. 175 Identities are issued to users by authorities. When a new user 176 becomes associated with example.com, the administrator of the SIP 177 service for that domain can issue them an identity in that namespace, 178 such as alice@example.com. Alice may then send REGISTER requests to 179 example.com that make her user agents eligible to receive requests 180 for sip:alice@example.com. In some cases, Alice may be the owner of 181 the domain herself, and may issue herself identities as she chooses. 182 But ultimately, it is the controller of the SIP service at 183 example.com that must be responsible for authorizing the use of names 184 in the example.com domain. Therefore, for the purposes of baseline 185 SIP, the credentials needed to prove a user is authorized to use a 186 particular From header field must ultimately derive from the domain 187 owner: either a user agent gives requests to the domain name owner in 188 order for them to be signed by the domain owner's credentials, or the 189 user agent must possess credentials that prove in some fashion that 190 the domain owner has given the user agent the right to a name. 192 The situation is however more complicated for telephone numbers, 193 however. Authority over telephone numbers does not correspond 194 directly to Internet domains. While a user could register at a SIP 195 domain with a username that corresponds to a telephone number, any 196 connection between the administrator of that domain and the 197 assignment of telephone numbers is not currently reflected on the 198 Internet. Telephone numbers do not share the domain-scope property 199 described above, as they are dialed without any domain component. 200 This document thus assumes the existence of a separate means of 201 establishing authority over telephone numbers, for cases where the 202 telephone number is the identity of the user. As with SIP URIs, the 203 necessary credentials to prove authority for a name might reside 204 either in the endpoint or at some intermediary. 206 This document specifies a means of sharing a cryptographic assurance 207 of end-user SIP identity in an interdomain or intradomain context. 208 It relies on the authentication service adding to requests a SIP 209 header, the Identity header, which contains that cryptographic 210 assurance. In order to assist in the validation of the Identity 211 header, this specification also describes an Identity-Info header 212 that can be used by the recipient of a request to recover the 213 credentials of the signer. Note that the scope of this document is 214 limited to providing this identity assurance for SIP requests; 215 solving this problem for SIP responses is outside the scope of this 216 work (see [RFC4916]). 218 This specification allows either a user agent or a proxy server to 219 provide the authentication service function and/or the verification 220 service function. To maximize end-to-end security, it is obviously 221 preferable for end-users to acquire their own credentials; if they 222 do, their user agents can act as authentication services. However, 223 for some deployments end-user credentials may be neither practical 224 nor affordable, given the potentially large number of SIP user agents 225 (phones, PCs, laptops, PDAs, gaming devices) that may be employed by 226 a single user. In such environments, synchronizing keying material 227 across multiple devices may be prohibitively complex and require 228 quite a good deal of additional endpoint behavior. Managing several 229 credentials for the various devices could also be burdensome. In 230 these cases, implementation the authentication service at an 231 intermediary may be more practical. This trade-off needs to be 232 understood by implementers of this specification. 234 3. Overview of Operations 236 This section provides an informative (non-normative) high-level 237 overview of the mechanisms described in this document. 239 Imagine a case where Alice, who has the home proxy of example.com and 240 the address-of-record sip:alice@example.com, wants to communicate 241 with Bob at sip:bob@example.org. They have no prior relationship, 242 and Bob implements best practices to prevent impersonation attacks. 244 Alice generates an INVITE and places her identity, in this case her 245 address-of-record, in the From header field of the request. She then 246 sends an INVITE over TLS to an authentication service proxy for the 247 example.com domain. 249 The authentication service authenticates Alice (possibly by sending a 250 Digest authentication challenge) and validates that she is authorized 251 to assert the identity that she populated in the From header field. 252 This value is Alice's AoR, but in other cases it could be some 253 different value that the proxy server has authority over, such as a 254 telephone number. The proxy then computes a hash over some 255 particular headers and fields, including part of the From header 256 field of the message. This hash is signed with the appropriate 257 credential for the identity (example.com, in the 258 sip:alice@example.com case) and inserted in a new header field in the 259 SIP message, the 'Identity' header. 261 The proxy, as the holder of the private key for the example.com 262 domain, is asserting that the originator of this request has been 263 authenticated and that she is authorized to claim the identity that 264 appears in the From header field. The proxy also inserts a companion 265 header field, Identity-Info, that tells Bob how to acquire keying 266 material necessary to validate its credentials (a public key), in 267 case he doesn't already have it. 269 When Bob's domain receives the request, it verifies the signature 270 provided in the Identity header, and thus can validate that the 271 authority over the identity in the From header field authenticated 272 the user, and permitted the user to assert that From header field 273 value. This same validation operation may be performed by Bob's user 274 agent server (UAS). As the request has been validated, it is 275 rendered to Bob. If the validation was unsuccessful, some other 276 treatment would be applied by the receiving domain. 278 4. Signature Generation and Validation 280 4.1. Authentication Service Behavior 282 This document specifies a role for SIP entities called an 283 authentication service. The authentication service role can be 284 instantiated by an intermediary such as a proxy server or by a user 285 agent. Any entity that instantiates the authentication service role 286 MUST possess the private key of one or more credentials that can be 287 used to sign for a domain or a telephone number (see Section 5.1). 288 Intermediaries that instantiate this role MUST be capable of 289 authenticating one or more SIP users who can register for that 290 identity. Commonly, this role will be instantiated by a proxy 291 server, since these entities are more likely to have a static 292 hostname, hold corresponding credentials, and have access to SIP 293 registrar capabilities that allow them to authenticate users. It is 294 also possible that the authentication service role might be 295 instantiated by an entity that acts as a redirect server, but that is 296 left as a topic for future work. 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 First, the authentication service must determine whether it is 305 authoritative for the identity of the sender of the request. In 306 ordinary operations, the authentication service decides this by 307 inspecting the URI value from the addr-spec component of From header 308 field; this URI will be referred to here as the 'identity field'. If 309 the identity field contains a SIP or SIP Secure (SIPS) URI, and the 310 user portion is not a telephone number, the authentication service 311 MUST extract the hostname portion of the identity field and compare 312 it to the domain(s) for which it is responsible (following the 313 procedures in RFC 3261 [RFC3261], Section 16.4). If the identity 314 field uses the TEL URI scheme [RFC3966], or the identity field is a 315 SIP or SIPS URI with a telephone number in the user portion, the 316 authentication service determines whether or not it is responsible 317 for this telephone number; see Section 6.1 for more information. An 318 authentication service proceeding with a signature over a telephone 319 number MUST then follow the canonicaliaation procedures described in 320 Section 6.1.1. If the authentication service is not authoritative 321 for the identity in question, it SHOULD process and forward the 322 request normally, but it MUST NOT follow the steps below to add an 323 Identity header. An authentication service MUST NOT add an Identity 324 header to a request that already has one. 326 Step 2: 328 The authentication service MUST then determine whether or not the 329 sender of the request is authorized to claim the identity given in 330 the identity field. In order to do so, the authentication service 331 MUST authenticate the sender of the message. Some possible ways in 332 which this authentication might be performed include: 334 If the authentication service is instantiated by a SIP 335 intermediary (proxy server), it may authenticate the request with 336 the authentication scheme used for registration in its domain 337 (e.g., Digest authentication). 339 If the authentication service is instantiated by a SIP user agent, 340 a user agent may authenticate its own user through any system- 341 specific means, perhaps simply by virtue of having physical access 342 to the user agent. 344 Authorization of the use of a particular username or telephone number 345 in the user part of the From header field is a matter of local policy 346 for the authentication service, see Section 5.1 for more information. 348 Note that this check is performed only on the addr-spec in the 349 identity field (e.g., the URI of the sender, like 350 'sip:alice@atlanta.example.com'); it does not convert the display- 351 name portion of the From header field (e.g., 'Alice Atlanta'). 352 Authentication services MAY check and validate the display-name as 353 well, and compare it to a list of acceptable display-names that may 354 be used by the sender; if the display-name does not meet policy 355 constraints, the authentication service could return a 403 response 356 code. In this case, the reason phrase should indicate the nature of 357 the problem; for example, "Inappropriate Display Name". However, the 358 display-name is not always present, and in many environments the 359 requisite operational procedures for display-name validation may not 360 exist, so no normative guidance is given here. For more information, 361 see Section 10.6. 363 Step 3: 365 An authentication service MUST add a Date header field to SIP 366 requests if one is not already present. The authentication service 367 MUST ensure that any preexisting Date header in the request is 368 accurate. Local policy can dictate precisely how accurate the Date 369 must be; a RECOMMENDED maximum discrepancy of sixty seconds will 370 ensure that the request is unlikely to upset any verifiers. If the 371 Date header contains a time different by more than one minute from 372 the current time noted by the authentication service, the 373 authentication service SHOULD reject the request. This behavior is 374 not mandatory because a user agent client (UAC) could only exploit 375 the Date header in order to cause a request to fail verification; the 376 Identity header is not intended to provide a source of non- 377 repudiation or a perfect record of when messages are processed. 378 Finally, the authentication service MUST verify that the Date header 379 falls within the validity period of its credential. 381 See Section 7 for information on how the Date header field assists 382 verifiers. 384 Step 4: 386 The authentication service MAY add extend the identity mechanism by 387 adding one or more Identity-Extension headers to the request. Only 388 implementations that extend this base mechanism MAY populate this 389 header field and add this signature. See Section 8. 391 Step 5: 393 Subsequently, the authentication service MUST form the identity 394 signature and add an Identity header to the request containing this 395 signature. After the Identity header has been added to the request, 396 the authentication service MUST also add an Identity-Info header. 397 The Identity-Info header contains a URI from which the authentication 398 service's credential can be acquired; see Section 5.3 for more on 399 credential acquisition. Details on the syntax of both of these 400 headers are provided in Section 7. 402 Finally, the authentication service MUST forward the message 403 normally. 405 4.2. Verifier Behavior 407 This document specifies a logical role for SIP entities called a 408 verification service, or verifier. When a verifier receives a SIP 409 message containing an Identity header, it inspects the signature to 410 verify the identity of the sender of the message. Typically, the 411 results of a verification are provided as input to an authorization 412 process that is outside the scope of this document. If an Identity 413 header is not present in a request, and one is required by local 414 policy (for example, based on a per-sending-domain policy, or a per- 415 sending-user policy), then a 428 'Use Identity Header' response MUST 416 be sent. 418 In order to verify the identity of the sender of a message, an entity 419 acting as a verifier MUST perform the following steps, in the order 420 here specified. 422 Step 1: 424 In order to determine whether the signature for the identity field 425 should be over the entire URI or just a canonicalized telephone 426 number, the verification service MUST follow the canonicalization 427 process described in Section 6.1.1. That section also describes the 428 procedures the verification service MUST follow to determine if the 429 signer is authoritative for a telephone number. For domains, the 430 verifier MUST follow the process described in Section 6.2 to 431 determine if the signer is authoritative for the identity field. 433 Step 2: 435 The verifier must first ensure that it possesses the proper keying 436 material to validate the signature in the Identity header field, 437 which usually involves dereferencing the Identity-Info header. See 438 Section 5.2 for more information on these procedures. 440 Step 3: 442 The verifier MUST must furthermore ensure that the value of the Date 443 header meets local policy for freshness (usually, within sixty 444 seconds) and that it falls within the validity period of the 445 credential used to sign the Identity header. For more on the attacks 446 this prevents, see Section 10.1. 448 Step 4: 450 The verifier MUST validate the signature in the Identity header 451 field, following the procedures for generating the hashed digest- 452 string described in Section 7. If a verifier determines that the 453 signature on the message does not correspond to the reconstructed 454 digest-string, then a 438 'Invalid Identity Header' response MUST be 455 returned. 457 Step 5: 459 If the request contains one or more Identity-Extension headers, then 460 if the verifier supports the included extension(s), it SHOULD verify 461 any associated fields following the procedures specified in that 462 extension (see Section 8). If a verifier determines that such a 463 signature in the message does not correspond to the reconstructed 464 digest-string, then a 438 'Invalid Identity Header' response SHOULD 465 be returned. If the verifier does not support the extension(s), then 466 the verifier takes no further action. 468 The handling of the message after the verification process depends on 469 how the implementation service is implemented, and on local policy. 471 This specification does not propose any authorization policy for user 472 agents or proxy servers to follow based on the presence of a valid 473 Identity header, the presence of an invalid Identity header, or the 474 absence of an Identity header, but it is anticipated that local 475 policies could involve making different forwarding decisions in 476 intermediary implementations, or changing how the user is alerted, or 477 how identity is rendered, in user agent implementations. 479 5. Credentials 481 5.1. Credential Use by the Authentication Service 483 In order to act as an authentication service, a SIP entity must have 484 access to the private keying material of one or more credentials that 485 cover domain names or telephone numbers. These credentials may 486 represent authority over an entire domain (such as example.com) or 487 potentially a set of domains enumerated by the credential. 488 Similarly, a credential may represent authority over a single 489 telephone number or a range of telephone numbers. The way that the 490 scope of a credential is expressed is specific to the credential 491 mechanism. 493 Authorization of the use of a particular username or telephone number 494 in the identity field is a matter of local policy for the 495 authentication service, one that depends greatly on the manner in 496 which authentication is performed. For non-telephone number user 497 parts, one policy might be as follows: the username given in the 498 'username' parameter of the Proxy-Authorization header MUST 499 correspond exactly to the username in the From header field of the 500 SIP message. However, there are many cases in which this is too 501 limiting or inappropriate; a realm might use 'username' parameters in 502 Proxy-Authorization that do not correspond to the user-portion of SIP 503 From headers, or a user might manage multiple accounts in the same 504 administrative domain. In this latter case, a domain might maintain 505 a mapping between the values in the 'username' parameter of Proxy- 506 Authorization and a set of one or more SIP URIs that might 507 legitimately be asserted for that 'username'. For example, the 508 username can correspond to the 'private identity' as defined in Third 509 Generation Partnership Project (3GPP), in which case the From header 510 field can contain any one of the public identities associated with 511 this private identity. In this instance, another policy might be as 512 follows: the URI in the From header field MUST correspond exactly to 513 one of the mapped URIs associated with the 'username' given in the 514 Proxy-Authorization header. This is a suitable approach for 515 telephone numbers in particular. 517 This specification could also be used with credentials that cover a 518 single name or URI, such as alice@example.com or 519 sip:alice@example.com. This would require a modification to 520 authentication service behavior to operate on a whole URI rather than 521 a domain name. Because this is not believed to be a pressing use 522 case, this is deferred to future work, but implementors should note 523 this as a possible future direction. 525 Exceptions to such authentication service policies arise for cases 526 like anonymity; if the AoR asserted in the From header field uses a 527 form like 'sip:anonymous@example.com' (see [RFC3323]), then the 528 'example.com' proxy might authenticate only that the user is a valid 529 user in the domain and insert the signature over the From header 530 field as usual. 532 5.2. Credential Use by the Verification Service 534 In order to act as a verification service, a SIP entity must have a 535 way to acquire and retain credentials for authorities over particular 536 domain names and/or telephone numbers or number ranges. 537 Dereferencing the Identity-Info header (as described in the next 538 section) MUST be supported by all verification service 539 implementations to create a baseline means of credential acquisition. 540 Provided that the credential used to sign a message is not previously 541 known to the verifier, SIP entities SHOULD discover this credential 542 by dereferencing the Identity-Info header, unless they have some more 543 other implementation-specific way of acquiring the needed keying 544 material, such as an offline store of periodically-updated 545 credentials. If the URI in the Identity-Info header cannot be 546 dereferenced, then a 436 'Bad Identity-Info' response MUST be 547 returned. 549 This specification does not propose any particular policy for a 550 verification service to determine whether or not the holder of a 551 credential is the appropriate party to sign for a given SIP identity. 552 Guidance on this is deferred to the credential mechanism 553 specifications, which must meet the requirements in Section 5.4. 555 Verification service implementations supporting this specification 556 SHOULD have some means of retaining credentials (in accordance with 557 normal practices for credential lifetimes and revocation) in order to 558 prevent themselves from needlessly downloading the same credential 559 every time a request from the same identity is received. Credentials 560 cached in this manner may be indexed in accordance with local policy: 561 for example, by their scope, or the URI given in the Identity-Info 562 header field value. Further consideration of how to cache 563 credentials is deferred to the credential mechanism specifications. 565 5.3. Handling Identity-Info URIs 567 An Identity-Info header MUST contain a URI which dereferences to a 568 resource that contains the public key components of the credential 569 used by the authentication service to sign a request. It is 570 essential that a URI in the Identity-Info header be dereferencable by 571 any entity that could plausibly receive the request. For common 572 cases, this means that the URI must be dereferencable by any entity 573 on the public Internet. In constrained deployment environments, a 574 service private to the environment might be used instead. 576 Beyond providing a means of accessing credentials for an identity, 577 the Identity-Info header further serves as a means of differentiating 578 which particular credential was used to sign a request, when there 579 are potentially multiple authorities eligible to sign. For example, 580 imagine a case where a domain implements the authentication service 581 role for a range of telephone and a user agent belonging to Alice has 582 acquired a credential for a single telephone number within that 583 range. Either would be eligible to sign a SIP request for the number 584 in question. Verification services however need a means to 585 differentiate which one performed the signature. The Identity-Info 586 header performs that function. 588 If the optional "canon" parameter is present, it contains the result 589 of the number canonicalization process performed by the 590 authentication service (see Section 6.1.1) on the identity in the 591 From. This value is provided purely informationally as an 592 optimization for the verification service. The verification service 593 MAY compute its own canonicalization of the number and compare this 594 to the value in the "canon" parameter before performing any 595 cryptographic functions in order to ascertain whether or not the two 596 ends agree on the canonical number form. 598 5.4. Credential Systems 600 This document makes no recommendation for the use of any specific 601 credential system. Today, there are two primary credential systems 602 in place for proving ownership of domain names: certificates (e.g., 603 X.509 v3, see [RFC5280]) and the domain name system itself (e.g., 604 DANE, see [RFC6698]). It is envisioned that either could be used in 605 the SIP identity context: an Identity-Info header could for example 606 give an HTTP URL of the form 'application/pkix-cert' pointing to a 607 certificate (following the conventions of [RFC2585]). The Identity- 608 Info headers may use the DNS URL scheme (see [RFC4501]) to designate 609 keys in the DNS. 611 While no comparable public credentials exist for telephone numbers, 612 either approach could be applied to telephone numbers. A credential 613 system based on certificates is given in 614 [I-D.ietf-stir-certificates]. One based on the domain name system is 615 given in [I-D.kaplan-stir-cider]. 617 In order for a credential system to work with this mechanism, its 618 specification must detail: 620 which URIs schemes the credential will use in the Identity-Info 621 header, and any special procedures required to dereference the 622 URIs 624 how the verifier can learn the scope of the credential 626 any special procedures required to extract keying material from 627 the resources designated by the URI 629 any algorithms that would appear in the Identity-Info "alg" 630 parameter other than 'rsa-sha256.' Note that per the IANA 631 Considerations of RFC 4474, new algorithms can only be specified 632 by Standards Action 634 SIP entities cannot reliably predict where SIP requests will 635 terminate. When choosing a credential scheme for deployments of this 636 specification, it is therefore essential that the trust anchor(s) for 637 credentials be widely trusted, or that deployments restrict the use 638 of this mechanism to environments where the reliance on particular 639 trust anchors is assured by business arrangements or similar 640 constraints. 642 Note that credential systems must address key lifecycle management 643 concerns: were a domain to change the credential available at the 644 Identity-Info URI before a verifier evaluates a request signed by an 645 authentication service, this would cause obvious verifier failures. 646 When a rollover occurs, authentication services SHOULD thus provide 647 new Identity-Info URIs for each new credential, and SHOULD continue 648 to make older key acquisition URIs available for a duration longer 649 than the plausible lifetime of a SIP transaction (a minute would most 650 likely suffice). 652 6. Identity Types 654 6.1. Telephone Numbers 656 Since many SIP applications provide a Voice over IP (VoIP) service, 657 telephone numbers are commonly used as identities in SIP deployments. 658 In order for telephone numbers to be used with the mechanism 659 described in this document, authentication services must enroll with 660 an authority that issues credentials for telephone numbers or 661 telephone number ranges, and verification services must trust the 662 authority employed by the authentication service that signs a 663 request. Enrollment procedures and credential management are outside 664 the scope of this document. 666 In the longer term, it is possible that some directory or other 667 discovery mechanism may provide a way to determine which 668 administrative domain is responsible for a telephone number, and this 669 may aid in the signing and verification of SIP identities that 670 contain telephone numbers. This is a subject for future work. 672 In order to work with any such authorities, authentication and 673 verification services must be able to identify when a request should 674 be signed by an authority for a telephone number, and when it should 675 be signed by an authority for a domain. Telephone numbers most 676 commonly appear in SIP header field values in the username portion of 677 a SIP URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). 678 The user part of that URI conforms to the syntax of the TEL URI 679 scheme (RFC 3966 [RFC3966]). It is also possible for a TEL URI to 680 appear in the SIP To or From header field outside the context of a 681 SIP or SIPS URI (e.g., 'tel:+17005551008'). In both of these cases, 682 it's clear that the signer must have authority over the telephone 683 number, not the domain name of the SIP URI. It is also possible, 684 however, for requests to contain a URI like 685 'sip:7005551000@chicago.example.com'. It may be non-trivial for a 686 service to ascertain in this case whether the URI contains a 687 telephone number or not. 689 6.1.1. Canonicalization Procedures 691 In order to determine whether or not the user portion of a SIP URI is 692 a telephone number, authentication services and verification services 693 must perform the following canonicalization procedure on any SIP URI 694 they inspect which contains a wholly numeric user part. Note that 695 the same procedures are followed for creating the canonical form of 696 URIs found in both the From and To header field values. 698 First, implementations must assess if the user-portion of the URI 699 constitutes a telephone number. In some environments, numbers 700 will be explicitly labeled by the use of TEL URIs or the 701 'user=phone' parameter, or implicitly by the presence of the '+' 702 indicator at the start of the user-portion. Absent these 703 indications, if there are numbers present in the user-portion, 704 implementations may also detect that the user-portion of the URI 705 contains a telephone number by determining whether or not those 706 numbers would be dialable or routable in the local environment -- 707 bearing in mind that the telephone number may be a valid E.164 708 number, a nationally-specific number, or even a private branch 709 exchange number. 711 Once an implementation has identified a telephone number, it must 712 construct a number string. Implementations MUST drop any leading 713 +'s, any internal dashes, parentheses or other non-numeric 714 characters, excepting only the leading "#" or "*" keys used in 715 some special service numbers (typically, these will appear only in 716 the To header field value). This MUST result in an ASCII string 717 limited to "#", "*" and digits without whitespace or visual 718 separators. 720 Next, an implementation must assess if the number string is a 721 valid, globally-routable number with a leading country code. If 722 not, implementations SHOULD convert the number into E.164 format, 723 adding a country code if necessary; this may involve transforming 724 the number from a dial string (see [RFC3966]), removing any 725 national or international dialing prefixes or performing similar 726 procedures. It is only in the case that an implementation cannot 727 determine how to convert the number to a globally-routable format 728 that this step may be skipped. 730 In some cases, further transformations MAY be made in accordance 731 with specific policies used within the local domain. For example, 732 one domain may only use local number formatting and need to 733 convert all To/From user portions to E.164 by prepending country- 734 code and region code digits; another domain might prefix usernames 735 with trunk-routing codes and need to remove the prefix. Also, in 736 some networks, the P-Asserted-Identity header field value is used 737 in lieu of the From header field to convey the telephone number of 738 the sender of a request; while it is not envisioned that most of 739 those networks would or should make use of the Identity mechanism 740 described in this specification, where they do, local policy might 741 therefore dictate that the canonical string derive from the P- 742 Asserted-Identity header field rather than the From. In any case 743 where local policy canonicalizes the number into a form different 744 from how it appears in the From header field, the use of the 745 "canon" parameter by authentication services is RECOMMENDED, but 746 because "canon" itself could then divulge information about users 747 or networks, implementers should be mindful of the guidelines in 748 Section 9. 750 The resulting canonical number string will be used as input to the 751 hash calculation during signing and verifying processes. 753 The ABNF of this number string is: 755 tn-spec = [ "#" / "*" ] 1*DIGIT 757 If the result of this procedure forms a complete telephone number, 758 that number is used for the purpose of creating and signing the 759 digest-string by both the authentication service and verification 760 service. Practically, entities that perform the authentication 761 service role will sometimes alter the telephone numbers that appear 762 in the To and From header field values, converting them to this 763 format (though note this is not a function that [RFC3261] permits 764 proxy servers to perform). The authentication service MAY also add 765 the result of the canonicalization process of the From header field 766 value to the "canon" parameter of the Identity-Info header. If the 767 result of the canonicalization of the From header field value does 768 not form a complete telephone number, the authentication service and 769 verification service should treat the entire URI as a SIP URI, and 770 apply a domain signature per the procedures in Section 6.2. 772 6.2. Domain Names 774 When a verifier processes a request containing an Identity-Info 775 header with a domain signature, it must compare the domain portion of 776 the URI in the From header field of the request with the domain name 777 that is the subject of the credential acquired from the Identity-Info 778 header. While it might seem that this should be a straightforward 779 process, it is complicated by two deployment realities. In the first 780 place, credentials have varying ways of describing their subjects, 781 and may indeed have multiple subjects, especially in 'virtual 782 hosting' cases where multiple domains are managed by a single 783 application. Secondly, some SIP services may delegate SIP functions 784 to a subordinate domain and utilize the procedures in RFC 3263 785 [RFC3263] that allow requests for, say, 'example.com' to be routed to 786 'sip.example.com'. As a result, a user with the AoR 787 'sip:jon@example.com' may process requests through a host like 788 'sip.example.com', and it may be that latter host that acts as an 789 authentication service. 791 To meet the second of these problems, a domain that deploys an 792 authentication service on a subordinate host MUST be willing to 793 supply that host with the private keying material associated with a 794 credential whose subject is a domain name that corresponds to the 795 domain portion of the AoRs that the domain distributes to users. 796 Note that this corresponds to the comparable case of routing inbound 797 SIP requests to a domain. When the NAPTR and SRV procedures of RFC 798 3263 are used to direct requests to a domain name other than the 799 domain in the original Request-URI (e.g., for 'sip:jon@example.com', 800 the corresponding SRV records point to the service 801 'sip1.example.org'), the client expects that the certificate passed 802 back in any TLS exchange with that host will correspond exactly with 803 the domain of the original Request-URI, not the domain name of the 804 host. Consequently, in order to make inbound routing to such SIP 805 services work, a domain administrator must similarly be willing to 806 share the domain's private key with the service. This design 807 decision was made to compensate for the insecurity of the DNS, and it 808 makes certain potential approaches to DNS-based 'virtual hosting' 809 unsecurable for SIP in environments where domain administrators are 810 unwilling to share keys with hosting services. 812 A verifier MUST evaluate the correspondence between the user's 813 identity and the signing credential by following the procedures 814 defined in RFC 2818 [RFC2818], Section 3.1. While RFC 2818 [RFC2818] 815 deals with the use of HTTP in TLS and is specific to certificates, 816 the procedures described are applicable to verifying identity if one 817 substitutes the "hostname of the server" in HTTP for the domain 818 portion of the user's identity in the From header field of a SIP 819 request with an Identity header. 821 7. Header Syntax 823 Baseline RFC4474 defined the Identity and Identity-Info headers. 824 This document updates that specification and adds the optional 825 Identity-Extension header (the grammar for which appears in 826 Section 8). Identity and Identity-Info are REQUIRED for securing 827 requests with this specification, and may appear only once in a 828 request, while Identity-Extension can be present multiple times. The 829 grammar for the first two headers is (following the ABNF [RFC4234] in 830 RFC 3261 [RFC3261]): 832 Identity = "Identity" HCOLON signed-identity-digest 833 signed-identity-digest = LDQUOT *base64-char RDQUOT 835 Identity-Info = "Identity-Info" HCOLON ident-info 836 *( SEMI ident-info-params ) 837 ident-info = LAQUOT absoluteURI RAQUOT 838 ident-info-params = ident-info-alg / canonical-str / ident-info-extension 839 ident-info-alg = "alg" EQUAL token 840 canonical-str = "canon" EQUAL tn-spec 841 ident-info-extension = generic-param 843 base64-char = ALPHA / DIGIT / "/" / "+" 845 This follows the original specification of Identity and Identity-Info 846 in RFC4474, except for the addition of the "canon" parameter. Note 847 that in RFC4474, the signed-identity-digest was given as quoted 848 32LHEX, whereas here it is given as a quoted sequence of base64-char. 850 The signed-identity-digest is a signed hash of a canonical string 851 generated from certain components of a SIP request. To create the 852 contents of the signed-identity-digest, the following elements of a 853 SIP message MUST be placed in a bit-exact string in the order 854 specified here, separated by a vertical line, "|" or %x7C, character: 856 First, the identity. If the user part of the AoR in the From 857 header field of the request contains a telephone number, then the 858 canonicalization of that number goes into the first slot (see 859 Section 6.1.1). Otherwise, the first slot contains the AoR of the 860 UA sending the message as taken from addr-spec of the From header 861 field. 863 Second, the target. If the user part of the AoR in the To header 864 field of the request contains a telephone number, then the 865 canonicalization of that number goes into the second slot (again, 866 see Section 6.1.1). Otherwise, the second slot contains the addr- 867 spec component of the To header field, which is the AoR to which 868 the request is being sent. 870 Third, the request method. 872 Fourth, the Date header field, with exactly one space each for 873 each SP and the weekday and month items case set as shown in the 874 BNF of RFC 3261 [RFC3261]. RFC 3261 specifies that the BNF for 875 weekday and month is a choice amongst a set of tokens. The RFC 876 4234 [RFC4234] rules for the BNF specify that tokens are case 877 sensitive. However, when used to construct the canonical string 878 defined here, the first letter of each week and month MUST be 879 capitalized, and the remaining two letters must be lowercase. 880 This matches the capitalization provided in the definition of each 881 token. All requests that use the Identity mechanism MUST contain 882 a Date header. 884 Fifth, if the request contains an SDP message body, and if that 885 SDP contains one or more "a=fingerprint" attributes, the value(s) 886 of the attributes if they differ. Each attribute value consists 887 of all characters following the colon after "a=fingerprint" 888 including the algorithm description and hexadecimal key 889 representation, any whitespace, carriage returns, and "/" line 890 break indicators. If multiple non-identical "a=fingerprint" 891 attributes appear in an SDP body, then all non-identical 892 attributes values MUST be concatenated, with no separating 893 character, after sorting the values in alphanumeric order. If the 894 SDP body contains no "a=fingerprint" attribute, the fifth element 895 MUST be empty, containing no whitespace, resulting in a "||" in 896 the signed-identity-digest. 898 Sixth, the Identity-Extension header field value(s), if there is 899 at least one Identity-Extension header field in the request. If 900 multiple Identity-Extension header fields are in the request, they 901 MUST be concatenated after sorting the header field values in 902 alphanumeric order, with each entry separated by a vertical line, 903 "|" or %x7C. If the message contains no Identity-Extension 904 header, then the sixth slot MUST be empty, containing no 905 whitespace, resulting in a "||" in the signed-identity-digest. 906 characters. 908 For more information on the security properties of these headers, and 909 why their inclusion mitigates replay attacks, see Section 10 and 910 [RFC3893]. The precise formulation of this digest-string is, 911 therefore (following the ABNF[RFC4234] in RFC 3261 [RFC3261]): 913 digest-string = ( addr-spec / tn-spec ) "|" ( addr-spec / tn-spec ) "|" 914 Method "|" SIP-date "|" [ sdp-fingerprint ] "|" 915 [ signed-identity-extension-digest ] 917 sdp-fingerprint = byte-string 919 For the definition of 'tn-spec' see Section 6.1.1. 921 After the digest-string is formed, it MUST be hashed and signed with 922 the certificate of authority over the identity. The hashing and 923 signing algorithm is specified by the 'alg' parameter of the 924 Identity-Info header (see below for more information on Identity-Info 925 header parameters). This document defines only one value for the 926 'alg' parameter: 'rsa-sha256'; further values MUST be defined in a 927 Standards Track RFC, see Section 11.3 for more information. All 928 implementations of this specification MUST support 'rsa-sha256'. 929 When the 'rsa-sha256' algorithm is specified in the 'alg' parameter 930 of Identity-Info, the hash and signature MUST be generated as 931 follows: compute the results of signing this string with 932 sha1WithRSAEncryption as described in RFC 3370 [RFC3370] and base64 933 encode the results as specified in RFC 3548 [RFC3548]. A 2048-bit or 934 longer RSA key MUST be used. The result of the digest-string hash is 935 placed in the Identity header field. 937 The 'absoluteURI' portion of the Identity-Info header MUST contain a 938 URI; see Section 5.3 for more on choosing how to advertise 939 credentials through Identity-Info. 941 8. Extensibility 943 As future requirements may warrant increasing the scope of the 944 Identity mechanism, this specification defines an optional Identity- 945 Extension header. Each extension header field value MUST consist of 946 a right hand side identifying the extension, an equals sign, and then 947 a left hand side consisting of a signature over an element in a SIP 948 request. 950 Future specifications that define extensions to the Identity 951 mechanism must explicitly designate which elements of a SIP request 952 are to be signed, how a canonical string of those elements is 953 generated by both the authentication service and the verifier, and 954 the mechanism and algorithms used to generate the signature (it is 955 RECOMMENDED that these follow the algorithm choice of this 956 specification). Note that per verifier behavior in Section 4.2, 957 verifying an extension is always optional. An authentication service 958 cannot assume that verifiers will understand any given extension. 959 Verifiers that do support an extension may then trigger appropriate 960 application-level behavior in the presence of a signature over 961 additional part of the SIP request; authors of Identity extensions 962 should provide appropriate extension-specific guidance to application 963 developers on this point. 965 Identity-Extension = "Identity-Extension" HCOLON identity-extension-string 966 identity-extension-string = identity-extension-name EQUAL *base64-char 967 identity-extension-name = token 968 signed-identity-extension-digest = LDQUOT *base64-char RDQUOT 970 Defining a new Identity-Extension requires a Standards Action; see 971 Section 11.4. 973 9. Privacy Considerations 975 The purpose of this mechanism is to provide a strong identification 976 of the originator of a SIP request, specifically a cryptographic 977 assurance that the URI given in the From header field value can 978 legitimately be claimed by the originator. This URI may contain a 979 variety of personally identifying information, including the name of 980 a human being, their place of work or service provider, and possibly 981 further details. The intrinsic privacy risks associated with that 982 URI are, however, no different from those of baseline SIP. Per the 983 guidance in [RFC6973], implementors should make users aware of the 984 privacy trade-off of providing secure identity. 986 The identity mechanism presented in this document is compatible with 987 the standard SIP practices for privacy described in [RFC3323]. A SIP 988 proxy server can act both as a privacy service and as an 989 authentication service. Since a user agent can provide any From 990 header field value that the authentication service is willing to 991 authorize, there is no reason why private SIP URIs that contain 992 legitimate domains (e.g., sip:anonymous@example.com) cannot be signed 993 by an authentication service. The construction of the Identity 994 header is the same for private URIs as it is for any other sort of 995 URIs. 997 Note, however, that even when using anonymous SIP URIs, an 998 authentication service must possess a certificate corresponding to 999 the host portion of the addr-spec of the From header field of the 1000 request; accordingly, using domains like 'anonymous.invalid' will not 1001 be possible for privacy services that also act as authentication 1002 services. The assurance offered by the usage of anonymous URIs with 1003 a valid domain portion is "this is a known user in my domain that I 1004 have authenticated, but I am keeping its identity private". The use 1005 of the domain 'anonymous.invalid' entails that no corresponding 1006 authority for the domain can exist, and as a consequence, 1007 authentication service functions for that domain are meaningless. 1009 [RFC3325] defines the "id" priv-value token, which is specific to the 1010 P-Asserted-Identity header. The sort of assertion provided by the P- 1011 Asserted-Identity header is very different from the Identity header 1012 presented in this document. It contains additional information about 1013 the sender of a message that may go beyond what appears in the From 1014 header field; P-Asserted-Identity holds a definitive identity for the 1015 sender that is somehow known to a closed network of intermediaries 1016 that presumably the network will use this identity for billing or 1017 security purposes. The danger of this network-specific information 1018 leaking outside of the closed network motivated the "id" priv-value 1019 token. The "id" priv-value token has no implications for the 1020 Identity header, and privacy services MUST NOT remove the Identity 1021 header when a priv-value of "id" appears in a Privacy header. 1023 The optional "canon" parameter of the Identity-Info header specified 1024 in this document provides a canonicalized form of the telephone 1025 number of the originator of a call. In some contexts, local policy 1026 may be used to populate a "canon" that may differ substantially from 1027 the original From header field. Depending on those policies, 1028 potentially the "canon" parameter might divulge information about the 1029 originating network or user that might not appear elsewhere in the 1030 SIP request. Were it to be used to reflect the contents of the P- 1031 Asserted-Identity header field, for example, then "canon" would need 1032 to be removed when the P-Asserted-Identity header is removed to avoid 1033 any such leakage outside of a trust domain. Since, in those 1034 contexts, the canonical form of the sender's identity could not be 1035 reassembled by a verifier, and thus the Identity signature validation 1036 process would fail, using P-Asserted-Identity with the Identity 1037 "canon" parameter in this fashion is NOT RECOMMENDED outside of 1038 environments where SIP requests will never leave the trust domain. 1040 Finally, note that unlike [RFC3325], the mechanism described in this 1041 specification adds no information to SIP requests that has privacy 1042 implications. 1044 10. Security Considerations 1046 This document describes a mechanism that provides a signature over 1047 the Date header field of SIP requests, parts of the To and From 1048 header fields, the request method, and when present any media keying 1049 material in the message body. In general, the considerations related 1050 to the security of these headers are the same as those given in 1051 [RFC3261] for including headers in tunneled 'message/sip' MIME bodies 1052 (see Section 23 in particular). The following section details the 1053 individual security properties obtained by including each of these 1054 header fields within the signature; collectively, this set of header 1055 fields provides the necessary properties to prevent impersonation. 1056 It adddresses the solution-specific attacks again in-band solutions 1057 enumerated in [RFC7375] Section 4.1. 1059 10.1. Protected Request Fields 1061 The From header field value indicates the identity of the sender of 1062 the message, and the SIP address-of-record URI, or an embedded 1063 telephone number, in the From header field is the identity of a SIP 1064 user, for the purposes of this document. This is the key piece of 1065 information that this mechanism secures; the remainder of the signed 1066 parts of a SIP request are present to provide reference integrity and 1067 to prevent certain types of cut-and-paste attacks. 1069 The Date header field value protects against cut-and-paste attacks, 1070 as described in [RFC3261], Section 23.4.2. Implementations of this 1071 specification MUST NOT deem valid a request with an outdated Date 1072 header field (the RECOMMENDED interval is that the Date header must 1073 indicate a time within 60 seconds of the receipt of a message). Note 1074 that per baseline [RFC3261] behavior, servers keep state of recently 1075 received requests, and thus if an Identity header is replayed by an 1076 attacker within the Date interval, verifiers can detect that it is 1077 spoofed; because a message with an identical Date from the same 1078 source had recently been received. 1080 The To header field value provides the identity of the SIP user that 1081 this request originally targeted. Providing the To header field in 1082 the Identity signature serves two purposes: first, it prevents cut- 1083 and-paste attacks in which an Identity header from legitimate request 1084 for one user is cut-and-pasted into a request for a different user; 1085 second, it preserves the starting URI scheme of the request, which 1086 helps prevent downgrade attacks against the use of SIPS. The To 1087 offers additional protection against cut-and-paste attacks beyond the 1088 Date header field: for example, without a signature over the To, an 1089 attacker who receives a call from a target could immediately forward 1090 the INVITE to the target's voicemail service within the Date 1091 interval, and the voicemail service would have no way knowing that 1092 the Identity header it received had been originally signed for a call 1093 intended for a different number. However, note the caveats below in 1094 Section 10.1.1. 1096 Without the request method, an INVITE request could be cut- and- 1097 pasted by an attacker and transformed into a MESSAGE request without 1098 changing any fields covered by the Identity header, and moreover 1099 requests within a transaction (for example, a re-INVITE) could be 1100 replayed in potentially confusing or malicious ways to enable 1101 impersonation. 1103 When signing a request that contains a fingerprint of keying material 1104 in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a 1105 signature over that fingerprint. This signature prevents certain 1106 classes of impersonation attacks in which an attacker forwards or 1107 cut-and-pastes a legitimate request: although the target of the 1108 attack may accept the request, the attacker will be unable to 1109 exchange media with the target as they will not possess a key 1110 corresponding to the fingerprint. For example there are some baiting 1111 attacks, launched with the REFER method or through social 1112 engineering, where the attacker receives a request from the target 1113 and reoriginates it to a third party: these might not be prevented by 1114 only a signature over the From, To and Date, but could be prevented 1115 by securing a fingerprint for DTLS-SRTP. While this is a different 1116 form of impersonation than is commonly used for robocalling, 1117 ultimately there is little purpose in establishing the identity of 1118 the user that originated a SIP request if this assurance is not 1119 coupled with a comparable assurance over the contents of the 1120 subsequent communication. This signature also, per [RFC7258], 1121 reduces the potential for passive monitoring attacks against the SIP 1122 media. In environments where DTLS-SRTP is unsupported, however, no 1123 field is signed and no protections are provided. 1125 10.1.1. Protection of the To Header and Retargeting 1127 The mechanism in this document provides a signature over the identity 1128 information in the To header field value of requests. This provides 1129 a means for verifiers to detect replay attacks where a signed request 1130 originally sent to one target is modified and then forwarded by an 1131 attacker to another, unrelated target. Armed with the original value 1132 of the To header field, the recipient of a request may compare it to 1133 their own identity in order to determine whether or not the identity 1134 information in this call might have been replayed. However, any 1135 request may be legitimately retargeted as well, and as a result 1136 legitimate requests may reach a SIP endpoint whose user is not 1137 identified by the URI designated in the To header field value. It is 1138 therefore difficult for any verifier to decide whether or not some 1139 prior retargeting was "legitimate." Retargeting can also cause 1140 confusion when identity information is provided for requests sent in 1141 the backwards in a dialog, as the dialog identifiers may not match 1142 credentials held by the ultimate target of the dialog. For further 1143 information on the problems of response identity see 1144 [I-D.peterson-sipping-retarget]. 1146 Any means for authentication services or verifiers to anticipate 1147 retargeting is outside the scope of this document, and likely to have 1148 equal applicability to response identity as it does to requests in 1149 the backwards direction within a dialog. Consequently, no special 1150 guidance is given for implementers here regarding the 'connected 1151 party' problem (see [RFC4916]); authentication service behavior is 1152 unchanged if retargeting has occurred for a dialog-forming request. 1153 Ultimately, the authentication service provides an Identity header 1154 for requests in the backwards dialog when the user is authorized to 1155 assert the identity given in the From header field, and if they are 1156 not, an Identity header is not provided. And per the threat model of 1157 [RFC7375], resolving problems with 'connected' identity has little 1158 bearing on detecting robocalling or related impersonation attacks. 1160 10.2. Unprotected Request Fields 1162 RFC4474 originally had protections for the Contact, Call-ID and CSeq. 1163 These are removed from RFC4474bis. The absence of these header 1164 values creates some opportunities for determined attackers to 1165 impersonate based on cut-and-paste attacks; however, the absence of 1166 these headers does not seem impactful to preventing the simple 1167 unauthorized claiming of an identity for the purposes of robocalling, 1168 voicemail hacking, or swatting, which is the primary scope of the 1169 current document. 1171 It might seem attractive to provide a signature over some of the 1172 information present in the Via header field value(s). For example, 1173 without a signature over the sent-by field of the topmost Via header, 1174 an attacker could remove that Via header and insert its own in a cut- 1175 and-paste attack, which would cause all responses to the request to 1176 be routed to a host of the attacker's choosing. However, a signature 1177 over the topmost Via header does not prevent attacks of this nature, 1178 since the attacker could leave the topmost Via intact and merely 1179 insert a new Via header field directly after it, which would cause 1180 responses to be routed to the attacker's host "on their way" to the 1181 valid host, which has exactly the same end result. Although it is 1182 possible that an intermediary-based authentication service could 1183 guarantee that no Via hops are inserted between the sending user 1184 agent and the authentication service, it could not prevent an 1185 attacker from adding a Via hop after the authentication service, and 1186 thereby preempting responses. It is necessary for the proper 1187 operation of SIP for subsequent intermediaries to be capable of 1188 inserting such Via header fields, and thus it cannot be prevented. 1189 As such, though it is desirable, securing Via is not possible through 1190 the sort of identity mechanism described in this document; the best 1191 known practice for securing Via is the use of SIPS. 1193 10.3. Malicious Removal of Identity Headers 1195 In the end analysis, the Identity, Identity-Info and Identity- 1196 Extension headers cannot protect themselves. Any attacker could 1197 remove these headers from a SIP request, and modify the request 1198 arbitrarily afterwards. However, this mechanism is not intended to 1199 protect requests from men-in-the-middle who interfere with SIP 1200 messages; it is intended only to provide a way that the originators 1201 of SIP requests can prove that they are who they claim to be. At 1202 best, by stripping identity information from a request, a man-in-the- 1203 middle could make it impossible to distinguish any illegitimate 1204 messages he would like to send from those messages sent by an 1205 authorized user. However, it requires a considerably greater amount 1206 of energy to mount such an attack than it does to mount trivial 1207 impersonations by just copying someone else's From header field. 1208 This mechanism provides a way that an authorized user can provide a 1209 definitive assurance of his identity that an unauthorized user, an 1210 impersonator, cannot. 1212 One additional respect in which the Identity-Info header cannot 1213 protect itself is the 'alg' parameter. The 'alg' parameter is not 1214 included in the digest-string, and accordingly, a man-in-the-middle 1215 might attempt to modify the 'alg' parameter. Once again, it is 1216 important to note that preventing men-in-the-middle is not the 1217 motivation for this mechanism. Moreover, changing the 'alg' would at 1218 worst result in some sort of bid-down attack, and at best cause a 1219 failure in the verifier. Note that only one valid 'alg' parameter is 1220 defined in this document and that thus there is currently no weaker 1221 algorithm to which the mechanism can be bid down. 'alg' has been 1222 incorporated into this mechanism for forward-compatibility reasons in 1223 case the current algorithm exhibits weaknesses, and requires swift 1224 replacement, in the future. 1226 10.4. Securing the Connection to the Authentication Service 1228 In the absence of user agent-based authentication services, the 1229 assurance provided by this mechanism is strongest when a user agent 1230 forms a direct connection, preferably one secured by TLS, to an 1231 intermediary-based authentication service. The reasons for this are 1232 twofold: 1234 If a user does not receive a certificate from the authentication 1235 service over the TLS connection that corresponds to the expected 1236 domain (especially when the user receives a challenge via a 1237 mechanism such as Digest), then it is possible that a rogue server 1238 is attempting to pose as an authentication service for a domain 1239 that it does not control, possibly in an attempt to collect shared 1240 secrets for that domain. A similar practice could be used for 1241 telephone numbers, though the application of certificates for 1242 telephone numbers to TLS is left as a matter for future study. 1244 Without TLS, the various header field values and the body of the 1245 request will not have integrity protection when the request 1246 arrives at an authentication service. Accordingly, a prior 1247 legitimate or illegitimate intermediary could modify the message 1248 arbitrarily. 1250 Of these two concerns, the first is most material to the intended 1251 scope of this mechanism. This mechanism is intended to prevent 1252 impersonation attacks, not man-in-the-middle attacks; integrity over 1253 the header and bodies is provided by this mechanism only to prevent 1254 replay attacks. However, it is possible that applications relying on 1255 the presence of the Identity header could leverage this integrity 1256 protection, especially body integrity, for services other than replay 1257 protection. 1259 Accordingly, direct TLS connections SHOULD be used between the UAC 1260 and the authentication service whenever possible. The opportunistic 1261 nature of this mechanism, however, makes it very difficult to 1262 constrain UAC behavior, and moreover there will be some deployment 1263 architectures where a direct connection is simply infeasible and the 1264 UAC cannot act as an authentication service itself. Accordingly, 1265 when a direct connection and TLS are not possible, a UAC should use 1266 the SIPS mechanism, Digest 'auth-int' for body integrity, or both 1267 when it can. The ultimate decision to add an Identity header to a 1268 request lies with the authentication service, of course; domain 1269 policy must identify those cases where the UAC's security association 1270 with the authentication service is too weak. 1272 10.5. Authorization and Transitional Strategies 1274 Ultimately, the worth of an assurance provided by an Identity header 1275 is limited by the security practices of the authentication service 1276 that issues the assurance. Relying on an Identity header generated 1277 by a remote administrative domain assumes that the issuing domain 1278 uses recommended administrative practices to authenticate its users. 1280 However, it is possible that some authentication services will 1281 implement policies that effectively make users unaccountable (e.g., 1282 ones that accept unauthenticated registrations from arbitrary users). 1283 The value of an Identity header from such authentication services is 1284 questionable. While there is no magic way for a verifier to 1285 distinguish "good" from "bad" signers by inspecting a SIP request, it 1286 is expected that further work in authorization practices could be 1287 built on top of this identity solution; without such an identity 1288 solution, many promising approaches to authorization policy are 1289 impossible. That much said, it is RECOMMENDED that authentication 1290 services based on proxy servers employ strong authentication 1291 practices. 1293 One cannot expect the Identity and Identity-Info headers to be 1294 supported by every SIP entity overnight. This leaves the verifier in 1295 a compromising position; when it receives a request from a given SIP 1296 user, how can it know whether or not the sender's domain supports 1297 Identity? In the absence of ubiquitous support for identity, some 1298 transitional strategies are necessary. 1300 A verifier could remember when it receives a request from a domain 1301 or telephone number that uses Identity, and in the future, view 1302 messages received from that sources without Identity headers with 1303 skepticism. 1305 A verifier could consult some sort of directory that indications 1306 whether a given caller should have a signed identity. There are a 1307 number of potential ways in which this could be implemented. This 1308 is left as a subject for future work. 1310 In the long term, some sort of identity mechanism, either the one 1311 documented in this specification or a successor, must become 1312 mandatory-to-use for the SIP protocol; that is the only way to 1313 guarantee that this protection can always be expected by verifiers. 1315 Finally, it is worth noting that the presence or absence of the 1316 Identity headers cannot be the sole factor in making an authorization 1317 decision. Permissions might be granted to a message on the basis of 1318 the specific verified Identity or really on any other aspect of a SIP 1319 request. Authorization policies are outside the scope of this 1320 specification, but this specification advises any future 1321 authorization work not to assume that messages with valid Identity 1322 headers are always good. 1324 10.6. Display-Names and Identity 1326 As a matter of interface design, SIP user agents might render the 1327 display-name portion of the From header field of a caller as the 1328 identity of the caller; there is a significant precedent in email 1329 user interfaces for this practice. Securing the display-name 1330 component of the From header field value is outside the scope of this 1331 document, but may be the subject of future work, such as an extension. 1333 11. IANA Considerations 1335 This document relies on the headers and response codes defined in RFC 1336 4474. It also retains the requirements for the specification of new 1337 algorithms or headers related to the mechanisms described in that 1338 document. 1340 11.1. Header Field Names 1342 This document also specifies a new SIP header called Identity- 1343 Extension. Its syntax is given in Section 8. A registry for 1344 Identity-Extension names is defined in Section 11.4. 1346 Header Name: Identity-Extension 1347 Compact Form: N/A 1349 11.2. Identity-Info Parameters 1351 The IANA has already created a registry for Identity-Info header 1352 parameters. This specification defines a new value called "canon" as 1353 defined in Section 5.3. 1355 11.3. Identity-Info Algorithm Parameter Values 1357 The IANA has already created a registry for Identity-Info 'alg' 1358 parameter values. This registry is to be prepopulated with a single 1359 entry for a value called 'rsa-sha256', which describes the algorithm 1360 used to create the signature that appears in the Identity header. 1361 Registry entries must contain the name of the 'alg' parameter value 1362 and the specification in which the value is described. New values 1363 for the 'alg' parameter may be defined only in Standards Track RFCs. 1365 RFC4474 defined the 'rsa-sha1' value for this registry. That value 1366 is hereby deprecated, and should be treated as such. It is not 1367 believed that any implementations are making use of this value. 1369 Future specifications may consider elliptical curves for smaller key 1370 sizes. 1372 11.4. Identity-Extension Names 1374 This specification requests that the IANA create a new registry for 1375 Identity-Extension names. The registry will consist solely of a list 1376 of names mapped to the Standards Track RFCs in which those extensions 1377 are defined. 1379 The syntax of Identity-Extension names is given in Section 8. 1380 Registering a new Identity-Extension name requires a Standards 1381 Action. 1383 This specification does not provide any initial values for Identity- 1384 Extension names. 1386 12. Acknowledgments 1388 The authors would like to thank Stephen Kent, Brian Rosen, Alex 1389 Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin 1390 Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, 1391 Pierce Gorman, David Schwartz, Philippe Fouquart, Michael Hamer, 1392 Henning Schulzrinne, and Richard Barnes for their comments. 1394 13. Changes from RFC4474 1396 The following are salient changes from the original RFC 4474: 1398 Generalized the credential mechanism; credential enrollment and 1399 acquisition is now outside the scope of this document 1401 Reduced the scope of the Identity signature to remove CSeq, Call- 1402 ID, Contact, and the message body 1404 Added any DTLS-SRTP fingerprint in SDP as a mandatory element of 1405 the digest-string 1407 Added the Identity-Extension header and extensibility mechanism 1409 Deprecated 'rsa-sha1' in favor of new baseline signing algorithm 1411 14. References 1413 14.1. Normative References 1415 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1416 DOI 10.17487/RFC2818, May 2000, 1417 . 1419 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1420 A., Peterson, J., Sparks, R., Handley, M., and E. 1421 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1422 DOI 10.17487/RFC3261, June 2002, 1423 . 1425 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1426 Protocol (SIP): Locating SIP Servers", RFC 3263, 1427 DOI 10.17487/RFC3263, June 2002, 1428 . 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 DOI 10.17487/RFC3280, April 2002, 1434 . 1436 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1437 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1438 . 1440 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1441 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1442 . 1444 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1445 Housley, R., and W. Polk, "Internet X.509 Public Key 1446 Infrastructure Certificate and Certificate Revocation List 1447 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1448 . 1450 14.2. Informative References 1452 [I-D.ietf-stir-certificates] 1453 Peterson, J., "Secure Telephone Identity Credentials: 1454 Certificates", draft-ietf-stir-certificates-02 (work in 1455 progress), July 2015. 1457 [I-D.kaplan-stir-cider] 1458 Kaplan, H., "A proposal for Caller Identity in a DNS-based 1459 Entrusted Registry (CIDER)", draft-kaplan-stir-cider-00 1460 (work in progress), July 2013. 1462 [I-D.peterson-sipping-retarget] 1463 Peterson, J., "Retargeting and Security in SIP: A 1464 Framework and Requirements", draft-peterson-sipping- 1465 retarget-00 (work in progress), February 2005. 1467 [I-D.rosenberg-sip-rfc4474-concerns] 1468 Rosenberg, J., "Concerns around the Applicability of RFC 1469 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 1470 progress), February 2008. 1472 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1473 Infrastructure Operational Protocols: FTP and HTTP", 1474 RFC 2585, DOI 10.17487/RFC2585, May 1999, 1475 . 1477 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1478 Initiation Protocol (SIP)", RFC 3323, 1479 DOI 10.17487/RFC3323, November 2002, 1480 . 1482 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1483 Extensions to the Session Initiation Protocol (SIP) for 1484 Asserted Identity within Trusted Networks", RFC 3325, 1485 DOI 10.17487/RFC3325, November 2002, 1486 . 1488 [RFC3548] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data 1489 Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003, 1490 . 1492 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1493 Authenticated Identity Body (AIB) Format", RFC 3893, 1494 DOI 10.17487/RFC3893, September 2004, 1495 . 1497 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1498 Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, 1499 October 2005, . 1501 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1502 Authenticated Identity Management in the Session 1503 Initiation Protocol (SIP)", RFC 4474, 1504 DOI 10.17487/RFC4474, August 2006, 1505 . 1507 [RFC4501] Josefsson, S., "Domain Name System Uniform Resource 1508 Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, 1509 . 1511 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1512 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 1513 2007, . 1515 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1516 for Establishing a Secure Real-time Transport Protocol 1517 (SRTP) Security Context Using Datagram Transport Layer 1518 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1519 2010, . 1521 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1522 of Named Entities (DANE) Transport Layer Security (TLS) 1523 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1524 2012, . 1526 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1527 Morris, J., Hansen, M., and R. Smith, "Privacy 1528 Considerations for Internet Protocols", RFC 6973, 1529 DOI 10.17487/RFC6973, July 2013, 1530 . 1532 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1533 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1534 2014, . 1536 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1537 Telephone Identity Problem Statement and Requirements", 1538 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1539 . 1541 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 1542 RFC 7375, DOI 10.17487/RFC7375, October 2014, 1543 . 1545 Authors' Addresses 1547 Jon Peterson 1548 Neustar, Inc. 1549 1800 Sutter St Suite 570 1550 Concord, CA 94520 1551 US 1553 Email: jon.peterson@neustar.biz 1555 Cullen Jennings 1556 Cisco 1557 400 3rd Avenue SW, Suite 350 1558 Calgary, AB T2P 4H2 1559 Canada 1561 Email: fluffy@iii.ca 1562 Eric Rescorla 1563 RTFM, Inc. 1564 2064 Edgewood Drive 1565 Palo Alto, CA 94303 1566 USA 1568 Phone: +1 650 678 2350 1569 Email: ekr@rtfm.com