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