idnits 2.17.1 draft-ietf-sip-identity-05.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1830. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 20 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 703 has weird spacing: '... where prox...' == Line 711 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 (March 2005) is 6975 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) == Unused Reference: '9' is defined on line 1540, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3548 (ref. '8') (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '9') (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 3761 (ref. '13') (Obsoleted by RFC 6116, RFC 6117) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 11 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: September 2, 2005 C. Jennings 5 Cisco Systems 6 March 2005 8 Enhancements for Authenticated Identity Management in the Session 9 Initiation Protocol (SIP) 10 draft-ietf-sip-identity-05 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 2, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 The existing security mechanisms in the Session Initiation Protocol 46 are inadequate for cryptographically assuring the identity of the end 47 users that originate SIP requests, especially in an interdomain 48 context. This document defines a mechanism for securely identifying 49 originators of SIP messages. It does so by defining two new SIP 50 header fields, Identity, for conveying a signature used for 51 validating the identity, and Identity-Info, for conveying a reference 52 to the certificate of the signer. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Overview of Operations . . . . . . . . . . . . . . . . . . . 6 61 6. Authentication Service Behavior . . . . . . . . . . . . . . 7 62 6.1 Identity within a Dialog and Retargeting . . . . . . . . . 10 63 7. Verifier Behavior . . . . . . . . . . . . . . . . . . . . . 10 64 8. Considerations for User Agent . . . . . . . . . . . . . . . 12 65 9. Considerations for Proxy Server . . . . . . . . . . . . . . 13 66 10. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 67 11. Compliance Tests and Examples . . . . . . . . . . . . . . . 16 68 11.1 Identity-Info with a Singlepart MIME body . . . . . . . 16 69 11.2 Identity for a Request with no MIME body or Contact . . 19 70 12. Identity and the TEL URI Scheme . . . . . . . . . . . . . . 22 71 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 72 14. Security Considerations . . . . . . . . . . . . . . . . . . 24 73 14.1 Handling of digest-string Elements . . . . . . . . . . . 24 74 14.2 Display Names and Identity . . . . . . . . . . . . . . . 26 75 14.3 Securing the Connection to the Authentication Service . 27 76 14.4 Domain Names and Subordination . . . . . . . . . . . . . 28 77 14.5 Authorization and Transitional Strategies . . . . . . . 30 78 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 79 15.1 Header Field Names . . . . . . . . . . . . . . . . . . . 31 80 15.2 428 'Use Identity Header' Response Code . . . . . . . . 31 81 15.3 436 'Bad Identity-Info' Response Code . . . . . . . . . 31 82 15.4 437 'Unsupported Certificate' Response Code . . . . . . 32 83 15.5 Identity-Info Parameters . . . . . . . . . . . . . . . . 32 84 15.6 Identity-Info Algorithm Parameter Values . . . . . . . . 32 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 86 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 34 87 B. Bit-exact archive of example messages . . . . . . . . . . . 34 88 B.1 Encoded Reference Files . . . . . . . . . . . . . . . . . 35 89 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 16.1 Normative References . . . . . . . . . . . . . . . . . . 33 91 16.2 Informative References . . . . . . . . . . . . . . . . . 33 92 C. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . 37 93 Intellectual Property and Copyright Statements . . . . . . . 40 95 1. Introduction 97 This document provides enhancements to the existing mechanisms for 98 authenticated identity management in the Session Initiation Protocol 99 (SIP [1]). An identity, for the purposes of this document, is 100 defined as a SIP URI, commonly a canonical AoR employed to reach a 101 user (such as 'sip:alice@atlanta.example.com'). 103 RFC3261 stipulates several places within a SIP request where a user 104 can express an identity for themselves, notably the user-populated 105 From header field. However, the recipient of a SIP request has no 106 way to verify that the From header field has been populated 107 appropriately, in the absence of some sort of cryptographic 108 authentication mechanism. 110 RFC3261 specifies a number of security mechanisms that can be 111 employed by SIP UAs, including Digest, TLS and S/MIME 112 (implementations may support other security schemes as well). 113 However, few SIP user agents today support the end-user certificates 114 necessary to authenticate themselves (via S/MIME, for example), and 115 furthermore Digest authentication is limited by the fact that the 116 originator and destination must share a pre-arranged secret. It is 117 desirable for SIP user agents to be able to send requests to 118 destinations with which they have no previous association - just as 119 in the telephone network today, one can receive a call from someone 120 with whom one has no previous association, and still have a 121 reasonable assurance that their displayed Caller-ID is accurate. 123 2. Terminology 125 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 126 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 127 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 128 described in RFC2119 [2] and indicate requirement levels for 129 compliant SIP implementations. 131 3. Background 133 The usage of many SIP applications and services is governed by 134 authorization policies. These policies may be automated, or they may 135 be applied manually by humans. An example of the latter would be an 136 Internet telephone application which displays the "Caller-ID" of a 137 caller, which a human may review before answering a call. An example 138 of the former would be a presence service that compares the identity 139 of potential subscribers to a whitelist before determining whether it 140 should accept or reject the subscription. In both of these cases, 141 attackers might attempt to circumvent these authorization policies 142 through impersonation. Since the primary identifier of the sender of 143 a SIP request, the From header field, can be populated arbitrarily by 144 the controller of a user agent, impersonation is very simple today. 145 The mechanism described in this document aspires to provide a strong 146 identity system for SIP in which authorization policies cannot be 147 circumvented by impersonation. 149 All RFC3261 compliant user agents support Digest authentication, 150 which utilizes a shared secret, as a means for authenticating 151 themselves to a SIP registrar. Registration allows a user agent to 152 express that it is an appropriate entity to which requests should be 153 sent for a particular address-of-record SIP URI (e.g., 154 'sip:alice@atlanta.example.com'). 156 By the definition of identity used in this document, registration is 157 a proof of the identity of the user to a registrar. However, the 158 credentials with which a user agent proves their identity to a 159 registrar cannot be validated by just any user agent or proxy server 160 - these credentials are only shared between the user agent and their 161 domain administrator. So this shared secret does not immediately 162 help a user to authenticate to a wide range of recipients. 163 Recipients require a means of determining whether or not the 'return 164 address' identity of a non-REGISTER request (i.e., the From header 165 field value) has legitimately been asserted. 167 The address-of-record URI used for registration is also the URI with 168 which a UA commonly populates the From header field of requests in 169 order to provide a 'return address' identity to recipients. From an 170 authorization perspective, if you are can prove you are eligible to 171 register in a domain under a particular address-of-record, you can 172 prove you can legitimately receive requests for that address-of- 173 record, and accordingly, when you place that address-of-record in the 174 From header field of a SIP request other than a registration (like an 175 INVITE), you are providing a 'return address' where you can 176 legitimately be reached. In other words, if you are authorized to 177 receive requests for that 'return address', logically, it follows 178 that you are also authorized to assert that 'return address' in your 179 From header field. This is of course only one manner in which a 180 domain might determine how a particular user is authorized to 181 populate the From header field; as an aside, for other sorts of URIs 182 in the From (like anonymous URIs), other authorization policies would 183 apply. 185 Ideally, then, SIP user agents should have some way of proving to 186 recipients of SIP requests that their local domain has authenticated 187 them and authorized the population of the From header field. This 188 document proposes a mediated authentication architecture for SIP in 189 which requests are sent to a server in the user's local domain, which 190 authenticates such requests (using the same practices by which the 191 domain would authenticate REGISTER requests). Once a message has 192 been authenticated, the local domain then needs some way to 193 communicate to other SIP entities that the sending user has been 194 authenticated and their use of the From header field has been 195 authorized. This draft addresses how that imprimatur of 196 authentication can be shared. 198 RFC3261 already describes an architecture very similar to this in 199 Section 26.3.2.2, in which a user agent authenticates itself to a 200 local proxy server which in turn authenticates itself to a remote 201 proxy server via mutual TLS, creating a two-link chain of transitive 202 authentication between the originator and the remote domain. While 203 this works well in some architectures, there are a few respects in 204 which this is impractical. For one, transitive trust is inherently 205 weaker than an assertion that can be validated end-to-end. It is 206 possible for SIP requests to cross multiple intermediaries in 207 separate administrative domains, in which case transitive trust 208 becomes even less compelling. 210 One solution to this problem is to use 'trusted' SIP intermediaries 211 that assert an identity for users in the form of a privileged SIP 212 header. A mechanism for doing so (with the P-Asserted-Identity 213 header) is given in [10]. However, this solution allows only hop-by- 214 hop trust between intermediaries, not end-to-end cryptographic 215 authentication, and it assumes a managed network of nodes with strict 216 mutual trust relationships, an assumption that is incompatible with 217 widespread Internet deployment. 219 Accordingly, this document specifies a means of sharing a 220 cryptographic assurance of end-user SIP identity in an interdomain or 221 intradomain context which is based on the concept of an 222 'authentication service' and a new SIP header, the Identity header. 223 Note that the scope of this document is limited to providing this 224 identity assurance for SIP requests; solving this problem for SIP 225 responses is more complicated, and is a subject for future work. 227 This specification allows either a user agent or a proxy server to 228 provide identity services and to verify identities. To maximize end- 229 to-end security, it is obviously preferable for end users to hold 230 their own certificates; if they do, they can act as an authentication 231 service. However, end-user certificates may be neither practical nor 232 affordable, given the difficulties of establishing a PKI that extends 233 to end users, and moreover, given the potentially large number of SIP 234 user agents (phones, PCs, laptops, PDAs, gaming devices) that may be 235 employed by a single user. In such environments, synchronizing 236 certificates across multiple devices may be very complex, and 237 requires quite a good deal of additional endpoint behavior. Managing 238 several certificates for the various devices is also quite 239 problematic and unpopular with users. Accordingly, in the initial 240 use of this mechanism, it is likely that intermediaries will 241 instantiate the authentication service role. 243 4. Requirements 245 This draft addresses the following requirements: 246 o The mechanism must allow a UAC or a proxy server to provide a 247 strong cryptographic identity assurance in a request that can be 248 verified by a proxy server or UAS. 249 o User agents that receive identity assurances must be able to 250 validate these assurances without performing any network lookup. 251 o User agents that hold certificates on behalf of their user must be 252 capable of adding this identity assurance to requests. 253 o Proxy servers that hold certificates on behalf of their domain 254 must be capable of adding this identity assurance to requests; a 255 UAC is not required to support this mechanism in order for an 256 identity assurance to be added to a request in this fashion. 257 o The mechanism must prevent replay of the identity assurance by an 258 attacker. 259 o In order to provide full replay protection, the mechanism must be 260 capable of protecting the integrity of SIP message bodies (to 261 ensure that media offers and answers are linked to the signaling 262 identity). 263 o It must be possible for a user to have multiple AoRs (i.e. 264 accounts or aliases) which it is authorized to use within a 265 domain, and for the UAC to assert one identity while 266 authenticating itself as another, related, identity, as permitted 267 by the local policy of the domain. 269 5. Overview of Operations 271 This section provides an informative (non-normative) high-level 272 overview of the mechanisms described in this document. 274 Imagine the case where Alice, who has the home proxy of example.com 275 and the address-of-record sip:alice@example.com, wants to communicate 276 with sip:bob@example.org. 278 Alice generates an INVITE and places her identity in the From header 279 field of the request. She then sends an INVITE over TLS to an 280 authentication service proxy for her domain. 282 The authentication service authenticates Alice (possibly by sending a 283 Digest authentication challenge) and validates that she is authorized 284 to assert the identity which is populated in the From header field. 285 This value may be Alice's AoR, or it may be some other value that the 286 policy of the proxy server permits her to use. It then computes a 287 hash over some particular headers, including the From header field 288 and the bodies in the message. This hash is signed with the 289 certificate for the domain (example.com, in Alice's case) and 290 inserted in a new header field in the SIP message, the 'Identity' 291 header. 293 The proxy, as the holder the private key of its domain, is asserting 294 that the originator of this request has been authenticated and that 295 she is authorized to claim the identity (the SIP address-of-record) 296 which appears in the From header field. The proxy also inserts a 297 companion header field, Identity-Info, that tells Bob how to acquire 298 its certificate, if he doesn't already have it. 300 When Bob's domain receives the request, it verifies the signature 301 provided in the Identity header, and thus can validates that the 302 domain indicated by the host portion of the AoR in the From header 303 field authenticated the user, and permitted them to assert that From 304 header field value. This same validation operation may be performed 305 by Bob's UAS. 307 6. Authentication Service Behavior 309 This document defines a new role for SIP entities called an 310 authentication service. The authentication service role can be 311 instantiated by a proxy server or a user agent. Any entity that 312 instantiates the authentication service role MUST possess the private 313 key of a domain certificate, and MUST be capable of authenticating 314 one or more SIP users that can register in that domain. Commonly, 315 this role will be instantiated by a proxy server, since these 316 entities are more likely to have a static hostname, hold a 317 corresponding certificate, and have access to SIP registrar 318 capabilities that allow them to authenticate users in their domain. 319 It is also possible that the authentication service role might be 320 instantiated by an entity that acts redirect server, but that is left 321 as a topic for future work. 323 SIP entities that act as an authentication service MUST add a Date 324 header field to SIP requests if one is not already present. 325 Similarly, authentication services MUST add a Content-Length header 326 field to SIP requests if one is not already present; this can help 327 the verifier to double-check that they are hashing exactly as many 328 bytes of message-body as the authentication service when they verify 329 the message. 331 Entities instantiating the authentication service role performs the 332 following steps, in order, to generate an Identity header for a SIP 333 request: 335 Step 1: The authentication service MUST extract the identity of the 336 sender from the request. The authentication service takes this value 337 from the From header field; this AoR will be referred to here as the 338 'identity field'. If the identity field contains a SIP or SIPS URI, 339 the authentication service MUST extract the hostname portion of the 340 identity field and compare it to the domain(s) for which it is 341 responsible. If the identity field uses the TEL URI scheme, the 342 policy of the authentication service determines whether or not it is 343 responsible for this identity; see Section 12 for more information. 344 If the authentication service is not responsible for the identity in 345 question, it SHOULD process and forward the request normally, but it 346 MUST NOT add an Identity header; see below for more information on 347 authentication service handling of an existing Identity header. 349 Step 2: The authentication service MUST determine whether or not the 350 sender of the request is authorized to claim the identity given in 351 the identity field. In order to do so, the authentication service 352 MUST authenticate the sender of the message. Some possible ways in 353 which this authentication might be performed include: 354 If the authentication service is instantiated by a SIP 355 intermediary (proxy server), it may challenge the request with a 356 407 response code using the Digest authentication scheme (or 357 viewing a Proxy-Authentication header sent in the request which 358 was sent in anticipation of a challenge using cached credentials, 359 as described in RFC 3261 Section 22.3). Note that if that proxy 360 server is maintaining a TLS connection with the client over which 361 the client had previously authenticated itself using Digest 362 authentication, the identity value obtained from that previous 363 authentication step can be reused without an additional Digest 364 challenge. 365 If the authentication service is instantiated by a SIP user agent, 366 a user agent can be said to authenticate its user on the grounds 367 that the user can provision the user agent with the private key of 368 the domain, or by preferably by providing a password that unlocks 369 said private key. 371 Authorization of the use of a particular username in the From header 372 field is a matter of local policy for the authentication service, one 373 which depends greatly on the manner in which authentication is 374 performed. For example, one policy might be as follows: the username 375 given in the 'username' parameter of the Proxy-Authorization header 376 MUST correspond exactly to the username in the From header field of 377 the SIP message. However, there are many cases in which this is too 378 limiting or inappropriate; a realm might use 'username' parameters in 379 Proxy-Authorization which do not correspond to the user-portion of 380 SIP From headers, or a user might manage multiple accounts in the 381 same administrative domain. In this latter case, a domain might 382 maintain a mapping between the values in the 'username' parameter of 383 Proxy-Authorization and a set of one or more SIP URIs which might 384 legitimately be asserted for that 'username'. For example, the 385 username can correspond to the 'private identity' as defined in 3GPP, 386 in which case the From header field can contain any one of the public 387 identities associated with this private identity. In this instance, 388 another policy might be as follows: the URI in the From header field 389 MUST correspond exactly to one of the mapped URIs associated with the 390 'username' given in the Proxy-Authorization header. Various 391 exceptions to such policies might arise for cases like anonymity; if 392 the AoR asserted in the From header field uses a form like 393 'sip:anonymous@example.com', then the 'example.com' proxy should 394 authenticate that the user is a valid user in the domain and insert 395 the signature over the From header field as usual. 397 Note that this check is performed on the addr-spec in the From header 398 field (e.g., the URI of the sender, like 399 'sip:alice@atlanta.example.com'); it does not convert the display- 400 name portion of the From header field (e.g., 'Alice Atlanta'). 401 Authentication services MAY check and validate the display-name as 402 well, and compare it to a list of acceptable display-names that may 403 be used by the sender; if the display-name does not meet policy 404 constraints, the authentication service MUST return a 403 response 405 code with the reason phrase "Inappropriate Display-Name". However, 406 the display-name is not always present, and in many environments the 407 requisite operational procedures for display-name validation may not 408 exist. For more information, see Section 14.2. 410 Step 3: The authentication service SHOULD ensure that any pre- 411 existing Date header in the request is accurate. Local policy can 412 dictate precisely how accurate the Date must be, a RECOMMENDED 413 maximum discrepancy of ten minutes will ensure that the request is 414 unlikely to upset any verifiers. If the Date header contains a time 415 different by more than ten minutes from the current time noted by the 416 authentication service, the authentication service SHOULD reject the 417 request. This behavior is not mandatory because a user agent client 418 could only exploit the Date header in order to cause a request to 419 fail verification; the Identity header is not intended to provide a 420 source of non-repudiation or a perfect record of when messages are 421 processed. 423 Step 4: The authentication service MUST form the identity signature 424 and add an Identity header to the request containing this signature. 425 After the Identity header has been added to the request, the 426 authentication service MUST also add an Identity-Info header. The 427 Identity-Info header contains a URI from which its certificate can be 428 acquired. Details on the generation of both of these headers are 429 provided in section Section 10. 431 Finally, the authentication service MUST forward the message 432 normally. 434 6.1 Identity within a Dialog and Retargeting 436 Retargeting is defined as the alteration of the Request-URI by 437 intermediaries in order to point to another URI that corresponds to a 438 user that cannot authenticate itself with the identity originally 439 present in the Request-URI. By this definition, retargeting excludes 440 translation of the Request-URI to a registered contact of an endpoint 441 that has authenticated itself as that user. 443 When a dialog-forming request is retargeted, this can cause a few 444 wrinkles for the Identity mechanism when it is applied to requests 445 sent in the backwards direction within a dialog. This section 446 provides some non-normative considerations related to this case. 448 When a request is retargeted, it may reach a SIP endpoint whose user 449 is not identified by the URI designated in the To header field value. 450 The value in the To header field of a dialog-forming request is used 451 as the From header field of requests sent in the backwards direction 452 during the dialog, and is accordingly the header that would be signed 453 by an authentication service for requests sent in the backwards 454 direction. In retargeting cases, if the URI in the From header does 455 not identify the sender of the request in the backwards direction, 456 then clearly it would be inappropriate to provide an Identity 457 signature over that From header. As specified above, if the 458 authentication service is not responsible for the domain in the From 459 header field of the request, it must not add an Identity header to 460 the request, and should process/forward the request normally. 462 Any means of anticipating retargeting and so on is outside the scope 463 of this document, and likely to have equal applicability to response 464 identity as it does to requests in the backwards direction within a 465 dialog. Consequently, no special guidance is given for implementers 466 here regarding the 'connected party' problem; authentication service 467 behavior is unchanged if retargeting has occurred for a dialog- 468 forming request. Ultimately, the authentication service provides an 469 Identity header for requests in the backwards dialog when the user is 470 authorized to assert the identity given in the From header field, and 471 if they are not, an Identity header is not provided. 473 For further information on the problems of response identity and the 474 potential solution spaces, see [14]. 476 7. Verifier Behavior 478 This document introduces a new logical role for SIP entities called a 479 'verifier', which may be instantiated by a user agent or proxy 480 server. When a verifier receives a SIP message containing an 481 Identity header, it may inspect the signature to verify the identity 482 of the sender of the message. Typically, the results of a 483 verification are provided as input to an authorization process which 484 is outside the scope of this document. If an Identity header is not 485 present in a request, and one is required by local policy (for 486 example, based on a per-sending-domain policy, or a per-sending-user 487 policy), then a 428 'Use Identity Header' response MUST be sent. 489 In order to verify the identity of the sender of a message, an entity 490 acting as a verifier MUST perform the following steps, in the order 491 here specified. 493 Step 1: The verifier MUST acquire the certificate for the signing 494 domain. Implementations supporting this specification SHOULD have 495 some means of retaining domain certificates (in accordance with 496 normal practices for certificate lifetimes and revocation) in order 497 to prevent themselves from needlessly downloading the same 498 certificate every time a request from the same domain is received. 499 Certificates cached in this manner should be indexed by the URI given 500 in the Identity-Info header field value. 502 Provided that the domain certificate used to sign this message is not 503 previously known to the recipient, SIP entities SHOULD discover this 504 certificate by dereferencing the Identity-Info header, unless they 505 have some more efficient implementation-specific way of acquiring 506 certificates for that domain. If the URI scheme in the Identity-Info 507 header cannot be dereferenced, then a 436 'Bad Identity-Info' 508 response MUST be returned. The client processes this certificate in 509 the usual ways, including checking that it has not expired, that the 510 chain is valid back to a trusted CA, and that it does not appear on 511 revocation lists. Once the certificate is acquired, it MUST be 512 validated. If the certificate cannot be validated (it is self-signed 513 and untrusted, or signed by an untrusted or unknown certificate 514 authority, expired, or revoked), the verifier MUST send a 437 515 'Unsupported Certificate' response. 517 Step 2: The verifier MUST compare the identity of the signer with the 518 domain portion of the URI in the From header field. The verifier 519 MUST follow the process described in Section 14.4 to determine if the 520 signer is authoritative for the URI in the From header field. 522 Step 3: The verifier MUST verify the signature in the Identity header 523 field, following the procedures for generating the hashed digest- 524 string described in Section 10. If a verifier determines that the 525 signature on the message does not correspond to the reconstructed 526 digest-string, then a 428 'Invalid Identity Header' response MUST be 527 returned. 529 Step 4: The verifier MUST validate the Date, Contact and Call-ID 530 headers the manner described in Section 14.1; recipients that wish to 531 verify Identity signatures MUST support all of the operations 532 described there. 534 8. Considerations for User Agent 536 This mechanism can be applied opportunistically to existing SIP 537 deployments; accordingly, it requires no change to SIP user agent 538 behavior in order for it to be effective. However, because this 539 mechanism does not provide integrity protection between the UAC and 540 the authentication service, a UAC SHOULD implement some means of 541 providing this integrity. TLS would be one such mechanism, which is 542 attractive because it MUST be supported by SIP proxy servers, but is 543 potentially problematic because it is a hop-by-hop mechanism. See 544 Section 14.3 for more information about securing the channel between 545 the UAC and the authentication service. 547 When a UAC sends a request, it MUST accurately populate the From 548 header field with a value corresponding to an identity that it 549 believes it is authorized to claim. In a request it MUST set the URI 550 portion of its From header to match a SIP, SIPS or TEL URI AoR which 551 it is authorized to use in the domain (including anonymous URIs, as 552 described in RFC 3323 [3]). In general, UACs SHOULD NOT use the TEL 553 URI form in the From header field (see Section 12). 555 Note that this document defines a number of new 4xx response codes. 556 If user agents support these response codes, they will be able to 557 respond intelligently to Identity-based error conditions. 559 The UAC MUST also be capable of sending requests, including mid-call 560 requests, through an 'outbound' proxy (the authentication service). 561 The best way to accomplish this is using pre-loaded Route headers and 562 loose routing. For a given domain, if an entity that can instantiate 563 the authentication service role is not in the path of dialog-forming 564 requests, identity for mid-dialog requests in the backwards direction 565 cannot be provided. 567 As a recipient of a request, a user agent that can verify signed 568 identities should also support an appropriate user interface to 569 render the validity of identity to a user. User agent 570 implementations SHOULD differentiate signed From header field values 571 from unsigned From header field values when rendering to an end user 572 the identity of the sender of a request. 574 9. Considerations for Proxy Server 576 Domain policy may require proxy servers to inspect and verify the 577 identity provided in SIP requests. A proxy server may wish to 578 ascertain the identity of the sender of the message to provide spam 579 prevention or call control services. Even if a proxy server does not 580 act as an authentication service, it MAY validate the Identity header 581 before it makes a forwarding decision for a request. Proxy servers 582 MUST NOT remove or modify an existing Identity or Identity-Info 583 header in a request. 585 10. Header Syntax 587 This document specifies two new SIP headers: Identity and Identity- 588 Info. Each of these headers can appear only once in a SIP message. 589 The grammar for these two headers is: 591 Identity = "Identity" HCOLON signed-identity-digest 592 signed-identity-digest = LDQUOT 32LHEX RDQUOT 594 Identity-Info = "Identity-Info" HCOLON ident-info (* SEMI identi-info-params ) 595 ident-info = LAQUOT absoluteURI RAQUOT 596 ident-info-params = ident-info-alg / ident-info-extension 597 ident-info-alg = "alg" EQUAL token 598 ident-info-extension = generic-param 600 The signed-identity-digest is a signed hash of a canonical string 601 generated from certain components of a SIP request. To create the 602 contents of the signed-identity-digest, the following elements of a 603 SIP message MUST placed in a bit-exact string in the order specified 604 here, separated by a vertical line, "|" or %x7C, character: 605 o The AoR of the UA sending the message, or addr-spec of the From 606 header field (referred to occasionally here as the 'identity 607 field'). 608 o The addr-spec component of the To header field, which is the AoR 609 to which the request is being sent. 610 o The callid from Call-Id header field. 611 o The digit (1*DIGIT) and method (method) portions from CSeq header 612 field, separated by a single space (ABNF SP, or %x20). Note that 613 the CSeq header field allows LWS rather than SP to separate the 614 digit and method portions, and thus the CSeq header field may need 615 to be transformed in order to be canonicalized. The 616 authentication service MUST strip leading zeros from the 'digit' 617 portion of the Cseq before generating the digest-string. 618 o The Date header field, with exactly one space each for each SP and 619 the weekday and month items case set as shown in BNF in 3261. RFC 620 3261 specifies that the BNF for weekday and month are a choice 621 amongst a set of tokens. The RFC 2234 rules for the BNF specify 622 that tokens are case sensitive. However, when used to construct 623 the canonical string defined here, the first letter of each week 624 and month MUST be capitalized, and the remaining two letter must 625 be lowercase. This matches the capitalization provided in the 626 definition of each token. All requests that use the Identity 627 mechanism MUST contain a Date header. 628 o The addr-spec component of the Contact header field value. If the 629 request does not contain a Contact header, this field MUST be 630 empty (i.e., there will be no whitespace between the fourth and 631 fifth "|" characters in the canonical string). 632 o The body content of the message with the bits exactly as they are 633 in the Message (in the ABNF for SIP, the message-body). This 634 includes all components of multipart message bodies. Note that 635 the message-body does NOT include the CRLF separating the SIP 636 headers from the message-body, but does include everything that 637 follows that CRLF. If the message has no body, then message-body 638 will be empty, and the final "|" will not be followed by any 639 additional characters. 641 For more information on the security properties of these headers, and 642 why their inclusion mitigates replay attacks, see Section 14 and [5]. 643 The precise formulation of this digest-string is, therefore 644 (following the ABNF [6] in RFC3261): 646 digest-string = addr-spec "|" addr-spec "|" callid "|" 1*DIGIT SP method "|" 647 SIP-Date "|" [ addr-spec ] "|" message-body 649 Note again that the first addr-spec MUST be taken from the From 650 header field value, the second addr-spec MUST be taken from the To 651 header field value, and the third addr-spec MUST be taken from the 652 Contact header field value, provided the Contact header is present in 653 the request. 655 After the digest-string is formed, it MUST be hashed and signed with 656 the certificate for the domain. The hashing and signing algorithm is 657 specified by the 'alg' parameter of the Identity-Info header (see 658 below for more information on Identity-Info header parameters). This 659 document defines only one value for the 'alg' parameter: 'rsa-sha1'; 660 further values MUST be defined in a Standards Track RFC, see 661 Section 15.6 for more information. It is MANDATORY for all 662 implementations of this specification to support 'rsa-sha1'. When 663 the 'rsa-sha1' algorithm is specified in the 'alg' parameter of 664 Identity-Info, the hash and signature MUST be generated as follows: 665 compute the results of signing this string with sha1WithRSAEncryption 666 as described in RFC 3370 [7] and base64 encode the results as 667 specified in RFC 3548 [8]. A 1024 bit or longer RSA key MUST be 668 used. The result in placed int the Identity header field. For 669 detailed examples of the usage of this algorithm, see Section 11. 671 Note on the use of 'rsa-sha1': The raw signature will result in about 672 170 octets of base64 encoded data (without base64, as an aside, it 673 would be about 130 bytes). For comparison's sake, a typical HTTP 674 Digest Authorization header (such as those used in RFC3261) with no 675 cnonce is around 180 octets. From a speed point of view, a 2.8GHz 676 Intel processor does somewhere in the range of 250 RSA 1024 bits 677 signs per second or 1200 RSA 512 bits signs; verifies are roughly 10 678 times faster. Hardware accelerator cards are available that speed 679 this up. 681 The 'absoluteURI' portion of the Identity-Info header MUST contain 682 either an HTTP or HTTPS URI which dereferences to a resource that 683 contains a single MIME body containing the certificate of the 684 authentication service. These URIs MUST follow the conventions of 685 RFC2585 [11] and the indicated resource MUST be of the form 686 'application/pkix-cert' described in that specification. Note that 687 this introduces key lifecycle management concerns; were a domain to 688 change the key available at the Identity-Info URI before a verifier 689 evaluates a request signed by an authentication service, this would 690 cause obvious verifier failures. When a rollover occurs, 691 authentication services SHOULD thus provide new Identity-Info URIs 692 for each new certificate, and SHOULD continue to make older key 693 acquisition URIs available for a duration longer than the plausible 694 lifetime of a SIP message (an hour would most likely suffice). 696 The Identity-Info header field MUST contain an 'alg' parameter. No 697 other parameters are defined for the Identity-Info header in this 698 document. Future Standards Track RFCs may define additional 699 Identity-Info header parameters. 701 This document adds the following entries to Table 2 of [1]: 703 Header field where proxy ACK BYE CAN INV OPT REG 704 ------------ ----- ----- --- --- --- --- --- --- 705 Identity R a o o - o o o 707 SUB NOT REF INF UPD PRA 708 --- --- --- --- --- --- 709 o o o o o o 711 Header field where proxy ACK BYE CAN INV OPT REG 712 ------------ ----- ----- --- --- --- --- --- --- 713 Identity-Info R a o o - o o o 715 SUB NOT REF INF UPD PRA 716 --- --- --- --- --- --- 717 o o o o o o 719 Note, in the table above, that this mechanism does not protect the 720 CANCEL method. The CANCEL method cannot be challenged, because it is 721 hop-by-hop, and accordingly authentication service behavior for 722 CANCEL would be significantly limited. Note as well that the 723 REGISTER method uses Contact header fields in very unusual ways that 724 complicate its applicability to this mechanism, and the use of 725 Identity with REGISTER is consequently a subject for future study, 726 although it is left as optional here for forward-compatibility 727 reasons. The Identity and Identity-Info header MUST NOT appear in 728 CANCEL. 730 11. Compliance Tests and Examples 732 The examples in this section illustrate the use of the Identity 733 header in the context of a SIP transaction. Implementers are advised 734 to verify their compliance with the specification against the 735 following criteria: 736 o Implementations of the authentication service role MUST generate 737 identical base64 identity strings to the ones shown in the 738 Identity headers in these examples when presented with the source 739 message and utilizing the appropriate supplied private key for the 740 domain in question. 741 o Implementations of the verifier role MUST correctly validate the 742 given messages containing the Identity header when utilizing the 743 supplied certificates (with the caveat about self-signed 744 certificates below). 746 Note that the following examples use self-signed certificates, rather 747 than certificates issued by a recognized certificate authority. The 748 use of self-signed certificates for this mechanism is NOT 749 RECOMMENDED, and it appears here only for illustrative purposes. 750 Therefore, in compliance testing, implementations of verifiers SHOULD 751 generated appropriate warnings about the use of self-signed 752 certificates. Also, the example certificates in this section have 753 placed their domain name subject in the subjectAltName field; in 754 practice, certificate authorities may place domain names in other 755 locations in the certificate (see Section 14.4 for more information). 757 Note that all examples in this section use the 'rsa-sha1' algorithm. 759 Bit-exact reference files for these messages and their various 760 transformations are supplied in Appendix B. 762 11.1 Identity-Info with a Singlepart MIME body 764 Consider the following private key and certificate pair assigned to 765 'atlanta.example.com'. 767 -----BEGIN RSA PRIVATE KEY----- 768 MIICXQIBAAKBgQC8HmM8b9E4WNhb7tZAoBVSkKyV9rAEX3nyQbg4hXte1oW1BxC+ 769 43MQHrG3nk6Kc9afPR6VloKwWoUoAcCnbTJ/zEiZ6dq+C5EsQGIOowYkSgqdO2po 770 joCnRgzgjgvAl41R2J6CE1kMwOQxNCxPnTco8l8UGdKbNLXIuNdUM1MG8QIDAQAB 771 AoGAAtPOGAVyNo+XSOJxE+2UBHaqMWLQyHAK7Coys57F+OnufocJqGTQwOhFMYZO 772 leQh0KjhgcwOUMo7gBtuotWQUbbLHTGKXiBR6Pqbm6CvhwJSuNYv0vONuTb1SMll 773 Kadg43na4B9kQeytn1y6lfkTkK2oYqkDVZ2AAmLSLrfhl1UCQQDp7VFItgmnybwK 774 PKwJs8gnF+u+K9j+sac/3vgGgrOvpxVqwoMXl6eWN//pZ/cqshanDLmtr9ahjWCD 775 DxYVyklrAkEAzd6JLJAhG8cZymVCS5Jf0F7FAVxpx0BgRPHwJliyUg6O4jPY+ASg 776 cLP6nz9a38wWZQj6rRygffGZHXbBFm+8EwJBAJmZEf5ESSK6+5VdMTlNqubAdjJw 777 aBMUY1U0+naL66AyfYWUIq+jDI8+RfLkKQ8H0IfvexvokW2SfwSPK1kzcfECQD/O 778 MQW2xgwt8ThhmeKCQ1/5f2WklsRCl5PGyH+aDeqQyIgjOaPlCzTjE1I3+JpUTryR 779 w9/Td4qRTrtrCv1BNDECQQCgHIzF8LFtI003w9MAEAoCyDbtHFPEj71b+qG22Yc4 780 SPFBAbo3JGO+mrB0MX/GwJr+3DfgzMHaUx/tinPr+u1D 781 -----END RSA PRIVATE KEY----- 782 -----BEGIN CERTIFICATE----- 783 MIIC/TCCAmagAwIBAgIBADANBgkqhkiG9w0BAQQFADBZMQswCQYDVQQGEwJVUzEQ 784 MA4GA1UECBMHR2VvcmdpYTESMBAGA1UEBxQJQXRsYXQIbnRhMQ0wCwYDVQQKEwRJ 785 RVRGMRUwEwYDVQQLFAxTT0lQCAgISVAgV0cwHhcNMDQwOTEzMTAxMzAzWhcNMDUw 786 OTEzMTAxMzAzWjBZMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHR2VvcmdpYTESMBAG 787 A1UEBxQJQXRsYXQIbnRhMQ0wCwYDVQQKEwRJRVRGMRUwEwYDVQQLFAxTT0lQCAgI 788 SVAgV0cwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALweYzxv0ThY2Fvu1kCg 789 FVKQrJX2sARfefJBuDiFe17WhbUHEL7jcxAesbeeTopz1p89HpWWgrBahSgBwKdt 790 Mn/MSJnp2r4LkSxAYg6jBiRKCp07amiOgKdGDOCOC8CXjVHYnoITWQzA5DE0LE+d 791 NyjyXxQZ0ps0tci411QzUwbxAgMBAAGjgdQwgdEwHQYDVR0OBBYEFGfCU7cNxqSK 792 NurvFqz8gj5px8uoMIGBBgNVHSMEejB4gBRnwlO3Dcakijbq7xas/II+acfLqKFd 793 pFswWTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0dlb3JnaWExEjAQBgNVBAcUCUF0 794 bGF0CG50YTENMAsGA1UEChMESUVURjEVMBMGA1UECxQMU09JUAgICElQIFdHggEA 795 MAwGA1UdEwQFMAMBAf8wHgYDVR0RBBcwFYITYXRsYW50YS5leGFtcGxlLmNvbTAN 796 BgkqhkiG9w0BAQQFAAOBgQAc0a/5hU6yqRTxwqoBuRk/iSqDnJD/B0QQnSFLqdjy 797 QV/Pm+aluA05aLRDWq6w/ufwX2HPLOvXYubpnNzjpaWCx3OLr4b5NwnsfNSxtKBJ 798 vI9PWwhSW6VMo/cT2llhNudCmN+LXPd/SLy3gnGvXtwcrWAT8MVYmkCUQTRvbWaR 799 fQ== 800 -----END CERTIFICATE----- 802 A user of atlanta.example.com, Alice, wants to send an INVITE to 803 bob@biloxi.example.org. She therefore creates the following INVITE 804 request, which she forwards to the atlanta.example.org proxy server 805 that instantiates the authentication service role: 807 INVITE sip:bob@biloxi.exmple.org SIP/2.0 808 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 809 To: Bob 810 From: Alice ;tag=1928301774 811 Call-ID: a84b4c76e66710 812 CSeq: 314159 INVITE 813 Max-Forwards: 70 814 Date: Thu, 21 Feb 2002 13:02:03 GMT 815 Contact: 816 Content-Type: application/sdp 817 Content-Length: 147 819 v=0 820 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 821 s=Session SDP 822 c=IN IP4 pc33.atlanta.example.com 823 t=0 0 824 m=audio 49172 RTP/AVP 0 825 a=rtpmap:0 PCMU/8000 827 When the authentication service receives the INVITE, in authenticates 828 Alice by sending a 407 response. As a result, Alice adds an 829 Authorization header to her request, and resends to the 830 atlanta.example.com authentication service. Now that the service is 831 sure of Alice's identity, it calculates an Identity header for the 832 request. The canonical string over which the identity signature will 833 be generated is the following (note that the first line wraps because 834 of RFC editorial conventions): 836 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 837 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 838 s=Session SDP 839 c=IN IP4 pc33.atlanta.example.com 840 t=0 0 841 m=audio 49172 RTP/AVP 0 842 a=rtpmap:0 PCMU/8000 844 The resulting signature (sha1WithRsaEncryption) using the private RSA 845 key given above, with base64 encoding, is the following: 847 NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/p4yiovrJBqhd3TZkegns 848 moHryzk9gTBH7Gj/erixEFIf82o3Anmb+CIbrgdl03gGaD6ICvkpVqoMXZZjdvSp 849 ycyHOhh1cmUx3b9Vr3pZuEh+cB01pbMQ8B1ch++iMjw= 851 Accordingly, the atlanta.example.com authentication service will 852 create an Identity header containing that base64 signature string 853 (175 bytes). It will also add an HTTPS URL where its certificate is 854 made available. With those two headers added, the message looks 855 like: 857 INVITE sip:bob@biloxi.exmple.org SIP/2.0 858 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 859 To: Bob 860 From: Alice ;tag=1928301774 861 Call-ID: a84b4c76e66710 862 CSeq: 314159 INVITE 863 Max-Forwards: 70 864 Date: Thu, 21 Feb 2002 13:02:03 GMT 865 Contact: 866 Identity:"NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/p4yiovrJBqhd3TZkegn 867 smoHryzk9gTBH7Gj/erixEFIf82o3Anmb+CIbrgdl03gGaD6ICvkpVqoMXZZjdvS 868 pycyHOhh1cmUx3b9Vr3pZuEh+cB01pbMQ8B1ch++iMjw=" 869 Identity-Info: ;alg=rsa-sha1 870 Content-Type: application/sdp 871 Content-Length: 147 873 v=0 874 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 875 s=Session SDP 876 c=IN IP4 pc33.atlanta.example.com 877 t=0 0 878 m=audio 49172 RTP/AVP 0 879 a=rtpmap:0 PCMU/8000 881 atlanta.example.com then forwards the request normally. When Bob 882 receives the request, if he does not already know the certificate of 883 atlanta.example.com, he de-references the URL the Identity-Info 884 header to acquire the certificate. Bob then generates the same 885 canonical string given above, from the same headers of the SIP 886 request. Using this canonical string, the signed digest in the 887 Identity header, and the certificate discovered by de-referencing the 888 Identity-Info header, Bob can verify that the given set of headers 889 and the message body have not been modified. 891 11.2 Identity for a Request with no MIME body or Contact 893 Consider the following private key and certificate pair assigned to 894 "biloxi.example.org". 896 -----BEGIN RSA PRIVATE KEY----- 897 MIICXQIBAAKBgQDDIREMIIS9vBBET2FFHss2Lbwri/nK+AMoUZ74UT3amG/bYgDn 898 H86eUUEjGfV3cfXErFXSnI86sUALoKjjwGYBoiUuaMhyerZyF+D9St2plnBeq6fq 899 rbaPpL6bvIAF636/O2+GFP3LSLj6KS4HQwnsaUBr2YzykBD05PfwrH28VQIDAQAB 900 AoGAZLRJFwglWcKYZpjNK54T5HdAGP1Zwo2zG3jcYW2UTZ/EguWWb7HzsbNfuZzp 901 GWcgHwuOE28nYHQgCKA26avfOGuebFHz2WLAFC3TCOVjMzJEWawtxIc7oX9vziTF 902 1Uk2K4ccK2zdJlPI46fHjJrI2xXKZWkxVNkZ8LeMspckUqECQQDqhD0SoLXoRGks 903 h7byNZAMR5PfZTpHli7uFg9O+GoLtxQNE/rW6JPVcVkpCvs8oPPUu+1D7dHnyFiO 904 heyme35tAkEA1QEiny94KRtTuP/WEyyYUkRfltYjrAX1BC73Xu395cNwjvnNw7qI 905 f2dFUm5akGijk9UtL1qNxg+akBgJXkbkiQJAXbUHXkkfRrcHO4bjIDcs3us++BXP 906 yskE6Zeg+FIktZerCGrCYVs/rxsCoHbF2v0JUSjibrE5nZ8dW53B6OgRpQJBAKfr 907 9zFrqN0vT/eeqVQAai0g/gLZ2tF4+MpNhHLwSKNkSk5NHSxa19UowvvTR85kz+Bx 908 xOd6Ch7EmmNSr8AFP5ECQQDOXmjIecxNI51of9u6g4T2ITRcHTYyCqWLO6VqAWlD 909 G6ej+6/h+8DQyfJKMNbfMCGjZ7xZC3isNMmFibGQTLZD 910 -----END RSA PRIVATE KEY----- 911 -----BEGIN CERTIFICATE----- 912 MIIC7DCCAlWgAwIBAgIBADANBgkqhkiG9w0BAQQFADBUMQswCQYDVQQGEwJVUzEU 913 MBIGA1UECBMLTWlzc2lzc2lwcGkxDzANBgNVBAcTBkJpbG94aTENMAsGA1UEChME 914 SUVURjEPMA0GA1UECxMGU0lQIFdHMB4XDTA0MDkxMzEwMzg1NVoXDTA1MDkxMzEw 915 Mzg1NVowVDELMAkGA1UEBhMCVVMxFDASBgNVBAgTC01pc3Npc3NpcHBpMQ8wDQYD 916 VQQHEwZCaWxveGkxDTALBgNVBAoTBElFVEYxDzANBgNVBAsTBlNJUCBXRzCBnzAN 917 BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwyERDCCEvbwQRE9hRR7LNi28K4v5yvgD 918 KFGe+FE92phv22IA5x/OnlFBIxn1d3H1xKxV0pyPOrFAC6Co48BmAaIlLmjIcnq2 919 chfg/UrdqZZwXqun6q22j6S+m7yABet+vztvhhT9y0i4+ikuB0MJ7GlAa9mM8pAQ 920 9OT38Kx9vFUCAwEAAaOBzTCByjAdBgNVHQ4EFgQUlZRLaS3Zm/b0xWcq7TSnQMHM 921 7w8wfAYDVR0jBHUwc4AUlZRLaS3Zm/b0xWcq7TSnQMHM7w+hWKRWMFQxCzAJBgNV 922 BAYTAlVTMRQwEgYDVQQIEwtNaXNzaXNzaXBwaTEPMA0GA1UEBxMGQmlsb3hpMQ0w 923 CwYDVQQKEwRJRVRGMQ8wDQYDVQQLEwZTSVAgV0eCAQAwDAYDVR0TBAUwAwEB/zAd 924 BgNVHREEFjAUghJiaWxveGkuZXhhbXBsZS5vcmcwDQYJKoZIhvcNAQEEBQADgYEA 925 SufJHtereahZlkE5ssRRZRd/erLpEe2uUfHnTOydPBKOkvhVG4Vr4aoroPlE7gJK 926 a/2BF9bohwAUSC5j5q3nvuhUcoK9XZYm2nLkN3IAhCU6oswVBJAxLanGUCjR5sxS 927 HfGhGsqLmTEQ22HsrtLo68IYiwftXcLZbep50gRVX6c= 928 -----END CERTIFICATE----- 930 Bob (bob@biloxi.example.org) now wants to send a BYE request to Alice 931 at the end of the dialog initiated in the previous example. He 932 therefore creates the following BYE request which he forwards to the 933 'biloxi.example.org' proxy server that instantiates the 934 authentication service role: 936 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 937 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 938 Max-Forwards: 70 939 From: Bob ;tag=a6c85cf 940 To: Alice ;tag=1928301774 941 Call-ID: a84b4c76e66710 942 CSeq: 231 BYE 943 Content-Length: 0 944 When the authentication service receives the BYE, it authenticates 945 Bob by sending a 407 response. As a result, Bob adds an 946 Authorization header to his request, and resends to the 947 biloxi.example.org authentication service. Now that the service is 948 sure of Bob's identity, it prepares to calculate an Identity header 949 for the request. Note that this request does not have a Date header 950 field. Accordingly, the biloxi.example.org will add a Date header to 951 the request before calculating the identity signature. If the 952 Content-Length header were not present, the authentication service 953 would add it as well. The baseline message is thus: 955 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 956 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 957 Max-Forwards: 70 958 From: Bob ;tag=a6c85cf 959 To: Alice ;tag=1928301774 960 Date: Thu, 21 Feb 2002 14:19:51 GMT 961 Call-ID: a84b4c76e66710 962 CSeq: 231 BYE 963 Content-Length: 0 965 Also note that this request contains no Contact header field. 966 Accordingly, biloxi.example.org will place no value in the canonical 967 string for the addr-spec of the Contact address. Also note that 968 there is no message body, and accordingly, the signature string will 969 terminate, in this case, with two colons. The canonical string over 970 which the identity signature will be generated is the following (note 971 that the first line wraps because of RFC editorial conventions): 973 sip:bob@biloxi.example.org|sip:alice@atlanta.example.com|a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT|| 975 The resulting signature (sha1WithRsaEncryption) using the private RSA 976 key given above for biloxi.example.org, with base64 encoding, is the 977 following: 979 kJl0ILrbzGtQX4zW4GlPo5DELq1hYXgfvI77xeQ1H7mXblNJBf6cLE0JAnRiDMp+ 980 tbwSi9tj7JoknqeZAXtj5czqAKskj7axdYfe40basFy34HhNVc3WH2c3TwAlqbrm 981 kspEbEWUnBnIRXjnihQ3Pi5rHwUVkKPdogI26IqRgQE= 983 Accordingly, the biloxi.example.org authentication service will 984 create an Identity header containing that base64 signature string. 985 It will also add an HTTPS URL where its certificate is made 986 available. With those two headers added, the message looks like: 988 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 989 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 990 Max-Forwards: 70 991 From: Bob ;tag=a6c85cf 992 To: Alice ;tag=1928301774 993 Date: Thu, 21 Feb 2002 14:19:51 GMT 994 Call-ID: a84b4c76e66710 995 CSeq: 231 BYE 996 Identity: "kJl0ILrbzGtQX4zW4GlPo5DELq1hYXgfvI77xeQ1H7mXblNJBf6cLE0JAnRiDMp 997 +tbwSi9tj7JoknqeZAXtj5czqAKskj7axdYfe40basFy34HhNVc3WH2c3TwAlqbr 998 mkspEbEWUnBnIRXjnihQ3Pi5rHwUVkKPdogI26IqRgQE=" 999 Identity-Info: ;alg=rsa-sha1 1000 Content-Length: 0 1002 biloxi.example.org then forwards the request normally. 1004 12. Identity and the TEL URI Scheme 1006 Since many SIP applications provide a VoIP service, telephone numbers 1007 are commonly used as identities in SIP deployments. In the majority 1008 of cases, this is not problematic for the identity mechanism 1009 described in this document. Telephone numbers commonly appear in the 1010 username portion of a SIP URI (e.g., 1011 'sip:+17005551008@chicago.example.com;user=phone'). That username 1012 conforms to the syntax of the TEL URI scheme (RFC3966 [12]). For 1013 this sort of SIP address-of-record, chicago.example.com is the 1014 appropriate signatory. 1016 It is also possible for a TEL URI to appear in the SIP To or From 1017 header field outside the context of a SIP or SIPS URI (e.g., 1018 'tel:+17005551008'). In this case, it is much less clear which 1019 signatory is appropriate for the identity. Fortunately for the 1020 identity mechanism, this form of the TEL URI is more common for the 1021 To header field and Request-URI in SIP than in the From header field, 1022 since the UAC has no option but to provide a TEL URI alone when the 1023 remote domain to which a request is sent is unknown. The local 1024 domain, however, is usually known by the UAC, and accordingly it can 1025 form a proper From header field containing a SIP URI with a username 1026 in TEL URI form. Implementations that intend to send their requests 1027 through an authentication service SHOULD put telephone numbers in the 1028 From header field into SIP or SIPS URIs whenever possible. 1030 If the local domain is unknown to a UAC formulating a request, it 1031 most likely will not be able to locate an authentication service for 1032 its request, and therefore the question of providing identity in 1033 these cases is somewhat moot. However, an authentication service MAY 1034 sign a request containing a TEL URI in the From header field. This 1035 is permitted in this specification strictly for forward compatibility 1036 purposes. In the longer-term, it is possible that ENUM [13] may 1037 provide a way to determine which administrative domain is responsible 1038 for a telephone number, and this may aid in the signing and 1039 verification of SIP identities that contain telephone numbers. This 1040 is a subject for future work. 1042 13. Privacy Considerations 1044 The identity mechanism presented in this draft is compatible with the 1045 standard SIP practices for privacy described in RFC3323 [3]. A SIP 1046 proxy server can act both as a privacy service and as an 1047 authentication service. Since a user agent can provide any From 1048 header field value which the authentication service is willing to 1049 authorize, there is no reason why private SIP URIs which contain 1050 legitimate domains (e.g., sip:anonymous@example.com) cannot be signed 1051 by an authentication service. The construction of the Identity 1052 header is the same for private URIs as it is for any other sort of 1053 URIs. 1055 Note, however, that an authentication service must possess a 1056 certificate corresponding to the host portion of the addr-spec of the 1057 From header field of any request that it signs; accordingly, using 1058 domains like 'invalid.net' will not be possible for privacy services 1059 that also act as authentication services. The assurance offered by 1060 the usage of anonymous URIs with a valid domain portion is "this is a 1061 known user in my domain that I have authenticated, but I am keeping 1062 their identity private". The use of the domain 'invalid.net' implies 1063 that no corresponding authority for the domain can exist, and as a 1064 consequence, authentication service functions are meaningless. 1066 The "header" level of privacy described in RFC3323 requests that a 1067 privacy service to alter the Contact header field value of a SIP 1068 message. Since the Contact header field is protected by the 1069 signature in an Identity header, privacy services cannot be applied 1070 after authentication services without a resulting integrity 1071 violation. 1073 RFC3325 [10] defines the "id" priv-value token which is specific to 1074 the P-Asserted-Identity header. The sort of assertion provided by 1075 the P-Asserted-Identity header is very different from the Identity 1076 header presented in this document. It contains additional 1077 information about the sender of a message that may go beyond what 1078 appears in the From header field; P-Asserted-Identity holds a 1079 definitive identity for the sender which is somehow known to a closed 1080 network of intermediaries that presumably the network will use this 1081 identity for billing or security purposes. The danger of this 1082 network-specific information leaking outside of the closed network 1083 motivated the "id" priv-value token. The "id" priv-value token has 1084 no implications for the Identity header, and privacy services MUST 1085 NOT remove the Identity header when a priv-value of "id" appears in a 1086 Privacy header. 1088 Finally, note that unlike RFC3325, the mechanism described in this 1089 specification adds no information to SIP requests that has privacy 1090 implications. 1092 14. Security Considerations 1094 14.1 Handling of digest-string Elements 1096 This document describes a mechanism which provides a signature over 1097 the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP 1098 requests. While a signature over the From header field would be 1099 sufficient to secure a URI alone, the additional headers provide 1100 replay protection and reference integrity necessary to make sure that 1101 the Identity header will not be used in cut-and-paste attacks. In 1102 general, the considerations related to the security of these headers 1103 are the same as those given in RFC3261 for including headers in 1104 tunneled 'message/sip' MIME bodies (see Section 23 in particular). 1106 The From header field indicates the identity of the sender of the 1107 message, and the SIP address-of-record URI in the From header field 1108 is the identity of a SIP user, for the purposes of this document. 1109 The To header field provides the identity of the SIP user that this 1110 request targets. Providing the To header field in the Identity 1111 signature serves two purposes: first, it prevents replay attacks in 1112 which an Identity header from legitimate request for one user is cut- 1113 and-pasted into a request for a different user; second, it preserves 1114 the starting URI scheme of the request, which helps prevent downgrade 1115 attacks against the use of SIPS. 1117 The Date and Contact headers provide reference integrity and replay 1118 protection, as described in RFC3261 Section 23.4.2. Implementations 1119 of this specification MUST NOT deem valid a request with an outdated 1120 Date header field (the RECOMMENDED interval is that the Date header 1121 must indicate a time within 3600 seconds of the receipt of a 1122 message). Implementations MUST also record Call-IDs received in 1123 valid requests containing an Identity header, and MUST remember those 1124 Call-IDs for at least the duration of a single Date interval (i.e. 1125 commonly 3600 seconds). This result of this is that if an Identity 1126 header is replayed within the Date interval, verifiers will recognize 1127 that it is invalid because of a Call-ID duplication; if an Identity 1128 header is replayed after the Date interval, verifiers will recognize 1129 that it is invalid because the Date is stale. The CSeq header field 1130 contains a numbered identifier for the transaction, and the name of 1131 the method of the request; without this information, an INVITE 1132 request could be cut-and-pasted by an attacker and transformed into a 1133 BYE request without changing any fields covered by the Identity 1134 header, and moreover requests within a certain transaction could be 1135 replayed in potentially confusing or malicious ways. 1137 The Contact header field is included to tie the Identity header to a 1138 particular user agent instance that generated the request. Were an 1139 active attacker to intercept a request containing an Identity header, 1140 and cut-and-paste the Identity header field into their own request 1141 (reusing the From, To, Contact, Date and Call-ID fields that appear 1142 in the original message), they would not be eligible to receive SIP 1143 requests from the called user agent, since those requests are routed 1144 to the URI identified in the Contact header field. However, the 1145 Contact header is only included in dialog-forming requests, so it 1146 does not provide this protection in all cases. 1148 It might seem attractive to provide a signature over some of the 1149 information present in the Via header field value(s). For example, 1150 without a signature over the sent-by field of the topmost Via header, 1151 an attacker could remove that Via header and insert their own in a 1152 cut-and-paste attack, which would cause all responses to the request 1153 to be routed to a host of the attacker's choosing. However, a 1154 signature over the topmost Via header does not prevent attacks of 1155 this nature, since the attacker could leave the topmost Via intact 1156 and merely insert a new Via header field directly after it, which 1157 would cause responses to be routed to the attacker's host "on their 1158 way" to the valid host, which has exactly the same end result. 1159 Although it is possible that an intermediary-based authentication 1160 service could guarantee that no Via hops are inserted between the 1161 sending user agent and the authentication service, it could not 1162 prevent an attacker from adding a Via hop after the authentication 1163 service, and thereby pre-empting responses. It is necessary for the 1164 proper operation of SIP for subsequent intermediaries to be capable 1165 of inserting such Via header fields, and thus it cannot be prevented. 1166 As such, though it is desirable, securing Via is not possible through 1167 the sort of identity mechanism described in this document; the best 1168 known practice for securing Via is the use of SIPS. 1170 This mechanism also provides a signature over the bodies of SIP 1171 requests. The most important reason for doing so is to protect SDP 1172 bodies carried in SIP requests. There is little purpose in 1173 establishing the identity of the user that originated a SIP request 1174 if this assurance is not coupled a comparable assurance over the 1175 media descriptors. Note however that this is not perfect end-to-end 1176 security. The authentication service itself, when instantiated at a 1177 intermediary, could conceivably change the SDP (and SIP headers, for 1178 that matter) before providing a signature. Thus, while this 1179 mechanism reduces the chance that a replayer or man-in-the-middle 1180 will modify SDP, it does not eliminate it entirely. Since it is a 1181 foundational assumption of this mechanism that the user trusts their 1182 local domain to vouch for their security, they must also trust the 1183 service not to violate the integrity of their message without good 1184 reason. Note that RFC3261 16.6 states that SIP proxy servers "MUST 1185 NOT add to, modify, or remove the message body." 1187 In the end analysis, the Identity and Identity-Info headers cannot 1188 protect themselves. Any attacker could remove these headers from a 1189 SIP request, and modify the request arbitrarily afterwards. However, 1190 this mechanism is not intended to protect requests from men-in-the- 1191 middle who interfere with SIP messages; it is intended only to 1192 provide a way that SIP users can prove definitively that they are who 1193 they claim to be. At best, by stripping identity information from a 1194 request, a man-in-the-middle could make it impossible to distinguish 1195 any illegitimate messages he would like to send from those messages 1196 sent by an authorized user. However, it requires a considerably 1197 greater amount of energy to mount such an attack than it does to 1198 mount trivial impersonations by just copying someone else's From 1199 header field. This mechanism provides a way that an authorized user 1200 can provide a definitive assurance of their identity which an 1201 unauthorized user, an impersonator, cannot. 1203 One additional respect in which the Identity-Info header cannot 1204 protect itself is the 'alg' parameter. The 'alg' parameter is not 1205 included in the digest-string, and accordingly, a man-in-the-middle 1206 might attempt to modify the 'alg' parameter. However, it is 1207 important to note that preventing men-in-the-middle is not the 1208 primary impetus for this mechanism. Moreover, changing the 'alg' 1209 would merely result in a failure at the verifier. Numerous changes 1210 that a man-in-the-middle might make would have the same effect. As 1211 such, 'alg' does not seem to introduce any new security 1212 considerations for this mechanism. 1214 14.2 Display Names and Identity 1216 As a matter of interface design, SIP user agents might render the 1217 display-name portion of the From header field of a caller as the 1218 identity of the caller; there is a significant precedent in email 1219 user interfaces for this practice. As such, it might seem that the 1220 lack of a signature over the display-name is a significant omission. 1222 However, there are several important senses in which a signature over 1223 the display-name does not prevent impersonation. In the first place, 1224 a particular display-name, like "Jon Peterson", is not unique in the 1225 world; many users in different administrative domains might 1226 legitimately claim that name. Furthermore, enrollment practices for 1227 SIP-based services might have a difficult term discerning the 1228 legitimate display-name for a user; it is safe to assume that 1229 impersonators will be capable of creating SIP accounts with 1230 arbitrarily display-names. The same situation prevails in email 1231 today. Note that an impersonator who attempted to replay a message 1232 with an Identity header, changing only the display-name in the From 1233 header field, would be detected by the other replay protection 1234 mechanisms described in Section 14.1. 1236 Of course, an authentication service can enforce policies about the 1237 display-name even if the display-name is not signed. The exact 1238 mechanics for creating and operationalizing such policies is outside 1239 the scope of this document. The effect of this policy would not be 1240 to prevent impersonation of a particular unique identifier like a SIP 1241 URI (since display-names are not unique identifiers), but to allow a 1242 domain to manage the claims made by its users. If such policies are 1243 enforced, users would not be free to claim any display-name of their 1244 choosing. In the absence of a signature, man-in-the-middle attackers 1245 could conceivably alter the display-names in a request with impunity. 1246 Note that the scope of this specification is impersonation attacks, 1247 however, and that a man-in-the-middle might also strip the Identity 1248 and Identity-Info headers from a message. 1250 There are many environments in which policies regarding the display- 1251 name aren't feasible. Distributing bit-exact and internationalizable 1252 display-names to end users as part of the enrollment or registration 1253 process would require mechanisms that are not explored in this 1254 document. In the absence of policy enforcement regarding domain 1255 names, there are conceivably attacks that an adversary could mount 1256 against SIP systems that rely too heavily on the display-name in 1257 their user interface, but this argues for intelligent interface 1258 design, not changes to the mechanisms. Relying on a non-unique 1259 identifier for identity would ultimately result in a weak mechanism. 1261 14.3 Securing the Connection to the Authentication Service 1263 The assurance provided by this mechanism is strongest when a user 1264 agent forms a direct connection, preferably one secured by TLS, to an 1265 intermediary-based authentication service. The reasons for this are 1266 twofold: 1267 If a user does not receive a certificate from the authentication 1268 service over this TLS connection that corresponds to the expected 1269 domain (especially when they receive a challenge via a mechanism 1270 such as Digest), then it is possible that a rogue server is 1271 attempting to pose as a authentication service for a domain that 1272 it does not control, possibly in an attempt to collect shared 1273 secrets for that domain. 1275 Without TLS, the various header field values and the body of the 1276 request will not have integrity protection into the request 1277 arrives at an authentication service. Accordingly, a prior 1278 legitimate or illegitimate intermediary could modify the message 1279 arbitrarily. 1281 Of these two concerns, the first is most material to the intended 1282 scope of this mechanism. This mechanism is intended to prevent 1283 impersonation attacks, not man-in-the-middle attacks; integrity over 1284 the header and bodies is provided by this mechanism only to prevent 1285 replay attacks. However, it is possible that applications relying on 1286 the presence of the Identity header could leverage this integrity 1287 protection, especially body integrity, for services other than replay 1288 protection. 1290 Accordingly, direct TLS connections SHOULD be used between the UAC 1291 and the authentication service whenever possible. The opportunistic 1292 nature of this mechanism, however, makes it very difficult to 1293 constrain UAC behavior, and moreover there will be some deployment 1294 architectures where a direct connection is simply infeasible and the 1295 UAC cannot act as an authentication service itself. Accordingly, 1296 when a direct connection and TLS is not possible, a UAC should use 1297 the SIPS mechanism, Digest 'auth-int' for body integrity, or both 1298 when it can. The ultimate decision to add an Identity header to a 1299 request lies with the authentication service, of course; domain 1300 policy must identify those cases where the UAC's security association 1301 with the authentication service is too weak. 1303 14.4 Domain Names and Subordination 1305 When a verifier processes a request containing an Identity-Info 1306 header, it must compare the domain portion of the URI in the From 1307 header field of the request with the domain name which is the subject 1308 of the certificate acquired from the Identity-Info header. While it 1309 might seem that this should be a straightforward process, it is 1310 complicated by two deployment realities. In the first place, 1311 certificates have varying ways of describing their subjects, and may 1312 indeed have multiple subjects, especially in 'virtual hosting' cases 1313 where multiple domains are managed by a single application. 1314 Secondly, some SIP services may delegate SIP functions to a 1315 subordinate domain and utilize the procedures in RFC3263 [4] allow 1316 requests for, say, 'example.com' to be routed to 'sip.example.com'; 1317 as a result, a user with the AoR 'sip:jon@example.com' may process 1318 their requests through a host like 'sip.example.com', and it may be 1319 that latter host which acts as an authentication service. 1321 To meet the second of these problems, a domain that deploys an 1322 authentication service on a subordinate host MUST be willing to 1323 supply that host with the private keying material associated with a 1324 certificate whose subject is a domain name that corresponds to the 1325 domain portion of the AoRs that the domain distributes to users. 1326 Note that this corresponds to the comparable case of routing inbound 1327 SIP requests to a domain. When the NAPTR and SRV procedures of 1328 RFC3263 are used to direct requests to a domain name other than the 1329 domain in the original Request-URI (e.g., for 'sip:jon@example.com', 1330 the corresponding SRV records point to the service 1331 'sip1.example.org'), the client expects that the certificate passed 1332 back by in any TLS exchange with that host will correspond exactly 1333 with the domain of the original Request-URI, not the domain name of 1334 the host. Consequently, in order to make inbound routing to such SIP 1335 services work, a domain administrator must similarly be willing to 1336 share the domain's private key with service. This design decision 1337 was made to compensate for the insecurity of the DNS, and it makes 1338 certain potential approaches to DNS-based 'virtual hosting' 1339 unsecurable for SIP in environments where domain administrators are 1340 unwilling to share keys with hosting services. 1342 A verifier must evaluate the correspondence between the user's 1343 identity and the signing certificate as follows: 1345 First, a verifier must acquire a list of one or more domain names 1346 which constitute the subject(s) of the certificate. A verifier MUST 1347 extract the subject CN field from the certificate. If the CN 1348 contains a domain name, it is added to a list we will call the 1349 'subject list'. A verifier MUST also extract all subjectAltName 1350 fields from the certificate. If any subjectAltName fields contain 1351 domain names, these domain names should also be added to the subject 1352 list. 1354 Once it accumulates the subject list, the verifier MUST compare each 1355 name in the subject list to the domain portion of the URI in the From 1356 header field of the request. If the domain portion of that URI 1357 matches any domain in the subject list, the verifier should consider 1358 the certificate to match the URI in the From header field for the 1359 purpose of verification. 1361 If no member of the subject list matches the domain portion of the 1362 URI in the From header field, then the verifier should consider the 1363 certificate ineligible to sign the request. 1365 Because the domain certificates that can be used by authentication 1366 services need to assert only the hostname of the authentication 1367 service, existing certificate authorities can provide adequate 1368 certificates for this mechanism. However, not all proxy servers and 1369 user agents will be able support the root certificates of all 1370 certificate authorities, and moreover there are some significant 1371 differences in the policies by which certificate authorities issue 1372 their certificates. This document makes no recommendations for the 1373 usage of particular certificate authorities, nor does it describe any 1374 particular policies that certificate authorities should follow, but 1375 it is anticipated that operational experience will create de facto 1376 standards for authentication services. Some federations of service 1377 providers, for example, might only trust certificates that have been 1378 provided by a certificate authority operated by the federation. It 1379 is strongly RECOMMENDED that self-signed domain certificates should 1380 not be trusted by verifiers, unless some pre-existing key exchange 1381 has justified such trust. 1383 14.5 Authorization and Transitional Strategies 1385 Ultimately, the worth of an assurance provided by an Identity header 1386 is limited by the security practices of the domain that issues the 1387 assurance. Relying on an Identity header generated by a remote 1388 administrative domain assumes that the issuing domain used its 1389 administrative practices to authenticate its users. However, it is 1390 possible that some domains will implement policies that effectively 1391 make users unaccountable (e.g., ones that accept unauthenticated 1392 registrations from arbitrary users). The value of an Identity header 1393 from such domains is questionable. While there is no magic way for a 1394 verifier to distinguish "good" from "bad" domains by inspecting a SIP 1395 request, it is expected that further work in authorization practices 1396 could be built on top of this identity solution; without such an 1397 identity solution, many promising approaches to authorization policy 1398 are impossible. That much said, it is RECOMMENDED that 1399 authentication services based on proxy servers employ strong 1400 authentication practices such as token-based identifiers. 1402 One cannot expect the Identity and Identity-Info headers to be 1403 supported by every SIP entity overnight. This leaves the verifier in 1404 a compromising position; when it receives a request from a given SIP 1405 user, how can it know whether or not the sender's domain supports 1406 Identity? In the absence of ubiquitous support for identity, some 1407 transitional strategies are necessary. 1408 A verifier could remember when it receives a request from a domain 1409 that uses Identity, and in the future, view messages received from 1410 that domain without Identity headers with skepticism. 1411 A verifier could query the domain through some sort of callback 1412 system to determine whether or not it is running an authentication 1413 service. There are a number of potential ways in which this could 1414 be implemented; use of the SIP OPTIONS method is one possibility. 1415 This is left as a subject for future work. 1417 In the long term, some sort of identity mechanism, either the one 1418 documented in this specification or a successor, must become 1419 mandatory-to-use for the SIP protocol; that is the only way to 1420 guarantee that this protection can always be expected by verifiers. 1422 Finally, it is worth noting that the presence or absence of the 1423 Identity headers cannot be sole factor in making an authorization 1424 decision. Permissions might be granted to a message on the basis of 1425 the specific verified Identity or really on any other aspect of a SIP 1426 request. Authorization policies are outside the scope of this 1427 specification, but this specification advises any future 1428 authorization work not to assume that messages with valid Identity 1429 headers are always good. 1431 15. IANA Considerations 1433 This document requests changes to the header and response-code sub- 1434 registries of the SIP parameters IANA registry, and requests the 1435 creation of two new registries for parameters for the Identity-Info 1436 header. 1438 15.1 Header Field Names 1440 This document specifies two new SIP headers: Identity and Identity- 1441 Info. Their syntax is given in Section 10. These headers are 1442 defined by the following information, which is to be added to the 1443 header sub-registry under 1444 http://www.iana.org/assignments/sip-parameters. 1445 Header Name: Identity 1446 Compact Form: y 1447 Header Name: Identity-Info 1448 Compact Form: n 1450 15.2 428 'Use Identity Header' Response Code 1452 This document registers a new SIP response code which is described in 1453 Section 7. It is sent when a verifier receives a SIP request that 1454 lacks an Identity header in order to indicate that the request should 1455 be re-sent with an Identity header. This response code is defined by 1456 the following information, which is to be added to the method and 1457 response-code sub-registry under 1458 http://www.iana.org/assignments/sip-parameters. 1459 Response Code Number: 428 1460 Default Reason Phrase: Use Identity Header 1462 15.3 436 'Bad Identity-Info' Response Code 1464 This document registers a new SIP response code which is described in 1465 Section 7. It is used when the Identity-Info header contains a URI 1466 that cannot be dereferenced by the verifier (either the URI scheme is 1467 unsupported by the verifier, or the resource designated by the URI is 1468 otherwise unavailable). This response code is defined by the 1469 following information, which is to be added to the method and 1470 response-code sub-registry under 1471 http://www.iana.org/assignments/sip-parameters. 1472 Response Code Number: 436 1473 Default Reason Phrase: Bad Identity-Info 1475 15.4 437 'Unsupported Certificate' Response Code 1477 This document registers a new SIP response code which is described in 1478 Section 7. It is used when the verifier cannot validate the 1479 certificate referenced by the URI of the Identity-Info header, 1480 because, for example, the certificate is self-signed, or signed by a 1481 root certificate authority for whom the verifier does not possess a 1482 root certificate. This response code is defined by the following 1483 information, which is to be added to the method and response-code 1484 sub-registry under http://www.iana.org/assignments/sip-parameters. 1485 Response Code Number: 437 1486 Default Reason Phrase: Unsupported Certificate 1488 15.5 Identity-Info Parameters 1490 This document requests that the IANA create a new registry for 1491 Identity-Info headers. This registry is to be prepopulated with a 1492 single entry for a parameter called 'alg', which describes the 1493 algorithm used to create the signature which appears in the Identity 1494 header. Registry entries must contain the name of the parameter and 1495 the specification in which the parameter is defined. New parameters 1496 for the Identity-Info header may be defined only in Standards Track 1497 RFCs. 1499 15.6 Identity-Info Algorithm Parameter Values 1501 This document requests that the IANA create a new registry for 1502 Identity-Info 'alg' parameter values. This registry is to be 1503 prepopulated with a single entry for a value called 'rsa-sha1', which 1504 describes the algorithm used to create the signature which appears in 1505 the Identity header. Registry entries must contain the name of the 1506 'alg' parameter value and the specification in which the value is 1507 described. New values for the 'alg' parameter may be defined only in 1508 Standards Track RFCs. 1510 16. References 1511 16.1 Normative References 1513 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1514 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1515 Session Initiation Protocol", RFC 3261, June 2002. 1517 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 1518 levels", RFC 2119, March 1997. 1520 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 1521 Protocol (SIP)", RFC 3323, November 2002. 1523 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1524 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1526 [5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 1527 Identity Body (AIB) Format", RFC 3893, September 2004. 1529 [6] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 1530 RFC 2234, November 1997. 1532 [7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 1533 RFC 3370, August 2002. 1535 [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1536 RFC 3548, July 2003. 1538 16.2 Informative References 1540 [9] Kohl, J. and C. Neumann, "The Kerberos Network Authentication 1541 Service (V5)", RFC 1510, September 1993. 1543 [10] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 1544 to the Session Initiation Protocol (SIP) for Asserted Identity 1545 within Trusted Networks", RFC 3325, November 2002. 1547 [11] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1548 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, 1549 May 1999. 1551 [12] Schulzrinne, H., "The TEL URI for Telephone Numbers", RFC 3966, 1552 December 2004. 1554 [13] Faltstrom, P. and M. Mealling, "The E.164 to URI DDDS 1555 Application", RFC 3761, April 2004. 1557 [14] Peterson, J., "Retargeting and Security in SIP: A Framework and 1558 Requirements", draft-peterson-sipping-retarget-00 (work in 1559 progress), February 2005. 1561 Authors' Addresses 1563 Jon Peterson 1564 NeuStar, Inc. 1565 1800 Sutter St 1566 Suite 570 1567 Concord, CA 94520 1568 US 1570 Phone: +1 925/363-8720 1571 Email: jon.peterson@neustar.biz 1572 URI: http://www.neustar.biz/ 1574 Cullen Jennings 1575 Cisco Systems 1576 170 West Tasman Drive 1577 MS: SJC-21/2 1578 San Jose, CA 95134 1579 USA 1581 Phone: +1 408 902-3341 1582 Email: fluffy@cisco.com 1584 Appendix A. Acknowledgments 1586 The authors would like to thank Eric Rescorla, Rohan Mahy, Robert 1587 Sparks, Jonathan Rosenberg, Mark Watson, Henry Sinnreich, Alan 1588 Johnston, Patrik Faltstrom, Paul Kyzviat, Adam Roach, John Elwell, 1589 Aki Niemi, and Jim Schaad for their comments. Jonathan Rosenberg 1590 provided detailed fixed to innumerable sections of the document. The 1591 bit-archive presented in Appendix B follows the pioneering example of 1592 Robert Sparks' torture-test draft. 1594 Appendix B. Bit-exact archive of example messages 1596 The following text block is an encoded, gzip compressed TAR archive 1597 of files that represent the transformations performed on the example 1598 messages discussed in Section 11. It includes for each example: 1599 o (foo).message: the original message 1600 o (foo).canonical: the canonical string constructed from that 1601 message 1602 o (foo).sha1: the SHA1 hash of the canonical string (hexadecimal) 1603 o (foo).signed: the RSA-signed SHA1 hash of the canonical string 1604 (binary) 1605 o (foo).signed.enc: the base64 encoding of the RSA-signed SHA1 hash 1606 of the canonical string as it would appear in the request 1607 o (foo).identity: the original message with the Identity and 1608 Identity-Info headers added 1610 Also included in the archive are two public key/certificate pairs, 1611 for atlanta.example.com and biloxi.example.org, respectively, 1612 including: 1613 o (foo).cert: the certificate of the domain 1614 o (foo).privkey: the private key of the domain 1615 o (foo).pubkey: the public key of the domain, extracted from the 1616 cert file for convenience 1618 To recover the compressed archive file intact, the text of this 1619 document may be passed as input to the following Perl script (the 1620 output should be redirected to a file or piped to "tar -xzvf -"). 1622 #!/usr/bin/perl 1623 use strict; 1624 my $bdata = ""; 1625 use MIME::Base64; 1626 while(<>) { 1627 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 1628 if ( m/^\s*[^\s]+\s*$/) { 1629 $bdata = $bdata . $_; 1630 } 1631 } 1632 } 1633 print decode_base64($bdata); 1635 Alternatively, the base-64 encoded block can be edited by hand to 1636 remove document structure lines and fed as input to any base-64 1637 decoding utility. 1639 B.1 Encoded Reference Files 1641 -- BEGIN MESSAGE ARCHIVE -- 1642 H4sICOOGdEICA2lkZW50cmVmLnRhcgDsW02v41haLpBYYFEb/sBEIxagTFX87eT2 1643 1GiOv78TfyfZINvxR2zHjj8SO6HEHwCh2aFBiA0LVixZgGYJG8SazWxYsOQfICGc 1644 e6u6urv6dtdI3aXu6XskXyev7ZNz/J73ed73se9+F5VdE8WzZ99eg2Ecpghi3GMo 1645 hZHjHsVxEhn3n7ZnCIxixPiHxLBnMIKRKPpsQjz7CO3Udn4zmTzLjlEXNW1VPnLe 1646 IU+a6nR8UbzYPfstavu3/ve7wi87/2UYNd037X8Ehkkcf8z/KIJgo/8RFEEpBCWo 1647 8XwSufkffvL/t95e3BrNCZI+YTjTlniJATZ3b4U0SWJmNsOAg5+AXqJBMm4s0Okk 1648 r9N8Lyx6mAaGwQOW3mpG2zPGhnUNQ+B62XWunAFpABcA4nAMrYkm6p7Dw+64sTlL 1649 o8G9nR4M2Vib7WZtSEFpppoB90x/34nC9aYMma4paKbTcw9GlQeDbcOFwYxDsVyQ 1650 uHDYi2moa6zRL23uqtlg0K7g6t3bnB76nDH78mF+1SihDxnmV40SejvMZDvvWWMj 1651 K9VWSs+hDgyOpg3AJhsYaJIgg0qggdpHm+twhu10g/LnE5IzCcS7itHIa7QFZhzF 1652 Mn1i93yEUF4aOCKnUlk4gKgNosiujlfkOF+IR89LGtpPrYTulV0HaeVMs+TyiDa4 1653 mlsD2CRkRu9NhTnClH/YLxNlJ7BLZsnMmXXmipuykmzPuAKC5WCVm+4g/ZJd1oOx 1654 hY8t3IV7HEGMq9MHA0jGWwSELNkZfbLjevF2Y014SdMbjhdixqFCfagtBdJPzZmv 1655 r/MkI47D/FSN86XpRHdFS+OijMYT2iz7YomxoZ/vs6CmBr+dSdLUD2O1VvgddOTb 1656 3rM5VQP5w8JJNcZ1tYFjwfLW0bg0bRreFQEml77HDVwGjAd76DAOD0OBwMOMQMCj 1657 X3UNtA/+TjXOclzHzDhXo7UH22BoDryQndF1DFcYEr8Tk4QD41LubyeMszR4DYzz 1658 jue9mNzP16TpsOc3kr25rRFv/BGLKCKB70JhKNSDfg5soEPvBc1t5AYIYX9GpA55 1659 qU176OuKPpn5bG/VbCmzMxo2jNLi1XqXXSDDna0OU784AZjwVZP1arKfneJ+jYor 1660 dXleb07BsdSv2dH3mAFbqg0eEHpftrFuDZ1Cy9BZWqy8PrU80tWqWWijRZHqpx1z 1661 0KfqerWbWeoFS0rhvO76sPGAPdfczSFnHMM2z4Hnm1BsvHoF3UMDp7Pvw8Wzp/Zb 1662 wP/HZn/Oo8tH5H+EIKkv8j9JPfH/x+Z/0wKTlSm5Y0BPFG7zLgcYaW/EeWWEK2Yu 1663 HrR5sOBwT08DqtuCinatXLm4iwZwa6y8GEGCp+suQioPoQdmCuGYZoiNgJU5qYQL 1664 P16ZpFtUSu9VTgVCpgxseXbl9ltyV08ZgmsNQVpW/Sa3knq3RI8VlFVMaSbXJEvO 1665 oMARE5VJhkNyrV8ag84Mq9IOq3kxd4SdEujqWjrpO0dDNGFuSCwwAA2NzApAt1oK 1666 wL3o1XRtLeWBm6IOLfq15qnGRQQKxVSXlqD46bI8xVUo14I9ZhQpr222S6iIjBRW 1667 sjQJ+6WjVVRCd6eq8wwnCFTRFpT1njbJVR0cSOac9rJ10jdn+LzUT3aAWFpRQIq/ 1668 S3Cs9HF6kRvRpSuRC1nEuZ0raLWpc9bdogAcVEtt4rRAHMYw2CPl8lKXHMpL0CvQ 1669 Sunldp6U/PQ0VRbZtPXDGXZOhKRZno+DW/eVti7IyNNns+N2FtZt6peseuiahZ9m 1670 HsNC7LBxL3nRgJwD1x0pqzJIhXm4vRxcxiLkGOYpHrjDcYDpxFyJvVzsL05CLvFs 1671 tZkCK4FCdUWW14WPzXtva2RkY16SOBa24jqg+cN0PiZTNJAPWy4mOMtSyCnh7jS7 1672 0OtTAHaZ3EM+rTkbxIGnpa+SJLjEG8+R6mnGSvOpGau5YsxFWIrP0XCucg+14t5a 1673 KUh+DWOOMdjZEtIMDx2SvpvbaXqIFMZAZkSMennRmkxBrISLOPXZqDYuUpIt/VXB 1674 XO2MQyRsKh8du7mYUL+Y2Tt85Nmma5gzQuvs2LPBJKJ05ecq30kjPvULDXCgYi5s 1675 0In8issoJJjWAopuQhyyVjwNggqTheX00NCwtp4JvdxMMTZOrproO8Os25erZnpC 1676 2Hc8+aVh9R3G/1PwDcP/1+E/jKO3+h/BcITAMQK/4T9OEk/4/5Hxf+XQqsR8FvqF 1677 WAOwwFi1YEkBxo4VCzAcMJZLOmAZem98NSVAj3HCh1IC9BgnfCglQI9ywqfR+cVJ 1678 /2Dzv2BfVMP+25B/vlb/gUn0bf6Ho9Qt/yMoCn+K/++C/kOxDAMK7+v0H+dLhBUH 1679 0mjprbKi2l5xDdH7rQ+FfGCvt47uS3SbzuVjICxw/wvVOfSmPF/dYOihPNcEB34o 1680 yzUaX7M2gDU2H7Qr12vXBNHd6mZD3tqgN8beZd8XD3gWWG/FAwZGjiGmP2wifdSM 1681 e7WGhcb5iFy/ZXxvOEe3YdtAfbiosmmu4F1u85mptDZd6LLD0GvzytDl9b26n7uv 1682 +zMD9MkmZ5INB/oLZ473mDsHvWFyi9Q0KVXfo3MFPxOXc8JCCi9EU55boMf0jKIS 1683 IIbZsix4WhpKZIeJyKAMLny8rJYNDxiSqfA5fQC+VKiHTArLGoXCNE5mTrOrt9t+ 1684 XZ9KskbRjLSmB+oC6Kibnq/dOU3txQXe49N9fhoTG5kSCuAvRmA/AgNaLG1srgyL 1685 M+8woOcA8Jf01WboSwZ29zKOgXN8YjjF1lR9C9seZgE8eGFN2VZpaKIGUf28j8G9 1686 WJLRotOHOHj0ZKqfpp5iehpvDMwVyLcfgGiwsUHh2ppp9Fxyv8okru90f61fHza6 1687 HxfPp+uEHteJcSjaAEuPN7UOek+ue+Pfm1w3utd+UOkiZiSHnn0YqU0Dpx+nS8+u 1688 YAfdz9PkOD4DTpLK+zfr4bRdp2mwptutRZzDQ/hFiY97kPg4AFmnWBZHhIn8dFvk 1689 HNG2prk1d7OoUY9chJ6cWCzt5WW3opVlfk5dAXcb3K+aalVwVCIrkD9DaX4RVGkP 1690 HIshMqLGyvMpdcJKWay3mwNaqrmOSSBlHLJqe5eWwaD6peAwmUm0gwWJsZAKba0e 1691 bM5AUbFtOrUi59Jm38fdOlS3QXQk4MR012T4JPP8UPn/W5B/fhP95w3/kwSOPPH/ 1692 d0//YVnJ5EaTtTjTNGejPC+2LaoGfbOflcoUaJWzpXDHxvyDMAs2CVtC4pyMHIfL 1693 hNjFwnjNNfzaKqU52TpArZQs64UNXe2dk6+ll6jZXvgpu7A69FiUdFSTcQ01gb86 1694 qmRwlgBPYuRsiU4FfoWplpqRioWLRl+2vkM36OZ6yWkWJlZx34jo3P2s/rNVTZnv 1695 k8ILlc32mOkKgduEuAPCCtn2FXoVsCzceKhjb2dccvK8gBKvbaDHp+31CAlemIj9 1696 acmh83IjGgmjAJT0z/FSOEUBL15RTwU8g9nM0s20q8x5ft8NUkhV68X5urd5CHFy 1697 VMHDUEGvO7lYSTgZi5ncSOiwVrZePrh6vp2rkdYew9ypb6oEW6csbFXqujKFvIVS 1698 KrjoW6CZ4+S29lEs9tSJTxbLqVCp3WDo3KzxSHnlhm5+ZM7tvFqtnNMUYamdWF74 1699 /RJKo8shwojupv8gBrcvLwtcMTv7tJp53OWycXIzLrpN1oA1QjMUtj5hCyLU++xc 1700 6j1VS1CM7njnQPi5sM/yhdOpSK0PydTP6URe50G+N2SwDhxxneex2YTiEg8yiQ1b 1701 7NROp/R6BV3anCO3UTLlpbzbRg0jNMzGbWfN0DKVGPDoGZYdK9sHDUeU2/nOIzCa 1702 XCbm0ZBpoMQNtLjyTa3DZ3sWRbVrAH8PJ7NE3aIdj0+1o56Kam8pem7lhC5ag48s 1703 nKo/n21zTuTXKT1Aw3JHMinFHQ661cwBvyLu7/RyPSZKUTjoEoFU8eJEJriNSrYZ 1704 ivbmwtSeuiTdGngFCwlklE3JWTqds8YllhVND2KNEbItNWwZbN/q2oHfB4Jhq9vv 1705 n/7zFv+/efnna+s/An5T/+EoSWDEDf8x7An/vx/6z+OUAD3GCR9KCdBjnPChlAA9 1706 ygmP6j9P9fBTPfxUDz/Vwz+Uevgd/1+il6FfVuU+9IuPyv+31/3u3/9EYQQjMPjG 1707 /yhGPfH/x2jt/ngXVMHP36R/0eAfjkX0smqS17dDfrEPo5+/fTb49mhYHV77czzA 1708 Q4qMSJJC4NcohkzoDffaTk8/maDIhI+CCTo6eoLgd8jijkAmgma/fv38ST76Dsf/ 1709 /Zd99w2n/1+r/yAo8e79b/Q+/hH86fnPR2ljzE7eBfqY72EvvyTaJ5a0mqEv4eeQ 1710 u/fv3n6b2ao1QRbjp5foS/yToPHLMH11XaQCHiil36a7Fhkv0fzhBV81vd/s2rsJ 1711 NVr4pjrcTegqmPz0cfz52Sedn7zyyXBOhPFzyK7uJuA2yIdrHgWmh8vGUc0xGKEo 1712 /DnE+l10N/lKYHoOMX5RvJDYu8nncW08YEX13eQNvD2HpDchcjf5cS4XsKQ2wVXo 1713 jDV+9XChWFXEmFjXSLpZJ/FZoqghMhCROqyDMQ2mYzJUOVgGpblnteNzaPJpm3ZB 1714 b+0XXUbJVV7W0Rasu4wIrzVQ2jyj/GG3iSMcDvyWv2C4mOpuiHkiGmJ2D4o6aD7b 1715 1yFvj1zAeU5Jl5K5zsp9amCrPdGIvePmympXJRJKSrWZGNyrH0/eTemFVMbjTf5p 1716 2nXH9m42e98ls9vT4Z994hfJq6b1X7Spj4w3qCq7sYMXalQmXXo3gZ8w/vuK/4eo 1717 bf0k+sjP/2F8tN30HxInSfR2HkJQ5JP+84T/3wz+fyi0/yCB7HPxfwP0b+E3vi7+ 1718 YYp8V//d7AiBEE/v/32UZokA+ePP1f5/8mqCzefwDiZQzA99dEdR6HwRhNRuvtjF 1719 ZDy/hdEOwdEQfyL637L43ydltPvo8Y+++f/fW/yT989/COKJ/z9O+8Uvu8m//Po/ 1720 8tWf/uV//td++fe/+NeX/+j7w49+9Vf/+2//Tfzon/+6tKTf+7+//Yn2+7/bBX/w 1721 73/+T7/6w7/4dfg/f/NHf/cPv/ydP/v/9s0ktIkoDuNasOJgQUFBkdJB9FACzeyT 1722 BKfQdE0hbbRJbEN7mEymySSdZJrNJIjQU6UILrihniriBi4IWnsRPYjrSfQgVITi 1723 LijoQUWok5Ta1DYZQs1Q5f8jh4GQIXnJ9733vu9FePXo/bKLW/Zfv5oYfjHZ8vxK 1724 742XKbvr8bMaP9u5bOv58deHHjQNNB8+tfFec+rNyDq2vi5Us2L9gdMToxXM25GD 1725 Q8tBgUtO/3ViWNBX/zT7W/8sRk73vzD/68IiQwwDssjkQkZKiStgwVE2/UvhpBQv 1726 TwWkpX8aI2f0TzBETv8sg4H+9aB4yVOkHZq7mbaQOIXTZtTW4bY5F2qBSAtGWDAy 1727 1wJp5w27k5y6+45wrpgYbUDV7QdmoiiaYPIvbR2ozUGhhW5RhcS4LjEWkyJhtKvJ 1728 UYUInOYr4hyW3fXLHJ/wSRGUMuMsge5wOowNbkf2CZ6LxhWZVywY6mi0u4wm9cf7 1729 j4cEf+q/HBWQ5vnf/P6HJOD/3zoyLVh0ntBndF4k+SukowWDQNN0gqeV+c1kg2VJ 1730 +uZ41EK5ZKGmKM+8pmNCXohb8t9doaGon1MYdbT7Ew1eRe5RVzkDqRZ5oDOUkO02 1731 g93THbQSktvYsZNOxVq2D2aajAqVliLJaLt1MOAjnZ6Q6A/nlzwxOdIWTWdCZr/T 1732 2sa2Bo1iVEo1t9j6TUSEbAjLXkOjzRv1+wYw0t/KNzG2xmRIcQ9G7N0eT9CX7Mq/ 1733 l5IW0m2dgQAuyK4U6TW7o6TiSTQHDIIVwxWvfbvJigsBg0GyB3dxmwv3RQt8/qKF 1734 kTOtqKPNK4o6hHxc9WljzKfMj2Fxiq1CqhCYEXTx/3JUQJr9P0bO9j9sbv1Hgf+D 1735 //8X/g9uB/xD/l+OClDz/Cc2e/4Tx7Prf5qhIf/XhVz/92f2U8upRiOaWYESVXMl 1736 cbP65fBivzop46QgUCTP8OrDywgYC+r/z/RfhgqwlP4ve509/83A+U9doI7XLR/v 1737 51Nvjq3tP/yu7videvzI5MrAkZ9Pb9697biITZ3dNzr6437lub4JxpdZ9fHE0IeH 1738 Zm4Ia/0YmMqMXV2zo+ZLkK1In/y2edOlleKTVGWgfi/yvdZ9YXXfUSH59fz9R8OW 1739 DYmoiE/ccl3O9Iy17VGq6TPX1nyu7h3+NEpsAwUuRf3/3QqwlP6PzPV/LEZD/q8L 1740 i8ykYsgigygFKSV9gtUGAAAAAAAAAAAAAAAAAAAAAACAFr8AHiHENgB4AAA= 1741 -- END MESSAGE ARCHIVE -- 1743 Appendix C. Changelog 1745 NOTE TO THE RFC-EDITOR: Please remove this section prior to 1746 publication as an RFC. 1748 Changes from draft-ietf-sip-identity-04: 1749 - Changed the delimiter of the digest-string from ":" to "|" 1750 - Removed support for the SIPS URI scheme from the Identity-Info 1751 header 1752 - Made the Identity-Info header extensible; added an Identity-Info 1753 header for algorithm with an initial defined value of 'rsa-sha1' 1754 - Broke up the Security Considerations into smaller chunks for 1755 organizational reasons; expanded discussion of most issues 1756 - Added some guidelines for authentication service certificate 1757 rollover and lifecycle management (also now based HTTP certificate 1758 retrieval on RFC2585) 1760 Changes from draft-ietf-sip-identity-03: 1761 - Softened requirement for TLS and direct connections; now SHOULD- 1762 strength, SIPS and Digest auth-int listed as alternatives. 1763 - Added non-normative section about authentication service 1764 behavior for backwards-direction requests within a dialog 1765 - Added support for CID URI in Identity Info 1766 - Added new response codes (436 and 437) corresponding to error 1767 cases for an unsupported URI scheme and an unsupported 1768 certificate, respectively 1770 Changes from draft-ietf-sip-identity-02: 1771 - Extracted text relating to providing identity in SIP responses; 1772 this text will appear in a separate draft 1773 - Added compliance testing/example section 1774 - Added CSeq to the signature of the Identity header to prevent a 1775 specific cut-and-paste attack; also added addr-spec of the To 1776 header to the signature of the Identity header for similar reasons 1777 - Added text about why neither Via headers nor display-names are 1778 protected by this mechanism 1779 - Added bit-exact reference files for compliance testing 1780 - Added privacy considerations 1782 Changes from draft-ietf-sip-identity-01: 1783 - Completely changed underlying mechanism - instead of using an 1784 AIB, the mechanism now recommends the use of the Identity header 1785 and Identity-Info header 1786 - Numerous other changes resulting from the above 1787 - Various other editorial corrections 1789 Changes from draft-peterson-sip-identity-01: 1790 - Split off child draft-ietf-sip-authid-body-00 for defining of 1791 the AIB 1792 - Clarified scope in introduction 1793 - Removed a lot of text that was redundant with RFC3261 1794 (especially about authentication practices) 1795 - Added mention of content indirection mechanism for adding token 1796 to requests and responses 1797 - Improved Security Considerations (added piece about credential 1798 strength) 1800 Changes from draft-peterson-sip-identity-00: 1801 - Added a section on authenticated identities in responses 1802 - Removed hostname convention for authentication services 1803 - Added text about using 'message/sip' or 'message/sipfrag' in 1804 authenticated identity bodies, also RECOMMENDED a few more headers 1805 in sipfrags to increase reference integrity 1806 - Various other editorial corrections 1808 Intellectual Property Statement 1810 The IETF takes no position regarding the validity or scope of any 1811 Intellectual Property Rights or other rights that might be claimed to 1812 pertain to the implementation or use of the technology described in 1813 this document or the extent to which any license under such rights 1814 might or might not be available; nor does it represent that it has 1815 made any independent effort to identify any such rights. Information 1816 on the procedures with respect to rights in RFC documents can be 1817 found in BCP 78 and BCP 79. 1819 Copies of IPR disclosures made to the IETF Secretariat and any 1820 assurances of licenses to be made available, or the result of an 1821 attempt made to obtain a general license or permission for the use of 1822 such proprietary rights by implementers or users of this 1823 specification can be obtained from the IETF on-line IPR repository at 1824 http://www.ietf.org/ipr. 1826 The IETF invites any interested party to bring to its attention any 1827 copyrights, patents or patent applications, or other proprietary 1828 rights that may cover technology that may be required to implement 1829 this standard. Please address the information to the IETF at 1830 ietf-ipr@ietf.org. 1832 Disclaimer of Validity 1834 This document and the information contained herein are provided on an 1835 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1836 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1837 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1838 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1839 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1840 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1842 Copyright Statement 1844 Copyright (C) The Internet Society (2005). This document is subject 1845 to the rights, licenses and restrictions contained in BCP 78, and 1846 except as set forth therein, the authors retain all their rights. 1848 Acknowledgment 1850 Funding for the RFC Editor function is currently provided by the 1851 Internet Society.