idnits 2.17.1 draft-ietf-sip-identity-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1859. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 81 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 679 has weird spacing: '... where prox...' == Line 687 has weird spacing: '... where prox...' == 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2005) is 6758 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3548 (ref. '8') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 3280 (ref. '9') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2818 (ref. '11') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3761 (ref. '14') (Obsoleted by RFC 6116, RFC 6117) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: April 27, 2006 C. Jennings 5 Cisco Systems 6 October 24, 2005 8 Enhancements for Authenticated Identity Management in the Session 9 Initiation Protocol (SIP) 10 draft-ietf-sip-identity-06 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The existing security mechanisms in the Session Initiation Protocol 44 are inadequate for cryptographically assuring the identity of the end 45 users that originate SIP requests, especially in an interdomain 46 context. This document defines a mechanism for securely identifying 47 originators of SIP messages. It does so by defining two new SIP 48 header fields, Identity, for conveying a signature used for 49 validating the identity, and Identity-Info, for conveying a reference 50 to the certificate of the signer. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Overview of Operations . . . . . . . . . . . . . . . . . . . . 6 58 5. Authentication Service Behavior . . . . . . . . . . . . . . . 7 59 5.1. Identity within a Dialog and Retargeting . . . . . . . . . 9 60 6. Verifier Behavior . . . . . . . . . . . . . . . . . . . . . . 10 61 7. Considerations for User Agent . . . . . . . . . . . . . . . . 11 62 8. Considerations for Proxy Servers . . . . . . . . . . . . . . . 12 63 9. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 64 10. Compliance Tests and Examples . . . . . . . . . . . . . . . . 15 65 10.1. Identity-Info with a Singlepart MIME body . . . . . . . . 16 66 10.2. Identity for a Request with no MIME body or Contact . . . 19 67 11. Identity and the TEL URI Scheme . . . . . . . . . . . . . . . 22 68 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 23 69 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 70 13.1. Handling of digest-string Elements . . . . . . . . . . . . 24 71 13.2. Display Names and Identity . . . . . . . . . . . . . . . . 27 72 13.3. Securing the Connection to the Authentication Service . . 28 73 13.4. Domain Names and Subordination . . . . . . . . . . . . . . 28 74 13.5. Authorization and Transitional Strategies . . . . . . . . 30 75 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 76 14.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 31 77 14.2. 428 'Use Identity Header' Response Code . . . . . . . . . 31 78 14.3. 436 'Bad Identity-Info' Response Code . . . . . . . . . . 31 79 14.4. 437 'Unsupported Certificate' Response Code . . . . . . . 32 80 14.5. 438 'Invalid Identity Header' Response Code . . . . . . . 32 81 14.6. Identity-Info Parameters . . . . . . . . . . . . . . . . . 32 82 14.7. Identity-Info Algorithm Parameter Values . . . . . . . . . 33 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 84 Appendix B. Bit-exact archive of example messages . . . . . . . . 33 85 B.1. Encoded Reference Files . . . . . . . . . . . . . . . . . 34 86 Appendix C. Original Requirements . . . . . . . . . . . . . . . . 36 87 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . . 37 88 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 89 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39 90 15.2. Informative References . . . . . . . . . . . . . . . . . . 39 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 92 Intellectual Property and Copyright Statements . . . . . . . . . . 42 94 1. Introduction 96 This document provides enhancements to the existing mechanisms for 97 authenticated identity management in the Session Initiation Protocol 98 (SIP, RFC 3261 [1]). An identity, for the purposes of this document, 99 is defined as a SIP URI, commonly a canonical address-of-record (AoR) 100 employed to reach a user (such as 'sip:alice@atlanta.example.com'). 102 RFC3261 stipulates several places within a SIP request where a user 103 can express an identity for themselves, notably the user-populated 104 From header field. However, the recipient of a SIP request has no 105 way to verify that the From header field has been populated 106 appropriately, in the absence of some sort of cryptographic 107 authentication mechanism. 109 RFC3261 specifies a number of security mechanisms that can be 110 employed by SIP UAs, including Digest, TLS and S/MIME 111 (implementations may support other security schemes as well). 112 However, few SIP user agents today support the end-user certificates 113 necessary to authenticate themselves (via S/MIME, for example), and 114 furthermore Digest authentication is limited by the fact that the 115 originator and destination must share a pre-arranged secret. It is 116 desirable for SIP user agents to be able to send requests to 117 destinations with which they have no previous association - just as 118 in the telephone network today, one can receive a call from someone 119 with whom one has no previous association, and still have a 120 reasonable assurance that their displayed Caller-ID is accurate. A 121 cryptographic approach, like the one described in this document, can 122 probably provide a much stronger and less-spoofable assurance of 123 identity than the telephone network provides today. 125 2. Terminology 127 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 129 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 130 described in RFC2119 [2] and indicate requirement levels for 131 compliant SIP implementations. 133 3. Background 135 The usage of many SIP applications and services is governed by 136 authorization policies. These policies may be automated, or they may 137 be applied manually by humans. An example of the latter would be an 138 Internet telephone application which displays the "Caller-ID" of a 139 caller, which a human may review before answering a call. An example 140 of the former would be a presence service that compares the identity 141 of potential subscribers to a whitelist before determining whether it 142 should accept or reject the subscription. In both of these cases, 143 attackers might attempt to circumvent these authorization policies 144 through impersonation. Since the primary identifier of the sender of 145 a SIP request, the From header field, can be populated arbitrarily by 146 the controller of a user agent, impersonation is very simple today. 147 The mechanism described in this document aspires to provide a strong 148 identity system for SIP in which authorization policies cannot be 149 circumvented by impersonation. 151 All RFC3261 compliant user agents support Digest authentication, 152 which utilizes a shared secret, as a means for authenticating 153 themselves to a SIP registrar. Registration allows a user agent to 154 express that it is an appropriate entity to which requests should be 155 sent for a particular SIP AoR URI (e.g., 156 'sip:alice@atlanta.example.com'). 158 By the definition of identity used in this document, registration is 159 a proof of the identity of the user to a registrar. However, the 160 credentials with which a user agent proves its identity to a 161 registrar cannot be validated by just any user agent or proxy server 162 - these credentials are only shared between the user agent and their 163 domain administrator. So this shared secret does not immediately 164 help a user to authenticate to a wide range of recipients. 165 Recipients require a means of determining whether or not the 'return 166 address' identity of a non-REGISTER request (i.e., the From header 167 field value) has legitimately been asserted. 169 The AoR URI used for registration is also the URI with which a UA 170 commonly populates the From header field of requests in order to 171 provide a 'return address' identity to recipients. From an 172 authorization perspective, if you can prove you are eligible to 173 register in a domain under a particular AoR, you can prove you can 174 legitimately receive requests for that AoR, and accordingly, when you 175 place that AoR in the From header field of a SIP request other than a 176 registration (like an INVITE), you are providing a 'return address' 177 where you can legitimately be reached. In other words, if you are 178 authorized to receive requests for that 'return address', logically, 179 it follows that you are also authorized to assert that 'return 180 address' in your From header field. This is of course only one 181 manner in which a domain might determine how a particular user is 182 authorized to populate the From header field; as an aside, for other 183 sorts of URIs in the From (like anonymous URIs), other authorization 184 policies would apply. 186 Ideally, then, SIP user agents should have some way of proving to 187 recipients of SIP requests that their local domain has authenticated 188 them and authorized the population of the From header field. This 189 document proposes a mediated authentication architecture for SIP in 190 which requests are sent to a server in the user's local domain, which 191 authenticates such requests (using the same practices by which the 192 domain would authenticate REGISTER requests). Once a message has 193 been authenticated, the local domain then needs some way to 194 communicate to other SIP entities that the sending user has been 195 authenticated and their use of the From header field has been 196 authorized. This draft addresses how that imprimatur of 197 authentication can be shared. 199 RFC3261 already describes an architecture very similar to this in 200 Section 26.3.2.2, in which a user agent authenticates itself to a 201 local proxy server which in turn authenticates itself to a remote 202 proxy server via mutual TLS, creating a two-link chain of transitive 203 authentication between the originator and the remote domain. While 204 this works well in some architectures, there are a few respects in 205 which this is impractical. For one, transitive trust is inherently 206 weaker than an assertion that can be validated end-to-end. It is 207 possible for SIP requests to cross multiple intermediaries in 208 separate administrative domains, in which case transitive trust 209 becomes even less compelling. 211 One solution to this problem is to use 'trusted' SIP intermediaries 212 that assert an identity for users in the form of a privileged SIP 213 header. A mechanism for doing so (with the P-Asserted-Identity 214 header) is given in [12]. However, this solution allows only hop-by- 215 hop trust between intermediaries, not end-to-end cryptographic 216 authentication, and it assumes a managed network of nodes with strict 217 mutual trust relationships, an assumption that is incompatible with 218 widespread Internet deployment. 220 Accordingly, this document specifies a means of sharing a 221 cryptographic assurance of end-user SIP identity in an interdomain or 222 intradomain context which is based on the concept of an 223 'authentication service' and a new SIP header, the Identity header. 224 Note that the scope of this document is limited to providing this 225 identity assurance for SIP requests; solving this problem for SIP 226 responses is more complicated, and is a subject for future work. 228 This specification allows either a user agent or a proxy server to 229 provide identity services and to verify identities. To maximize end- 230 to-end security, it is obviously preferable for end users to acquire 231 their own certificates and corresponding private keys; if they do, 232 they can act as an authentication service. However, end-user 233 certificates may be neither practical nor affordable, given the 234 difficulties of establishing a PKI that extends to end users, and 235 moreover, given the potentially large number of SIP user agents 236 (phones, PCs, laptops, PDAs, gaming devices) that may be employed by 237 a single user. In such environments, synchronizing keying material 238 across multiple devices may be very complex, and requires quite a 239 good deal of additional endpoint behavior. Managing several 240 certificates for the various devices is also quite problematic and 241 unpopular with users. Accordingly, in the initial use of this 242 mechanism, it is likely that intermediaries will instantiate the 243 authentication service role. 245 4. Overview of Operations 247 This section provides an informative (non-normative) high-level 248 overview of the mechanisms described in this document. 250 Imagine the case where Alice, who has the home proxy of example.com 251 and the address-of-record sip:alice@example.com, wants to communicate 252 with sip:bob@example.org. 254 Alice generates an INVITE and places her identity in the From header 255 field of the request. She then sends an INVITE over TLS to an 256 authentication service proxy for her domain. 258 The authentication service authenticates Alice (possibly by sending a 259 Digest authentication challenge) and validates that she is authorized 260 to assert the identity which is populated in the From header field. 261 This value may be Alice's AoR, or it may be some other value that the 262 policy of the proxy server permits her to use. It then computes a 263 hash over some particular headers, including the From header field 264 and the bodies in the message. This hash is signed with the 265 certificate for the domain (example.com, in Alice's case) and 266 inserted in a new header field in the SIP message, the 'Identity' 267 header. 269 The proxy, as the holder of the private key of its domain, is 270 asserting that the originator of this request has been authenticated 271 and that she is authorized to claim the identity (the SIP address-of- 272 record) which appears in the From header field. The proxy also 273 inserts a companion header field, Identity-Info, that tells Bob how 274 to acquire its certificate, if he doesn't already have it. 276 When Bob's domain receives the request, it verifies the signature 277 provided in the Identity header, and thus can validates that the 278 domain indicated by the host portion of the AoR in the From header 279 field authenticated the user, and permitted them to assert that From 280 header field value. This same validation operation may be performed 281 by Bob's UAS. 283 5. Authentication Service Behavior 285 This document defines a new role for SIP entities called an 286 authentication service. The authentication service role can be 287 instantiated by a proxy server or a user agent. Any entity that 288 instantiates the authentication service role MUST possess the private 289 key of a domain certificate, and MUST be capable of authenticating 290 one or more SIP users that can register in that domain. Commonly, 291 this role will be instantiated by a proxy server, since these 292 entities are more likely to have a static hostname, hold a 293 corresponding certificate, and have access to SIP registrar 294 capabilities that allow them to authenticate users in their domain. 295 It is also possible that the authentication service role might be 296 instantiated by an entity that acts as a redirect server, but that is 297 left as a topic for future work. 299 SIP entities that act as an authentication service MUST add a Date 300 header field to SIP requests if one is not already present (see 301 Section 9 for information on how the Date header field assist 302 verifiers). Similarly, authentication services MUST add a Content- 303 Length header field to SIP requests if one is not already present; 304 this can help the verifier to double-check that they are hashing 305 exactly as many bytes of message-body as the authentication service 306 when they verify the message. 308 Entities instantiating the authentication service role performs the 309 following steps, in order, to generate an Identity header for a SIP 310 request: 312 Step 1: The authentication service MUST extract the identity of the 313 sender from the request. The authentication service takes this value 314 from the From header field; this AoR will be referred to here as the 315 'identity field'. If the identity field contains a SIP or SIPS URI, 316 the authentication service MUST extract the hostname portion of the 317 identity field and compare it to the domain(s) for which it is 318 responsible (following the procedures in RFC3261 16.4 used by a proxy 319 server to determine the domain(s) for which it is responsible). If 320 the identity field uses the TEL URI scheme, the policy of the 321 authentication service determines whether or not it is responsible 322 for this identity; see Section 11 for more information. If the 323 authentication service is not responsible for the identity in 324 question, it SHOULD process and forward the request normally, but it 325 MUST NOT add an Identity header; see below for more information on 326 authentication service handling of an existing Identity header. 328 Step 2: The authentication service MUST determine whether or not the 329 sender of the request is authorized to claim the identity given in 330 the identity field. In order to do so, the authentication service 331 MUST authenticate the sender of the message. Some possible ways in 332 which this authentication might be performed include: 333 If the authentication service is instantiated by a SIP 334 intermediary (proxy server), it may challenge the request with a 335 407 response code using the Digest authentication scheme (or 336 viewing a Proxy-Authentication header sent in the request which 337 was sent in anticipation of a challenge using cached credentials, 338 as described in RFC 3261 Section 22.3). Note that if that proxy 339 server is maintaining a TLS connection with the client over which 340 the client had previously authenticated itself using Digest 341 authentication, the identity value obtained from that previous 342 authentication step can be reused without an additional Digest 343 challenge. 344 If the authentication service is instantiated by a SIP user agent, 345 a user agent can be said to authenticate its user on the grounds 346 that the user can provision the user agent with the private key of 347 the domain, or preferably by providing a password that unlocks 348 said private key. 350 Authorization of the use of a particular username in the From header 351 field is a matter of local policy for the authentication service, one 352 which depends greatly on the manner in which authentication is 353 performed. For example, one policy might be as follows: the username 354 given in the 'username' parameter of the Proxy-Authorization header 355 MUST correspond exactly to the username in the From header field of 356 the SIP message. However, there are many cases in which this is too 357 limiting or inappropriate; a realm might use 'username' parameters in 358 Proxy-Authorization which do not correspond to the user-portion of 359 SIP From headers, or a user might manage multiple accounts in the 360 same administrative domain. In this latter case, a domain might 361 maintain a mapping between the values in the 'username' parameter of 362 Proxy-Authorization and a set of one or more SIP URIs which might 363 legitimately be asserted for that 'username'. For example, the 364 username can correspond to the 'private identity' as defined in 3GPP, 365 in which case the From header field can contain any one of the public 366 identities associated with this private identity. In this instance, 367 another policy might be as follows: the URI in the From header field 368 MUST correspond exactly to one of the mapped URIs associated with the 369 'username' given in the Proxy-Authorization header. Various 370 exceptions to such policies might arise for cases like anonymity; if 371 the AoR asserted in the From header field uses a form like 372 'sip:anonymous@example.com', then the 'example.com' proxy should 373 authenticate that the user is a valid user in the domain and insert 374 the signature over the From header field as usual. 376 Note that this check is performed on the addr-spec in the From header 377 field (e.g., the URI of the sender, like 378 'sip:alice@atlanta.example.com'); it does not convert the display- 379 name portion of the From header field (e.g., 'Alice Atlanta'). 380 Authentication services MAY check and validate the display-name as 381 well, and compare it to a list of acceptable display-names that may 382 be used by the sender; if the display-name does not meet policy 383 constraints, the authentication service MUST return a 403 response 384 code with the reason phrase "Inappropriate Display-Name". However, 385 the display-name is not always present, and in many environments the 386 requisite operational procedures for display-name validation may not 387 exist. For more information, see Section 13.2. 389 Step 3: The authentication service SHOULD ensure that any pre- 390 existing Date header in the request is accurate. Local policy can 391 dictate precisely how accurate the Date must be, a RECOMMENDED 392 maximum discrepancy of ten minutes will ensure that the request is 393 unlikely to upset any verifiers. If the Date header contains a time 394 different by more than ten minutes from the current time noted by the 395 authentication service, the authentication service SHOULD reject the 396 request. This behavior is not mandatory because a user agent client 397 could only exploit the Date header in order to cause a request to 398 fail verification; the Identity header is not intended to provide a 399 source of non-repudiation or a perfect record of when messages are 400 processed. Finally, the authentication service MUST verify that the 401 Date header falls within the validity period of its certificate. For 402 more information on the security properties associated with the Date 403 header field value, see Section 9. 405 Step 4: The authentication service MUST form the identity signature 406 and add an Identity header to the request containing this signature. 407 After the Identity header has been added to the request, the 408 authentication service MUST also add an Identity-Info header. The 409 Identity-Info header contains a URI from which its certificate can be 410 acquired. Details on the generation of both of these headers are 411 provided in section Section 9. 413 Finally, the authentication service MUST forward the message 414 normally. 416 5.1. Identity within a Dialog and Retargeting 418 Retargeting is broadly defined as the alteration of the Request-URI 419 by intermediaries. More specifically, retargeting supplants the 420 original target URI with one that corresponds to a different user, a 421 user that is not authorized to register under the original target 422 URI. By this definition, retargeting does not include translation of 423 the Request-URI to a contact address of an endpoint that has 424 registered under the original target URI, for example. 426 When a dialog-forming request is retargeted, this can cause a few 427 wrinkles for the Identity mechanism when it is applied to requests 428 sent in the backwards direction within a dialog. This section 429 provides some non-normative considerations related to this case. 431 When a request is retargeted, it may reach a SIP endpoint whose user 432 is not identified by the URI designated in the To header field value. 433 The value in the To header field of a dialog-forming request is used 434 as the From header field of requests sent in the backwards direction 435 during the dialog, and is accordingly the header that would be signed 436 by an authentication service for requests sent in the backwards 437 direction. In retargeting cases, if the URI in the From header does 438 not identify the sender of the request in the backwards direction, 439 then clearly it would be inappropriate to provide an Identity 440 signature over that From header. As specified above, if the 441 authentication service is not responsible for the domain in the From 442 header field of the request, it MUST NOT add an Identity header to 443 the request, and should process/forward the request normally. 445 Any means of anticipating retargeting and so on is outside the scope 446 of this document, and likely to have equal applicability to response 447 identity as it does to requests in the backwards direction within a 448 dialog. Consequently, no special guidance is given for implementers 449 here regarding the 'connected party' problem; authentication service 450 behavior is unchanged if retargeting has occurred for a dialog- 451 forming request. Ultimately, the authentication service provides an 452 Identity header for requests in the backwards dialog when the user is 453 authorized to assert the identity given in the From header field, and 454 if they are not, an Identity header is not provided. 456 For further information on the problems of response identity and the 457 potential solution spaces, see [15]. 459 6. Verifier Behavior 461 This document introduces a new logical role for SIP entities called a 462 'verifier', which may be instantiated by a user agent or proxy 463 server. When a verifier receives a SIP message containing an 464 Identity header, it may inspect the signature to verify the identity 465 of the sender of the message. Typically, the results of a 466 verification are provided as input to an authorization process which 467 is outside the scope of this document. If an Identity header is not 468 present in a request, and one is required by local policy (for 469 example, based on a per-sending-domain policy, or a per-sending-user 470 policy), then a 428 'Use Identity Header' response MUST be sent. 472 In order to verify the identity of the sender of a message, an entity 473 acting as a verifier MUST perform the following steps, in the order 474 here specified. 476 Step 1: The verifier MUST acquire the certificate for the signing 477 domain. Implementations supporting this specification SHOULD have 478 some means of retaining domain certificates (in accordance with 479 normal practices for certificate lifetimes and revocation) in order 480 to prevent themselves from needlessly downloading the same 481 certificate every time a request from the same domain is received. 482 Certificates cached in this manner should be indexed by the URI given 483 in the Identity-Info header field value. 485 Provided that the domain certificate used to sign this message is not 486 previously known to the recipient, SIP entities SHOULD discover this 487 certificate by dereferencing the Identity-Info header, unless they 488 have some more efficient implementation-specific way of acquiring 489 certificates for that domain. If the URI scheme in the Identity-Info 490 header cannot be dereferenced, then a 436 'Bad Identity-Info' 491 response MUST be returned. The client processes this certificate in 492 the usual ways, including checking that it has not expired, that the 493 chain is valid back to a trusted CA, and that it does not appear on 494 revocation lists. Once the certificate is acquired, it MUST be 495 validated following the procedures in RFC3280 [9]. If the 496 certificate cannot be validated (it is self-signed and untrusted, or 497 signed by an untrusted or unknown certificate authority, expired, or 498 revoked), the verifier MUST send a 437 'Unsupported Certificate' 499 response. 501 Step 2: The verifier MUST follow the process described in 502 Section 13.4 to determine if the signer is authoritative for the URI 503 in the From header field. 505 Step 3: The verifier MUST verify the signature in the Identity header 506 field, following the procedures for generating the hashed digest- 507 string described in Section 9. If a verifier determines that the 508 signature on the message does not correspond to the reconstructed 509 digest-string, then a 438 'Invalid Identity Header' response MUST be 510 returned. 512 Step 4: The verifier MUST validate the Date, Contact and Call-ID 513 headers in the manner described in Section 13.1; recipients that wish 514 to verify Identity signatures MUST support all of the operations 515 described there. It must furthermore ensure that the value of the 516 Date header falls within the validity period of the certificate whose 517 corresponding private key was used to sign the Identity header. 519 7. Considerations for User Agent 520 This mechanism can be applied opportunistically to existing SIP 521 deployments; accordingly, it requires no change to SIP user agent 522 behavior in order for it to be effective. However, because this 523 mechanism does not provide integrity protection between the UAC and 524 the authentication service, a UAC SHOULD implement some means of 525 providing this integrity. TLS would be one such mechanism, which is 526 attractive because it MUST be supported by SIP proxy servers, but is 527 potentially problematic because it is a hop-by-hop mechanism. See 528 Section 13.3 for more information about securing the channel between 529 the UAC and the authentication service. 531 When a UAC sends a request, it MUST accurately populate the From 532 header field with a value corresponding to an identity that it 533 believes it is authorized to claim. In a request it MUST set the URI 534 portion of its From header to match a SIP, SIPS or TEL URI AoR which 535 it is authorized to use in the domain (including anonymous URIs, as 536 described in RFC 3323 [3]). In general, UACs SHOULD NOT use the TEL 537 URI form in the From header field (see Section 11). 539 Note that this document defines a number of new 4xx response codes. 540 If user agents support these response codes, they will be able to 541 respond intelligently to Identity-based error conditions. 543 The UAC MUST also be capable of sending requests, including mid-call 544 requests, through an 'outbound' proxy (the authentication service). 545 The best way to accomplish this is using pre-loaded Route headers and 546 loose routing. For a given domain, if an entity that can instantiate 547 the authentication service role is not in the path of dialog-forming 548 requests, identity for mid-dialog requests in the backwards direction 549 cannot be provided. 551 As a recipient of a request, a user agent that can verify signed 552 identities should also support an appropriate user interface to 553 render the validity of identity to a user. User agent 554 implementations SHOULD differentiate signed From header field values 555 from unsigned From header field values when rendering to an end user 556 the identity of the sender of a request. 558 8. Considerations for Proxy Servers 560 Domain policy may require proxy servers to inspect and verify the 561 identity provided in SIP requests. A proxy server may wish to 562 ascertain the identity of the sender of the message to provide spam 563 prevention or call control services. Even if a proxy server does not 564 act as an authentication service, it MAY validate the Identity header 565 before it makes a forwarding decision for a request. Proxy servers 566 MUST NOT remove or modify an existing Identity or Identity-Info 567 header in a request. 569 9. Header Syntax 571 This document specifies two new SIP headers: Identity and Identity- 572 Info. Each of these headers can appear only once in a SIP message. 573 The grammar for these two headers is (following the ABNF [6] in s): 574 (following the ABNF [6] in RFC3261 [1]): 576 Identity = "Identity" HCOLON signed-identity-digest 577 signed-identity-digest = LDQUOT 32LHEX RDQUOT 579 Identity-Info = "Identity-Info" HCOLON ident-info *( SEMI ident-info-params ) 580 ident-info = LAQUOT absoluteURI RAQUOT 581 ident-info-params = ident-info-alg / ident-info-extension 582 ident-info-alg = "alg" EQUAL token 583 ident-info-extension = generic-param 585 The signed-identity-digest is a signed hash of a canonical string 586 generated from certain components of a SIP request. To create the 587 contents of the signed-identity-digest, the following elements of a 588 SIP message MUST be placed in a bit-exact string in the order 589 specified here, separated by a vertical line, "|" or %x7C, character: 590 o The AoR of the UA sending the message, or addr-spec of the From 591 header field (referred to occasionally here as the 'identity 592 field'). 593 o The addr-spec component of the To header field, which is the AoR 594 to which the request is being sent. 595 o The callid from Call-Id header field. 596 o The digit (1*DIGIT) and method (method) portions from CSeq header 597 field, separated by a single space (ABNF SP, or %x20). Note that 598 the CSeq header field allows LWS rather than SP to separate the 599 digit and method portions, and thus the CSeq header field may need 600 to be transformed in order to be canonicalized. The 601 authentication service MUST strip leading zeros from the 'digit' 602 portion of the Cseq before generating the digest-string. 603 o The Date header field, with exactly one space each for each SP and 604 the weekday and month items case set as shown in BNF in 3261. RFC 605 3261 specifies that the BNF for weekday and month are a choice 606 amongst a set of tokens. The RFC 2234 rules for the BNF specify 607 that tokens are case sensitive. However, when used to construct 608 the canonical string defined here, the first letter of each week 609 and month MUST be capitalized, and the remaining two letters must 610 be lowercase. This matches the capitalization provided in the 611 definition of each token. All requests that use the Identity 612 mechanism MUST contain a Date header. 614 o The addr-spec component of the Contact header field value. If the 615 request does not contain a Contact header, this field MUST be 616 empty (i.e., there will be no whitespace between the fourth and 617 fifth "|" characters in the canonical string). 618 o The body content of the message with the bits exactly as they are 619 in the Message (in the ABNF for SIP, the message-body). This 620 includes all components of multipart message bodies. Note that 621 the message-body does NOT include the CRLF separating the SIP 622 headers from the message-body, but does include everything that 623 follows that CRLF. If the message has no body, then message-body 624 will be empty, and the final "|" will not be followed by any 625 additional characters. 627 For more information on the security properties of these headers, and 628 why their inclusion mitigates replay attacks, see Section 13 and [5]. 629 The precise formulation of this digest-string is, therefore 630 (following the ABNF [6] in RFC3261): 632 digest-string = addr-spec "|" addr-spec "|" callid "|" 1*DIGIT SP Method "|" 633 SIP-date "|" [ addr-spec ] "|" message-body 635 Note again that the first addr-spec MUST be taken from the From 636 header field value, the second addr-spec MUST be taken from the To 637 header field value, and the third addr-spec MUST be taken from the 638 Contact header field value, provided the Contact header is present in 639 the request. 641 After the digest-string is formed, it MUST be hashed and signed with 642 the certificate for the domain. The hashing and signing algorithm is 643 specified by the 'alg' parameter of the Identity-Info header (see 644 below for more information on Identity-Info header parameters). This 645 document defines only one value for the 'alg' parameter: 'rsa-sha1'; 646 further values MUST be defined in a Standards Track RFC, see 647 Section 14.7 for more information. All implementations of this 648 specification MUST support 'rsa-sha1'. When the 'rsa-sha1' algorithm 649 is specified in the 'alg' parameter of Identity-Info, the hash and 650 signature MUST be generated as follows: compute the results of 651 signing this string with sha1WithRSAEncryption as described in RFC 652 3370 [7] and base64 encode the results as specified in RFC 3548 [8]. 653 A 1024 bit or longer RSA key MUST be used. The result is placed in 654 the Identity header field. For detailed examples of the usage of 655 this algorithm, see Section 10. 657 The 'absoluteURI' portion of the Identity-Info header MUST contain 658 either an HTTP or HTTPS URI which dereferences to a resource that 659 contains a single MIME body containing the certificate of the 660 authentication service. These URIs MUST follow the conventions of 661 RFC2585 [10] and the indicated resource MUST be of the form 662 'application/pkix-cert' described in that specification. Note that 663 this introduces key lifecycle management concerns; were a domain to 664 change the key available at the Identity-Info URI before a verifier 665 evaluates a request signed by an authentication service, this would 666 cause obvious verifier failures. When a rollover occurs, 667 authentication services SHOULD thus provide new Identity-Info URIs 668 for each new certificate, and SHOULD continue to make older key 669 acquisition URIs available for a duration longer than the plausible 670 lifetime of a SIP message (an hour would most likely suffice). 672 The Identity-Info header field MUST contain an 'alg' parameter. No 673 other parameters are defined for the Identity-Info header in this 674 document. Future Standards Track RFCs may define additional 675 Identity-Info header parameters. 677 This document adds the following entries to Table 2 of RFC 3261 [1]: 679 Header field where proxy ACK BYE CAN INV OPT REG 680 ------------ ----- ----- --- --- --- --- --- --- 681 Identity R a o o - o o o 683 SUB NOT REF INF UPD PRA 684 --- --- --- --- --- --- 685 o o o o o o 687 Header field where proxy ACK BYE CAN INV OPT REG 688 ------------ ----- ----- --- --- --- --- --- --- 689 Identity-Info R a o o - o o o 691 SUB NOT REF INF UPD PRA 692 --- --- --- --- --- --- 693 o o o o o o 695 Note, in the table above, that this mechanism does not protect the 696 CANCEL method. The CANCEL method cannot be challenged, because it is 697 hop-by-hop, and accordingly authentication service behavior for 698 CANCEL would be significantly limited. Note as well that the 699 REGISTER method uses Contact header fields in very unusual ways that 700 complicate its applicability to this mechanism, and the use of 701 Identity with REGISTER is consequently a subject for future study, 702 although it is left as optional here for forward-compatibility 703 reasons. The Identity and Identity-Info header MUST NOT appear in 704 CANCEL. 706 10. Compliance Tests and Examples 707 The examples in this section illustrate the use of the Identity 708 header in the context of a SIP transaction. Implementers are advised 709 to verify their compliance with the specification against the 710 following criteria: 711 o Implementations of the authentication service role MUST generate 712 identical base64 identity strings to the ones shown in the 713 Identity headers in these examples when presented with the source 714 message and utilizing the appropriate supplied private key for the 715 domain in question. 716 o Implementations of the verifier role MUST correctly validate the 717 given messages containing the Identity header when utilizing the 718 supplied certificates (with the caveat about self-signed 719 certificates below). 721 Note that the following examples use self-signed certificates, rather 722 than certificates issued by a recognized certificate authority. The 723 use of self-signed certificates for this mechanism is NOT 724 RECOMMENDED, and it appears here only for illustrative purposes. 725 Therefore, in compliance testing, implementations of verifiers SHOULD 726 generate appropriate warnings about the use of self-signed 727 certificates. Also, the example certificates in this section have 728 placed their domain name subject in the subjectAltName field; in 729 practice, certificate authorities may place domain names in other 730 locations in the certificate (see Section 13.4 for more information). 732 Note that all examples in this section use the 'rsa-sha1' algorithm. 734 Bit-exact reference files for these messages and their various 735 transformations are supplied in Appendix B. 737 10.1. Identity-Info with a Singlepart MIME body 739 Consider the following private key and certificate pair assigned to 740 'atlanta.example.com' (rendered in OpenSSL format). 742 -----BEGIN RSA PRIVATE KEY----- 743 MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO 744 aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc 745 IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB 746 AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt 747 PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw 748 +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30 749 tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H 750 0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 751 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C 752 DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r 753 xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU 754 6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK 755 Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk 756 -----END RSA PRIVATE KEY----- 757 -----BEGIN CERTIFICATE----- 758 MIIC3TCCAkagAwIBAgIBADANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEL 759 MAkGA1UECAwCR0ExEDAOBgNVBAcMB0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAa 760 BgNVBAMME2F0bGFudGEuZXhhbXBsZS5jb20wHhcNMDUxMDI0MDYzNjA2WhcNMDYx 761 MDI0MDYzNjA2WjBZMQswCQYDVQQGEwJVUzELMAkGA1UECAwCR0ExEDAOBgNVBAcM 762 B0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAaBgNVBAMME2F0bGFudGEuZXhhbXBs 763 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM88wG0dWg+RdX5nqOrU 764 uyB9MQtVanLYFVR98kw8fTosvRwlJA5oh5XMiiPNa2lq4HsjKVkqUCMHl/jb21G6 765 hSJ50LAwspuVYCpm3p4dakI1knuU41wgTCeaHacBxwqTzcun9Ufe2ABL/jcNChfa 766 yd2diH6DznbY/PCDsQZaynPPAgMBAAGjgbQwgbEwHQYDVR0OBBYEFNmU/MrbVYcE 767 KDr/20WISrG1j1rNMIGBBgNVHSMEejB4gBTZlPzK21WHBCg6/9tFiEqxtY9azaFd 768 pFswWTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkdBMRAwDgYDVQQHDAdBdGxhbnRh 769 MQ0wCwYDVQQKDARJRVRGMRwwGgYDVQQDDBNhdGxhbnRhLmV4YW1wbGUuY29tggEA 770 MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADdQYtswBDmTSTq0mt211 771 7alm/XGFrb2zdbU0vorxRdOZ04qMyrIpXG1LEmnEOgcocyrXRBvq5p6WbZAcEQk0 772 DsE3Ve0Nc8x9nmvljW7GsMGFCnCuo4ODTf/1lGdVr9DeCzcj10YUQ3MRemDMXhY2 773 CtDisLWl7SXOORcZAi1oU9w= 774 -----END CERTIFICATE----- 776 A user of atlanta.example.com, Alice, wants to send an INVITE to 777 bob@biloxi.example.org. She therefore creates the following INVITE 778 request, which she forwards to the atlanta.example.org proxy server 779 that instantiates the authentication service role: 781 INVITE sip:bob@biloxi.example.org SIP/2.0 782 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 783 To: Bob 784 From: Alice ;tag=1928301774 785 Call-ID: a84b4c76e66710 786 CSeq: 314159 INVITE 787 Max-Forwards: 70 788 Date: Thu, 21 Feb 2002 13:02:03 GMT 789 Contact: 790 Content-Type: application/sdp 791 Content-Length: 147 793 v=0 794 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 795 s=Session SDP 796 c=IN IP4 pc33.atlanta.example.com 797 t=0 0 798 m=audio 49172 RTP/AVP 0 799 a=rtpmap:0 PCMU/8000 801 When the authentication service receives the INVITE, it authenticates 802 Alice by sending a 407 response. As a result, Alice adds an 803 Authorization header to her request, and resends to the 804 atlanta.example.com authentication service. Now that the service is 805 sure of Alice's identity, it calculates an Identity header for the 806 request. The canonical string over which the identity signature will 807 be generated is the following (note that the first line wraps because 808 of RFC editorial conventions): 810 sip:alice@atlanta.example.com|sip:bob@biloxi.example.org|a84b4c76e66710|314159 INVITE|Thu, 21 Feb 2002 13:02:03 GMT|alice@pc33.atlanta.example.com|v=0 811 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 812 s=Session SDP 813 c=IN IP4 pc33.atlanta.example.com 814 t=0 0 815 m=audio 49172 RTP/AVP 0 816 a=rtpmap:0 PCMU/8000 818 The resulting signature (sha1WithRsaEncryption) using the private RSA 819 key given above, with base64 encoding, is the following: 821 kjOP4YVZXmF0X3/4RUfAG6ffwbVQepNGRBz58b3dJq3prEV4h5GnS4F6udDRCI4/ 822 rSK9cl+TFv45nu0Qu2d/0WPPOvvc3JWwuUmHrCwGwC+tW7fOWnC07QKgQn40uwg5 823 7WaXixQev5N0JfoLXnO3UDoum89JRhXPAIp2vffJbD4= 825 Accordingly, the atlanta.example.com authentication service will 826 create an Identity header containing that base64 signature string 827 (175 bytes). It will also add an HTTPS URL where its certificate is 828 made available. With those two headers added, the message looks 829 like: 831 INVITE sip:bob@biloxi.exmple.org SIP/2.0 832 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 833 To: Bob 834 From: Alice ;tag=1928301774 835 Call-ID: a84b4c76e66710 836 CSeq: 314159 INVITE 837 Max-Forwards: 70 838 Date: Thu, 21 Feb 2002 13:02:03 GMT 839 Contact: 840 Identity:"kjOP4YVZXmF0X3/4RUfAG6ffwbVQepNGRBz58b3dJq3prEV4h5GnS4F6udDRCI4/ 841 rSK9cl+TFv45nu0Qu2d/0WPPOvvc3JWwuUmHrCwGwC+tW7fOWnC07QKgQn40uwg5 842 7WaXixQev5N0JfoLXnO3UDoum89JRhXPAIp2vffJbD4=" 843 Identity-Info: ;alg=rsa-sha1 844 Content-Type: application/sdp 845 Content-Length: 147 847 v=0 848 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 849 s=Session SDP 850 c=IN IP4 pc33.atlanta.example.com 851 t=0 0 852 m=audio 49172 RTP/AVP 0 853 a=rtpmap:0 PCMU/8000 855 atlanta.example.com then forwards the request normally. When Bob 856 receives the request, if he does not already know the certificate of 857 atlanta.example.com, he de-references the URL in the Identity-Info 858 header to acquire the certificate. Bob then generates the same 859 canonical string given above, from the same headers of the SIP 860 request. Using this canonical string, the signed digest in the 861 Identity header, and the certificate discovered by de-referencing the 862 Identity-Info header, Bob can verify that the given set of headers 863 and the message body have not been modified. 865 10.2. Identity for a Request with no MIME body or Contact 867 Consider the following private key and certificate pair assigned to 868 "biloxi.example.org". 870 -----BEGIN RSA PRIVATE KEY----- 871 MIICXgIBAAKBgQC/obBYLRMPjskrAqWOiGPAUxI3/m2ti7ix4caqCTAuFX5cLegQ 872 7nmquLOHfIhxVIqT2f06UA0lOo2NVofK9G7MTkVbVNiyAlLYUDEj7XWLDICf3ZHL 873 6Fr/+CF7wrQ9r4kv7XiJKxodVCCd/DhCT9Gp+VDoe8HymqOW/KsneriyIwIDAQAB 874 AoGBAJ7fsFIKXKkjWgj8ksGOthS3Sn19xPSCyEdBxfEm2Pj7/Nzzeli/PcOaic0k 875 JALBcnqN2fHEeIGK/9xUBxTufgQYVJqvyHERs6rXX/iT4Ynm9t1905EiQ9ZpHsrI 876 /AMMUYA1QrGgAIHvZLVLzq+9KLDEZ+HQbuCLJXF+6bl0Eb5BAkEA636oMANp0Qa3 877 mYWEQ2utmGsYxkXSfyBb18TCOwCty0ndBR24zyOJF2NbZS98Lz+Ga25hfIGw/JHK 878 nD9bOE88UwJBANBRSpd4bmS+m48R/13tRESAtHqydNinX0kS/RhwHr7mkHTU3k/M 879 FxQtx34I3GKzaZxMn0A66KS9v/SHdnF+ePECQQCGe7QshyZ8uitLPtZDclCWhEKH 880 qAQHmUEZvUF2VHLrbukLLOgHUrHNa24cILv4d3yaCVUetymNcuyTwhKj24wFAkAO 881 z/jx1EplN3hwL+NsllZoWI58uvu7/Aq2c3czqaVGBbb317sHCYgKk0bAG3kwO3mi 882 93/LXWT1cdiYVpmBcHDBAkEAmpgkFj+xZu5gWASY5ujv+FCMP0WwaH5hTnXu+tKe 883 PJ3d2IJZKxGnl6itKRN7GeRh9PSK0kZSqGFeVrvsJ4Nopg== 884 -----END RSA PRIVATE KEY----- 885 -----BEGIN CERTIFICATE----- 886 MIIC1jCCAj+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJVUzEL 887 MAkGA1UECAwCTVMxDzANBgNVBAcMBkJpbG94aTENMAsGA1UECgwESUVURjEbMBkG 888 A1UEAwwSYmlsb3hpLmV4YW1wbGUuY29tMB4XDTA1MTAyNDA2NDAyNloXDTA2MTAy 889 NDA2NDAyNlowVzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAk1TMQ8wDQYDVQQHDAZC 890 aWxveGkxDTALBgNVBAoMBElFVEYxGzAZBgNVBAMMEmJpbG94aS5leGFtcGxlLmNv 891 bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv6GwWC0TD47JKwKljohjwFMS 892 N/5trYu4seHGqgkwLhV+XC3oEO55qrizh3yIcVSKk9n9OlANJTqNjVaHyvRuzE5F 893 W1TYsgJS2FAxI+11iwyAn92Ry+ha//ghe8K0Pa+JL+14iSsaHVQgnfw4Qk/RqflQ 894 6HvB8pqjlvyrJ3q4siMCAwEAAaOBsTCBrjAdBgNVHQ4EFgQU0Z+RL47W/APDtc5B 895 fSoQXuEFE/wwfwYDVR0jBHgwdoAU0Z+RL47W/APDtc5BfSoQXuEFE/yhW6RZMFcx 896 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJNUzEPMA0GA1UEBwwGQmlsb3hpMQ0wCwYD 897 VQQKDARJRVRGMRswGQYDVQQDDBJiaWxveGkuZXhhbXBsZS5jb22CAQAwDAYDVR0T 898 BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBiyKHIt8TXfGNfpnJXi5jCizOxmY8Y 899 gln8tyPFaeyq95TGcvTCWzdoBLVpBD+fpRWrX/II5sE6VHbbAPjjVmKbZwzQAtpp 900 P2Fauj28t94ZeDHN2vqzjfnHjCO24kG3Juf2T80ilp9YHcDwxjUFrt86UnlC+yid 901 yaTeusW5Gu7v1g== 902 -----END CERTIFICATE----- 904 Bob (bob@biloxi.example.org) now wants to send a BYE request to Alice 905 at the end of the dialog initiated in the previous example. He 906 therefore creates the following BYE request which he forwards to the 907 'biloxi.example.org' proxy server that instantiates the 908 authentication service role: 910 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 911 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 912 Max-Forwards: 70 913 From: Bob ;tag=a6c85cf 914 To: Alice ;tag=1928301774 915 Call-ID: a84b4c76e66710 916 CSeq: 231 BYE 917 Content-Length: 0 918 When the authentication service receives the BYE, it authenticates 919 Bob by sending a 407 response. As a result, Bob adds an 920 Authorization header to his request, and resends to the 921 biloxi.example.org authentication service. Now that the service is 922 sure of Bob's identity, it prepares to calculate an Identity header 923 for the request. Note that this request does not have a Date header 924 field. Accordingly, the biloxi.example.org will add a Date header to 925 the request before calculating the identity signature. If the 926 Content-Length header were not present, the authentication service 927 would add it as well. The baseline message is thus: 929 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 930 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 931 Max-Forwards: 70 932 From: Bob ;tag=a6c85cf 933 To: Alice ;tag=1928301774 934 Date: Thu, 21 Feb 2002 14:19:51 GMT 935 Call-ID: a84b4c76e66710 936 CSeq: 231 BYE 937 Content-Length: 0 939 Also note that this request contains no Contact header field. 940 Accordingly, biloxi.example.org will place no value in the canonical 941 string for the addr-spec of the Contact address. Also note that 942 there is no message body, and accordingly, the signature string will 943 terminate, in this case, with two vertical bars. The canonical 944 string over which the identity signature will be generated is the 945 following (note that the first line wraps because of RFC editorial 946 conventions): 948 sip:bob@biloxi.example.org|sip:alice@atlanta.example.com|a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT|| 950 The resulting signature (sha1WithRsaEncryption) using the private RSA 951 key given above for biloxi.example.org, with base64 encoding, is the 952 following: 954 vvXEPaukq60Jd1M7Ag0CeCiI0cGfgV0uAyJA7UdpkT82E1TkWFJhc8DTDV5xnafv 955 wKtekBNpfc0sbW2gfK7i/FRMNLuYOIk9aH9Oc+GhvR5J+m1uw1e2WBSYXH3FQJKM 956 p94gYvRM3hD0P081WBGgxXlaN5LFplIKE25n4FzLhBc= 958 Accordingly, the biloxi.example.org authentication service will 959 create an Identity header containing that base64 signature string. 960 It will also add an HTTPS URL where its certificate is made 961 available. With those two headers added, the message looks like: 963 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 964 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 965 Max-Forwards: 70 966 From: Bob ;tag=a6c85cf 967 To: Alice ;tag=1928301774 968 Date: Thu, 21 Feb 2002 14:19:51 GMT 969 Call-ID: a84b4c76e66710 970 CSeq: 231 BYE 971 Identity: "vvXEPaukq60Jd1M7Ag0CeCiI0cGfgV0uAyJA7UdpkT82E1TkWFJhc8DTDV5xnafv 972 wKtekBNpfc0sbW2gfK7i/FRMNLuYOIk9aH9Oc+GhvR5J+m1uw1e2WBSYXH3FQJKM 973 p94gYvRM3hD0P081WBGgxXlaN5LFplIKE25n4FzLhBc=" 974 Identity-Info: ;alg=rsa-sha1 975 Content-Length: 0 977 biloxi.example.org then forwards the request normally. 979 11. Identity and the TEL URI Scheme 981 Since many SIP applications provide a VoIP service, telephone numbers 982 are commonly used as identities in SIP deployments. In the majority 983 of cases, this is not problematic for the identity mechanism 984 described in this document. Telephone numbers commonly appear in the 985 username portion of a SIP URI (e.g., 986 'sip:+17005551008@chicago.example.com;user=phone'). That username 987 conforms to the syntax of the TEL URI scheme (RFC3966 [13]). For 988 this sort of SIP address-of-record, chicago.example.com is the 989 appropriate signatory. 991 It is also possible for a TEL URI to appear in the SIP To or From 992 header field outside the context of a SIP or SIPS URI (e.g., 993 'tel:+17005551008'). In this case, it is much less clear which 994 signatory is appropriate for the identity. Fortunately for the 995 identity mechanism, this form of the TEL URI is more common for the 996 To header field and Request-URI in SIP than in the From header field, 997 since the UAC has no option but to provide a TEL URI alone when the 998 remote domain to which a request is sent is unknown. The local 999 domain, however, is usually known by the UAC, and accordingly it can 1000 form a proper From header field containing a SIP URI with a username 1001 in TEL URI form. Implementations that intend to send their requests 1002 through an authentication service SHOULD put telephone numbers in the 1003 From header field into SIP or SIPS URIs whenever possible. 1005 If the local domain is unknown to a UAC formulating a request, it 1006 most likely will not be able to locate an authentication service for 1007 its request, and therefore the question of providing identity in 1008 these cases is somewhat moot. However, an authentication service MAY 1009 sign a request containing a TEL URI in the From header field. This 1010 is permitted in this specification strictly for forward compatibility 1011 purposes. In the longer-term, it is possible that ENUM [14] may 1012 provide a way to determine which administrative domain is responsible 1013 for a telephone number, and this may aid in the signing and 1014 verification of SIP identities that contain telephone numbers. This 1015 is a subject for future work. 1017 12. Privacy Considerations 1019 The identity mechanism presented in this draft is compatible with the 1020 standard SIP practices for privacy described in RFC3323 [3]. A SIP 1021 proxy server can act both as a privacy service and as an 1022 authentication service. Since a user agent can provide any From 1023 header field value which the authentication service is willing to 1024 authorize, there is no reason why private SIP URIs which contain 1025 legitimate domains (e.g., sip:anonymous@example.com) cannot be signed 1026 by an authentication service. The construction of the Identity 1027 header is the same for private URIs as it is for any other sort of 1028 URIs. 1030 Note, however, that an authentication service must possess a 1031 certificate corresponding to the host portion of the addr-spec of the 1032 From header field of any request that it signs; accordingly, using 1033 domains like 'anonymous.invalid' will not be possible for privacy 1034 services that also act as authentication services. The assurance 1035 offered by the usage of anonymous URIs with a valid domain portion is 1036 "this is a known user in my domain that I have authenticated, but I 1037 am keeping their identity private". The use of the domain 1038 'anonymous.invalid' entails that no corresponding authority for the 1039 domain can exist, and as a consequence, authentication service 1040 functions are meaningless. 1042 The "header" level of privacy described in RFC3323 requests that a 1043 privacy service to alter the Contact header field value of a SIP 1044 message. Since the Contact header field is protected by the 1045 signature in an Identity header, privacy services cannot be applied 1046 after authentication services without a resulting integrity 1047 violation. 1049 RFC3325 [12] defines the "id" priv-value token which is specific to 1050 the P-Asserted-Identity header. The sort of assertion provided by 1051 the P-Asserted-Identity header is very different from the Identity 1052 header presented in this document. It contains additional 1053 information about the sender of a message that may go beyond what 1054 appears in the From header field; P-Asserted-Identity holds a 1055 definitive identity for the sender which is somehow known to a closed 1056 network of intermediaries that presumably the network will use this 1057 identity for billing or security purposes. The danger of this 1058 network-specific information leaking outside of the closed network 1059 motivated the "id" priv-value token. The "id" priv-value token has 1060 no implications for the Identity header, and privacy services MUST 1061 NOT remove the Identity header when a priv-value of "id" appears in a 1062 Privacy header. 1064 Finally, note that unlike RFC3325, the mechanism described in this 1065 specification adds no information to SIP requests that has privacy 1066 implications. 1068 13. Security Considerations 1070 13.1. Handling of digest-string Elements 1072 This document describes a mechanism which provides a signature over 1073 the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP 1074 requests. While a signature over the From header field would be 1075 sufficient to secure a URI alone, the additional headers provide 1076 replay protection and reference integrity necessary to make sure that 1077 the Identity header will not be used in cut-and-paste attacks. In 1078 general, the considerations related to the security of these headers 1079 are the same as those given in RFC3261 for including headers in 1080 tunneled 'message/sip' MIME bodies (see Section 23 in particular). 1081 The following section details the individual security properties 1082 obtained by including each of these header fields within the 1083 signature; collectively, this set of header fields provides the 1084 necessary properties to prevent impersonation. 1086 The From header field indicates the identity of the sender of the 1087 message, and the SIP address-of-record URI in the From header field 1088 is the identity of a SIP user, for the purposes of this document. 1089 The To header field provides the identity of the SIP user that this 1090 request targets. Providing the To header field in the Identity 1091 signature serves two purposes: first, it prevents cut-and-paste 1092 attacks in which an Identity header from legitimate request for one 1093 user is cut-and-pasted into a request for a different user; second, 1094 it preserves the starting URI scheme of the request, which helps 1095 prevent downgrade attacks against the use of SIPS. 1097 The Date and Contact headers provide reference integrity and replay 1098 protection, as described in RFC3261 Section 23.4.2. Implementations 1099 of this specification MUST NOT deem valid a request with an outdated 1100 Date header field (the RECOMMENDED interval is that the Date header 1101 must indicate a time within 3600 seconds of the receipt of a 1102 message). Implementations MUST also record Call-IDs received in 1103 valid requests containing an Identity header, and MUST remember those 1104 Call-IDs for at least the duration of a single Date interval (i.e. 1105 commonly 3600 seconds). Because a SIP-compliant UA never generates 1106 the same Call-ID twice, verifiers can use the Call-ID to recognize 1107 cut-and-paste attacks; the Call-ID serves as a nonce. The result of 1108 this is that if an Identity header is replayed within the Date 1109 interval, verifiers will recognize that it is invalid because of a 1110 Call-ID duplication; if an Identity header is replayed after the Date 1111 interval, verifiers will recognize that it is invalid because the 1112 Date is stale. The CSeq header field contains a numbered identifier 1113 for the transaction, and the name of the method of the request; 1114 without this information, an INVITE request could be cut-and-pasted 1115 by an attacker and transformed into a BYE request without changing 1116 any fields covered by the Identity header, and moreover requests 1117 within a certain transaction could be replayed in potentially 1118 confusing or malicious ways. 1120 The Contact header field is included to tie the Identity header to a 1121 particular user agent instance that generated the request. Were an 1122 active attacker to intercept a request containing an Identity header, 1123 and cut-and-paste the Identity header field into their own request 1124 (reusing the From, To, Contact, Date and Call-ID fields that appear 1125 in the original message), they would not be eligible to receive SIP 1126 requests from the called user agent, since those requests are routed 1127 to the URI identified in the Contact header field. However, the 1128 Contact header is only included in dialog-forming requests, so it 1129 does not provide this protection in all cases. 1131 It might seem attractive to provide a signature over some of the 1132 information present in the Via header field value(s). For example, 1133 without a signature over the sent-by field of the topmost Via header, 1134 an attacker could remove that Via header and insert their own in a 1135 cut-and-paste attack, which would cause all responses to the request 1136 to be routed to a host of the attacker's choosing. However, a 1137 signature over the topmost Via header does not prevent attacks of 1138 this nature, since the attacker could leave the topmost Via intact 1139 and merely insert a new Via header field directly after it, which 1140 would cause responses to be routed to the attacker's host "on their 1141 way" to the valid host, which has exactly the same end result. 1142 Although it is possible that an intermediary-based authentication 1143 service could guarantee that no Via hops are inserted between the 1144 sending user agent and the authentication service, it could not 1145 prevent an attacker from adding a Via hop after the authentication 1146 service, and thereby pre-empting responses. It is necessary for the 1147 proper operation of SIP for subsequent intermediaries to be capable 1148 of inserting such Via header fields, and thus it cannot be prevented. 1149 As such, though it is desirable, securing Via is not possible through 1150 the sort of identity mechanism described in this document; the best 1151 known practice for securing Via is the use of SIPS. 1153 This mechanism also provides a signature over the bodies of SIP 1154 requests. The most important reason for doing so is to protect SDP 1155 bodies carried in SIP requests. There is little purpose in 1156 establishing the identity of the user that originated a SIP request 1157 if this assurance is not coupled with a comparable assurance over the 1158 media descriptors. Note however that this is not perfect end-to-end 1159 security. The authentication service itself, when instantiated at a 1160 intermediary, could conceivably change the SDP (and SIP headers, for 1161 that matter) before providing a signature. Thus, while this 1162 mechanism reduces the chance that a replayer or man-in-the-middle 1163 will modify SDP, it does not eliminate it entirely. Since it is a 1164 foundational assumption of this mechanism that the user trusts their 1165 local domain to vouch for their security, they must also trust the 1166 service not to violate the integrity of their message without good 1167 reason. Note that RFC3261 16.6 states that SIP proxy servers "MUST 1168 NOT add to, modify, or remove the message body." 1170 In the end analysis, the Identity and Identity-Info headers cannot 1171 protect themselves. Any attacker could remove these headers from a 1172 SIP request, and modify the request arbitrarily afterwards. However, 1173 this mechanism is not intended to protect requests from men-in-the- 1174 middle who interfere with SIP messages; it is intended only to 1175 provide a way that SIP users can prove definitively that they are who 1176 they claim to be. At best, by stripping identity information from a 1177 request, a man-in-the-middle could make it impossible to distinguish 1178 any illegitimate messages he would like to send from those messages 1179 sent by an authorized user. However, it requires a considerably 1180 greater amount of energy to mount such an attack than it does to 1181 mount trivial impersonations by just copying someone else's From 1182 header field. This mechanism provides a way that an authorized user 1183 can provide a definitive assurance of their identity which an 1184 unauthorized user, an impersonator, cannot. 1186 One additional respect in which the Identity-Info header cannot 1187 protect itself is the 'alg' parameter. The 'alg' parameter is not 1188 included in the digest-string, and accordingly, a man-in-the-middle 1189 might attempt to modify the 'alg' parameter. However, it is 1190 important to note that preventing men-in-the-middle is not the 1191 primary impetus for this mechanism. Moreover, changing the 'alg' 1192 would at worst result in some sort of bid-down attack, and at best 1193 cause a failure in the verifier. Note that only one valid 'alg' 1194 parameter is defined in this document, and that thus there is 1195 currently no weaker algorithm to which the mechanism can be bid-down. 1196 'alg' has been incorporated into this mechanism for forward- 1197 compatibility reasons in case the current algorithm exhibits 1198 weaknesses, and requires swift replacement, in the future. 1200 13.2. Display Names and Identity 1202 As a matter of interface design, SIP user agents might render the 1203 display-name portion of the From header field of a caller as the 1204 identity of the caller; there is a significant precedent in email 1205 user interfaces for this practice. As such, it might seem that the 1206 lack of a signature over the display-name is a significant omission. 1208 However, there are several important senses in which a signature over 1209 the display-name does not prevent impersonation. In the first place, 1210 a particular display-name, like "Jon Peterson", is not unique in the 1211 world; many users in different administrative domains might 1212 legitimately claim that name. Furthermore, enrollment practices for 1213 SIP-based services might have a difficult time discerning the 1214 legitimate display-name for a user; it is safe to assume that 1215 impersonators will be capable of creating SIP accounts with 1216 arbitrarily display-names. The same situation prevails in email 1217 today. Note that an impersonator who attempted to replay a message 1218 with an Identity header, changing only the display-name in the From 1219 header field, would be detected by the other replay protection 1220 mechanisms described in Section 13.1. 1222 Of course, an authentication service can enforce policies about the 1223 display-name even if the display-name is not signed. The exact 1224 mechanics for creating and operationalizing such policies is outside 1225 the scope of this document. The effect of this policy would not be 1226 to prevent impersonation of a particular unique identifier like a SIP 1227 URI (since display-names are not unique identifiers), but to allow a 1228 domain to manage the claims made by its users. If such policies are 1229 enforced, users would not be free to claim any display-name of their 1230 choosing. In the absence of a signature, man-in-the-middle attackers 1231 could conceivably alter the display-names in a request with impunity. 1232 Note that the scope of this specification is impersonation attacks, 1233 however, and that a man-in-the-middle might also strip the Identity 1234 and Identity-Info headers from a message. 1236 There are many environments in which policies regarding the display- 1237 name aren't feasible. Distributing bit-exact and internationalizable 1238 display-names to end users as part of the enrollment or registration 1239 process would require mechanisms that are not explored in this 1240 document. In the absence of policy enforcement regarding domain 1241 names, there are conceivably attacks that an adversary could mount 1242 against SIP systems that rely too heavily on the display-name in 1243 their user interface, but this argues for intelligent interface 1244 design, not changes to the mechanisms. Relying on a non-unique 1245 identifier for identity would ultimately result in a weak mechanism. 1247 13.3. Securing the Connection to the Authentication Service 1249 The assurance provided by this mechanism is strongest when a user 1250 agent forms a direct connection, preferably one secured by TLS, to an 1251 intermediary-based authentication service. The reasons for this are 1252 twofold: 1253 If a user does not receive a certificate from the authentication 1254 service over this TLS connection that corresponds to the expected 1255 domain (especially when they receive a challenge via a mechanism 1256 such as Digest), then it is possible that a rogue server is 1257 attempting to pose as an authentication service for a domain that 1258 it does not control, possibly in an attempt to collect shared 1259 secrets for that domain. 1260 Without TLS, the various header field values and the body of the 1261 request will not have integrity protection with the request 1262 arrives at an authentication service. Accordingly, a prior 1263 legitimate or illegitimate intermediary could modify the message 1264 arbitrarily. 1266 Of these two concerns, the first is most material to the intended 1267 scope of this mechanism. This mechanism is intended to prevent 1268 impersonation attacks, not man-in-the-middle attacks; integrity over 1269 the header and bodies is provided by this mechanism only to prevent 1270 replay attacks. However, it is possible that applications relying on 1271 the presence of the Identity header could leverage this integrity 1272 protection, especially body integrity, for services other than replay 1273 protection. 1275 Accordingly, direct TLS connections SHOULD be used between the UAC 1276 and the authentication service whenever possible. The opportunistic 1277 nature of this mechanism, however, makes it very difficult to 1278 constrain UAC behavior, and moreover there will be some deployment 1279 architectures where a direct connection is simply infeasible and the 1280 UAC cannot act as an authentication service itself. Accordingly, 1281 when a direct connection and TLS are not possible, a UAC should use 1282 the SIPS mechanism, Digest 'auth-int' for body integrity, or both 1283 when it can. The ultimate decision to add an Identity header to a 1284 request lies with the authentication service, of course; domain 1285 policy must identify those cases where the UAC's security association 1286 with the authentication service is too weak. 1288 13.4. Domain Names and Subordination 1290 When a verifier processes a request containing an Identity-Info 1291 header, it must compare the domain portion of the URI in the From 1292 header field of the request with the domain name which is the subject 1293 of the certificate acquired from the Identity-Info header. While it 1294 might seem that this should be a straightforward process, it is 1295 complicated by two deployment realities. In the first place, 1296 certificates have varying ways of describing their subjects, and may 1297 indeed have multiple subjects, especially in 'virtual hosting' cases 1298 where multiple domains are managed by a single application. 1299 Secondly, some SIP services may delegate SIP functions to a 1300 subordinate domain and utilize the procedures in RFC3263 [4] allow 1301 requests for, say, 'example.com' to be routed to 'sip.example.com'; 1302 as a result, a user with the AoR 'sip:jon@example.com' may process 1303 their requests through a host like 'sip.example.com', and it may be 1304 that latter host which acts as an authentication service. 1306 To meet the second of these problems, a domain that deploys an 1307 authentication service on a subordinate host MUST be willing to 1308 supply that host with the private keying material associated with a 1309 certificate whose subject is a domain name that corresponds to the 1310 domain portion of the AoRs that the domain distributes to users. 1311 Note that this corresponds to the comparable case of routing inbound 1312 SIP requests to a domain. When the NAPTR and SRV procedures of 1313 RFC3263 are used to direct requests to a domain name other than the 1314 domain in the original Request-URI (e.g., for 'sip:jon@example.com', 1315 the corresponding SRV records point to the service 1316 'sip1.example.org'), the client expects that the certificate passed 1317 back in any TLS exchange with that host will correspond exactly with 1318 the domain of the original Request-URI, not the domain name of the 1319 host. Consequently, in order to make inbound routing to such SIP 1320 services work, a domain administrator must similarly be willing to 1321 share the domain's private key with the service. This design 1322 decision was made to compensate for the insecurity of the DNS, and it 1323 makes certain potential approaches to DNS-based 'virtual hosting' 1324 unsecurable for SIP in environments where domain administrators are 1325 unwilling to share keys with hosting services. 1327 A verifier MUST evaluate the correspondence between the user's 1328 identity and the signing certificate by following the procedures 1329 defined in RFC 2818 [11] Section 3.1. While RFC2818 deals with the 1330 use of HTTP in TLS, the procedures described are applicable to 1331 verifying identity if one subtitutes the "hostname of the server" in 1332 HTTP for the domain portion of the user's identity in the From header 1333 field of a SIP request with an Identity header. 1335 Because the domain certificates that can be used by authentication 1336 services need to assert only the hostname of the authentication 1337 service, existing certificate authorities can provide adequate 1338 certificates for this mechanism. However, not all proxy servers and 1339 user agents will be able to support the root certificates of all 1340 certificate authorities, and moreover there are some significant 1341 differences in the policies by which certificate authorities issue 1342 their certificates. This document makes no recommendations for the 1343 usage of particular certificate authorities, nor does it describe any 1344 particular policies that certificate authorities should follow, but 1345 it is anticipated that operational experience will create de facto 1346 standards for authentication services. Some federations of service 1347 providers, for example, might only trust certificates that have been 1348 provided by a certificate authority operated by the federation. It 1349 is strongly RECOMMENDED that self-signed domain certificates should 1350 not be trusted by verifiers, unless some previous key exchange has 1351 justified such trust. 1353 For further information on certificate security and practices see 1354 RFC3280 [9]. The Security Considerations of RFC3280 are applicable 1355 to this document. 1357 13.5. Authorization and Transitional Strategies 1359 Ultimately, the worth of an assurance provided by an Identity header 1360 is limited by the security practices of the domain that issues the 1361 assurance. Relying on an Identity header generated by a remote 1362 administrative domain assumes that the issuing domain used its 1363 administrative practices to authenticate its users. However, it is 1364 possible that some domains will implement policies that effectively 1365 make users unaccountable (e.g., ones that accept unauthenticated 1366 registrations from arbitrary users). The value of an Identity header 1367 from such domains is questionable. While there is no magic way for a 1368 verifier to distinguish "good" from "bad" domains by inspecting a SIP 1369 request, it is expected that further work in authorization practices 1370 could be built on top of this identity solution; without such an 1371 identity solution, many promising approaches to authorization policy 1372 are impossible. That much said, it is RECOMMENDED that 1373 authentication services based on proxy servers employ strong 1374 authentication practices such as token-based identifiers. 1376 One cannot expect the Identity and Identity-Info headers to be 1377 supported by every SIP entity overnight. This leaves the verifier in 1378 a compromising position; when it receives a request from a given SIP 1379 user, how can it know whether or not the sender's domain supports 1380 Identity? In the absence of ubiquitous support for identity, some 1381 transitional strategies are necessary. 1382 A verifier could remember when it receives a request from a domain 1383 that uses Identity, and in the future, view messages received from 1384 that domain without Identity headers with skepticism. 1385 A verifier could query the domain through some sort of callback 1386 system to determine whether or not it is running an authentication 1387 service. There are a number of potential ways in which this could 1388 be implemented; use of the SIP OPTIONS method is one possibility. 1389 This is left as a subject for future work. 1391 In the long term, some sort of identity mechanism, either the one 1392 documented in this specification or a successor, must become 1393 mandatory-to-use for the SIP protocol; that is the only way to 1394 guarantee that this protection can always be expected by verifiers. 1396 Finally, it is worth noting that the presence or absence of the 1397 Identity headers cannot be the sole factor in making an authorization 1398 decision. Permissions might be granted to a message on the basis of 1399 the specific verified Identity or really on any other aspect of a SIP 1400 request. Authorization policies are outside the scope of this 1401 specification, but this specification advises any future 1402 authorization work not to assume that messages with valid Identity 1403 headers are always good. 1405 14. IANA Considerations 1407 This document requests changes to the header and response-code sub- 1408 registries of the SIP parameters IANA registry, and requests the 1409 creation of two new registries for parameters for the Identity-Info 1410 header. 1412 14.1. Header Field Names 1414 This document specifies two new SIP headers: Identity and Identity- 1415 Info. Their syntax is given in Section 9. These headers are defined 1416 by the following information, which is to be added to the header sub- 1417 registry under http://www.iana.org/assignments/sip-parameters. 1418 Header Name: Identity 1419 Compact Form: y 1420 Header Name: Identity-Info 1421 Compact Form: n 1423 14.2. 428 'Use Identity Header' Response Code 1425 This document registers a new SIP response code which is described in 1426 Section 6. It is sent when a verifier receives a SIP request that 1427 lacks an Identity header in order to indicate that the request should 1428 be re-sent with an Identity header. This response code is defined by 1429 the following information, which is to be added to the method and 1430 response-code sub-registry under 1431 http://www.iana.org/assignments/sip-parameters. 1432 Response Code Number: 428 1433 Default Reason Phrase: Use Identity Header 1435 14.3. 436 'Bad Identity-Info' Response Code 1437 This document registers a new SIP response code which is described in 1438 Section 6. It is used when the Identity-Info header contains a URI 1439 that cannot be dereferenced by the verifier (either the URI scheme is 1440 unsupported by the verifier, or the resource designated by the URI is 1441 otherwise unavailable). This response code is defined by the 1442 following information, which is to be added to the method and 1443 response-code sub-registry under 1444 http://www.iana.org/assignments/sip-parameters. 1445 Response Code Number: 436 1446 Default Reason Phrase: Bad Identity-Info 1448 14.4. 437 'Unsupported Certificate' Response Code 1450 This document registers a new SIP response code which is described in 1451 Section 6. It is used when the verifier cannot validate the 1452 certificate referenced by the URI of the Identity-Info header, 1453 because, for example, the certificate is self-signed, or signed by a 1454 root certificate authority for whom the verifier does not possess a 1455 root certificate. This response code is defined by the following 1456 information, which is to be added to the method and response-code 1457 sub-registry under http://www.iana.org/assignments/sip-parameters. 1458 Response Code Number: 437 1459 Default Reason Phrase: Unsupported Certificate 1461 14.5. 438 'Invalid Identity Header' Response Code 1463 This document registers a new SIP response code which is described in 1464 Section 6. It is used when the verifier receives a message with an 1465 Identity signature that does not correspond to the digest-string 1466 calculated by the verifier. This response code is defined by the 1467 following information, which is to be added to the method and 1468 response-code sub-registry under 1469 http://www.iana.org/assignments/sip-parameters. 1470 Response Code Number: 438 1471 Default Reason Phrase: Invalid Identity Header 1473 14.6. Identity-Info Parameters 1475 This document requests that the IANA create a new registry for 1476 Identity-Info headers. This registry is to be prepopulated with a 1477 single entry for a parameter called 'alg', which describes the 1478 algorithm used to create the signature which appears in the Identity 1479 header. Registry entries must contain the name of the parameter and 1480 the specification in which the parameter is defined. New parameters 1481 for the Identity-Info header may be defined only in Standards Track 1482 RFCs. 1484 14.7. Identity-Info Algorithm Parameter Values 1486 This document requests that the IANA create a new registry for 1487 Identity-Info 'alg' parameter values. This registry is to be 1488 prepopulated with a single entry for a value called 'rsa-sha1', which 1489 describes the algorithm used to create the signature which appears in 1490 the Identity header. Registry entries must contain the name of the 1491 'alg' parameter value and the specification in which the value is 1492 described. New values for the 'alg' parameter may be defined only in 1493 Standards Track RFCs. 1495 Appendix A. Acknowledgments 1497 The authors would like to thank Eric Rescorla, Rohan Mahy, Robert 1498 Sparks, Jonathan Rosenberg, Mark Watson, Henry Sinnreich, Alan 1499 Johnston, Patrik Faltstrom, Paul Kyzviat, Adam Roach, John Elwell, 1500 Aki Niemi, and Jim Schaad for their comments. Jonathan Rosenberg 1501 provided detailed fixes to innumerable sections of the document. The 1502 bit-archive presented in Appendix B follows the pioneering example of 1503 Robert Sparks' torture-test draft. Thanks to Hans Persson and Tao 1504 Wan for thorough nit reviews. 1506 Appendix B. Bit-exact archive of example messages 1508 The following text block is an encoded, gzip compressed TAR archive 1509 of files that represent the transformations performed on the example 1510 messages discussed in Section 10. It includes for each example: 1511 o (foo).message: the original message 1512 o (foo).canonical: the canonical string constructed from that 1513 message 1514 o (foo).sha1: the SHA1 hash of the canonical string (hexadecimal) 1515 o (foo).signed: the RSA-signed SHA1 hash of the canonical string 1516 (binary) 1517 o (foo).signed.enc: the base64 encoding of the RSA-signed SHA1 hash 1518 of the canonical string as it would appear in the request 1519 o (foo).identity: the original message with the Identity and 1520 Identity-Info headers added 1522 Also included in the archive are two public key/certificate pairs, 1523 for atlanta.example.com and biloxi.example.org, respectively, 1524 including: 1525 o (foo).cer: the certificate of the domain 1526 o (foo).privkey: the private key of the domain 1527 o (foo).pubkey: the public key of the domain, extracted from the 1528 cert file for convenience 1530 To recover the compressed archive file intact, the text of this 1531 document may be passed as input to the following Perl script (the 1532 output should be redirected to a file or piped to "tar -xzvf -"). 1534 #!/usr/bin/perl 1535 use strict; 1536 my $bdata = ""; 1537 use MIME::Base64; 1538 while(<>) { 1539 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 1540 if ( m/^\s*[^\s]+\s*$/) { 1541 $bdata = $bdata . $_; 1542 } 1543 } 1544 } 1545 print decode_base64($bdata); 1547 Alternatively, the base-64 encoded block can be edited by hand to 1548 remove document structure lines and fed as input to any base-64 1549 decoding utility. 1551 B.1. Encoded Reference Files 1553 -- BEGIN MESSAGE ARCHIVE -- 1554 H4sICPuIXEMCA25ld2lkZW50LnRhcgDsW0us5NhZboUVlloCDRI7VJpVUKXbb7t8 1555 J53M8dvlR5XLj3KVQiS/ys+yq8qusqvUEUJiARILyCobRJAQWYxgyQaBgiArxAJl 1556 HwFii9iEDWKB7+339PT0RJm+mkzuL5XsOj62zzm//+87/3fsKu6yKK5a+N67MwQh 1557 EJokhy2O0Tg1bDGCoNBh+9zuodfHUITAsaEeilMEem9E3rsFOzatfxiN7uW7uI0P 1558 TV29od62SA71cfegfBDd+xJZ9cz/flv6Ves/DOPD5+5/FEEogniT/zFkKHvufxQb 1559 6pM0id0bIXf+f+f24NpYQVKMEScsbEVUOGALN6WQrigcbnMcKPwEdAoLkuHHA4NN 1560 in1aZBLTISwwHRHw7Fo3m44zV7xrmpLQTV3nImiQDgoJoI7AgY5bIEIv8GDGJobL 1561 glBnEREJJPEYSULP20B7Ul7rrFCKrrDqZR740JNCXRew55WPay9NA49t1haZBxjS 1562 yWlo6LzT67yC6PzqYuQAW96UrXrolcL8k5v5aa2EPkszP62V0LNmJutJx5urqVqv 1563 lfQUGsAUWNYEfLJCgK5IU1BLwzUmk05ComUyXkQeWe1nBwc6nllGN1vXr7SV6C6Y 1564 SdFNNnbdnBZdOQVknZKenmVzw8fKPSE3ueoWe4fT5RIe7otKFJRaUxLRQNfsju6K 1565 223xHRH5hYIW1dEh0C6xudiX/ZDtu719CY8V42xiDLAanIcGl2586BxhUSZT/KUK 1566 VvCc4xtz7Z+r+RwkOguAlCeB2SWB0MnXA7tAZiy7EkRj68D6IXBXoQCp/AHGkKVi 1567 HSQ0Rw/G0F/2etBkSxfinCUS1l6X84uKoUuZ5RIKZloxE/Z9u2L8iy9G0E5suqX9 1568 wlVsqnOuq/fcBUyfjH4yHIpYfQG6YUSv3Ts4JmIjqU+DapFCuol0XHdzQOXBYrpw 1569 F5K+6DrpSWWeZ430WWVt6xKrJdoFknNcYUybJAIYHuXu+s6R0JmiDoZ+b15zp/jE 1570 nQLgI3PVNh3Lb23L3iPbFkNRiPbLLexJ4iHALlHgIKf60C+i2Roh9vr5oOw8CdWE 1571 bSXMkrAOzwdvwZ725I5aBmsQCmaBQHwj4G6MGOGkZ6rtqcyXtNTokshV3LEmZry9 1572 gdFSitwDw8fcJcxRZOWYuL6It7zupSsM4lo+a7RlSVvebLYI1yBDa4fpHkE30S4Y 1573 /OsIcO/OvuT2Gv/vDtmpiM+3yP8oSdHP+B8hbuZ/FI3gd/x/y/y/sMBovlDcIfpH 1574 qrB6MQfwzIH3gcomJj+f62wru/W88Nzxmsr3qNYkmwGZ3eXujLGus9lM9bmMUJqG 1575 hFPLnEG+ErsXpc4vy3bnH1laOZdrtQQ5S26IAVwXx9rJ4ojrdE0NyiXYr1sqlpc7 1576 zlhP6XJmhJAidNU2xSoQhmoxwbUd7Mp4mwALJnDerD2sqaJqlY6TCYlh80uX0IK0 1577 bHaXS6fwwAQsdMOsKrLE20oQeRrkrgmqqeHxbU8ywEfdIzYVvJiqs/HsUIjnZpoH 1578 62nXaFu1PSRtC829mTNpse16lyGdSqQe0a7Tqs06SS2cOYenDJvvxlJ8yDZznEAX 1579 +lmfjanNPMn3s4vDd9D4MM9zfdcNNy9CIdzzSWAf1tXyBJsVZ/m+iPeFI23EQuvJ 1580 mRouQCEA2umrRph4vo0jUDuHHSck0cQoMFVSk940bbnesWHcMedNzC3E9BRpdL7z 1581 Jb8VMjJbd5I00Jo7c2XHQGUIWWk72cwXdTdlgTFeYMEJwEa23RMUsU6quBT4+d4X 1582 wHrp83gx26QWMz5pdL0XrPGRFBBoShdeQK+LzHKdhPEceDLvdbWHeXBBImc708YO 1583 Z8oTjhFsR1ewoxDs5YCNXEcyiiGb4yBeDKvI6t10jBPqfhrl2crqKXc+P2GUx2xp 1584 C5mdI7uwkgaHibqe9/VE9vW9t50gnMmOD1AfsLhT7mZ1GrKdqDJb+1DqLMU1zL6k 1585 KDXpqlJjjoWQyvKqvgzjEHlxzXLn1GnqJLIciIJ9C4jhaSlIbU7Dp/NU4EyT4yy0 1586 VBPBqw1zvp8Zfnlapeezvl54ohbxRBJ0i7mKHj0VWu0KnCs24mV23uSxFkrz3rvs 1587 sf3lKF8km+/XzBzEu84jFlbxglQ/May+wPh/DD5n+H8b/g+Y/zz/x1ASv8Z/gibu 1588 8P+W8X/usJrCvQz90kYHiMRZe8lSggFshet0DwBCMgDPsZn56ZQAvYkTPislQG/i 1589 hM9KCdAbOeF5dH6807+0878gK+s+exfyz9v1H+wl/QcjrvUfCqXu4v+LoP+gOceB 1590 fPw2/cd7q/5jD+k6f7k++an+U0x3gcQQvi0YOmie1Es6wXJcZ5ELwVBBgq4LQddZ 1591 q23ZBHi6+3hqrrOEx9sA1W1wNniADb+zUdbXZdh1GfRSYede3iYgoLZu3qT1TwWE 1592 NQf5y/4US8Unaj/SBayfaz/bp92xyDKWxDaU+lLbGicosDm2unx80AQRgBmbm6BL 1593 VgV3LRqcKKlbcojNE/RU7dQyr9O8E3ULMmCyPayORBPL0j4pOi11xx6H18KMJPeH 1594 7JLiZyV0LbVgKmZWAmNq743c9eXzaXG8CKQILVF71SRTCxNBr4xRNOvOoGKwxXmc 1595 +jCcpPFEReb+eKqNUSKzGl92zaTadIRZwIv9pjQhSj6xk90+L0/nwxTfE02mDx4V 1596 APBnbDN075CD6EbOMQlBTEwHWY8XGkEvYTDn25BkoY1Vm95REAW46zbdjUiUs3LS 1597 RTV4rfKLuud0SS3Wuhj20As3rWxQuvZLT9sA6FNjeNrm11R149quk8ynz8sz2Qd6 1598 VfdphhrPdJ9p9tTFHxMWMW4gio4HN621IRY43dBnFr58wvN/rReabHZWZaWd2N5G 1599 Mja7auplZM5ll1m/XU1WUFJWk/Y8F/34vGdIWwpPNre8RDWruTuWH292i+XBgxWF 1600 bATKlYMADCmDu1WDdXcxQbvbQXNM9I85NmkZYh3zsoGd9pd8U8k5N8OIQsKnxw1m 1601 T5Cs3DErOeS7PnfEQzuhnKrkxucsgs6+HR+bJSkd6ROaPLrTfe7sdf5/B/LP2/Uf 1602 Gn/G/yg2zAWG+T9J3K3/fHH0n+SZ/sPBdcCutIU+z5viAPbLWSbNgdMrOLzF2ozO 1603 eiL095wNjqJHhlqcmBBdbfdHbSZvlLR3lb2NbRDKAUg5qzHDrTcqI9G6XbiBa2Rn 1604 UGorhxdy2ltqvMJt8LWsQZR4gMecSHcHkzkQxYn2sqna15HLcRHMp5zNSLuxy9fx 1605 RD5v97MlrDZVfMjOyiv6z5TeNKKiemqRL5N8UjTSrE0t3KpQpp9b3FmI2H4jbLF5 1606 TsPG5RKXGTwPZ34WIgU0Hag/rPYGtpGFWJFUmOkdtrePm8RcudP96SwLi4Y6eB6c 1607 2cSq2jItyiCkkJnMeic3BwWChwmCswKoeZASoMinteZql/2YUTVeWI9lMzhy2tQT 1608 x1RQIkJAstf6D4VTtQ6MHWL6OLRdLQUTO7ZbqVn1hWdtzmyATmxu1nHtGakidoER 1609 l/NsKmJGsLaYiXYZSz5GphtF6uCprEIVzwQzYTJxbvQfdmHtIiLYWuMtMVnAKN4u 1610 BAu08v4cGVnlIYUFL9JOPtDbQrYdvIB1SOzNtscJBZfUi7/u9QoBFKVazAm25KgS 1611 x/H8RkyRYtps0vN6csxabd6u+bDklqmgytAemPLWEdYnR8RcWTsEx0LTZonsHGTD 1612 x4hQ0U5EhJ99znXi9rw1wuPZ7lI1x4hOBAWYQRc471FhVxp42mljoynLdb1UyMnx 1613 dKRhsMdCPLzsfVdigwBH6UbmVolaIAGQ8KKb4dsMYnBY85Y2GkbZyt1t2VDmb0Z6 1614 u0sKMR/36yOZLIG1Io/5aSxy+hxZdr5MpnblHcetGkPzKR5hynSt9lJVUlmrLgxa 1615 ihcpM7dUpFgPabIYu4dTMyWMevcKwX5xNaDX8P/zl39+Nv2HvtF/cAK5w/9fCP3n 1616 zZQAvYkTPislQG/ihM9KCdAbOeFO/3kt/s/xw9Cv6ioL/fJ24x8d9p+t/6HUzfwP 1617 o+7W/27Fmmx3FdTBh0/hP+797a6MH9aH5PH1Ib/MwvjDZ2sDz46G9faxPyECIqSp 1618 mKIGvz3GcHTEroTHdnr82ghDR2IcjLDB0SOUuEKZKxIdSbr9+PH9u9TyCxz/N3tZ 1619 +znT/1vzPxQnnuu/GH2t/1IofZf/3YoNMTt6Eei7EMcffkK0jyxlDmMPkfuQm/lX 1620 z/7BtmaNUGbYe4g9JD4IDn4Vpo8uTCoRgVr5TRo16HCK7vcPxPrQ+YeouRrRQ4l4 1621 qLdXI7YORl9/M/5844PWTx75VDghw819yK6vRuC6kU/OeSMwPTltaNUER1CaJu5D 1622 vN/GV6NPBab7EOeX5QOFvxq9imvDASveX42ewtt9SHkaIlej908nT5j7x2JPIdMI 1623 1WmQIFzMZQoSSpvERY7gPAW0E+0Ke4IJqF0sxWkaTnibd8m+8jen+9DohXVqGxes 1624 sduESBMssWSj0hksLnRDO65mSsH4MjMLx1J6WpDT8RY9dmiMLVlr5cm4aE5V/ZWL 1625 7RgiWZ0WOp7yyByZoEtWSnqv9A1SE3elogoYWRHiRUvZ8NH7L/r0QKk2wyh/PW3b 1626 XXMFw6/75KVVom984JfJo0PjP2hSHx3Gqa7a4TIPtLhK2vRqhNxB/S8c/m/jpvGT 1627 +JbX/xDixfvfT+d/JE2Rd/h/h/+fC/5/Vmj/pUSwV+L/GsnfwT3eFv8I/Tz+UYq+ 1628 fv+TxO7e/7wds2SAfvWV3P+3H43wyQSJEBLD/dDHIprGJkwQ0tGEiTbUZnIdRhFK 1629 YCFxx/BfsvjPkiqObj3+sRff/2EIdq3/kiSN3sX/bdjf/88/PfroLz76q1/trA++ 1630 cv8r/Vf/4F//4c9+73ce/sr7H/6XlP3JN6n37P/0Fn7zwx/f//b+T3/w3z/86Nt/ 1631 /F72nX/52nb7/cd//R//Z2vE335v8oeP0t81mn//87/7LeV/t9U/Lv/G+43vfes7 1632 P/rwu3/0g5+Mgp9qP/m1n35zRnq//v0fndf0d3/0lwvovSr5t2/98+//5l0EfuHi 1633 /2Fchbcb/+Tz7z8wgkRu1n/Iu/n/rdjPK2JAP69wAf0sYsXdhOOdxX9WnbL23SwB 1634 vS3+SQR/Kf9Hb77/ou/i/1bs0xd5PmV16NVk+gpHCZRkRorhKvYnrQLhVwh2heA3 1635 q0Bv1xsenx4N2Xf9yGniAxgN6cf/t3M+oU2DYRgXDzIqBQ/qRZEgKMjEfEm+Jk2h 1636 k61da1tt0//dhI00bbbp2sY2aWcPDg8yUFB0iAdBvO2ygQdljFGcRy/W3TfEo4ce 1637 PPkPxLRj0m7rSpktbrw/ciiUhPLR5+nX53n5kBljE83Wv3R5CZeAiWaPMBpy1mAy 1638 l5vIpImgXTAaJGvLO1Qrqv7rT1lFLTGRITBPcTQRCAlkf0SoviFas6qSEhULIgTb 1639 tTBp1r+8+zwk2Kr/TlRALef/6s5/oDFX0z/Fgf67wYZgiW1C39T5LslfMx3tGASa 1640 NxK8VpnfZjbYkaSvwaN2yiWbNUV15rURE4qSaqn/dM2Woq+hMLp5wyfgochwLOVA 1641 MYbEgbDc72RluRCP+JOK1xkYKJrMcSbhvsUo2cEIHjc500HsYLWEPWBzYbKh48kG 1642 Pbw02Rty5LEprSG/RidIFBUEXz4vMe5oQQunrmRtBWfB1qtGOdkXTdsQ5/eM+dMY 1643 aYUxU8PDuKgYm5jyJ/MmL3LLmauxtI8J2zNaysy7A+Mxod+l0HlZdsfteLfCaIcV 1644 qD9XplllFLqt6MsuKoq+lqKqGzaZSyjb81gKc0aD0QA/DZ30/05UQC37/+37P8yC 1645 /4P/HwT/B5MD9pH/d6ICbDn/if7Of1IcVcv/OQTz312h1v9tzX4uWHWjSfKchJO6 1646 uTIUj2hGTMqYoylGkjAjsqJ+xVkJcaD+A6b/DlSAbfV/qHb+E0OB/rvCE+bR53tD 1647 I6I6Ov190Llyau7TuzdCcdZhP/3ja2n9/MKX+cGpmcdznrvFpY+rPQ8vL5wtZUdn 1648 T/7mX1SOLY9Nr0ply6+1taevllwz8xePrJAL1xc/DCuvK4dfDtzByz18RX724PiZ 1649 t7PquZ9HR3KLguXS87LLcaJ86H6+9O39ZB8o8H/U/7+tANvq/9jq/Hd1JwD67wZ7 1650 zaQMe82hDO1kT7DbAAAAAAAAAAAAAAAAAAAAAAAAAAAAaMYfe7L1egB4AAA= 1651 -- END MESSAGE ARCHIVE -- 1653 Appendix C. Original Requirements 1655 The following requirements were crafted throughout the development of 1656 the mechanism described in this document. They are preserved here 1657 for historical reasons. 1658 o The mechanism must allow a UAC or a proxy server to provide a 1659 strong cryptographic identity assurance in a request that can be 1660 verified by a proxy server or UAS. 1661 o User agents that receive identity assurances must be able to 1662 validate these assurances without performing any network lookup. 1663 o User agents that hold certificates on behalf of their user must be 1664 capable of adding this identity assurance to requests. 1665 o Proxy servers that hold certificates on behalf of their domain 1666 must be capable of adding this identity assurance to requests; a 1667 UAC is not required to support this mechanism in order for an 1668 identity assurance to be added to a request in this fashion. 1669 o The mechanism must prevent replay of the identity assurance by an 1670 attacker. 1672 o In order to provide full replay protection, the mechanism must be 1673 capable of protecting the integrity of SIP message bodies (to 1674 ensure that media offers and answers are linked to the signaling 1675 identity). 1676 o It must be possible for a user to have multiple AoRs (i.e. 1677 accounts or aliases) which it is authorized to use within a 1678 domain, and for the UAC to assert one identity while 1679 authenticating itself as another, related, identity, as permitted 1680 by the local policy of the domain. 1682 Appendix D. Changelog 1684 NOTE TO THE RFC-EDITOR: Please remove this section prior to 1685 publication as an RFC. 1687 Changes from draft-ietf-sip-identity-06: 1688 - Disambiguated 428 response code, added new 438 for invalid 1689 Identity headers 1690 - Used RFC2585 format for Identity-Info URIs 1691 - Updated example certificates to comply with RFC3280 1692 - Replaced certificate validation and mapping procedures with 1693 reference to RFC2818 1694 - Numerous editorial fixes 1696 Changes from draft-ietf-sip-identity-05: 1697 - Removed the requirements section 1698 - Numerous editorial fixes 1700 Changes from draft-ietf-sip-identity-04: 1701 - Changed the delimiter of the digest-string from ":" to "|" 1702 - Removed support for the SIPS URI scheme from the Identity-Info 1703 header 1704 - Made the Identity-Info header extensible; added an Identity-Info 1705 header for algorithm with an initial defined value of 'rsa-sha1' 1706 - Broke up the Security Considerations into smaller chunks for 1707 organizational reasons; expanded discussion of most issues 1708 - Added some guidelines for authentication service certificate 1709 rollover and lifecycle management (also now based HTTP certificate 1710 retrieval on RFC2585) 1712 Changes from draft-ietf-sip-identity-03: 1713 - Softened requirement for TLS and direct connections; now SHOULD- 1714 strength, SIPS and Digest auth-int listed as alternatives. 1715 - Added non-normative section about authentication service 1716 behavior for backwards-direction requests within a dialog 1717 - Added support for CID URI in Identity Info 1718 - Added new response codes (436 and 437) corresponding to error 1719 cases for an unsupported URI scheme and an unsupported 1720 certificate, respectively 1722 Changes from draft-ietf-sip-identity-02: 1723 - Extracted text relating to providing identity in SIP responses; 1724 this text will appear in a separate draft 1725 - Added compliance testing/example section 1726 - Added CSeq to the signature of the Identity header to prevent a 1727 specific cut-and-paste attack; also added addr-spec of the To 1728 header to the signature of the Identity header for similar reasons 1729 - Added text about why neither Via headers nor display-names are 1730 protected by this mechanism 1731 - Added bit-exact reference files for compliance testing 1732 - Added privacy considerations 1734 Changes from draft-ietf-sip-identity-01: 1735 - Completely changed underlying mechanism - instead of using an 1736 AIB, the mechanism now recommends the use of the Identity header 1737 and Identity-Info header 1738 - Numerous other changes resulting from the above 1739 - Various other editorial corrections 1741 Changes from draft-peterson-sip-identity-01: 1742 - Split off child draft-ietf-sip-authid-body-00 for defining of 1743 the AIB 1744 - Clarified scope in introduction 1745 - Removed a lot of text that was redundant with RFC3261 1746 (especially about authentication practices) 1747 - Added mention of content indirection mechanism for adding token 1748 to requests and responses 1749 - Improved Security Considerations (added piece about credential 1750 strength) 1752 Changes from draft-peterson-sip-identity-00: 1753 - Added a section on authenticated identities in responses 1754 - Removed hostname convention for authentication services 1755 - Added text about using 'message/sip' or 'message/sipfrag' in 1756 authenticated identity bodies, also RECOMMENDED a few more headers 1757 in sipfrags to increase reference integrity 1758 - Various other editorial corrections 1760 15. References 1761 15.1. Normative References 1763 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1764 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1765 Session Initiation Protocol", RFC 3261, June 2002. 1767 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 1768 levels", RFC 2119, March 1997. 1770 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 1771 Protocol (SIP)", RFC 3323, November 2002. 1773 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1774 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1776 [5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 1777 Identity Body (AIB) Format", RFC 3893, September 2004. 1779 [6] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 1780 RFC 2234, November 1997. 1782 [7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 1783 RFC 3370, August 2002. 1785 [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1786 RFC 3548, July 2003. 1788 [9] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1789 Public Key Infrastructure Certificate and Certificate 1790 Revocation List (CRL) Profile", RFC 3280, April 2002. 1792 [10] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1793 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, 1794 May 1999. 1796 [11] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. 1798 15.2. Informative References 1800 [12] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 1801 to the Session Initiation Protocol (SIP) for Asserted Identity 1802 within Trusted Networks", RFC 3325, November 2002. 1804 [13] Schulzrinne, H., "The TEL URI for Telephone Numbers", RFC 3966, 1805 December 2004. 1807 [14] Faltstrom, P. and M. Mealling, "The E.164 to URI DDDS 1808 Application", RFC 3761, April 2004. 1810 [15] Peterson, J., "Retargeting and Security in SIP: A Framework and 1811 Requirements", draft-peterson-sipping-retarget-00 (work in 1812 progress), February 2005. 1814 Authors' Addresses 1816 Jon Peterson 1817 NeuStar, Inc. 1818 1800 Sutter St 1819 Suite 570 1820 Concord, CA 94520 1821 US 1823 Phone: +1 925/363-8720 1824 Email: jon.peterson@neustar.biz 1825 URI: http://www.neustar.biz/ 1827 Cullen Jennings 1828 Cisco Systems 1829 170 West Tasman Drive 1830 MS: SJC-21/2 1831 San Jose, CA 95134 1832 USA 1834 Phone: +1 408 902-3341 1835 Email: fluffy@cisco.com 1837 Intellectual Property Statement 1839 The IETF takes no position regarding the validity or scope of any 1840 Intellectual Property Rights or other rights that might be claimed to 1841 pertain to the implementation or use of the technology described in 1842 this document or the extent to which any license under such rights 1843 might or might not be available; nor does it represent that it has 1844 made any independent effort to identify any such rights. Information 1845 on the procedures with respect to rights in RFC documents can be 1846 found in BCP 78 and BCP 79. 1848 Copies of IPR disclosures made to the IETF Secretariat and any 1849 assurances of licenses to be made available, or the result of an 1850 attempt made to obtain a general license or permission for the use of 1851 such proprietary rights by implementers or users of this 1852 specification can be obtained from the IETF on-line IPR repository at 1853 http://www.ietf.org/ipr. 1855 The IETF invites any interested party to bring to its attention any 1856 copyrights, patents or patent applications, or other proprietary 1857 rights that may cover technology that may be required to implement 1858 this standard. Please address the information to the IETF at 1859 ietf-ipr@ietf.org. 1861 Disclaimer of Validity 1863 This document and the information contained herein are provided on an 1864 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1865 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1866 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1867 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1868 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1871 Copyright Statement 1873 Copyright (C) The Internet Society (2005). This document is subject 1874 to the rights, licenses and restrictions contained in BCP 78, and 1875 except as set forth therein, the authors retain all their rights. 1877 Acknowledgment 1879 Funding for the RFC Editor function is currently provided by the 1880 Internet Society.