idnits 2.17.1 draft-ietf-stir-rfc4474bis-09.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 3 instances of too long lines in the document, the longest one being 26 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In a departure from JWT practice, the SIP usage of PASSporT MAY NOT include the base64 encoded version of the JSON objects in the Identity header: only the signature component of the PASSporT is REQUIRED. Optionally, as a debugging measure or optimization, the base64 encoded concatenation of the JSON header and claims may be included as the value of a "canon" parameter of the Identity header. Note that this may be lengthy string. -- The document date (May 25, 2016) is 2892 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 1615, but no explicit reference was found in the text == Unused Reference: 'RFC3370' is defined on line 1621, but no explicit reference was found in the text == Unused Reference: 'RFC3548' is defined on line 1678, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-stir-passport-02 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Downref: Normative reference to an Experimental RFC: RFC 6919 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-03 -- 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) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar 4 Intended status: Standards Track C. Jennings 5 Expires: November 26, 2016 Cisco 6 E. Rescorla 7 RTFM, Inc. 8 C. Wendt 9 Comcast 10 May 25, 2016 12 Authenticated Identity Management in the Session Initiation Protocol 13 (SIP) 14 draft-ietf-stir-rfc4474bis-09.txt 16 Abstract 18 The baseline security mechanisms in the Session Initiation Protocol 19 (SIP) are inadequate for cryptographically assuring the identity of 20 the end users that originate SIP requests, especially in an 21 interdomain context. This document defines a mechanism for securely 22 identifying originators of SIP requests. It does so by defining a 23 SIP header field for conveying a signature used for validating the 24 identity, and for conveying a reference to the credentials of the 25 signer. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 26, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Overview of Operations . . . . . . . . . . . . . . . . . . . 6 65 5. Signature Generation and Validation . . . . . . . . . . . . . 7 66 5.1. Authentication Service Behavior . . . . . . . . . . . . . 7 67 5.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 10 68 5.2.1. Handling 'canon' parameters . . . . . . . . . . . . . 12 69 6. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 6.1. Credential Use by the Authentication Service . . . . . . 13 71 6.2. Credential Use by the Verification Service . . . . . . . 14 72 6.3. Handling 'info' parameter URIs . . . . . . . . . . . . . 15 73 6.4. Credential System Requirements . . . . . . . . . . . . . 15 74 7. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 16 75 7.1. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 16 76 7.1.1. Canonicalization Procedures . . . . . . . . . . . . . 17 77 7.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . 19 78 8. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20 79 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 23 80 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 82 11.1. Protected Request Fields . . . . . . . . . . . . . . . . 26 83 11.1.1. Protection of the To Header and Retargeting . . . . 28 84 11.2. Unprotected Request Fields . . . . . . . . . . . . . . . 28 85 11.3. Malicious Removal of Identity Headers . . . . . . . . . 29 86 11.4. Securing the Connection to the Authentication Service . 29 87 11.5. Authorization and Transitional Strategies . . . . . . . 30 88 11.6. Display-Names and Identity . . . . . . . . . . . . . . . 31 89 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 90 12.1. Identity-Info Parameters . . . . . . . . . . . . . . . . 32 91 12.2. Identity-Info Algorithm Parameter Values . . . . . . . . 32 92 12.3. Response Codes defined in RFC4474 . . . . . . . . . . . 32 93 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 94 14. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 34 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 97 15.2. Informative References . . . . . . . . . . . . . . . . . 35 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 100 1. Introduction 102 This document provides enhancements to the existing mechanisms for 103 authenticated identity management in the Session Initiation Protocol 104 (SIP, [RFC3261]). An identity, for the purposes of this document, is 105 defined as either a SIP URI, commonly a canonical address-of-record 106 (AoR) employed to reach a user (such as 107 'sip:alice@atlanta.example.com'), or a telephone number, which can be 108 represented as either a TEL URI [RFC3966] or as the user portion of a 109 SIP URI. 111 [RFC3261] specifies several places within a SIP request where users 112 can express an identity for themselves, most prominently the user- 113 populated From header field. However, the recipient of a SIP request 114 has no way to verify that the From header field has been populated 115 appropriately, in the absence of some sort of cryptographic 116 authentication mechanism. This leaves SIP vulnerable to a category 117 of abuses, including impersonation attacks that enable robocalling 118 and related problems as described in [RFC7340]. Ideally, a 119 cryptographic approach to identity can provide a much stronger and 120 less spoofable assurance of identity than the Caller ID services that 121 the telephone network provides today. 123 [RFC3261] encourages user agents (UAs) to implement a number of 124 potential authentication mechanisms, including Digest authentication, 125 Transport Layer Security (TLS), and S/MIME (implementations may 126 support other security schemes as well). However, few SIP user 127 agents today support the end-user certificates necessary to 128 authenticate themselves (via S/MIME, for example), and for its part 129 Digest authentication is limited by the fact that the originator and 130 destination must share a prearranged secret. Practically speaking, 131 originating user agents need to be able to securely communicate their 132 users' identity to destinations with which they have no previous 133 association. 135 As an initial attempt to address this gap, [RFC4474] specified a 136 means of signing portions of SIP requests in order to provide an 137 identity assurance. However, RFC 4474 was in several ways misaligned 138 with deployment realities (see [I-D.rosenberg-sip-rfc4474-concerns]). 139 Most significantly, RFC 4474 did not deal well with telephone numbers 140 as identifiers, despite their enduring use in SIP deployments. RFC 141 4474 also provided a signature over material that intermediaries in 142 existing deployments commonly altered. This specification therefore 143 revises RFC 4474 in light of recent reconsideration of the problem 144 space to align with the threat model in [RFC7375], and aligns the 145 signature format with PASSporT [I-D.ietf-stir-passport]. 147 2. Terminology 149 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 150 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 151 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 152 described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 154 3. Background 156 Per [RFC7340], problems such as robocalling, voicemail hacking, and 157 swatting are enabled by an attacker's ability to impersonate someone 158 else. The secure operation of most SIP applications and services 159 depends on authorizing the source of communications as it is 160 represented in a SIP request. Such authorization policies can be 161 automated or be a part of human operation of SIP devices. An example 162 of the former would be a voicemail service that compares the identity 163 of the caller to a whitelist before determining whether it should 164 allow the caller access to recorded messages. An example of the 165 latter would be an Internet telephone application that displays the 166 calling party number (and/or Caller-ID) of a caller, which a human 167 may review to make a policy decision before answering a call. In 168 both of these cases, attackers might attempt to circumvent these 169 authorization policies through impersonation. Since the primary 170 identifier of the sender of a SIP request, the From header field, can 171 be populated arbitrarily by the controller of a user agent, 172 impersonation is very simple today in many environments. The 173 mechanism described in this document provides a strong identity 174 system for detecting attempted impersonation in SIP requests. 176 This identity architecture for SIP depends on a logical 177 "authentication service" which validates outgoing requests. An 178 authentication service may be implemented either as part of a user 179 agent or as a proxy server; typically, it is a component of a network 180 intermediary like a proxy to which originating user agents send 181 unsigned requests. Once the sender of the message has been 182 authenticated, the authentication service then computes and adds 183 cryptographic information (including a digital signature over some 184 components of messages) to requests to communicate to other SIP 185 entities that the sending user has been authenticated and its claim 186 of a particular identity has been authorized. A "verification 187 service" on the receiving end then validates this signature and 188 enables policy decisions to be made based on the results of the 189 verification. 191 Identities are issued to users by authorities. When a new user 192 becomes associated with example.com, the administrator of the SIP 193 service for that domain can issue them an identity in that namespace, 194 such as alice@example.com. Alice may then send REGISTER requests to 195 example.com that make her user agents eligible to receive requests 196 for sip:alice@example.com. In some cases, Alice may be the owner of 197 the domain herself, and may issue herself identities as she chooses. 198 But ultimately, it is the controller of the SIP service at 199 example.com that must be responsible for authorizing the use of names 200 in the example.com domain. Therefore, for the purposes of baseline 201 SIP, the credentials needed to prove a user is authorized to use a 202 particular From header field must ultimately derive from the domain 203 owner: either a user agent gives requests to the domain name owner in 204 order for them to be signed by the domain owner's credentials, or the 205 user agent must possess credentials that prove in some fashion that 206 the domain owner has given the user agent the right to a name. 208 The situation is however more complicated for telephone numbers, 209 however. Authority over telephone numbers does not correspond 210 directly to Internet domains. While a user could register at a SIP 211 domain with a username that corresponds to a telephone number, any 212 connection between the administrator of that domain and the 213 assignment of telephone numbers is not currently reflected on the 214 Internet. Telephone numbers do not share the domain-scope property 215 described above, as they are dialed without any domain component. 216 This document thus assumes the existence of a separate means of 217 establishing authority over telephone numbers, for cases where the 218 telephone number is the identity of the user. As with SIP URIs, the 219 necessary credentials to prove authority for a name might reside 220 either in the endpoint or at some intermediary. 222 This document specifies a means of sharing a cryptographic assurance 223 of end-user SIP identity in an interdomain or intradomain context. 224 It relies on the authentication service constructing tokens based on 225 the PASSporT [I-D.ietf-stir-passport] format, a JSON [RFC7159] object 226 comprising values copied from certain header field values in the SIP 227 request. The authentication service then computes a signature over 228 those JSON object in a manner following PASSporT. That signature is 229 then placed in a SIP Identity header. In order to assist in the 230 validation of the Identity header, this specification also describes 231 some metadata fields associated with the header that can be used by 232 the recipient of a request to recover the credentials of the signer. 233 Note that the scope of this document is limited to providing this 234 identity assurance for SIP requests; solving this problem for SIP 235 responses is outside the scope of this work (see [RFC4916]). Future 236 work might specify ways that a SIP implementation could gateway 237 PASSporT objects to other protocols. 239 This specification allows either a user agent or a proxy server to 240 provide the authentication service function and/or the verification 241 service function. To maximize end-to-end security, it is obviously 242 preferable for end-users to acquire their own credentials; if they 243 do, their user agents can act as authentication services. However, 244 for some deployments, end-user credentials may be neither practical 245 nor affordable, given the potentially large number of SIP user agents 246 (phones, PCs, laptops, PDAs, gaming devices) that may be employed by 247 a single user. In such environments, synchronizing keying material 248 across multiple devices may be prohibitively complex and require 249 quite a good deal of additional endpoint behavior. Managing several 250 credentials for the various devices could also be burdensome. In 251 these cases, implementation the authentication service at an 252 intermediary may be more practical. This trade-off needs to be 253 understood by implementers of this specification. 255 4. Overview of Operations 257 This section provides an informative (non-normative) high-level 258 overview of the mechanisms described in this document. 260 Imagine a case where Alice, who has the home proxy of example.com and 261 the address-of-record sip:alice@example.com, wants to communicate 262 with Bob at sip:bob@example.org. They have no prior relationship, 263 and Bob implements best practices to prevent impersonation attacks. 265 Alice generates an INVITE and places her identity, in this case her 266 address-of-record, in the From header field of the request. She then 267 sends an INVITE over TLS to an authentication service proxy for the 268 example.com domain. 270 The proxy authenticates Alice (possibly by sending a Digest 271 authentication challenge), and validates that she is authorized to 272 assert the identity that she populated in the From header field. 273 This value could be Alice's AoR, but in other cases it could be some 274 different value that the authentication service has authority over, 275 such as a telephone number. The proxy authentication service then 276 constructs a PASSporT object which contains a JSON representations of 277 headers and claims which mirror certain parts of the SIP request, 278 including the identity in the From header field. As a part of 279 generating the PASSporT object, the authentication service signs a 280 hash of those headers and claims with the appropriate credential for 281 the identity (in this case, the certificate for example.com, which 282 covers the identity sip:alice@example.com), and the signature is 283 inserted by the proxy server into the Identity header field value of 284 the request. Optionally, the JSON headers and claims themselves may 285 also be included in the object, encoded in the "canon" parameter of 286 the Identity header. 288 The proxy, as the holder of the private key for the example.com 289 domain, is asserting that the originator of this request has been 290 authenticated and that she is authorized to claim the identity that 291 appears in the From header field. The proxy inserts an "info" 292 parameter into the Identity header that tells Bob how to acquire 293 keying material necessary to validate its credentials (a public key), 294 in case he doesn't already have it. 296 When Bob's domain receives the request, it verifies the signature 297 provided in the Identity header, and thus can validate that the 298 authority over the identity in the From header field authenticated 299 the user, and permitted the user to assert that From header field 300 value. This same validation operation may be performed by Bob's user 301 agent server (UAS). As the request has been validated, it is 302 rendered to Bob. If the validation was unsuccessful, some other 303 treatment would be applied by the receiving domain. 305 5. Signature Generation and Validation 307 5.1. Authentication Service Behavior 309 This document specifies a role for SIP entities called an 310 authentication service. The authentication service role can be 311 instantiated, for example, by an intermediary such as a proxy server 312 or by a user agent. Any entity that instantiates the authentication 313 service role MUST possess the private key of one or more credentials 314 that can be used to sign for a domain or a telephone number (see 315 Section 6.1). Intermediaries that instantiate this role MUST be 316 capable of authenticating one or more SIP users who can register for 317 that identity. Commonly, this role will be instantiated by a proxy 318 server, since these entities are more likely to have a static 319 hostname, hold corresponding credentials, and have access to SIP 320 registrar capabilities that allow them to authenticate users. It is 321 also possible that the authentication service role might be 322 instantiated by an entity that acts as a redirect server, but that is 323 left as a topic for future work. 325 An authentication service adds the Identity header to SIP requests. 326 The procedures below define the steps that must be taken when each an 327 header is added. More than one may appear in a single request, and 328 an authentication service may add an Identity header to a request 329 that already contains one or more Identity headers. If the Identity 330 header added follows extended signing procedures beyond the baseline 331 given in Section 8, then it differentiates the header with a "ppt" 332 parameter per the fourth step below. 334 Entities instantiating the authentication service role perform the 335 following steps, in order, to generate an Identity header for a SIP 336 request: 338 Step 1: 340 First, the authentication service must determine whether it is 341 authoritative for the identity of the sender of the request. In 342 ordinary operations, the authentication service decides this by 343 inspecting the URI value from the addr-spec component of From header 344 field; this URI will be referred to here as the 'identity field'. If 345 the identity field contains a SIP or SIP Secure (SIPS) URI, and the 346 user portion is not a telephone number, the authentication service 347 MUST extract the hostname portion of the identity field and compare 348 it to the domain(s) for which it is responsible (following the 349 procedures in RFC 3261 [RFC3261], Section 16.4). If the identity 350 field uses the TEL URI scheme [RFC3966], or the identity field is a 351 SIP or SIPS URI with a telephone number in the user portion, the 352 authentication service determines whether or not it is responsible 353 for this telephone number; see Section 7.1 for more information. An 354 authentication service proceeding with a signature over a telephone 355 number MUST then follow the canonicalization procedures described in 356 Section 7.1.1. If the authentication service is not authoritative 357 for the identity in question, it SHOULD process and forward the 358 request normally unless the local policy is to block such requests. 359 The authentication service MUST NOT add an Identity header if the 360 authentication service does not have the authority to make the claim 361 it asserts. 363 Step 2: 365 The authentication service MUST then determine whether or not the 366 sender of the request is authorized to claim the identity given in 367 the identity field. In order to do so, the authentication service 368 MUST authenticate the sender of the message. Some possible ways in 369 which this authentication might be performed include: 371 If the authentication service is instantiated by a SIP 372 intermediary (proxy server), it may authenticate the request with 373 the authentication scheme used for registration in its domain 374 (e.g., Digest authentication). 376 If the authentication service is instantiated by a SIP user agent, 377 a user agent may authenticate its own user through any system- 378 specific means, perhaps simply by virtue of having physical access 379 to the user agent. 381 Authorization of the use of a particular username or telephone number 382 in the user part of the From header field is a matter of local policy 383 for the authentication service; see Section 6.1 for more information. 385 Note that this check is performed only on the addr-spec in the 386 identity field (e.g., the URI of the sender, like 387 'sip:alice@atlanta.example.com'); it does not convert the display- 388 name portion of the From header field (e.g., 'Alice Atlanta'). For 389 more information, see Section 11.6. 391 Step 3: 393 An authentication service MUST add a Date header field to SIP 394 requests that do not have one. The authentication service MUST 395 ensure that any preexisting Date header in the request is accurate. 396 Local policy can dictate precisely how accurate the Date must be; a 397 RECOMMENDED maximum discrepancy of sixty seconds will ensure that the 398 request is unlikely to upset any verifiers. If the Date header 399 contains a time different by more than one minute from the current 400 time noted by the authentication service, the authentication service 401 SHOULD reject the request. This behavior is not mandatory because a 402 user agent client (UAC) could only exploit the Date header in order 403 to cause a request to fail verification; the Identity header is not 404 intended to provide a source of non-repudiation or a perfect record 405 of when messages are processed. Finally, the authentication service 406 MUST verify that both the Date header and the current time fall 407 within the validity period of its credential. 409 See Section 11 for information on how the Date header field assists 410 verifiers. 412 Step 4: 414 Subsequently, the authentication service MUST form a PASSporT object 415 and add a corresponding an Identity header to the request containing 416 this signature. For baseline PASSporT objects headers (without an 417 Identity header "ppt" parameter), this follows the procedures in 418 Section 8; if the authentication service is using an alternative 419 "ppt" format, it MUST add an appropriate "ppt" parameter and follow 420 the procedures associated with that extension (see Section 9). After 421 the Identity header has been added to the request, the authentication 422 service MUST also add a "info" parameter to the Identity header. The 423 "info" parameter contains a URI from which the authentication 424 service's credential can be acquired; see Section 6.3 for more on 425 credential acquisition. 427 Step 5: 429 In the circumstances described below, an authentication service will 430 add a "canon" parameter to the Identity header. The syntax of 431 "canon" is given in Section 8; essentially, it contains a base64 432 encoding of the JSON header and claims in the PASSporT object. The 433 presence of "canon" is OPTIONAL baseline PASSporT objects in SIP as a 434 because the information carried in the baseline PASSporT object's 435 headers and claims is usually redundant with information already 436 carried elsewhere in the SIP request. Omitting "canon" can 437 significantly reduce SIP message size, especially when the PASSporT 438 object contains media keys. 440 When however an authentication service creates a PASSporT that uses 441 extension claims beyond the baseline PASSporT object, including 442 "canon" is REQUIRED in order for the verification service to be 443 capable of validating the signature. See Section 9. 445 Also, in some cases, a request signed by an authentication service 446 will be rejected by the verification service on the receiving side, 447 and the authentication service will receive a SIP 4xx status code in 448 the backwards direction, such as a 438 indicating a verification 449 failure. If the authentication service did not originally send the 450 Identity header with the "canon" parameter, it SHOULD retry a request 451 once after receiving a 438 response, this time including the "canon". 452 The information in "canon" is useful on the verification side for 453 debugging errors, and there are some known causes of verification 454 failures (such as the Date header changing in transit, see 455 Section 11.1 for more information) that can be resolved by the 456 inclusion of "canon". 458 Finally, the authentication service MUST forward the message 459 normally. 461 5.2. Verifier Behavior 463 This document specifies a logical role for SIP entities called a 464 verification service, or verifier. When a verifier receives a SIP 465 message containing one or more Identity headers, it inspects the 466 signature(s) to verify the identity of the sender of the message. 467 The results of a verification are provided as input to an 468 authorization process that is outside the scope of this document. 470 A SIP request may contain zero, one, or more Identity headers. A 471 verification service performs the procedures above on each Identity 472 header that appears in a request. If the verifier does not support 473 an Identity header present in a request due to the presence of an 474 unsupported "ppt" parameter, or if no Identity header is present, and 475 the presence of an Identity header is required by local policy (for 476 example, based on a per-sending-domain policy, or a per-sending-user 477 policy), then a 428 'Use Identity Header' response MUST be sent in 478 the backwards direction. For more on this and other failure 479 responses, see Section 12.3. 481 In order to verify an Identity header in a message, an entity acting 482 as a verifier MUST perform the following steps, in the order here 483 specified. Note that when an Identity header contains the optional 484 "canon" parameter, the verifier MUST follow the additional procedures 485 in Section 5.2.1. 487 Step 1: 489 The verifier MUST inspect any optional "ppt" parameter appearing the 490 Identity request. If no "ppt" parameter is present, then the 491 verifier proceeds normally below. If a "ppt" parameter value is 492 present, and the verifier does not support it, it MUST ignore the 493 Identity header. If a supported "ppt" parameter value is present, 494 the verifier follows the procedures below, including the variations 495 described in Step 5. 497 Step 2: 499 In order to determine whether the signature for the identity field 500 should be over the entire identity field URI or just a canonicalized 501 telephone number, the verification service MUST follow the 502 canonicalization process described in Section 7.1.1. That section 503 also describes the procedures the verification service MUST follow to 504 determine if the signer is authoritative for a telephone number. For 505 domains, the verifier MUST follow the process described in 506 Section 7.2 to determine if the signer is authoritative for the 507 identity field. 509 Step 3: 511 The verifier must first ensure that it possesses the proper keying 512 material to validate the signature in the Identity header field, 513 which usually involves dereferencing a URI in the "info" parameter of 514 the Identity header. See Section 6.2 for more information on these 515 procedures. If the verifier does not support the credential 516 described in the "info" parameter, then it should consider the 517 credential for this header unsupported. If a SIP request contains no 518 Identity headers with a supported credential, then the verifier MUST 519 return a 437 "Unsupported Credential" response. 521 Step 4: 523 The verifier MUST furthermore ensure that the value of the Date 524 header of the request meets local policy for freshness (usually, 525 within sixty seconds) and that it falls within the validity period of 526 the credential used to sign the Identity header. For more on the 527 attacks this prevents, see Section 11.1. If the "canon" parameter is 528 present, the verifier should follow the Date-related behavior in 529 Section 5.2.1. 531 Step 5: 533 The verifier MUST validate the signature in the Identity header field 534 over the PASSporT object. For baseline PASSporT objects (with no 535 Identity header "ppt" parameter) the verifier MUST follow the 536 procedures for generating the signature over a PASSporT object 537 described in Section 8. If a "ppt" parameter is present (and per 538 Step 1, is understood), the verifier follows the procedures for that 539 "ppt" (see Section 9). If a verifier determines that the that the 540 signature in the Identity does not correspond to the reconstructed 541 signed-identity-digest, then the Identity header should be considered 542 invalid. 544 The presence of multiple Identity headers within a message raises the 545 prospect that a verification services could receive a message 546 containing some valid and some invalid Identity headers. If the 547 verifier determines all Identity headers within a message are 548 invalid, then a 438 'Invalid Identity Header' response MUST be 549 returned. 551 The verification of an Identity header does not entail any particular 552 treatment of the request. The handling of the message after the 553 verification process depends on how the implementation service is 554 implemented and on local policy. This specification does not propose 555 any authorization policy for user agents or proxy servers to follow 556 based on the presence of a valid Identity header, the presence of an 557 invalid Identity header, or the absence of an Identity header, but it 558 is anticipated that local policies could involve making different 559 forwarding decisions in intermediary implementations, or changing how 560 the user is alerted, or how identity is rendered, in user agent 561 implementations. 563 5.2.1. Handling 'canon' parameters 565 If the optional "canon" parameter of the Identity header is present, 566 it contains a base64 encoding of the header and claim component of 567 the PASSporT object constructed by the authentication service, and 568 this it conveys any canonical telephone number formats created by the 569 authentication service (see Section 7.1.1), as well as an "iat" claim 570 corresponding to the Date header that the authentication service 571 used. The "canon" is provided purely as an optimization and 572 debugging mechanism for the verification service. 574 When "canon" is present, the verification service MAY compute its own 575 canonicalization of the numbers and compare them to the values in the 576 "canon" parameter before performing any cryptographic functions in 577 order to ascertain whether or not the two ends agree on the canonical 578 number form. Also, when "canon" is present, during Step 4 the 579 verification service SHOULD compare the "iat" value in the "canon" to 580 its Date header field value. If the two are different, and the "iat" 581 value is later but within verification service policy for freshness, 582 the verification service SHOULD perform the computation required by 583 Step 5 using the "iat" value instead of the Date value. As some 584 deployments in the field have been observed to change the Date header 585 in transit, this procedure will prevent some unnecessary verification 586 failures. 588 6. Credentials 590 6.1. Credential Use by the Authentication Service 592 In order to act as an authentication service, a SIP entity must have 593 access to the private keying material of one or more credentials that 594 cover domain names or telephone numbers. These credentials may 595 represent authority over an entire domain (such as example.com) or 596 potentially a set of domains enumerated by the credential. 597 Similarly, a credential may represent authority over a single 598 telephone number or a range of telephone numbers. The way that the 599 scope of a credential is expressed is specific to the credential 600 mechanism. 602 Authorization of the use of a particular username or telephone number 603 in the identity field is a matter of local policy for the 604 authentication service, one that depends greatly on the manner in 605 which authentication is performed. For non-telephone number user 606 parts, one policy might be as follows: the username given in the 607 'username' parameter of the Proxy-Authorization header MUST 608 correspond exactly to the username in the From header field of the 609 SIP message. However, there are many cases in which this is too 610 limiting or inappropriate; a realm might use 'username' parameters in 611 Proxy-Authorization that do not correspond to the user-portion of SIP 612 From headers, or a user might manage multiple accounts in the same 613 administrative domain. In this latter case, a domain might maintain 614 a mapping between the values in the 'username' parameter of Proxy- 615 Authorization and a set of one or more SIP URIs that might 616 legitimately be asserted for that 'username'. For example, the 617 username can correspond to the 'private identity' as defined in Third 618 Generation Partnership Project (3GPP), in which case the From header 619 field can contain any one of the public identities associated with 620 this private identity. In this instance, another policy might be as 621 follows: the URI in the From header field MUST correspond exactly to 622 one of the mapped URIs associated with the 'username' given in the 623 Proxy-Authorization header. This is a suitable approach for 624 telephone numbers in particular. 626 This specification could also be used with credentials that cover a 627 single name or URI, such as alice@example.com or 628 sip:alice@example.com. This would require a modification to 629 authentication service behavior to operate on a whole URI rather than 630 a domain name. Because this is not believed to be a pressing use 631 case, this is deferred to future work, but implementers should note 632 this as a possible future direction. 634 Exceptions to such authentication service policies arise for cases 635 like anonymity; if the AoR asserted in the From header field uses a 636 form like 'sip:anonymous@example.com' (see [RFC3323]), then the 637 'example.com' proxy might authenticate only that the user is a valid 638 user in the domain and insert the signature over the From header 639 field as usual. 641 6.2. Credential Use by the Verification Service 643 In order to act as a verification service, a SIP entity must have a 644 way to acquire and retain credentials for authorities over particular 645 domain names and/or telephone numbers or number ranges. 646 Dereferencing the URI found in the "info" parameter of the Identity 647 header (as described in the next section) MUST be supported by all 648 verification service implementations to create a baseline means of 649 credential acquisition. Provided that the credential used to sign a 650 message is not previously known to the verifier, SIP entities SHOULD 651 discover this credential by dereferencing the "info" parameter, 652 unless they have some more other implementation-specific way of 653 acquiring the needed keying material, such as an offline store of 654 periodically-updated credentials. If the URI in the "info" parameter 655 cannot be dereferenced, then a 436 'Bad Identity-Info' response MUST 656 be returned. 658 This specification does not propose any particular policy for a 659 verification service to determine whether or not the holder of a 660 credential is the appropriate party to sign for a given SIP identity. 661 Guidance on this is deferred to the credential mechanism 662 specifications, which must meet the requirements in Section 6.4. 664 Verification service implementations supporting this specification 665 may wish to have some means of retaining credentials (in accordance 666 with normal practices for credential lifetimes and revocation) in 667 order to prevent themselves from needlessly downloading the same 668 credential every time a request from the same identity is received. 669 Credentials cached in this manner may be indexed in accordance with 670 local policy: for example, by their scope, or the URI given in the 671 "info" parameter value. Further consideration of how to cache 672 credentials is deferred to the credential mechanism specifications. 674 6.3. Handling 'info' parameter URIs 676 An "info" parameter MUST contain a URI which dereferences to a 677 resource that contains the public key components of the credential 678 used by the authentication service to sign a request. It is 679 essential that a URI in the "info parameter" be dereferencable by any 680 entity that could plausibly receive the request. For common cases, 681 this means that the URI must be dereferencable by any entity on the 682 public Internet. In constrained deployment environments, a service 683 private to the environment might be used instead. 685 Beyond providing a means of accessing credentials for an identity, 686 the "info" parameter further serves as a means of differentiating 687 which particular credential was used to sign a request, when there 688 are potentially multiple authorities eligible to sign. For example, 689 imagine a case where a domain implements the authentication service 690 role for a range of telephone and a user agent belonging to Alice has 691 acquired a credential for a single telephone number within that 692 range. Either would be eligible to sign a SIP request for the number 693 in question. Verification services however need a means to 694 differentiate which one performed the signature. The "info" 695 parameter performs that function. 697 6.4. Credential System Requirements 699 This document makes no recommendation for the use of any specific 700 credential system. Today, there are two primary credential systems 701 in place for proving ownership of domain names: certificates (e.g., 702 X.509 v3, see [RFC5280]) and the domain name system itself (e.g., 703 DANE, see [RFC6698]). It is envisioned that either could be used in 704 the SIP identity context: an "info" parameter could for example give 705 an HTTP URL of the Content-Type 'application/pkix-cert' pointing to a 706 certificate (following the conventions of [RFC2585]). The "info" 707 parameter may use the DNS URL scheme (see [RFC4501]) to designate 708 keys in the DNS. 710 While no comparable public credentials exist for telephone numbers, 711 either approach could be applied to telephone numbers. A credential 712 system based on certificates is given in 713 [I-D.ietf-stir-certificates], but this specification can work with 714 other credential systems; for example, using the DNS was proposed in 715 [I-D.kaplan-stir-cider]. 717 In order for a credential system to work with this mechanism, its 718 specification must detail: 720 which URIs schemes the credential will use in the "info" 721 parameter, and any special procedures required to dereference the 722 URIs 724 how the verifier can learn the scope of the credential 726 any special procedures required to extract keying material from 727 the resources designated by the URI 729 any algorithms required to validate the credentials (e.g. for 730 certificates, any algorithms used by certificate authorities to 731 sign certificates themselves) 733 It is furthermore required that all credential specifications 734 describe how the associated credentials will support the mandatory 735 signing algorithm(s) required by PASSporT [I-D.ietf-stir-passport]. 737 SIP entities cannot reliably predict where SIP requests will 738 terminate. When choosing a credential scheme for deployments of this 739 specification, it is therefore essential that the trust anchor(s) for 740 credentials be widely trusted, or that deployments restrict the use 741 of this mechanism to environments where the reliance on particular 742 trust anchors is assured by business arrangements or similar 743 constraints. 745 Note that credential systems must address key lifecycle management 746 concerns: were a domain to change the credential available at the 747 Identity-Info URI before a verifier evaluates a request signed by an 748 authentication service, this would cause obvious verifier failures. 749 When a rollover occurs, authentication services SHOULD thus provide 750 new Identity-Info URIs for each new credential, and SHOULD continue 751 to make older key acquisition URIs available for a duration longer 752 than the plausible lifetime of a SIP transaction (a minute would most 753 likely suffice). 755 7. Identity Types 757 7.1. Telephone Numbers 759 Since many SIP applications provide a Voice over IP (VoIP) service, 760 telephone numbers are commonly used as identities in SIP deployments. 761 In order for telephone numbers to be used with the mechanism 762 described in this document, authentication services must enroll with 763 an authority that issues credentials for telephone numbers or 764 telephone number ranges, and verification services must trust the 765 authority employed by the authentication service that signs a 766 request. Enrollment procedures and credential management are outside 767 the scope of this document. 769 In the longer term, it is possible that some directory or other 770 discovery mechanism may provide a way to determine which 771 administrative domain is responsible for a telephone number, and this 772 may aid in the signing and verification of SIP identities that 773 contain telephone numbers. This is a subject for future work. 775 In order to work with any such authorities, authentication and 776 verification services must be able to identify when a request should 777 be signed by an authority for a telephone number, and when it should 778 be signed by an authority for a domain. Telephone numbers most 779 commonly appear in SIP header field values in the username portion of 780 a SIP URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). 781 The user part of that URI conforms to the syntax of the TEL URI 782 scheme (RFC 3966 [RFC3966]). It is also possible for a TEL URI to 783 appear in the SIP To or From header field outside the context of a 784 SIP or SIPS URI (e.g., 'tel:+17005551008'). In both of these cases, 785 it's clear that the signer must have authority over the telephone 786 number, not the domain name of the SIP URI. It is also possible, 787 however, for requests to contain a URI like 788 'sip:7005551000@chicago.example.com'. It may be non-trivial for a 789 service to ascertain in this case whether the URI contains a 790 telephone number or not. 792 7.1.1. Canonicalization Procedures 794 In order to determine whether or not the user portion of a SIP URI is 795 a telephone number, authentication services and verification services 796 must perform the following canonicalization procedure on any SIP URI 797 they inspect which contains a wholly numeric user part. Note that 798 the same procedures are followed for creating the canonical form of 799 URIs found in both the From and To header field values; this section 800 also describes procedures for extracting the URI containing the 801 telephone number from the P-Asserted-Identity header field value for 802 environments where that is applicable. 804 In some networks, the P-Asserted-Identity header field value is used 805 in lieu of the From header field to convey the telephone number of 806 the sender of a request; while it is not envisioned that most of 807 those networks would or should make use of the Identity mechanism 808 described in this specification, where they do, local policy might 809 therefore dictate that the canonical string derive from the P- 810 Asserted-Identity header field rather than the From. In any case 811 where local policy canonicalizes the number into a form different 812 from how it appears in the From header field, the use of the "canon" 813 parameter by authentication services is RECOMMENDED, but because 814 "canon" itself could then divulge information about users or 815 networks, implementers should be mindful of the guidelines in 816 Section 10. 818 First, implementations must assess if the user-portion of the URI 819 constitutes a telephone number. In some environments, numbers 820 will be explicitly labeled by the use of TEL URIs or the 821 'user=phone' parameter, or implicitly by the presence of the '+' 822 indicator at the start of the user-portion. Absent these 823 indications, if there are numbers present in the user-portion, 824 implementations may also detect that the user-portion of the URI 825 contains a telephone number by determining whether or not those 826 numbers would be dialable or routable in the local environment -- 827 bearing in mind that the telephone number may be a valid E.164 828 number, a nationally-specific number, or even a private branch 829 exchange number. 831 Once an implementation has identified a telephone number, it must 832 construct a number string. Implementations MUST drop any leading 833 +'s, any internal dashes, parentheses or other non-numeric 834 characters, excepting only the leading "#" or "*" keys used in 835 some special service numbers (typically, these will appear only in 836 the To header field value). This MUST result in an ASCII string 837 limited to "#", "*" and digits without whitespace or visual 838 separators. 840 Next, an implementation must assess if the number string is a 841 valid, globally-routable number with a leading country code. If 842 not, implementations SHOULD convert the number into E.164 format, 843 adding a country code if necessary; this may involve transforming 844 the number from a dial string (see [RFC3966]), removing any 845 national or international dialing prefixes or performing similar 846 procedures. It is only in the case that an implementation cannot 847 determine how to convert the number to a globally-routable format 848 that this step may be skipped. This will be the case, for 849 example, for nationally-specific service numbers (e.g. 911, 112); 850 however, the routing procedures associated with those numbers will 851 likely make sure that the verification service understands the 852 context of their use. 854 Other transformations during canonicalization MAY be made in 855 accordance with specific policies used within a local domain. For 856 example, one domain may only use local number formatting and need 857 to convert all To/From user portions to E.164 by prepending 858 country-code and region code digits; another domain might prefix 859 usernames with trunk-routing codes and need to remove the prefix. 861 This specification cannot anticipate all of the potential 862 transformations that might be useful. 864 The resulting canonical number string will be used as input to the 865 hash calculation during signing and verifying processes. 867 The ABNF of this number string is: 869 tn-spec = [ "#" / "*" ] 1*DIGIT 871 If the result of this procedure forms a complete telephone number, 872 that number is used for the purpose of creating and signing the 873 signed-identity-string by both the authentication service and 874 verification service. Practically, entities that perform the 875 authentication service role will sometimes alter the telephone 876 numbers that appear in the To and From header field values, 877 converting them to this format (though note this is not a function 878 that [RFC3261] permits proxy servers to perform). The result of the 879 canonicalization process of the From header field value may also be 880 recorded through the use of the "canon" parameter of the Identity(see 881 Section 8). If the result of the canonicalization of the From header 882 field value does not form a complete telephone number, the 883 authentication service and verification service should treat the 884 entire URI as a SIP URI, and apply a domain signature per the 885 procedures in Section 7.2. 887 7.2. Domain Names 889 When a verifier processes a request containing an Identity-Info 890 header with a domain signature, it must compare the domain portion of 891 the URI in the From header field of the request with the domain name 892 that is the subject of the credential acquired from the "info" 893 parameter. While it might seem that this should be a straightforward 894 process, it is complicated by two deployment realities. In the first 895 place, credentials have varying ways of describing their subjects, 896 and may indeed have multiple subjects, especially in 'virtual 897 hosting' cases where multiple domains are managed by a single 898 application. Secondly, some SIP services may delegate SIP functions 899 to a subordinate domain and utilize the procedures in RFC 3263 900 [RFC3263] that allow requests for, say, 'example.com' to be routed to 901 'sip.example.com'. As a result, a user with the AoR 902 'sip:jon@example.com' may process requests through a host like 903 'sip.example.com', and it may be that latter host that acts as an 904 authentication service. 906 To meet the second of these problems, a domain that deploys an 907 authentication service on a subordinate host MUST be willing to 908 supply that host with the private keying material associated with a 909 credential whose subject is a domain name that corresponds to the 910 domain portion of the AoRs that the domain distributes to users. 911 Note that this corresponds to the comparable case of routing inbound 912 SIP requests to a domain. When the NAPTR and SRV procedures of RFC 913 3263 are used to direct requests to a domain name other than the 914 domain in the original Request-URI (e.g., for 'sip:jon@example.com', 915 the corresponding SRV records point to the service 916 'sip1.example.org'), the client expects that the certificate passed 917 back in any TLS exchange with that host will correspond exactly with 918 the domain of the original Request-URI, not the domain name of the 919 host. Consequently, in order to make inbound routing to such SIP 920 services work, a domain administrator must similarly be willing to 921 share the domain's private key with the service. This design 922 decision was made to compensate for the insecurity of the DNS, and it 923 makes certain potential approaches to DNS-based 'virtual hosting' 924 unsecurable for SIP in environments where domain administrators are 925 unwilling to share keys with hosting services. 927 A verifier MUST evaluate the correspondence between the user's 928 identity and the signing credential by following the procedures 929 defined in RFC 2818 [RFC2818], Section 3.1. While RFC 2818 [RFC2818] 930 deals with the use of HTTP in TLS and is specific to certificates, 931 the procedures described are applicable to verifying identity if one 932 substitutes the "hostname of the server" in HTTP for the domain 933 portion of the user's identity in the From header field of a SIP 934 request with an Identity header. 936 8. Header Syntax 938 The Identity and Identity-Info headers that were previously defined 939 in RFC4474 are deprecated. This revised specification collapses the 940 grammar of Identity-Info into the Identity header via the "info" 941 parameter. Note that unlike the prior specification in RFC4474, the 942 Identity header is now allowed to appear more than one time in a SIP 943 request. The revised grammar for the Identity header is (following 944 the ABNF [RFC4234] in RFC 3261 [RFC3261]): 946 Identity = "Identity" HCOLON signed-identity-digest SEMI ident-info *( SEMI ident-info-params ) 947 signed-identity-digest = LDQUOT *base64-char RDQUOT 948 ident-info = "info" EQUAL ident-info-uri 949 ident-info-uri = LAQUOT absoluteURI RAQUOT 950 ident-info-params = ident-info-alg / ident-type / canonical-str / ident-info-extension 951 ident-info-alg = "alg" EQUAL token 952 ident-type = "ppt" EQUAL token 953 canonical-str = "canon" EQUAL *base64-char 954 ident-info-extension = generic-param 956 base64-char = ALPHA / DIGIT / "/" / "+" 958 In addition to "info" parameter, and the "alg" parameter previously 959 defined in RFC4474, this specification includes the optional "canon" 960 and "ppt" parameters. Note that in RFC4474, the signed-identity- 961 digest (see ABNF above) was given as quoted 32LHEX, whereas here it 962 is given as a quoted sequence of base64-char. 964 The 'absoluteURI' portion of ident-info-uri MUST contain a URI; see 965 Section 6.3 for more on choosing how to advertise credentials through 966 this parameter. 968 The signed-identity-digest is the signed hash component of a PASSporT 969 object [I-D.ietf-stir-passport], a signature which PASSporT generates 970 over a pair of JSON objects. The first PASSporT object contains 971 header information, and the second contains claims, following the 972 conventions of JWT [RFC7519]; some header and claim values will 973 mirror elements of the SIP request. Once these two JSON objects have 974 been generated, they will be encoded, then hashed with a SHA-256 975 hash. Those two hashes are then concatenated (header then claims) 976 into a string separated by a single "." per baseline PASSporT. 977 Finally, that string is signed to generate the signed-identity-digest 978 value of the Identity header. 980 For SIP implementations to populate the PASSporT header object from a 981 SIP request, the following elements message MUST be placed as the 982 values corresponding to the designated JSON keys: 984 First, per baseline [I-D.ietf-stir-passport], the JSON key "typ" 985 key MUST have the value "passport". 987 Second, the JSON key "alg" MUST mirror the value of the optional 988 "alg" parameter in the SIP Identity header. Note if the "alg" 989 parameter is absent, the default value is "ES256". 991 Third, the JSON key "x5u" MUST have a value equivalent to the 992 quoted URI in the "info" parameter. 994 Fourth, the optional JSON key "ppt", if present, MUST have a value 995 equivalent to the quoted value of the "ppt" parameter of the 996 Identity header. If the "ppt" parameter is absent from the 997 header, the "ppt" key MUST NOT not appear in the JSON heaer 998 object. 1000 For example: 1002 { "typ":"passport", 1003 "alg":"ES256", 1004 "x5u":"https://www.example.com/cert.pkx" } 1006 To populate the PASSporT claims JSON object from a SIP request, the 1007 following elements MUST be placed as values corresponding to the 1008 designated JSON keys: 1010 First, if the originating identity is a telephone number, the JSON 1011 key "otn" MUST be used, set to the value of the quoted originating 1012 identity, a canonicalized telephone number (see Section 7.1.1). 1013 Otherwise, the JSON key "ouri" MUST be used, set to the value of 1014 the AoR of the UA sending the message as taken from addr-spec of 1015 the From header field. 1017 Second, if the destination identity is a telephone number, the 1018 JSON key "dtn" MUST be used, set to the value of the quoted 1019 destination identity, a canonicalized telephone number (see 1020 Section 7.1.1). Otherwise, the JSON key "duri" MUST be used, set 1021 to the value of the addr-spec component of the To header field, 1022 which is the AoR to which the request is being sent. 1024 Third, the JSON key "iat" MUST appear, set to the value of a 1025 quoted encoding of the value of the SIP Date header field as a 1026 JSON NumericDate (as UNIX time, per [RFC7519] Section 2). 1028 Fourth, if the request contains an SDP message body, and if that 1029 SDP contains one or more "a=fingerprint" attributes, then the JSON 1030 key "mky" MUST appear with the algorithm(s) and value(s) of the 1031 fingerprint attributes (if they differ), following the format 1032 given in [I-D.ietf-stir-passport] Section 3.2.2.2. 1034 For example: 1036 { "otn":"12155551212", 1037 "dtn":"12155551213", 1038 "iat":"1443208345" } 1040 For more information on the security properties of these SIP message 1041 elements, and why their inclusion mitigates replay attacks, see 1042 Section 11 and [RFC3893]. Note that future extensions to the 1043 PASSporT object could introduce new claims, and that further SIP 1044 procedures could be required to extract further information from the 1045 SIP request to populate the values of those claims; see Section 9. 1047 After these two JSON objects, the header and the claims, have been 1048 constructed, they must each be hashed per [I-D.ietf-stir-passport] 1049 Section 3.3. The signed value of those concatenated hashes then 1050 becomes the signed-identity-string of the Identity header. The 1051 hashing and signing algorithm is specified by the 'alg' parameter of 1052 the Identity header and the mirrored "alg" parameter of PASSporT. 1053 This specification inherits from the PASSporT specification one value 1054 for the 'alg' parameter: 'ES256', as defined in [RFC7519], which 1055 connotes an ECDSA P-256 digital signature. All implementations of 1056 this specification MUST support the required signing algorithms of 1057 PASSporT. 1059 The complete form of the Identity header will therefore look like the 1060 following example: 1062 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 1063 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 1064 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 1065 info=;alg=ES256 1067 In a departure from JWT practice, the SIP usage of PASSporT MAY NOT 1068 include the base64 encoded version of the JSON objects in the 1069 Identity header: only the signature component of the PASSporT is 1070 REQUIRED. Optionally, as a debugging measure or optimization, the 1071 base64 encoded concatenation of the JSON header and claims may be 1072 included as the value of a "canon" parameter of the Identity header. 1073 Note that this may be lengthy string. 1075 9. Extensibility 1077 For the extensibility of baseline PASSporT with now claims, see 1078 [I-D.ietf-stir-passport] Section 4. 1080 As future requirements may warrant increasing the scope of the 1081 Identity mechanism, this specification defines an optional "ppt" 1082 parameter of the Identity header, which mirrors the "ppt" header key 1083 in PASSporT. The "ppt" parameter value MUST consist of a token 1084 containing an extension specification, which denotes an extended set 1085 of one or more signed claims per the type extensibility mechanism 1086 specified in [I-D.ietf-stir-passport]. 1088 An authentication service cannot assume that verifiers will 1089 understand any given extension. Verifiers that do support an 1090 extension may then trigger appropriate application-level behavior in 1091 the presence of an extension; authors of extensions should provide 1092 appropriate extension-specific guidance to application developers on 1093 this point. 1095 If any claim in an extension contains a JSON value that does not 1096 correspond to any field of the SIP request, but then the optional 1097 "canon" parameter MUST be used for the Identity header containing 1098 that extension. 1100 10. Privacy Considerations 1102 The purpose of this mechanism is to provide a strong identification 1103 of the originator of a SIP request, specifically a cryptographic 1104 assurance that an authority asserts the originator can claim the URI 1105 given in the From header field. This URI may contain a variety of 1106 personally identifying information, including the name of a human 1107 being, their place of work or service provider, and possibly further 1108 details. The intrinsic privacy risks associated with that URI are, 1109 however, no different from those of baseline SIP. Per the guidance 1110 in [RFC6973], implementers should make users aware of the privacy 1111 trade-off of providing secure identity. 1113 The identity mechanism presented in this document is compatible with 1114 the standard SIP practices for privacy described in [RFC3323]. A SIP 1115 proxy server can act both as a privacy service and as an 1116 authentication service. Since a user agent can provide any From 1117 header field value that the authentication service is willing to 1118 authorize, there is no reason why private SIP URIs that contain 1119 legitimate domains (e.g., sip:anonymous@example.com) cannot be signed 1120 by an authentication service. The construction of the Identity 1121 header is the same for private URIs as it is for any other sort of 1122 URIs. Similar practices could be used to support opportunistic 1123 signing of SIP requests for UA-integrated authentications services 1124 with self-signed certificates, though that is outside the scope of 1125 this specification and is left as a matter for future investigation. 1127 Note, however, that even when using anonymous SIP URIs, an 1128 authentication service must possess a certificate corresponding to 1129 the host portion of the addr-spec of the From header field of the 1130 request; accordingly, using domains like 'anonymous.invalid' will not 1131 be possible for privacy services that also act as authentication 1132 services. The assurance offered by the usage of anonymous URIs with 1133 a valid domain portion is "this is a known user in my domain that I 1134 have authenticated, but I am keeping its identity private". 1136 It is worth noting two features of this more anonymous form of 1137 identity. One can eliminate any identifying information in a domain 1138 through the use of the domain 'anonymous.invalid," but we must then 1139 acknowledge that it is difficult for a domain to be both anonymous 1140 and authenticated. The use of the "anonymous.invalid" domain entails 1141 that no corresponding authority for the domain can exist, and as a 1142 consequence, authentication service functions for that domain are 1143 meaningless. The second feature is more germane to the threats this 1144 document mitigates [RFC7375]. None of the relevant attacks, all of 1145 which rely on the attacker taking on the identity of a victim or 1146 hiding their identity using someone else's identity, are enabled by 1147 an anonymous identity. As such, the inability to assert an authority 1148 over an anonymous domain is irrelevant to our threat model. 1150 [RFC3325] defines the "id" priv-value token, which is specific to the 1151 P-Asserted-Identity header. The sort of assertion provided by the P- 1152 Asserted-Identity header is very different from the Identity header 1153 presented in this document. It contains additional information about 1154 the sender of a message that may go beyond what appears in the From 1155 header field; P-Asserted-Identity holds a definitive identity for the 1156 sender that is somehow known to a closed network of intermediaries. 1157 Presumably, that network will use this identity for billing or 1158 security purposes. The danger of this network-specific information 1159 leaking outside of the closed network motivated the "id" priv-value 1160 token. The "id" priv-value token has no implications for the 1161 Identity header, and privacy services MUST NOT remove the Identity 1162 header when a priv-value of "id" appears in a Privacy header. 1164 The optional "canon" parameter of the Identity header specified in 1165 this document provides the complete JSON objects used to generate the 1166 signed-identity-digest of the Identity header, including the 1167 canonicalized form of the telephone number of the originator of a 1168 call, if the signature is over a telephone number. In some contexts, 1169 local policy may require a canonicalization which differs 1170 substantially from the original From header field. Depending on 1171 those policies, potentially the "canon" parameter might divulge 1172 information about the originating network or user that might not 1173 appear elsewhere in the SIP request. Were it to be used to reflect 1174 the contents of the P-Asserted-Identity header field, for example, 1175 then "canon" would need to be removed when the P-Asserted-Identity 1176 header is removed to avoid any such leakage outside of a trust 1177 domain. Since, in those contexts, the canonical form of the sender's 1178 identity could not be reassembled by a verifier, and thus the 1179 Identity signature validation process would fail, using P-Asserted- 1180 Identity with the Identity "canon" parameter in this fashion is NOT 1181 RECOMMENDED outside of environments where SIP requests will never 1182 leave the trust domain. As a side note, history shows that closed 1183 networks never stay closed and one should design their implementation 1184 assuming connectivity to the broader Internet. 1186 Finally, note that unlike [RFC3325], the mechanism described in this 1187 specification adds no information to SIP requests that has privacy 1188 implications. 1190 11. Security Considerations 1192 This document describes a mechanism that provides a signature over 1193 the Date header field of SIP requests, parts of the To and From 1194 header fields, and when present any media keying material in the 1195 message body. In general, the considerations related to the security 1196 of these headers are the same as those given in [RFC3261] for 1197 including headers in tunneled 'message/sip' MIME bodies (see 1198 Section 23 of RFC3261 in particular). The following section details 1199 the individual security properties obtained by including each of 1200 these header fields within the signature; collectively, this set of 1201 header fields provides the necessary properties to prevent 1202 impersonation. It addresses the solution-specific attacks against 1203 in-band solutions enumerated in [RFC7375] Section 4.1. 1205 11.1. Protected Request Fields 1207 The From header field value (in ordinary operations) indicates the 1208 identity of the sender of the message. The SIP address-of-record 1209 URI, or an embedded telephone number, in the From header field is the 1210 identity of a SIP user, for the purposes of this document. Note that 1211 in some deployments the identity of the sender may reside in P- 1212 Asserted-Id instead. The sender's identity is the key piece of 1213 information that this mechanism secures; the remainder of the signed 1214 parts of a SIP request are present to provide reference integrity and 1215 to prevent certain types of cut-and-paste attacks. 1217 The Date header field value protects against cut-and-paste attacks, 1218 as described in [RFC3261], Section 23.4.2. Implementations of this 1219 specification MUST NOT deem valid a request with an outdated Date 1220 header field (the RECOMMENDED interval is that the Date header must 1221 indicate a time within 60 seconds of the receipt of a message). Note 1222 that per baseline [RFC3261] behavior, servers keep state of recently 1223 received requests, and thus if an Identity header is replayed by an 1224 attacker within the Date interval, verifiers can detect that it is 1225 spoofed because a message with an identical Date from the same source 1226 had recently been received. 1228 It has been observed in the wild that some networks change the Date 1229 header field value of SIP requests in transit, and that alternative 1230 behavior might be necessary to accommodate that use case. 1231 Verification services that observe a signature validation failure MAY 1232 therefore reconstruct the Date header field component of the 1233 signature from the "iat" carried in PASSporT via the "canon" 1234 parameter: provided that time recorded by "iat" falls within the 1235 local policy for freshness that would ordinarily apply to the Date 1236 header, the verification service MAY treat the signature as valid, 1237 provided it keeps adequate state to detect recent replays. Note that 1238 this will require the inclusion of the "canon" parameter by 1239 authentication services in networks where such failures are observed. 1241 The To header field value provides the identity of the SIP user that 1242 this request originally targeted. Covering the identity in the To 1243 header field with the Identity signature serves two purposes. First, 1244 it prevents cut-and-paste attacks in which an Identity header from 1245 legitimate request for one user is cut-and-pasted into a request for 1246 a different user. Second, it preserves the starting URI scheme of 1247 the request, which helps prevent downgrade attacks against the use of 1248 SIPS. The To identity offers additional protection against cut-and- 1249 paste attacks beyond the Date header field. For example, without a 1250 signature over the To identity, an attacker who receives a call from 1251 a target could immediately forward the INVITE to the target's 1252 voicemail service within the Date interval, and the voicemail service 1253 would have no way knowing that the Identity header it received had 1254 been originally signed for a call intended for a different number. 1255 However, note the caveats below in Section 11.1.1. 1257 When signing a request that contains a fingerprint of keying material 1258 in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a 1259 signature over that fingerprint. This signature prevents certain 1260 classes of impersonation attacks in which an attacker forwards or 1261 cut-and-pastes a legitimate request. Although the target of the 1262 attack may accept the request, the attacker will be unable to 1263 exchange media with the target as they will not possess a key 1264 corresponding to the fingerprint. For example, there are some 1265 baiting attacks, launched with the REFER method or through social 1266 engineering, where the attacker receives a request from the target 1267 and reoriginates it to a third party. These might not be prevented 1268 by only a signature over the From, To and Date, but could be 1269 prevented by securing a fingerprint for DTLS-SRTP. While this is a 1270 different form of impersonation than is commonly used for 1271 robocalling, ultimately there is little purpose in establishing the 1272 identity of the user that originated a SIP request if this assurance 1273 is not coupled with a comparable assurance over the contents of the 1274 subsequent media communication. This signature also, per [RFC7258], 1275 reduces the potential for passive monitoring attacks against the SIP 1276 media. In environments where DTLS-SRTP is unsupported, however, no 1277 field is signed and no protections are provided. 1279 11.1.1. Protection of the To Header and Retargeting 1281 The mechanism in this document provides a signature over the identity 1282 information in the To header field value of requests. This provides 1283 a means for verifiers to detect replay attacks where a signed request 1284 originally sent to one target is modified and then forwarded by an 1285 attacker to another, unrelated target. Armed with the original value 1286 of the To header field, the recipient of a request may compare it to 1287 their own identity in order to determine whether or not the identity 1288 information in this call might have been replayed. However, any 1289 request may be legitimately retargeted as well, and as a result 1290 legitimate requests may reach a SIP endpoint whose user is not 1291 identified by the URI designated in the To header field value. It is 1292 therefore difficult for any verifier to decide whether or not some 1293 prior retargeting was "legitimate." Retargeting can also cause 1294 confusion when identity information is provided for requests sent in 1295 the backwards direction in a dialog, as the dialog identifiers may 1296 not match credentials held by the ultimate target of the dialog. For 1297 further information on the problems of response identity see 1298 [I-D.peterson-sipping-retarget]. 1300 Any means for authentication services or verifiers to anticipate 1301 retargeting is outside the scope of this document, and likely to have 1302 equal applicability to response identity as it does to requests in 1303 the backwards direction within a dialog. Consequently, no special 1304 guidance is given for implementers here regarding the 'connected 1305 party' problem (see [RFC4916]); authentication service behavior is 1306 unchanged if retargeting has occurred for a dialog-forming request. 1307 Ultimately, the authentication service provides an Identity header 1308 for requests in the backwards dialog when the user is authorized to 1309 assert the identity given in the From header field, and if they are 1310 not, an Identity header is not provided. And per the threat model of 1311 [RFC7375], resolving problems with 'connected' identity has little 1312 bearing on detecting robocalling or related impersonation attacks. 1314 11.2. Unprotected Request Fields 1316 RFC4474 originally had protections for the Contact, Call-ID and CSeq. 1317 These are removed from RFC4474bis. The absence of these header 1318 values creates some opportunities for determined attackers to 1319 impersonate based on cut-and-paste attacks; however, the absence of 1320 these headers does not seem impactful to preventing the simple 1321 unauthorized claiming of an identity for the purposes of robocalling, 1322 voicemail hacking, or swatting, which is the primary scope of the 1323 current document. 1325 It might seem attractive to provide a signature over some of the 1326 information present in the Via header field value(s). For example, 1327 without a signature over the sent-by field of the topmost Via header, 1328 an attacker could remove that Via header and insert its own in a cut- 1329 and-paste attack, which would cause all responses to the request to 1330 be routed to a host of the attacker's choosing. However, a signature 1331 over the topmost Via header does not prevent attacks of this nature, 1332 since the attacker could leave the topmost Via intact and merely 1333 insert a new Via header field directly after it, which would cause 1334 responses to be routed to the attacker's host "on their way" to the 1335 valid host, which has exactly the same end result. Although it is 1336 possible that an intermediary-based authentication service could 1337 guarantee that no Via hops are inserted between the sending user 1338 agent and the authentication service, it could not prevent an 1339 attacker from adding a Via hop after the authentication service, and 1340 thereby preempting responses. It is necessary for the proper 1341 operation of SIP for subsequent intermediaries to be capable of 1342 inserting such Via header fields, and thus it cannot be prevented. 1343 As such, though it is desirable, securing Via is not possible through 1344 the sort of identity mechanism described in this document; the best 1345 known practice for securing Via is the use of SIPS. 1347 11.3. Malicious Removal of Identity Headers 1349 In the end analysis, the Identity header cannot protect itself. Any 1350 attacker could remove the header from a SIP request, and modify the 1351 request arbitrarily afterwards. However, this mechanism is not 1352 intended to protect requests from men-in-the-middle who interfere 1353 with SIP messages; it is intended only to provide a way that the 1354 originators of SIP requests can prove that they are who they claim to 1355 be. At best, by stripping identity information from a request, a 1356 man-in-the-middle could make it impossible to distinguish any 1357 illegitimate messages he would like to send from those messages sent 1358 by an authorized user. However, it requires a considerably greater 1359 amount of energy to mount such an attack than it does to mount 1360 trivial impersonations by just copying someone else's From header 1361 field. This mechanism provides a way that an authorized user can 1362 provide a definitive assurance of his identity that an unauthorized 1363 user, an impersonator, cannot. 1365 11.4. Securing the Connection to the Authentication Service 1367 In the absence of user agent-based authentication services, the 1368 assurance provided by this mechanism is strongest when a user agent 1369 forms a direct connection, preferably one secured by TLS, to an 1370 intermediary-based authentication service. The reasons for this are 1371 twofold: 1373 If a user does not receive a certificate from the authentication 1374 service over the TLS connection that corresponds to the expected 1375 domain (especially when the user receives a challenge via a 1376 mechanism such as Digest), then it is possible that a rogue server 1377 is attempting to pose as an authentication service for a domain 1378 that it does not control, possibly in an attempt to collect shared 1379 secrets for that domain. A similar practice could be used for 1380 telephone numbers, though the application of certificates for 1381 telephone numbers to TLS is left as a matter for future study. 1383 Without TLS, the various header field values and the body of the 1384 request will not have integrity protection when the request 1385 arrives at an authentication service. Accordingly, a prior 1386 legitimate or illegitimate intermediary could modify the message 1387 arbitrarily. 1389 Of these two concerns, the first is most material to the intended 1390 scope of this mechanism. This mechanism is intended to prevent 1391 impersonation attacks, not man-in-the-middle attacks; integrity over 1392 the header and bodies is provided by this mechanism only to prevent 1393 replay attacks. However, it is possible that applications relying on 1394 the presence of the Identity header could leverage this integrity 1395 protection for services other than replay protection. 1397 Accordingly, direct TLS connections SHOULD be used between the UAC 1398 and the authentication service whenever possible. The opportunistic 1399 nature of this mechanism, however, makes it very difficult to 1400 constrain UAC behavior, and moreover there will be some deployment 1401 architectures where a direct connection is simply infeasible and the 1402 UAC cannot act as an authentication service itself. Accordingly, 1403 when a direct connection and TLS are not possible, a UAC should use 1404 the SIPS mechanism, Digest 'auth-int' for body integrity, or both 1405 when it can. The ultimate decision to add an Identity header to a 1406 request lies with the authentication service, of course; domain 1407 policy must identify those cases where the UAC's security association 1408 with the authentication service is too weak. 1410 11.5. Authorization and Transitional Strategies 1412 Ultimately, the worth of an assurance provided by an Identity header 1413 is limited by the security practices of the authentication service 1414 that issues the assurance. Relying on an Identity header generated 1415 by a remote administrative domain assumes that the issuing domain 1416 uses recommended administrative practices to authenticate its users. 1417 However, it is possible that some authentication services will 1418 implement policies that effectively make users unaccountable (e.g., 1419 ones that accept unauthenticated registrations from arbitrary users). 1420 The value of an Identity header from such authentication services is 1421 questionable. While there is no magic way for a verifier to 1422 distinguish "good" from "bad" signers by inspecting a SIP request, it 1423 is expected that further work in authorization practices could be 1424 built on top of this identity solution; without such an identity 1425 solution, many promising approaches to authorization policy are 1426 impossible. That much said, it is RECOMMENDED that authentication 1427 services based on proxy servers employ strong authentication 1428 practices. 1430 One cannot expect the Identity header to be supported by every SIP 1431 entity overnight. This leaves the verifier in a compromising 1432 position; when it receives a request from a given SIP user, how can 1433 it know whether or not the sender's domain supports Identity? In the 1434 absence of ubiquitous support for identity, some transitional 1435 strategies are necessary. 1437 A verifier could remember when it receives a request from a domain 1438 or telephone number that uses Identity, and in the future, view 1439 messages received from that sources without Identity headers with 1440 skepticism. 1442 A verifier could consult some sort of directory that indications 1443 whether a given caller should have a signed identity. There are a 1444 number of potential ways in which this could be implemented. This 1445 is left as a subject for future work. 1447 In the long term, some sort of identity mechanism, either the one 1448 documented in this specification or a successor, must become 1449 mandatory-to-use for the SIP protocol; that is the only way to 1450 guarantee that this protection can always be expected by verifiers. 1452 Finally, it is worth noting that the presence or absence of the 1453 Identity headers cannot be the sole factor in making an authorization 1454 decision. Permissions might be granted to a message on the basis of 1455 the specific verified Identity or really on any other aspect of a SIP 1456 request. Authorization policies are outside the scope of this 1457 specification, but this specification advises any future 1458 authorization work not to assume that messages with valid Identity 1459 headers are always good. 1461 11.6. Display-Names and Identity 1463 As a matter of interface design, SIP user agents might render the 1464 display-name portion of the From header field of a caller as the 1465 identity of the caller; there is a significant precedent in email 1466 user interfaces for this practice. Securing the display-name 1467 component of the From header field value is outside the scope of this 1468 document, but may be the subject of future work, such as through the 1469 "ppt" name mechanism. 1471 In the absence of signing the display-name, authentication services 1472 might check and validate it, and compare it to a list of acceptable 1473 display-names that may be used by the sender; if the display-name 1474 does not meet policy constraints, the authentication service could 1475 return a 403 response code. In this case, the reason phrase should 1476 indicate the nature of the problem; for example, "Inappropriate 1477 Display Name". However, the display-name is not always present, and 1478 in many environments the requisite operational procedures for 1479 display-name validation may not exist, so no normative guidance is 1480 given here. 1482 12. IANA Considerations 1484 This document relies on the headers and response codes defined in RFC 1485 4474. It also retains the requirements for the specification of new 1486 algorithms or headers related to the mechanisms described in that 1487 document. 1489 12.1. Identity-Info Parameters 1491 The IANA has already created a registry for Identity-Info parameters. 1492 This specification defines a new value called "canon" as defined in 1493 Section 6.3. Note however that unlike in RFC4474, Identity-Info 1494 parameters now appear in the Identity header. 1496 12.2. Identity-Info Algorithm Parameter Values 1498 The IANA has already created a registry for Identity-Info "alg" 1499 parameter values. Note that now, the "alg" parameter appears in the 1500 Identity header rather than the deprecated Identity-Info header. 1501 Since the algorithms for signing PASSporT objects are defined in 1502 PASSporT rather than in this specification, there is no longer a need 1503 for an algorithm parameter registry for the Identity header. This 1504 registry is therefore deprecated. 1506 12.3. Response Codes defined in RFC4474 1508 RFC4474 defined four response codes for failure conditions specific 1509 to the Identity header and its original mechanism. These status 1510 codes are retained in this specification, with some modifications. 1512 The semantics of the 428 'Use Identity Header' response code are 1513 slightly altered by the potential presence of the "ppt" parameter. 1514 Now, a 428 response MUST be sent when an Identity header is required, 1515 but no Identity header without a "ppt" parameter, or with a support 1516 "ppt" value, has been received. In the case where one or more 1517 Identity headers with unsupported "ppt" values have been received, 1518 then a verification service SHOULD send a 428 with the reason phrase 1519 "Use Supported PASSporT Format". Note however that this 1520 specification gives no guidance on how a verification service might 1521 decide to require an Identity header for a particular SIP request. 1522 Such authorization policies are outside the scope of this 1523 specification. 1525 For 436 'Bad Identity-Info' response, the default reason phrase is 1526 now renamed 'Bad Identity info', as the deprecation of the Identity- 1527 Info header has made 'info' a parameter of the Identity header. 1528 Again, given the potential presence of multiple Identity headers, 1529 this response code is sent when the verification service is unable to 1530 deference the URIs and/or acquire the credentials associated with all 1531 Identity headers in the request. This failure code could be 1532 repairable if the authentication service resends the request with an 1533 'info' parameter pointing to a credential that the verification 1534 service can access. 1536 The 437 'Unsupported Certificate' default reason phrase is now 1537 changed to 'Unsupported Credential'. This response is sent when a 1538 verification service can acquire, or already holds, the credential 1539 represented by the 'info' parameter of at least one Identity header 1540 in the request, but does not support said credential(s), for reasons 1541 such as failing to trust the issuing CA, or failing to support the 1542 algorithm with which the credential was signed. 1544 Finally, the 438 'Invalid Identity Header' response now indicates 1545 that of the set of Identity headers in a request, no header with a 1546 valid and supported PASSporT object has been received. Like the 428 1547 response, this is sent by a verification service when its local 1548 policy dictates that a broken signature in an Identity header is 1549 grounds for rejecting a request. Note that in some cases, an 1550 Identity header may be broken for other reasons than that an 1551 originator is attempting to spoof an identity: for example, when a 1552 transit network alters the Date header of the request. Relying on 1553 the full PASSporT object presented through the "canon" parameter can 1554 repair some of these conditions (see Section 5.2.1), so the 1555 recommended way to attempt to repair this failure is to retry the 1556 request with "canon". 1558 13. Acknowledgments 1560 The authors would like to thank Stephen Kent, Brian Rosen, Alex 1561 Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin 1562 Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, 1563 Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Philippe 1564 Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for 1565 their comments. 1567 14. Changes from RFC4474 1569 The following are salient changes from the original RFC 4474: 1571 Generalized the credential mechanism; credential enrollment, 1572 acquisition and trust is now outside the scope of this document 1574 Reduced the scope of the Identity signature to remove CSeq, Call- 1575 ID, Contact, and the message body 1577 Removed the Identity-Info header and relocated its components into 1578 parameters of the Identity header 1580 The Identity header can now appear multiple times in one request 1582 Replaced previous signed-identity-digest format with PASSporT 1583 (signing algorithms now defined there) 1585 Revised status code descriptions 1587 15. References 1589 15.1. Normative References 1591 [I-D.ietf-stir-passport] 1592 Wendt, C. and J. Peterson, "Persona Assertion Token", 1593 draft-ietf-stir-passport-02 (work in progress), May 2016. 1595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1596 Requirement Levels", BCP 14, RFC 2119, 1597 DOI 10.17487/RFC2119, March 1997, 1598 . 1600 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1601 DOI 10.17487/RFC2818, May 2000, 1602 . 1604 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1605 A., Peterson, J., Sparks, R., Handley, M., and E. 1606 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1607 DOI 10.17487/RFC3261, June 2002, 1608 . 1610 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1611 Protocol (SIP): Locating SIP Servers", RFC 3263, 1612 DOI 10.17487/RFC3263, June 2002, 1613 . 1615 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1616 X.509 Public Key Infrastructure Certificate and 1617 Certificate Revocation List (CRL) Profile", RFC 3280, 1618 DOI 10.17487/RFC3280, April 2002, 1619 . 1621 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1622 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 1623 . 1625 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1626 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1627 . 1629 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1630 Housley, R., and W. Polk, "Internet X.509 Public Key 1631 Infrastructure Certificate and Certificate Revocation List 1632 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1633 . 1635 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 1636 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 1637 DOI 10.17487/RFC6919, April 2013, 1638 . 1640 15.2. Informative References 1642 [I-D.ietf-stir-certificates] 1643 Peterson, J., "Secure Telephone Identity Credentials: 1644 Certificates", draft-ietf-stir-certificates-03 (work in 1645 progress), March 2016. 1647 [I-D.kaplan-stir-cider] 1648 Kaplan, H., "A proposal for Caller Identity in a DNS-based 1649 Entrusted Registry (CIDER)", draft-kaplan-stir-cider-00 1650 (work in progress), July 2013. 1652 [I-D.peterson-sipping-retarget] 1653 Peterson, J., "Retargeting and Security in SIP: A 1654 Framework and Requirements", draft-peterson-sipping- 1655 retarget-00 (work in progress), February 2005. 1657 [I-D.rosenberg-sip-rfc4474-concerns] 1658 Rosenberg, J., "Concerns around the Applicability of RFC 1659 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 1660 progress), February 2008. 1662 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1663 Infrastructure Operational Protocols: FTP and HTTP", 1664 RFC 2585, DOI 10.17487/RFC2585, May 1999, 1665 . 1667 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1668 Initiation Protocol (SIP)", RFC 3323, 1669 DOI 10.17487/RFC3323, November 2002, 1670 . 1672 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1673 Extensions to the Session Initiation Protocol (SIP) for 1674 Asserted Identity within Trusted Networks", RFC 3325, 1675 DOI 10.17487/RFC3325, November 2002, 1676 . 1678 [RFC3548] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data 1679 Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003, 1680 . 1682 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1683 Authenticated Identity Body (AIB) Format", RFC 3893, 1684 DOI 10.17487/RFC3893, September 2004, 1685 . 1687 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1688 Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, 1689 October 2005, . 1691 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1692 Authenticated Identity Management in the Session 1693 Initiation Protocol (SIP)", RFC 4474, 1694 DOI 10.17487/RFC4474, August 2006, 1695 . 1697 [RFC4501] Josefsson, S., "Domain Name System Uniform Resource 1698 Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, 1699 . 1701 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1702 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 1703 2007, . 1705 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1706 for Establishing a Secure Real-time Transport Protocol 1707 (SRTP) Security Context Using Datagram Transport Layer 1708 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1709 2010, . 1711 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1712 of Named Entities (DANE) Transport Layer Security (TLS) 1713 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1714 2012, . 1716 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1717 Morris, J., Hansen, M., and R. Smith, "Privacy 1718 Considerations for Internet Protocols", RFC 6973, 1719 DOI 10.17487/RFC6973, July 2013, 1720 . 1722 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1723 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1724 2014, . 1726 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1727 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1728 2014, . 1730 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1731 Telephone Identity Problem Statement and Requirements", 1732 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1733 . 1735 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 1736 RFC 7375, DOI 10.17487/RFC7375, October 2014, 1737 . 1739 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1740 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1741 . 1743 Authors' Addresses 1745 Jon Peterson 1746 Neustar, Inc. 1747 1800 Sutter St Suite 570 1748 Concord, CA 94520 1749 US 1751 Email: jon.peterson@neustar.biz 1752 Cullen Jennings 1753 Cisco 1754 400 3rd Avenue SW, Suite 350 1755 Calgary, AB T2P 4H2 1756 Canada 1758 Email: fluffy@iii.ca 1760 Eric Rescorla 1761 RTFM, Inc. 1762 2064 Edgewood Drive 1763 Palo Alto, CA 94303 1764 USA 1766 Email: ekr@rtfm.com 1768 Chris Wendt 1769 Comcast 1770 One Comcast Center 1771 Philadelphia, PA 19103 1772 USA 1774 Email: chris-ietf@chriswendt.net