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