idnits 2.17.1 draft-ietf-sip-identity-04.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1598. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1614), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 19 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 655 has weird spacing: '... where prox...' == Line 663 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 (February 16, 2005) is 7006 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: '7' is defined on line 1329, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '7') (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 3761 (ref. '10') (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. -------------------------------------------------------------------------------- 1 SIP WG J. Peterson 2 Internet-Draft NeuStar 3 Expires: August 17, 2005 C. Jennings 4 Cisco Systems 5 February 16, 2005 7 Enhancements for Authenticated Identity Management in the Session 8 Initiation Protocol (SIP) 9 draft-ietf-sip-identity-04 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 17, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 The existing security mechanisms in the Session Initiation Protocol 43 are inadequate for cryptographically assuring the identity of the end 44 users that originate SIP requests, especially in an interdomain 45 context. This document recommends practices and conventions for 46 identifying end users in SIP messages, and proposes a way to 47 distribute cryptographically-secure authenticated identities. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Overview of Operations . . . . . . . . . . . . . . . . . . . 6 56 6. Authentication Service Behavior . . . . . . . . . . . . . . 7 57 6.1 Identity within a Dialog and Retargeting . . . . . . . . . 9 58 7. Verifying Identity . . . . . . . . . . . . . . . . . . . . . 11 59 8. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 12 60 9. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . 12 61 10. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 62 11. Compliance Tests and Examples . . . . . . . . . . . . . . . 15 63 11.1 Identity-Info with a Singlepart MIME body . . . . . . . 16 64 11.2 Identity for a Request with no MIME body or Contact . . 18 65 12. Identity and the TEL URI Scheme . . . . . . . . . . . . . . 21 66 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 67 14. Security Considerations . . . . . . . . . . . . . . . . . . 23 68 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 69 15.1 Header Field Names . . . . . . . . . . . . . . . . . . . 27 70 15.2 428 'Use Identity Header' Response Code . . . . . . . . 27 71 15.3 436 'Bad Identity-Info' Response Code . . . . . . . . . 28 72 15.4 437 'Unsupported Certificate' Response Code . . . . . . 28 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 74 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30 75 B. Bit-exact archive of example messages . . . . . . . . . . . 30 76 B.1 Encoded Reference Files . . . . . . . . . . . . . . . . . 31 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 78 16.1 Normative References . . . . . . . . . . . . . . . . . . . 28 79 16.2 Informative References . . . . . . . . . . . . . . . . . . 29 80 C. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . 33 81 Intellectual Property and Copyright Statements . . . . . . . 35 83 1. Introduction 85 This document provides enhancements to the existing mechanisms for 86 authenticated identity management in the Session Initiation Protocol 87 (SIP [1]). An identity, for the purposes of this document, is 88 defined as a canonical SIP address-of-record URI employed to reach a 89 user (such as 'sip:alice@atlanta.example.com'). 91 RFC3261 stipulates several places within a SIP request that a user 92 can express an identity for themselves, notably the user-populated 93 From header field. However, the recipient of a SIP request has no 94 way to verify that the From header field has been populated 95 accurately, in the absence of some sort of cryptographic 96 authentication mechanism. 98 RFC3261 specifies a number of security mechanisms that can be 99 employed by SIP UAs, including Digest, TLS and S/MIME 100 (implementations may support other security schemes as well). 101 However, few SIP user agents today support the end-user certificates 102 necessary to authenticate themselves via TLS or S/MIME, and 103 furthermore Digest authentication is limited by the fact that the 104 originator and destination must share a pre-arranged secret. It is 105 desirable for SIP user agents to be able to send requests to 106 destinations with which they have no previous association - just as 107 in the telephone network today, one can receive a call from someone 108 with whom one has no previous association, and still have a 109 reasonable assurance that their displayed Caller-ID is accurate. 111 2. Terminology 113 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 115 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 116 described in RFC2119 [2] and indicate requirement levels for 117 compliant SIP implementations. 119 3. Background 121 The usage of many SIP applications and services is governed by 122 authorization policies. These policies may be automated, or they may 123 be applied manually by humans. An example of the latter would be an 124 Internet telephone application which displays the "Caller-ID" of a 125 caller, which a human may review before answering a call. An example 126 of the former would be a presence service that compares the identity 127 of potential subscribers to a whitelist before determining whether it 128 should begin sending presence notifications. In both of these cases, 129 attackers might attempt to circumvent these authorization policies 130 through impersonation. Since the primary identifier of the sender of 131 a SIP request, the From header field, can be populated arbitrarily be 132 the controller of a user agent, impersonation is very simple today. 133 The mechanism described in this document aspires to provide a strong 134 identity system for SIP in which authorization policies cannot be 135 circumvented by impersonation. 137 All RFC3261-compliant SIP user agents support a means of 138 authenticating themselves to a SIP registrar, commonly with a shared 139 secret; Digest authentication, which MUST be supported by SIP user 140 agents, is typically used for this purpose. Registration allows a 141 user agent to express that it is an appropriate entity to which 142 requests should be sent for a particular address-of-record SIP URI 143 (e.g., 'sip:alice@atlanta.example.com'). 145 By the definition of identity used in this document, registration is 146 a proof of the identity of the user to a registrar. However, the 147 credentials with which a user agent proves their identity to a 148 registrar cannot be validated by just any user agent or proxy server 149 - these credentials are only shared between the user agent and their 150 domain administrator. So this shared secret does not immediately 151 help a user to authenticate to a wide range of recipients. 152 Recipients require a means of determining whether or not the 'return 153 address' identity of a non-REGISTER request (i.e., the From header 154 field value) has legitimately been asserted. 156 The address-of-record URI used for registration is also the URI with 157 which a UA commonly populates the From header of requests in order to 158 provide a 'return address' identity to recipients. The identity 159 mechanism specified in this document derives from the following 160 principle: if you can prove you are eligible to register in a domain 161 under a particular address-of-record, you are proving that you are 162 capable of legitimately receiving requests for that 163 address-of-record, and accordingly, when you place that 164 address-of-record in the From header field of a SIP request other 165 than a registration (like an INVITE), you are providing a 'return 166 address' where you can legitimately be reached. In other words, if 167 you are authorized to receive requests for that 'return address', 168 logically, it follows that you are also authorized to assert that 169 'return address' in your From header field. 171 Ideally, then, SIP user agents should have some way of proving to 172 recipients of SIP requests that their local domain has authenticated 173 them and authorized the population of the From header field. This 174 document proposes a mediated authentication architecture for SIP in 175 which requests are sent to a server in the user's local domain, which 176 authenticates such requests (using the same practices by which the 177 domain would authenticate REGISTER requests). Once a message has 178 been authenticated, the local domain then needs some way to 179 communicate to other SIP entities that the sending user has been 180 authenticated and their use of the From header field has been 181 authorized. This draft addresses how that imprimatur of 182 authentication can be shared. 184 RFC3261 already describes an architecture very similar to this in 185 Section 26.3.2.2, in which a user agent authenticates itself to a 186 local proxy server which in turn authenticates itself to a remote 187 proxy server via mutual TLS, creating a two-link chain of transitive 188 authentication between the originator and the remote domain. While 189 this works well in some architectures, there are a few respects in 190 which this is impractical. For one, transitive trust is inherently 191 weaker than an assertion that can be validated end-to-end. It is 192 possible for SIP requests to cross multiple intermediaries in 193 separate administrative domains, in which case transitive trust 194 becomes even less compelling. 196 One solution to this problem is to use 'trusted' SIP intermediaries 197 that assert an identity for users in the form of a privileged SIP 198 header. A mechanism for doing so (with the P-Asserted-Identity 199 header) is given in [8]. However, this solution allows only 200 hop-by-hop trust between intermediaries, not end-to-end cryptographic 201 authentication, and it assumes a managed network of nodes with strict 202 mutual trust relationships, an assumption that is incompatible with 203 widespread Internet deployment. 205 Accordingly, this document specifies a means of sharing a 206 cryptographic assurance of end-user SIP identity in an interdomain 207 context which is based on the concept of an 'authentication service' 208 and a new SIP header, the Identity header. Note that the scope of 209 this document is limited to providing this identity assurance for SIP 210 requests; solving this problem for SIP responses is more complicated, 211 and is a subject for future work. 213 This specification allows either a user agent or a proxy server to 214 act as an authentication service. To maximize end-to-end security, 215 it is obviously preferable for end users to hold their own 216 certificates; if they do, they can act as an authentication service. 217 However, end-user certificates may be neither practical nor 218 affordable, given the difficulties of establishing a PKI that extends 219 to end users, and moreover, given the potentially large number of SIP 220 user agents (phones, PCs, laptops, PDAs, gaming devices) that may be 221 employed by a single user. In such environments, synchronizing 222 certificates across multiple devices may be very complex, and 223 requires quite a good deal of additional endpoint behavior. Managing 224 several certificates for the various devices is also quite 225 problematic and unpopular with users. Accordingly, in the initial 226 use of this mechanism, it is likely that intermediaries will 227 instantiate the authentication service role. 229 4. Requirements 231 This draft addresses the following requirements: 232 o The mechanism must allow a UAC to provide a strong cryptographic 233 identity assurance in a request that can be verified by a proxy 234 server or UAS. 235 o User agents that receive identity assurances must be able to 236 validate these assurances without performing any network lookup. 237 o User agents that hold certificates on behalf of their user must be 238 capable of adding this identity assurance to requests. 239 o Proxy servers that hold certificates on behalf of their domain 240 must be capable of adding this identity assurance to requests; a 241 UAC is not required to support this mechanism in order for an 242 identity assurance to be added to a request in this fashion. 243 o The mechanism must prevent replay of the identity assurance by an 244 attacker. 245 o The mechanism must be capable of protecting the integrity of SIP 246 message bodies (to ensure that media offers and answers are linked 247 to the signaling identity). 248 o It must be possible for a user to have multiple AoRs (i.e. 249 accounts or aliases) under which it is known at a domain, and for 250 the UAC to assert one identity while authenticating itself as 251 another, related, identity, as permitted by the local policy of 252 the domain. 253 o It must be possible, in cases where a request has been retargeted 254 to a different AoR than the one designated in the To header field, 255 for the UAC to ascertain the AoR to which the request has been 256 sent. 258 5. Overview of Operations 260 This section provides an informative (non-normative) high-level 261 overview of the mechanisms described in this document. 263 Imagine the case where Alice, who has the home proxy of example.com 264 and the address-of-record sip:alice@example.com, wants to communicate 265 with sip:bob@example.org. 267 Alice generates an INVITE and places her identity in the From header 268 field of the request. She then sends an INVITE over TLS to an 269 authentication service proxy for her domain. 271 The authentication service authenticates Alice (possibly by sending a 272 Digest authentication challenge) and validates that she is authorized 273 to populate the value of the From header field (which may be Alice's 274 AoR, or it may be some other value that the policy of the proxy 275 server permits her to use). It then computes a hash over some 276 particular headers, including the From header field and the bodies in 277 the message. This hash is signed with the certificate for the domain 278 (example.com, in Alice's case) and inserted in a new header field in 279 the SIP message, the 'Identity' header. 281 The proxy, as the holder the private key of its domain, is asserting 282 that the originator of this request has been authenticated and that 283 she is authorized to claim the identity (the SIP address-of-record) 284 which appears in the From header field. The proxy also inserts a 285 companion header field that tells Bob how to acquire its certificate, 286 if he doesn't already have it. 288 When Bob's domain receives the request, it verifies the signature 289 provided in the Identity header, and thus can authenticate that the 290 domain indicated by the host portion of the AoR in the From header 291 field authenticated the user, and permitted them to assert that From 292 header field value. 294 6. Authentication Service Behavior 296 This document defines a new role for SIP entities called an 297 authentication service. The authentication service role can be 298 instantiated by a proxy server or a user agent. Any entity that 299 instantiates the authentication service role MUST possess the private 300 key of a domain certificate, and MUST be capable of authenticating 301 one or more SIP users that can register in that domain. Commonly, 302 this role will be instantiated by a proxy server, since these 303 entities are more likely to have a static hostname, hold a 304 corresponding certificate, and access to SIP registrar capabilities 305 that allow them to authenticate users in their domain. It is also 306 possible that the authentication service role might be instantiated 307 by a redirect server, but that is left as a topic for future work. 309 SIP entities that act as an authentication service MUST add a Date 310 header field to SIP requests if one is not already present. 311 Similarly, authentication services MUST add a Content-Length header 312 field to SIP requests if one is not already present; this can help 313 the verifier to double-check that they are hashing exactly as many 314 bytes of message-body as the authentication service when they verify 315 the message. 317 The authentication service authenticates the identity of the message 318 sender and validates that the identity given in the message can 319 legitimately be asserted by the sender. Then it computes a signature 320 over the canonical form of several headers and all the bodies, and 321 inserts this signature into the message. 323 First, an authentication service MUST extract the identity of the 324 sender from the request. The authentication service takes this value 325 from the From header field; this AoR will be referred to here as the 326 'identity field'. If the identity field contains a SIP or SIPS URI, 327 the authentication service MUST extract the hostname portion of the 328 identity field and compare it to the domain(s) for which it is 329 responsible. If the identity field uses the TEL URI scheme, the 330 policy of the authentication service determines whether or not it is 331 responsible for this identity; see Section 12 for more information. 332 If the authentication service is not responsible for the identity in 333 question, it SHOULD process and forward the request normally, but it 334 MUST NOT add an Identity header; see below for more information on 335 authentication service handling of an existing Identity header. 337 Second, the authentication service needs to determine whether or not 338 the sender of the request is authorized to claim the identity given 339 in the identity field. In order to do so, the authentication service 340 MUST authenticate the sender of the message. Some possible ways in 341 which this authentication might be performed include: 342 o If the authentication service is instantiated by a SIP 343 intermediary (proxy server), it may challenge the request with a 344 407 response code using the Digest authentication scheme (or 345 viewing a Proxy-Authentication header sent in the request which 346 was sent in anticipation of a challenge using cached credentials, 347 as described in RFC 3261 Section 22.3). 348 o If the authentication service is instantiated by a SIP user agent, 349 a user agent can be said to authenticate its user on the grounds 350 that the user can provision the user agent with the private key of 351 the domain, or by preferably by providing a password that unlocks 352 said private key. 354 Authorization of the use of a particular username in the From header 355 field is a matter of local policy for the authorization service, one 356 which depends greatly on the manner in which authentication is 357 performed. For example, one policy might be as follows: the username 358 given in the 'username' parameter of the Proxy-Authorization header 359 MUST correspond exactly to the username in the From header field of 360 the SIP message. However, there are many cases in which this is too 361 limiting or inappropriate; a realm might use 'username' parameters in 362 Proxy-Authorization which do not correspond to the user-portion of 363 SIP From headers, or a user might manage multiple accounts in the 364 same administrative domain. In this latter case, a domain might 365 maintain a mapping between the values in the 'username' parameter of 366 Proxy-Authorization and a set of one or more SIP URIs which might 367 legitimately be asserted for that 'username'. In this instance, 368 another policy might be as follows: the URI in the From header field 369 MUST correspond exactly to one of the mapped URIs associated with the 370 'username' given in the Proxy-Authorization header. Various 371 exceptions to such policies might arise for cases like anonymity; if 372 the AoR asserted in the From header field is anonymous (per RFC3323 373 [3]), then the proxy should authenticate that the user is a valid 374 user in the domain and insert the signature over the From header 375 field as usual. 377 Note that this check is performed on the addr-spec in the From header 378 field (e.g., the URI of the sender, like 379 'sip:alice@atlanta.example.com'); it does not convert the 380 display-name portion of the From header field (e.g., 'Alice 381 Atlanta'). Some SIP user agents that receive requests render the 382 display-name of the caller as the identity of the caller. However, 383 there are many environments in which legislating the display-name 384 isn't feasible, judging from experience with email, where users 385 frequent make slight textual changes to their display-names. 386 Ultimately, there is more value in focusing on the SIP address of the 387 sender (which has some meaning in the network and provides a chain of 388 accountability) than trying to constrain how the display-name is set. 389 As such, authentication services MAY check the display-name as well, 390 and compare it to a list of acceptable display-names that may be used 391 by the sender; if the display-name does not meet policy constraints, 392 the authentication service MUST return a 403 'Inappropriate 393 Display-Name' response code. However, in many environments this will 394 not make sense. For more information on rendering identity in a user 395 interface, see Section 8. 397 Third, the authentication service MUST form the identity signature 398 and add an Identity header to the request containing this signature. 399 After the Identity header has been added to the request, the 400 authentication service MUST also add an Identity-Info header. The 401 Identity-Info header contains a URI from which its certificate can be 402 acquired. Details are provided in section Section 10. 404 Finally, the authentication service MUST forward the message 405 normally. 407 6.1 Identity within a Dialog and Retargeting 409 Retargeting, the alteration by intermediaries of the Request-URI of a 410 SIP request, can cause a few wrinkles for the Identity mechanism when 411 it is applied to requests sent in the backwards direction within a 412 dialog. This section provides some non-normative considerations 413 related to this case. 415 When a request is retargeted, it may reach a SIP endpoint whose user 416 is not identified by the URI designated in the To header field value. 417 The value in the To header field of a dialog-forming request is used 418 as the From header field of requests sent in the backwards direction 419 during the dialog, and is accordingly the header that would be signed 420 by an authentication service for requests sent in the backwards 421 direction. In retargeting cases, if the URI in the From header does 422 not identify the sender of the request in the backwards direction, 423 then clearly it would be inappropriate to provide an Identity 424 signature over that From header. As specified above, if the 425 authentication service is not responsible for the domain in the From 426 header field of the request, it must not add an Identity header to 427 the request, and should process/forward the request normally. 429 If there were a means in backwards-direction requests to signify a 430 'connected party', an identity of the unanticipated user whose SIP 431 endpoint was reached by the dialog-forming request, it isn't clear 432 that it would actually be beneficial to provide a corresponding 433 Identity header signature over that information. The Identity header 434 is designed to prevent impersonation-based attacks, and it is very 435 unclear how and why an attacker might attempt to impersonate an 436 unanticipated third party in a backwards-direction request within an 437 existing dialog. That is, it's unclear how the caller's potential 438 authorization policies would be any more successful at thwarting 439 impersonation if new requests in the backwards direction came from an 440 assured unanticipated third-party instead of an unassured 441 unanticipated third-party. Thwarting impersonation is, ultimately, 442 the purpose of this Identity mechanism, and it must be left to other 443 mechanisms to solve other security problems for SIP. 445 The mechanism in this draft cannot aid in determining whether or not 446 the unanticipated party is an appropriate target of this request and, 447 accordingly, solving this problem is outside the scope of this draft. 448 If, however, it were possible for the sender of the dialog-forming 449 request to anticipate that retargeting had occurred, and to gain some 450 kind of assurance of the new target of the request before any 451 requests in the backwards direction were received, this would open up 452 some new approaches to authorization policy. 454 Any such means of anticipating retargeting and so on is outside the 455 scope of this document, and likely to have equal applicability to 456 response identity as it does to requests in the backwards direction 457 within a dialog. Consequently, no special guidandance is given for 458 implementers here regarding the 'connected party' problem; 459 authentication service behavior is unchanged if retargeting has 460 occurred for a dialog-forming request. Ultimately, the 461 authentication service provides an Identity header for requests in 462 the backwards dialog when the user is authorized to assert the 463 identity given in the From header field, and if they are not, an 464 Identity header is not provided. 466 7. Verifying Identity 468 When a user agent or proxy server receives a SIP message containing 469 an Identity header, it may inspect the signature to verify the 470 identity of the sender of the message. If an Identity header is not 471 present in a request, and one is required by local policy (for 472 example, based on a global policy, a per-sending-domain policy, or a 473 per-sending-user policy), then a 428 'Use Identity Header' response 474 MUST be sent. 476 In order to verify the identity of the sender of a message, the user 477 agent or proxy server MUST first acquire the certificate for the 478 signing domain. Implementations supporting this specification should 479 have some means of retaining domain certificates (in accordance with 480 normal practices for certificate lifetimes and revocation) in order 481 to prevent themselves from needlessly downloading the same 482 certificate every time a request from the same domain is received. 483 Certificates retained in this manner should be indexed by the URI 484 given in the Identity-Info header field value. 486 Provided that the domain certificate used to sign this message is not 487 previously known to the recipient, SIP entities SHOULD discover this 488 certificate by dereferencing the Identity-Info header, unless they 489 have some more efficient implementation-specific way of acquiring 490 certificates for that domain. If the URI scheme in the Identity-Info 491 header cannot be dereferenced, then a 436 'Bad Identity-Info' 492 response MUST be returned. The client processes this certificate in 493 the usual ways, including checking that it has not expired, that the 494 chain is valid back to a trusted CA, and that it does not appear on 495 revocation lists. Once the certificate is acquired, it MUST be 496 validated. If the certificate cannot be validated (it is self-signed 497 and untrusted, or signed by an untrusted or unknown certificate 498 authority), the verifier MUST send a 437 'Unsupported Certificate' 499 response. 501 Subsequently, the recipient MUST verify the signature in the Identity 502 header, and compare the identity of the signer (the subjectAltName of 503 the certificate) with the domain portion of the URI in the From 504 header field of the request as described in Section 14. 505 Additionally, the Date, Contact and Call-ID headers MUST be analyzed 506 in the manner described in Section 14; recipients that wish to verify 507 Identity signatures MUST support all of the operations described 508 there. 510 If a verifier determines that the signature on the message does not 511 correspond to the text of the message, then a 428 'Invalid Identity 512 Header' response MUST be returned. 514 Once the identity of the sender of a request has been ascertained, 515 various policies MAY be used to make authorization decisions about 516 accepting communications and the like. Such policies are outside the 517 scope of this document. 519 8. User Agent Behavior 521 This mechanism can be applied opportunistically to existing SIP 522 deployments; accordingly, it requires no change to SIP user agent 523 behavior in order for it to be effective. However, because this 524 mechanism does not provide integrity protection between the UAC and 525 the authentication service, a UAC SHOULD implement some means of 526 providing this integrity. TLS would be one such mechanism, which is 527 attractive because it MUST be supported by SIP proxy servers, but is 528 potentially problematic because it is a hop-by-hop mechanism. See 529 Section 14 for more information about securing the channel between 530 the UAC and the authentication service. 532 When a UAC sends a request, it MUST accurately populate the header 533 field that asserts its identity (for a SIP request, this is the From 534 header field). In a request it MUST set the URI portion of its From 535 header to match a SIP, SIPS or TEL URI AoR under which the UAC can 536 register (including anonymous URIs, as described in RFC 3323 [3]). 537 In general, UACs SHOULD NOT use the TEL URI form in the From header 538 field (see Section 12). 540 The UAC MUST also be capable of sending requests, including mid-call 541 requests, through an 'outbound' proxy (the authentication service). 542 The best way to accomplish this is using pre-loaded Route headers and 543 loose routing. UAC implementations MUST provide a way of 544 provisioning pre-loaded Route headers in order for this mechanism to 545 work for mid-call requests in the backwards direction of a dialog. 547 As a recipient of a request, a user agent that can verify signed 548 identities should also support an appropriate user interface to 549 render the validity of identity to a user. User agent 550 implementations SHOULD differentiate signed From header field values 551 from unsigned From header field values when rendering to an end user 552 the identity of the sender of a request. 554 9. Proxy Server Behavior 556 Domain policy may require proxy servers to inspect and verify the 557 identity provided in SIP requests. A proxy server may wish to 558 ascertain the identity of the sender of the message to provide spam 559 prevention or call control services. Even if a proxy server does not 560 act as an authentication service, it MAY verify the existence of an 561 Identity before it makes a forwarding decision for a request. Proxy 562 servers MUST NOT remove or modify an existing Identity or 563 Identity-Info header in a request. 565 For the purposes of identifying mid-dialog requests, proxy servers 566 that instantiate the authentication service role MUST Record-Route 567 themselves in dialog-forming requests. 569 10. Header Syntax 571 This document specifies two new SIP headers: Identity and 572 Identity-Info. Each of these headers can appear only once in a SIP 573 message. 575 Identity = "Identity" HCOLON signed-identity-digest 576 signed-identity-digest = LDQUOT 32LHEX RDQUOT 578 Identity-Info = "Identity-Info" HCOLON ident-info 579 ident-info = LAQUOT absoluteURI RAQUOT 581 The signed-identity-digest is a signed hash of a canonical string 582 generated from certain components of a SIP request. To create the 583 contents of the signed-identity-digest, the following elements of a 584 SIP message MUST placed in a bit-exact string in the order specified 585 here, separated by a colon: 586 o The AoR of the UA sending the message, or the 'identity field'. 587 For a request, this is the addr-spec from the From header field. 588 o The addr-spec component of the To header field, which is the AoR 589 to which the request is being sent. 590 o The callid from Call-Id header field. 591 o The digit (1*DIGIT) and method (method) portions from CSeq header 592 field, separated by a single space (ABNF SP, or %x20). Note that 593 the CSeq header field allows LWS rather than SP to separate the 594 digit and method portions, and thus the CSeq header field may need 595 to be transformed in order to be canonicalized. The 596 authentication service MUST strip leading zeros from the 'digit' 597 portion of the Cseq before generating the digest-string. 598 o The Date header field, with exactly one space each for each SP and 599 the weekday and month items case set as shown in BNF in 3261. The 600 first letter is upper case and the rest of the letters are lower 601 case. All requests that use the Identity mechanism MUST contain a 602 Date header. 603 o The addr-spec component of the Contact header field value. If the 604 request does not contain a Contact header, this field MUST be 605 empty (i.e., there will be no whitespace between the fourth and 606 fifth colons in the canonical string). 607 o The body content of the message with the bits exactly as they are 608 in the Message (in the ABNF for SIP, the message-body). Note that 609 the message-body does NOT include the CRLF separating the SIP 610 headers from the message-body, but does include everything that 611 follows that CRLF. If the message has no body, then message-body 612 will be empty, and the final colon will not be followed by any 613 additional characters. 615 For more information on the security properties of these headers, and 616 why their inclusion mitigates replay attacks, see Section 14 and [5]. 617 The precise formulation of this digest-string is, therefore 618 (following the ABNF [6] in RFC3261): 620 digest-string = addr-spec ":" addr-spec ":" callid ":" 1*DIGIT SP method ":" 621 SIP-Date ":" [ addr-spec ] ":" message-body 623 Note again that the first addr-spec MUST be taken from the From 624 header field value, the second addr-spec MUST be taken from the To 625 header field value, and the third addr-spec MUST be taken from the 626 Contact header field value, provided the Contact header is present in 627 the request. 629 After the digest-string is formed, it MUST be hashed and signed with 630 the certificate for the domain, as follows: compute the results of 631 signing this string with sha1WithRSAEncryption as described in RFC 632 3370 and base64 encode the results as specified in RFC 3548. Put the 633 result in the Identity header. 635 Note on this choice: Assuming a 1024 bit RSA key, the raw signature 636 will result in about 170 octets of base64 encoded data (without 637 base64, as an aside, it would be about 130 bytes). For comparison's 638 sake, a typical HTTP Digest Authorization header (such as those used 639 in RFC3261) with no cnonce is around 180 octets. From a speed point 640 of view, a 2.8GHz Intel processor does somewhere in the range of 250 641 RSA 1024 bits signs per second or 1200 RSA 512 bits signs; verifies 642 are roughly 10 times faster. Hardware accelerator cards are 643 available that speed this up. 645 The Identity-Info header MUST contain either an HTTPS URI or a SIPS 646 URI. If it contains an HTTPS URI, the URI must dereference to a 647 resource that contains a single MIME body containing the certificate 648 of the authentication service. If it is a SIPS URI, then the 649 authentication service intends for a user agent that wishes to fetch 650 the certificate to form a TLS connection to that URI, acquire the 651 certificate during normal TLS negotiation, and close the connection. 653 This document adds the following entries to Table 2 of [1]: 655 Header field where proxy ACK BYE CAN INV OPT REG 656 ------------ ----- ----- --- --- --- --- --- --- 657 Identity R a o o - o o - 659 SUB NOT REF INF UPD PRA 660 --- --- --- --- --- --- 661 o o o o o o 663 Header field where proxy ACK BYE CAN INV OPT REG 664 ------------ ----- ----- --- --- --- --- --- --- 665 Identity-Info R a o o - o o - 667 SUB NOT REF INF UPD PRA 668 --- --- --- --- --- --- 669 o o o o o o 671 Note, in the table above, that this mechanism does not protect the 672 REGISTER method or the CANCEL method. The CANCEL method cannot be 673 challenged, because it is hop-by-hop, and accordingly authentication 674 service behavior for CANCEL would be significantly limited. The 675 REGISTER method uses Contact header fields in very unusual ways that 676 complicate its applicability to this mechanism. Accordingly, the 677 Identity and Identity-Info header MUST NOT appear in REGISTER or 678 CANCEL. 680 11. Compliance Tests and Examples 682 The examples in this section illustrate the use of the Identity 683 header in the context of a SIP transaction. Implementations MUST 684 verify their compliance with these examples, i.e.: 685 o Implementations of the authentication service role MUST generate 686 identical base64 identity strings to the ones shown in the 687 Identity headers in these examples when presented with the source 688 message and utilizing the appropriate supplied private key for the 689 domain in question. 690 o Implementations of the verifier role MUST correctly validate the 691 given messages containing the Identity header when utilizing the 692 supplied certificates (with the caveat about self-signed 693 certificates below). 695 Note that the following examples use self-signed certificates, rather 696 than certificates issued by a recognized certificate authority. The 697 use of self-signed certificates for this mechanism is NOT 698 RECOMMENDED, and appear here only for illustrative purposes. 699 Therefore, in compliance testing, implementations of verifiers SHOULD 700 generated appropriate warnings about the use of self-signed 701 certificates. 703 Bit-exact reference files for these messages and their various 704 transformations are supplied in Appendix B. 706 11.1 Identity-Info with a Singlepart MIME body 708 Consider the following private key and certificate pair assigned to 709 'atlanta.example.com'. 711 -----BEGIN RSA PRIVATE KEY----- 712 MIICXQIBAAKBgQC8HmM8b9E4WNhb7tZAoBVSkKyV9rAEX3nyQbg4hXte1oW1BxC+ 713 43MQHrG3nk6Kc9afPR6VloKwWoUoAcCnbTJ/zEiZ6dq+C5EsQGIOowYkSgqdO2po 714 joCnRgzgjgvAl41R2J6CE1kMwOQxNCxPnTco8l8UGdKbNLXIuNdUM1MG8QIDAQAB 715 AoGAAtPOGAVyNo+XSOJxE+2UBHaqMWLQyHAK7Coys57F+OnufocJqGTQwOhFMYZO 716 leQh0KjhgcwOUMo7gBtuotWQUbbLHTGKXiBR6Pqbm6CvhwJSuNYv0vONuTb1SMll 717 Kadg43na4B9kQeytn1y6lfkTkK2oYqkDVZ2AAmLSLrfhl1UCQQDp7VFItgmnybwK 718 PKwJs8gnF+u+K9j+sac/3vgGgrOvpxVqwoMXl6eWN//pZ/cqshanDLmtr9ahjWCD 719 DxYVyklrAkEAzd6JLJAhG8cZymVCS5Jf0F7FAVxpx0BgRPHwJliyUg6O4jPY+ASg 720 cLP6nz9a38wWZQj6rRygffGZHXbBFm+8EwJBAJmZEf5ESSK6+5VdMTlNqubAdjJw 721 aBMUY1U0+naL66AyfYWUIq+jDI8+RfLkKQ8H0IfvexvokW2SfwSPK1kzcfECQD/O 722 MQW2xgwt8ThhmeKCQ1/5f2WklsRCl5PGyH+aDeqQyIgjOaPlCzTjE1I3+JpUTryR 723 w9/Td4qRTrtrCv1BNDECQQCgHIzF8LFtI003w9MAEAoCyDbtHFPEj71b+qG22Yc4 724 SPFBAbo3JGO+mrB0MX/GwJr+3DfgzMHaUx/tinPr+u1D 725 -----END RSA PRIVATE KEY----- 726 -----BEGIN CERTIFICATE----- 727 MIIC/TCCAmagAwIBAgIBADANBgkqhkiG9w0BAQQFADBZMQswCQYDVQQGEwJVUzEQ 728 MA4GA1UECBMHR2VvcmdpYTESMBAGA1UEBxQJQXRsYXQIbnRhMQ0wCwYDVQQKEwRJ 729 RVRGMRUwEwYDVQQLFAxTT0lQCAgISVAgV0cwHhcNMDQwOTEzMTAxMzAzWhcNMDUw 730 OTEzMTAxMzAzWjBZMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHR2VvcmdpYTESMBAG 731 A1UEBxQJQXRsYXQIbnRhMQ0wCwYDVQQKEwRJRVRGMRUwEwYDVQQLFAxTT0lQCAgI 732 SVAgV0cwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALweYzxv0ThY2Fvu1kCg 733 FVKQrJX2sARfefJBuDiFe17WhbUHEL7jcxAesbeeTopz1p89HpWWgrBahSgBwKdt 734 Mn/MSJnp2r4LkSxAYg6jBiRKCp07amiOgKdGDOCOC8CXjVHYnoITWQzA5DE0LE+d 735 NyjyXxQZ0ps0tci411QzUwbxAgMBAAGjgdQwgdEwHQYDVR0OBBYEFGfCU7cNxqSK 736 NurvFqz8gj5px8uoMIGBBgNVHSMEejB4gBRnwlO3Dcakijbq7xas/II+acfLqKFd 737 pFswWTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0dlb3JnaWExEjAQBgNVBAcUCUF0 738 bGF0CG50YTENMAsGA1UEChMESUVURjEVMBMGA1UECxQMU09JUAgICElQIFdHggEA 739 MAwGA1UdEwQFMAMBAf8wHgYDVR0RBBcwFYITYXRsYW50YS5leGFtcGxlLmNvbTAN 740 BgkqhkiG9w0BAQQFAAOBgQAc0a/5hU6yqRTxwqoBuRk/iSqDnJD/B0QQnSFLqdjy 741 QV/Pm+aluA05aLRDWq6w/ufwX2HPLOvXYubpnNzjpaWCx3OLr4b5NwnsfNSxtKBJ 742 vI9PWwhSW6VMo/cT2llhNudCmN+LXPd/SLy3gnGvXtwcrWAT8MVYmkCUQTRvbWaR 743 fQ== 744 -----END CERTIFICATE----- 746 A user of atlanta.example.com, Alice, wants to send an INVITE to 747 bob@biloxi.example.org. She therefore creates the following INVITE 748 request, which she forwards to the atlanta.example.org proxy server 749 that instantiates the authentication service role: 751 INVITE sip:bob@biloxi.exmple.org SIP/2.0 752 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 753 To: Bob 754 From: Alice ;tag=1928301774 755 Call-ID: a84b4c76e66710 756 CSeq: 314159 INVITE 757 Max-Forwards: 70 758 Date: Thu, 21 Feb 2002 13:02:03 GMT 759 Contact: 760 Content-Type: application/sdp 761 Content-Length: 147 763 v=0 764 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 765 s=Session SDP 766 c=IN IP4 pc33.atlanta.example.com 767 t=0 0 768 m=audio 49172 RTP/AVP 0 769 a=rtpmap:0 PCMU/8000 771 When the authentication service receives the INVITE, in authenticates 772 Alice by sending a 407 response. As a result, Alice adds an 773 Authorization header to her request, and resends to the 774 atlanta.example.com authentication service. Now that the service is 775 sure of Alice's identity, it calculates an Identity header for the 776 request. The canonical string over which the identity signature will 777 be generated is the following (note that the first line wraps because 778 of RFC editorial conventions): 780 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 781 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 782 s=Session SDP 783 c=IN IP4 pc33.atlanta.example.com 784 t=0 0 785 m=audio 49172 RTP/AVP 0 786 a=rtpmap:0 PCMU/8000 788 The resulting signature (sha1WithRsaEncryption) using the private RSA 789 key given above, with base64 encoding, is the following: 791 CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k0nB2sN 792 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFCHYWGCl 793 sM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= 795 Accordingly, the atlanta.example.com authentication service will 796 create an Identity header containing that base64 signature string 797 (175 bytes). It will also add an HTTPS URL where its certificate is 798 made available. With those two headers added, the message looks 799 like: 801 INVITE sip:bob@biloxi.exmple.org SIP/2.0 802 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 803 To: Bob 804 From: Alice ;tag=1928301774 805 Call-ID: a84b4c76e66710 806 CSeq: 314159 INVITE 807 Max-Forwards: 70 808 Date: Thu, 21 Feb 2002 13:02:03 GMT 809 Contact: 810 Identity: "CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k0nB2s 811 N3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFCHYWGC 812 lsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=" 813 Identity-Info: https://atlanta.example.com/cert 814 Content-Type: application/sdp 815 Content-Length: 147 817 v=0 818 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 819 s=Session SDP 820 c=IN IP4 pc33.atlanta.example.com 821 t=0 0 822 m=audio 49172 RTP/AVP 0 823 a=rtpmap:0 PCMU/8000 825 atlanta.example.com then forwards the request normally. When Bob 826 receives the request, if he does not already know the certificate of 827 atlanta.example.com, he de-references the URL the Identity-Info 828 header to acquire the certificate. Bob then generates the same 829 canonical string given above, from the same headers of the SIP 830 request. Using this canonical string, the signed digest in the 831 Identity header, and the certificate discovered by de-referencing the 832 Identity-Info header, Bob can verify that the given set of headers 833 and the message body have not been modified. 835 11.2 Identity for a Request with no MIME body or Contact 837 Consider the following private key and certificate pair assigned to 838 "biloxi.example.org". 840 -----BEGIN RSA PRIVATE KEY----- 841 MIICXQIBAAKBgQDDIREMIIS9vBBET2FFHss2Lbwri/nK+AMoUZ74UT3amG/bYgDn 842 H86eUUEjGfV3cfXErFXSnI86sUALoKjjwGYBoiUuaMhyerZyF+D9St2plnBeq6fq 843 rbaPpL6bvIAF636/O2+GFP3LSLj6KS4HQwnsaUBr2YzykBD05PfwrH28VQIDAQAB 844 AoGAZLRJFwglWcKYZpjNK54T5HdAGP1Zwo2zG3jcYW2UTZ/EguWWb7HzsbNfuZzp 845 GWcgHwuOE28nYHQgCKA26avfOGuebFHz2WLAFC3TCOVjMzJEWawtxIc7oX9vziTF 846 1Uk2K4ccK2zdJlPI46fHjJrI2xXKZWkxVNkZ8LeMspckUqECQQDqhD0SoLXoRGks 847 h7byNZAMR5PfZTpHli7uFg9O+GoLtxQNE/rW6JPVcVkpCvs8oPPUu+1D7dHnyFiO 848 heyme35tAkEA1QEiny94KRtTuP/WEyyYUkRfltYjrAX1BC73Xu395cNwjvnNw7qI 849 f2dFUm5akGijk9UtL1qNxg+akBgJXkbkiQJAXbUHXkkfRrcHO4bjIDcs3us++BXP 850 yskE6Zeg+FIktZerCGrCYVs/rxsCoHbF2v0JUSjibrE5nZ8dW53B6OgRpQJBAKfr 851 9zFrqN0vT/eeqVQAai0g/gLZ2tF4+MpNhHLwSKNkSk5NHSxa19UowvvTR85kz+Bx 852 xOd6Ch7EmmNSr8AFP5ECQQDOXmjIecxNI51of9u6g4T2ITRcHTYyCqWLO6VqAWlD 853 G6ej+6/h+8DQyfJKMNbfMCGjZ7xZC3isNMmFibGQTLZD 854 -----END RSA PRIVATE KEY----- 855 -----BEGIN CERTIFICATE----- 856 MIIC7DCCAlWgAwIBAgIBADANBgkqhkiG9w0BAQQFADBUMQswCQYDVQQGEwJVUzEU 857 MBIGA1UECBMLTWlzc2lzc2lwcGkxDzANBgNVBAcTBkJpbG94aTENMAsGA1UEChME 858 SUVURjEPMA0GA1UECxMGU0lQIFdHMB4XDTA0MDkxMzEwMzg1NVoXDTA1MDkxMzEw 859 Mzg1NVowVDELMAkGA1UEBhMCVVMxFDASBgNVBAgTC01pc3Npc3NpcHBpMQ8wDQYD 860 VQQHEwZCaWxveGkxDTALBgNVBAoTBElFVEYxDzANBgNVBAsTBlNJUCBXRzCBnzAN 861 BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwyERDCCEvbwQRE9hRR7LNi28K4v5yvgD 862 KFGe+FE92phv22IA5x/OnlFBIxn1d3H1xKxV0pyPOrFAC6Co48BmAaIlLmjIcnq2 863 chfg/UrdqZZwXqun6q22j6S+m7yABet+vztvhhT9y0i4+ikuB0MJ7GlAa9mM8pAQ 864 9OT38Kx9vFUCAwEAAaOBzTCByjAdBgNVHQ4EFgQUlZRLaS3Zm/b0xWcq7TSnQMHM 865 7w8wfAYDVR0jBHUwc4AUlZRLaS3Zm/b0xWcq7TSnQMHM7w+hWKRWMFQxCzAJBgNV 866 BAYTAlVTMRQwEgYDVQQIEwtNaXNzaXNzaXBwaTEPMA0GA1UEBxMGQmlsb3hpMQ0w 867 CwYDVQQKEwRJRVRGMQ8wDQYDVQQLEwZTSVAgV0eCAQAwDAYDVR0TBAUwAwEB/zAd 868 BgNVHREEFjAUghJiaWxveGkuZXhhbXBsZS5vcmcwDQYJKoZIhvcNAQEEBQADgYEA 869 SufJHtereahZlkE5ssRRZRd/erLpEe2uUfHnTOydPBKOkvhVG4Vr4aoroPlE7gJK 870 a/2BF9bohwAUSC5j5q3nvuhUcoK9XZYm2nLkN3IAhCU6oswVBJAxLanGUCjR5sxS 871 HfGhGsqLmTEQ22HsrtLo68IYiwftXcLZbep50gRVX6c= 872 -----END CERTIFICATE----- 874 Bob (bob@biloxi.example.org) now wants to send a BYE request to Alice 875 at the end of the dialog initiated in the previous example. He 876 therefore creates the following BYE request which he forwards to the 877 'biloxi.example.org' proxy server that instantiates the 878 authentication service role: 880 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 881 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 882 Max-Forwards: 70 883 From: Bob ;tag=a6c85cf 884 To: Alice ;tag=1928301774 885 Call-ID: a84b4c76e66710 886 CSeq: 231 BYE 887 Content-Length: 0 888 When the authentication service receives the BYE, it authenticates 889 Bob by sending a 407 response. As a result, Bob adds an 890 Authorization header to his request, and resends to the 891 biloxi.example.org authentication service. Now that the service is 892 sure of Bob's identity, it prepares to calculate an Identity header 893 for the request. Note that this request does not have a Date header 894 field. Accordingly, the biloxi.example.org will add a Date header to 895 the request before calcuating the identity signature. If the 896 Content-Length header were not present, the authentication service 897 would add it as well. The baseline message is thus: 899 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 900 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 901 Max-Forwards: 70 902 From: Bob ;tag=a6c85cf 903 To: Alice ;tag=1928301774 904 Date: Thu, 21 Feb 2002 14:19:51 GMT 905 Call-ID: a84b4c76e66710 906 CSeq: 231 BYE 907 Content-Length: 0 909 Also note that this request contains no Contact header field. 910 Accordingly, biloxi.example.org will place no value in the canonical 911 string for the addr-spec of the Contact address. Also note that 912 there is no message body, and accordingly, the signature string will 913 terminate, in this case, with two colons. The canonical string over 914 which the identity signature will be generated is the following (note 915 that the first line wraps because of RFC editorial conventions): 917 sip:bob@biloxi.example.org:sip:alice@atlanta.example.com:a84b4c76e66710:231 BYE:Thu, 21 Feb 2002 14:19:51 GMT:: 919 The resulting signature (sha1WithRsaEncryption) using the private RSA 920 key given above for biloxi.example.org, with base64 encoding, is the 921 following: 923 A5oh1tSWpbmXTyXJDhaCiHjT2xR2PAwBroi5Y8tdJ+CL3ziY72N3Y+lP8eoiXlrZ 924 Ouwb0DicF9GGxA5vw2mCTUxc0XG0KJOhpBnzoXnuPNAZdcZEWsVOQAKj/ERsYR9B 925 fxNPazWmJZjGmDoFDbUNamJRjiEPOKn13uAZIcuf9zM= 927 Accordingly, the biloxi.example.org authentication service will 928 create an Identity header containing that base64 signature string. 929 It will also add an HTTPS URL where its certificate is made 930 available. With those two headers added, the message looks like: 932 BYE sip:alice@pc33.atlanta.example.com SIP/2.0 933 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 934 Max-Forwards: 70 935 From: Bob ;tag=a6c85cf 936 To: Alice ;tag=1928301774 937 Date: Thu, 21 Feb 2002 14:19:51 GMT 938 Call-ID: a84b4c76e66710 939 CSeq: 231 BYE 940 Identity: "A5oh1tSWpbmXTyXJDhaCiHjT2xR2PAwBroi5Y8tdJ+CL3ziY72N3Y+lP8eoiXlr 941 ZOuwb0DicF9GGxA5vw2mCTUxc0XG0KJOhpBnzoXnuPNAZdcZEWsVOQAKj/ERsYR9 942 BfxNPazWmJZjGmDoFDbUNamJRjiEPOKn13uAZIcuf9zM=" 943 Identity-Info: https://biloxi.example.org/cert 944 Content-Length: 0 946 biloxi.example.org then forwards the request normally. 948 12. Identity and the TEL URI Scheme 950 Since many SIP applications provide a VoIP service, telephone numbers 951 are commonly used as identities in SIP deployments. In the majority 952 of cases, this is not problematic for the identity mechanism 953 described in this document. Telephone numbers commonly appear in the 954 username portion of a SIP URI (e.g., 955 'sip:+17005551008@chicago.example.com'). That username conforms to 956 the syntax of the TEL URI scheme (RFC2806bis [9]). For this sort of 957 SIP address-of-record, chicago.example.com is the appropriate 958 signatory. 960 It is also possible for a TEL URI to appear in the SIP To or From 961 header field outside the context of a SIP or SIPS URI (e.g., 962 'tel:+17005551008'). In this case, it is much less clear which 963 signatory is appropriate for the identity. Fortunately for the 964 identity mechanism, this form of the TEL URI is more common for the 965 To header field and Request-URI in SIP than in the From header field, 966 since the UAC has no option but to provide a TEL URI alone when the 967 remote domain to which a request is sent is unknown. The local 968 domain, however, is usually known by the UAC, and accordingly it can 969 form a proper From header field containing a SIP URI with a username 970 in TEL URI form. Implementations that intend to send their requests 971 through an authentication service MUST put telephone numbers in the 972 From header field into SIP or SIPS URIs, if possible. 974 If the local domain is unknown to a UAC formulating a request, it 975 most likely will not be able to locate an authentication service for 976 its request, and therefore the question of providing identity in 977 these cases is somewhat moot. However, an authentication service MAY 978 sign a request containing a TEL URI in the From header field in 979 accordance with its local policies. Verifiers SHOULD NOT accept 980 signatures over From header TEL URIs in the absence of some 981 pre-provisioned relationship with the signing domain that authorizes 982 this usage of TEL URIs. 984 The guidance in the paragraph above is largely provided for forward 985 compatibility. In the longer-term, it is possible that ENUM [10] may 986 provide a way to determine which administrative domain is responsible 987 for a telephone number, and this may aid in the signing and 988 verification of SIP identities that contain telephone numbers. This 989 is a subject for future work. 991 13. Privacy Considerations 993 The identity mechanism presented in this draft is compatible with the 994 standard SIP practices for privacy described in RFC3323 [3]. A SIP 995 proxy server can act both as a privacy service and as an 996 authentication service. Since a user agent can provide any From 997 header field value which the authentication service is willing to 998 authorize, there is no reason why private SIP URIs (e.g., 999 sip:anonymous@example.com) cannot be signed by an authentication 1000 service. The construction of the Identity header is the same for 1001 private URIs as it is for any other sort of URIs. 1003 Note, however, that an authentication service must possess a 1004 certificate corresponding to the host portion of the addr-spec of the 1005 From header field of any request that it signs; accordingly, using 1006 domains like 'invalid.net' may not be possible for privacy services 1007 that also act as authentication services. The assurance offered by 1008 this combination service is "this is a known user in my domain that I 1009 have authenticated, but I am keeping their identity private". 1011 The "header" level of privacy described in RFC3323 requests that a 1012 privacy service to alter the Contact header field value of a SIP 1013 message. Since the Contact header field is protected by the 1014 signature in an Identity header, privacy services cannot be applied 1015 after authentication services without a resulting integrity 1016 violation. 1018 RFC3325 [8] defines the "id" priv-value token which is specific to 1019 the P-Asserted-Identity header. The sort of assertion provided by 1020 the P-Asserted-Identity header is very different from the Identity 1021 header presented in this document. It contains additional 1022 information about the sender of a message that may go beyond what 1023 appears in the From header field; P-Asserted-Identity holds a 1024 definitive identity for the sender which is somehow known to a closed 1025 network of intermediaries that presumably the network will use this 1026 identity for billing or security purposes. The danger of this 1027 network-specific information leaking outside of the closed network 1028 motivated the "id" priv-value token. The "id" priv-value token has 1029 no implications for the Identity header, and privacy services MUST 1030 NOT remove the Identity header when a priv-value of "id" appears in a 1031 Privacy header. 1033 14. Security Considerations 1035 This document describes a mechanism which provides a signature over 1036 the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP 1037 messages. While a signature over the From header field would be 1038 sufficient to secure a URI alone, the additional headers provide 1039 replay protection and reference integrity necessary to make sure that 1040 the Identity header will not be used in cut-and-paste attacks. In 1041 general, the considerations related to the security of these headers 1042 are the same as those given in RFC3261 for including headers in 1043 tunneled 'message/sip' MIME bodies (see Section 23 in particular). 1045 The From header field indicates the identity of the sender of the 1046 message, and the SIP address-of-record URI in the From header field 1047 is the identity of a SIP user, for the purposes of this document. 1048 The To header field provides the identity of the SIP user that this 1049 request targets. Providing the To header field in the Identity 1050 signature servers two purposes: first, it prevents replay attacks in 1051 which an Identity header from legitimate request for one user is 1052 cut-and-pasted into a request for a different user; second, it 1053 preserves the starting URI scheme of the request, which helps prevent 1054 downgrade attacks against the use of SIPS. 1056 The Date and Contact headers provide reference integrity and replay 1057 protection, as described in RFC3261 Section 23.4.2. Implementations 1058 of this specification MUST NOT deem valid a request with an outdated 1059 Date header field (the RECOMMENDED interval is that the Date header 1060 must indicate a time within 3600 seconds of the receipt of a 1061 message). Implementations MUST also record Call-IDs received in 1062 valid requests containing an Identity header, and MUST remember those 1063 Call-IDs for at least the duration of a single Date interval (i.e. 1064 commonly 3600 seconds). Accordingly, if an Identity header is 1065 replayed within the Date interval, receivers will recognize that it 1066 is invalid because of a Call-ID duplication; if an Identity header is 1067 replayed after the Date interval, receivers will recognize that it is 1068 invalid because the Date is stale. The CSeq header field contains a 1069 numbered identifier for the transaction, and the name of the method 1070 of the request; without this information, an INVITE request could be 1071 cut-and-pasted by an attacker and transformed into a BYE request 1072 without changing any fields covered by the Identity header, and 1073 moreover requests within a certain transaction could be replayed in 1074 potentially confusing or malicious ways. 1076 The Contact header field is included to tie the Identity header to a 1077 particular device instance that generated the request. Were an 1078 active attacker to intercept a request containing an Identity header, 1079 and cut-and-paste the Identity header field into their own request 1080 (reusing the From, To, Contact, Date and Call-ID fields that appear 1081 in the original message), they would not be eligible to receive SIP 1082 requests from the called user agent, since those requests are routed 1083 to the URI identified in the Contact header field. However, the 1084 Contact header is only included in dialog-forming requests, so it 1085 does not provide this protection in all cases. 1087 It might seem attractive to provide a signature over some of the 1088 information present in the Via header field value(s). For example, 1089 without a signature over the sent-by field of the topmost Via header, 1090 an attacker could remove that Via header and insert their own in a 1091 cut-and-paste attack, which would cause all responses to the request 1092 to be routed to a host of the attacker's choosing. However, a 1093 signature over the topmost Via header does not prevent attacks of 1094 this nature, since the attacker could leave the topmost Via intact 1095 and merely insert a new Via header field directly after it, which 1096 would cause responses to be routed to the attacker's host "on their 1097 way" to the valid host, which has exactly the same end result. 1098 Although it is possible that an intermediary-based authentication 1099 service could guarantee that no Via hops are inserted between the 1100 sending user agent and the authentication service, it could not 1101 prevent an attacker from adding a Via hop after the authentication 1103 service, and accordingly pre-empting responses. It is necessary for 1104 the proper operation of SIP for subsequent intermediaries to be 1105 capable of inserting such Via header fields, and thus it cannot be 1106 prevented. As such, though it is desirable, securing Via is not 1107 possible through the sort of identity mechanism described in this 1108 document; the best known practice for securing Via is the use of 1109 SIPS. 1111 Note that this mechanism does not provide any protection for the 1112 display-name portion of the From header field, and thus users are 1113 free to use any display-name of their choosing, and attackers could 1114 conceivably alter the display-names in a request with impunity. If 1115 an administrative domain wants to control the display-names selected 1116 by users, they could do so with policies outside the scope of this 1117 document (for example, their authentication service could reject 1118 requests from valid users that contain an improper display-name in 1119 the From header field). While there are conceivably attacks that an 1120 adversary could mount against SIP systems that rely too heavily on 1121 the display-name in their user interface, this argues for intelligent 1122 interface design, not changes to the protocol. 1124 This mechanism also provides a signature over the bodies of SIP 1125 requests. The most important reason for doing so is to protect SDP 1126 bodies carried in SIP requests. There is little purpose in 1127 establishing the identity of the user agent that originated a SIP 1128 request if a man-in-the-middle can change the SDP and direct media to 1129 an different IP address. Note however that this is not perfect 1130 end-to-end security. The authentication service itself, when 1131 instantiated at a intermediary, could conceivably change the SDP (and 1132 SIP headers, for that matter) before providing a signature. Thus, 1133 while this mechanism reduces the chance that a man-in-the-middle will 1134 interfere with sessions, it does not eliminate it entirely. Since it 1135 is a foundational assumption of this mechanism that the user trusts 1136 their local domain to vouch for their security, they must also trust 1137 the service not to violate the integrity of their message without 1138 good reason. Note that RFC3261 16.6 states that SIP proxy servers 1139 "MUST NOT add to, modify, or remove the message body." 1141 The assurance provided by this mechanism is strongest when a user 1142 agent forms a direct connection, preferably one secured by TLS, to an 1143 intermediary-based authentication service. The reasons for this are 1144 twofold: 1145 If a user does not receive a certificate from the authentication 1146 service over this TLS connection that corresponds to the expected 1147 domain (especially when they receive a challenge via a mechanism 1148 such as Digest), then it is possible that a rogue server is 1149 attempting to pose as a authentication service for a domain that 1150 it does not control, possibly in an attempt to collect shared 1151 secrets for that domain. 1152 Without TLS, the various header field values and the body of the 1153 request will not have integrity protection into the request 1154 arrives at an authentication service. Accordingly, a prior 1155 legitimate or illegitimate intermediary could modify the message 1156 arbitrarily. 1158 Of these two concerns, the first is most material to the intended 1159 scope of this mechanism. This mechanism is intended to prevent 1160 impersonation attacks, not man-in-the-middle attacks; integrity over 1161 the header and bodies is provided by this mechanism only to prevent 1162 replay attacks. However, it is likely that applications building on 1163 the Identity header could leverage this integrity protection, 1164 especially body integrity, to provide further security services. 1166 Accordingly, direct TLS connections SHOULD be used between the UAC 1167 and the authentication service whenever possible. The opportunistic 1168 nature of this mechanism, however, makes it very difficult to 1169 constrain UAC behavior, and moreover there will be some deployment 1170 architectures where a direct connection is simply infeasible and the 1171 UAC cannot act as an authentication service itself. Accordingly, 1172 when a direct connection and TLS is not possible, a UAC should use 1173 the SIPS mechanism, Digest 'auth-int' for body integrity, or both 1174 when it can. The ultimate decision to add an Identity header to a 1175 request lies with the authentication service, of course, domain 1176 policy must identify those cases where the UAC's security association 1177 with the authentication service is too weak. 1179 Ultimately, the worth of an assurance provided by an Identity header 1180 is limited by the security practices of the domain that issues the 1181 assurance. Relying on an Identity header generated by a remote 1182 administrative domain assumes that the issuing domain uses some 1183 trustworthy practice to authenticate its users. However, it is 1184 possible that some domains will implement policies that effectively 1185 make users unaccountable (such as accepting unauthenticated 1186 registrations from arbitrary users). The value of an Identity header 1187 from such domains is questionable. While there is no magic way for a 1188 verifier to distinguish "good" from "bad" domains by inspecting a SIP 1189 request, it is expected that further work in authorization practices 1190 could be built on top of this identity solution; without such an 1191 identity solution, many promising approaches to authorization policy 1192 are impossible. That much said, it is RECOMMENDED that 1193 authentication services based on proxy servers employ strong 1194 authentication practices such as token-based identifiers. 1196 Since a domain certificate is used by an authentication service 1197 (rather than individual certificates for each identity), certain 1198 problems can arise with name subordination. For example, if an 1199 authentication service holds a common certificate for the hostname 1200 'sip.atlanta.example.com', can it legitimately sign a token 1201 containing an identity of 'sip:alice@atlanta.example.com'? It is 1202 difficult for the recipient of a request to ascertain whether or not 1203 'sip.atlanta.example.com' is authoritative for the 1204 'atlanta.example.com' domain unless the recipient has some 1205 foreknowledge of the administration of 'atlanta.example.com'. 1206 Therefore, it is RECOMMENDED that UASs receiving signed requests 1207 notify end users if there is ANY discrepancy between the 1208 subjectAltName of the signer's certificate and the host portion of 1209 the identity within the From header field. If the domain name in the 1210 subject of the certificate is subordinate to the domain name in the 1211 identity URI, then verifiers may consider this a minor discrepancy. 1212 Additionally, there are ways that a verifier might leverage the 1213 information about canonical SIP servers within a domain stored in the 1214 DNS (see RFC3263 [4]) to determine whether or not a particular 1215 authentication service is authoritative for a domain; however, this 1216 is a subject for future work. 1218 Because the domain certificates that can be used by authentication 1219 services need to assert only the hostname of the authentication 1220 service, existing certificate authorities can provide adequate 1221 certificates for this mechanism. However, not all proxy servers and 1222 user agents will be able support the root certificates of all 1223 certificate authorities, and moreover there are some significant 1224 differences in the policies by which certificate authorities issue 1225 their certificates. This document makes no recommendations for the 1226 usage of particular certificate authorities, nor does it describe any 1227 particular policies that certificate authorities should follow, but 1228 it is anticipated that operational experience will create de facto 1229 standards for authentication services. Some federations of service 1230 providers, for example, might only trust certificates that have been 1231 provided by a certificate authority operated by the federation. It 1232 is STRONGLY RECOMMENDED that self-signed domain certificates should 1233 not be trusted by verifiers, unless some pre-existing key exchange 1234 has justified such trust. 1236 Finally, the Identity and Identity-Info headers cannot protect 1237 themselves. Any attacker could remove these headers from a SIP 1238 request, and modify the request arbitrarily afterwards. Accordingly, 1239 these headers are only truly efficacious if the would-be verifier 1240 knows that they must be included in a request. In the long term, 1241 some sort of identity mechanism along these lines must become 1242 mandatory-to-use for the SIP protocol; that is the only way to 1243 guarantee that this protection can always be expected. In the 1244 interim, however, identity reception policies at a domain level or an 1245 address-book level should be used by verifiers to determine whether 1246 or not identity is expected from a particular source of SIP requests. 1247 Those authorization policies are outside the scope of this document. 1249 15. IANA Considerations 1251 This document requests changes to the header and response-code 1252 sub-registries of the SIP parameters IANA registry. 1254 15.1 Header Field Names 1256 This document specifies two new SIP headers: Identity and 1257 Identity-Info. Their syntax is given in Section 10. These headers 1258 are defined by the following information, which is to be added to the 1259 header sub-registry under 1260 http://www.iana.org/assignments/sip-parameters. 1261 Header Name: Identity 1262 Compact Form: y 1263 Header Name: Identity-Info 1264 Compact Form: (none) 1266 15.2 428 'Use Identity Header' Response Code 1268 This document registers a new SIP response code which is described in 1269 Section 7. It is used when a verifier received a SIP request that 1270 lacks an Identity header as a response indicating that the request 1271 should be re-sent with an Identity header. This response code is 1272 defined by the following information, which is to be added to the 1273 method and response-code sub-registry under 1274 http://www.iana.org/assignments/sip-parameters. 1275 Response Code Number: 428 1276 Default Reason Phrase: Use Identity Header 1278 15.3 436 'Bad Identity-Info' Response Code 1280 This document registers a new SIP response code which is described in 1281 Section 7. It is used when the Identity-Info header contains a URI 1282 that cannot be dereferenced by the verifier (either the URI scheme is 1283 unsupported by the verifier, or the resource designated by the URI is 1284 otherwise unavailable). This response code is defined by the 1285 following information, which is to be added to the method and 1286 response-code sub-registry under 1287 http://www.iana.org/assignments/sip-parameters. 1288 Response Code Number: 436 1289 Default Reason Phrase: Bad Identity-Info 1291 15.4 437 'Unsupported Certificate' Response Code 1293 This document registers a new SIP response code which is described in 1294 Section 7. It is used when the verifier cannot validate the 1295 certificate referenced by the URI of the Identity-Info header, 1296 because, for example, the certificate is self-signed, or signed by a 1297 root certificate authority for whom the verifier does not possess a 1298 root certificate. This response code is defined by the following 1299 information, which is to be added to the method and response-code 1300 sub-registry under http://www.iana.org/assignments/sip-parameters. 1301 Response Code Number: 437 1302 Default Reason Phrase: Unsupported Certificate 1304 16. References 1306 16.1 Normative References 1308 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1309 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1310 Session Initiation Protocol", RFC 3261, June 2002. 1312 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 1313 levels", RFC 2119, March 1997. 1315 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 1316 Protocol (SIP)", RFC 3323, November 2002. 1318 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1319 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1321 [5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 1322 Identity Body (AIB) Format", RFC 3893, September 2004. 1324 [6] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 1325 RFC 2234, November 1997. 1327 16.2 Informative References 1329 [7] Kohl, J. and C. Neumann, "The Kerberos Network Authentication 1330 Service (V5)", RFC 1510, September 1993. 1332 [8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 1333 to the Session Initiation Protocol (SIP) for Asserted Identity 1334 within Trusted Networks", RFC 3325, November 2002. 1336 [9] Schulzrinne, H., "The TEL URI for Telephone Numbers", RFC 3966, 1337 December 2004. 1339 [10] Faltstrom, P. and M. Mealling, "The E.164 to URI DDDS 1340 Application", RFC 3761, April 2004. 1342 Authors' Addresses 1344 Jon Peterson 1345 NeuStar, Inc. 1346 1800 Sutter St 1347 Suite 570 1348 Concord, CA 94520 1349 US 1351 Phone: +1 925/363-8720 1352 EMail: jon.peterson@neustar.biz 1353 URI: http://www.neustar.biz/ 1355 Cullen Jennings 1356 Cisco Systems 1357 170 West Tasman Drive 1358 MS: SJC-21/2 1359 San Jose, CA 95134 1360 USA 1362 Phone: +1 408 902-3341 1363 EMail: fluffy@cisco.com 1365 Appendix A. Acknowledgments 1367 The authors would like to thank Eric Rescorla, Rohan Mahy, Robert 1368 Sparks, Jonathan Rosenberg, Mark Watson, Henry Sinnreich, Alan 1369 Johnston, Patrik Faltstrom, Paul Kyzviat, Adam Roach, John Elwell, 1370 and Aki Niemi for their comments. The bit-archive presented in 1371 Appendix B follows the pioneering example of Robert Sparks' 1372 torture-test draft. 1374 Appendix B. Bit-exact archive of example messages 1376 The following text block is an encoded, gzip compressed TAR archive 1377 of files that represent the transformations performed on the example 1378 messages discussed in Section 11. It includes for each example: 1379 o (foo).message: the original message 1380 o (foo).canonical: the canonical string constructed from that 1381 message 1382 o (foo).sha1: the SHA1 hash of the canonical string (hexadecimal) 1383 o (foo).signed: the RSA-signed SHA1 hash of the canonical string 1384 (binary) 1385 o (foo).signed.enc: the base64 encoding of the RSA-signed SHA1 hash 1386 of the canonical string as it would appear in the request 1387 o (foo).identity: the original message with the Identity and 1388 Identity-Info headers added 1390 Also included in the archive are two public key/certificate pairs, 1391 for atlanta.example.com and biloxi.example.org, respectively, 1392 including: 1393 o (foo).cert: the certificate of the domain 1394 o (foo).privkey: the private key of the domain 1395 o (foo).pubkey: the public key of the domain, extracted from the 1396 cert file for convenience 1398 To recover the compressed archive file intact, the text of this 1399 document may be passed as input to the following Perl script (the 1400 output should be redirected to a file or piped to "tar -xzvf -"). 1402 #!/usr/bin/perl 1403 use strict; 1404 my $bdata = ""; 1405 use MIME::Base64; 1406 while(<>) { 1407 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 1408 if ( m/^\s*[^\s]+\s*$/) { 1409 $bdata = $bdata . $_; 1410 } 1411 } 1412 } 1413 print decode_base64($bdata); 1415 Alternatively, the base-64 encoded block can be edited by hand to 1416 remove document structure lines and fed as input to any base-64 1417 decoding utility. 1419 B.1 Encoded Reference Files 1421 -- BEGIN MESSAGE ARCHIVE -- 1422 H4sICPGlE0ICA2lkZW50cmVmLnRhcgDsW8uv43hWLsTOomaFYMEmtIQAhar47eTO 1423 FJqf3+/E78QakGzHb8dO7CR2spwFGok9IMSWLftZwwaxYQRCQixgC0JC/Ac491ZV 1424 P6pvVyF1l3q675EsJyd+/F7n+8757OTbuD62cTJ79s0ZDOMwRRDjHkMpjBz3KI6T 1425 yLh/a88QGIVxCkVJFHsGIxiJEs8mxLOPYKfuGLSTybNiHx/jtmvqR47blWnbnPYv 1426 qhfbZ98hy9/Mf3CsgvoYvIzi9vh1zz8CwySOPzb/KIJg4/wjKIJSCEpQ4/EkgqLP 1427 JvDT/H/j9uJmNCdI+oThTFviJQbY3L0X0iSJmdkMA3ZBCnqJBum4sUCn0/KQlbmw 1428 6GEaGAYPWNrXjK5njA3rGobA9bLrXDkD0gAuAMThGFoTTdQ9R7vtfmNzlkaDez89 1429 GLKxNrvN2pDC2sw0A+6Z/v4iCtebMmS6pqCZTs89OFUeDLYNVwYzNsVyQerCUS9m 1430 ka6xRr+0uatmg0G7gqt373N66HPO4sub+VWthD6kmV/VSuhNM1N/3rPGRlYaX8rO 1431 kQ4MjqYNwKYbGGiSIINGoIHax5vrcIbtbIPy5xNSMinEu4rRymu0A2YSJzJ9YnM+ 1432 RigvCx2RU6kiGkDchXFsN/srsp8vxL3npS0dZFZK98r2CGn1TLPkeo+2uFpaA9ik 1433 ZEHnpsLsYSrY5ctU2Qrsklkyc2ZduOKmbiTbM66AYDlY5aZbSL8Ul/Vg+PC+g49R 1434 jiOIcXX6cADpOERAKNKt0adbrhdvA2vCS5recLyQMA4V6cPBUiD91J75w3WeFsR+ 1435 mJ+asb80nequaGlcXNB4Spt1Xy0xNgrKvAgP1BB0M0maBlGiHhR+C+35rvdsTtVA 1436 +bBwMo1xXW3gWLC8XWhcmjYNb6sQk+vA4wauAMaDP3IYh4ehUOBhRiDgcV51DXQP 1437 851pnOW4jllwrkZrD77B0Bx4ITvj1DFcZUj8VkxTDoxLub8dMPbS4DUw9juZ92J6 1438 31+TpqOe30j25rZGvPEmFlHFAn+MhKFSd/o5tIEOvRM0t5YbIIKDGZE55OVg2kN/ 1439 aOiTWc5y68DWMjujYcOoLV49bIsLZLiz1W4aVCcAE4Fqst6B7GenpF+j4kpdnteb 1440 U7iv9WuxDzxmwJZqi4eE3tddolvDUaFl6CwtVl6fWR7pas0sstGqyvTTltnpU3W9 1441 2s4s9YKltXBeH/uo9YA919zNrmQcwzbPoReYUGK8egXdQwOns+/CxbMn+w7w/77N 1442 z2V8+Yj8jxAk9UX+J6kn/v/Y/G9aYLIyJXcM6InCbT7NAUbaG3FeGeGKmYs7bR4u 1443 ONzTs5A6+qChXatULu6iBdwaqy9GmOLZ+hgjjYfQAzOFcEwzxFbA6pJUokWQrEzS 1444 rRql9xqnARFTh7Y8u3K5T24PU4bgOkOQlk2/Ka30sF2i+wYqGqY202tapGdQ4YiJ 1445 yiTDIaXWL41BZ4ZVbUfNvJo7wlYJdXUtnfStoyGaMDckFhiAhkZmBeC4WgrAvejN 1446 dG0t5YGbog4tBgfNU42LCBSKaS4dQfHTZX1Kmkg+CPaYUWS8tvGXUBUbGawUWRr1 1447 S0drqJQ+npqjZzhhqIq2oKxz2iRXh3BHMuesl62TvjnD56V+skPE0qoKUoJtimN1 1448 gNOL0ogvxxq5kFVS2qWCNptDybo+CsBOtdQ2ySrEYQyD3VMuLx3TXX0JewVaKb3c 1449 zdOan56myqKYdkE0w86pkLbL835wD32jrSsy9vTZbO/PokOXBTWr7o7tIsgKj2Eh 1450 dti4l7JqQcmB65aUVRlkwjzyLzuXsQg5gXmKB+6wH2A6NVdiL1f5xUnJJV6sNlNg 1451 pVCkrsj6ugiwee/5RkG25iVNEsEX1yHN76bzMZmigbzzuYTgLEshp4S71exKP5xC 1452 sC3kHgpozdkgDjytA5UkwSXZeI50mBasNJ+aiVoqxlyEpeQcD+em9FAr6a2VgpTX 1453 KOEYg50tIc3w0CHtj3M7y3axwhjIjEhQr6w6k6mIlXARpwEbH4yLlBbLYFUxV7vg 1454 EAmbynvHbi8m1C9m9hYfebY9tswZoXV2vLLBpKJ05ecqf5RGfOoXGuBAw1zY8Cjy 1455 K66gkHB6EFB0E+GQteJpEDaYLCynu5aGtfVM6OV2irFJetXEwBlmx7xetdMTwn7K 1456 k18aVt9i/D+FXzP8vw//YRy91f8IhiMEjhH4Df9xknjC/4+M/yuHViXms9AvJBqA 1457 BcY6CJYUYuxYsQDDAWO5pAOWoXPjqykBeowTPpQSoMc44UMpAXqUE95G5xc7/b3N 1458 /8K8aob8m5B/3qv/wCT6Jv/DUeqW/xEUhT/F/7dB/6FYhgGV9z79x/kSYcWBNFp6 1459 o6yotlddI/R+6yOhHNjr7UL3JbpNl/I+FBZ48IXqHHpdnq9uMPRQnmuCAz+U5RqN 1460 r1kbwBpbDtqV67Vriuhuc/Mhb3zQa2fvsu+KBzwLrDfiAQMj+wjTHzaR3mvGvVrD 1461 QmN/RK73mcAbzvGt2TZQH05qbJqreJfbfKYrnU1Xuuww9Nq8MnR9fafu5+7r/sIA 1462 fbopmXTDgf7CmeMYc+ewN0xukZkmpeo5OlfwM3E5pyyk8EI85bkFus/OKCoBYpgt 1463 64qnpaFGtpiIDMrgwvvLatnygCGZBp/TOxBIlborpKg+oFCUJenMabcH3+/Xh1NN 1464 HlC0IK3pjroAOj5Oz9fjOcvsxQXO8WlensbERqaECgSLEdj3wIAWSxubK8PizDsM 1465 6DkAgiV9tRn6UoDtvYxj4ByfGk7lm2pgYf5uFsKDFx0o26oNTdQgqp/3CbgXSwpa 1466 dPoIB48eTPXTzFNMT+ONgbkC+XYDiAYbG1SurZlGz6X3q0zi+qMerPXrw0b34+J5 1467 u07ocZ0Yu6oLsWx/U+ugd+S61/N7k+vG6bUfVLqYGcmhZx9aatPA6cfu0rMr2EL3 1468 /TQ5ji+Ak2Zy/no9nPx1loVruvMt4hztoi9KfNyDxMcByDolsjgiTBxkflVyRNeZ 1469 pm9uZ3Gr7rkYPTmJWNvLy3ZFK8vynLkC7rZ40LTNquKoVFagYIbS/CJssh44FkMU 1470 xAGrz6fMiRplsfY3O7RWSx2TQMY4ZNP1Li2DQQ1qwWEKk+gGCxITIRO6g7qzOQNF 1471 xa49qg05lzZ5nxzXkeqH8Z6AU9Ndk9GTzPN95f9vQP75/+g/r/mfJHDkif+/ffoP 1472 y0omN7qsxZmmORvlebHrUDXs23xWK1OgNY5P4Y6NBTthFm5StobEORk7DlcIiYtF 1473 yZpr+bVVS3Oyc4DaKEXRCxu6yZ1ToGWXuPUv/JRdWEd0X9V0fCCTA9SGwWqvkuFZ 1474 AjyJkbMlOhX4FaZaakEqFi4afd0FDt2im+ulpFmYWCV9K6Jz97P6j6+aMt+nlRcp 1475 G39f6AqB24S4BcIK8fsGvQpYEW081LH9GZeePC+kxGsX6snJv+4hwYtSsT8tOXRe 1476 b0QjZRSAksE5WQqnOOTFK+qpgGcwm1m6hXaVOS/oj4MUUc16cb7mNg8hTokqeBQp 1477 6HUrVysJJxOxkFsJHdaK75WDq5f+XI21bh+VzuGmSrCHjIWtRl03plB2UEaFF90H 1478 mjl2zrf3YpVTJz5dLKdCox4HQ+dmrUfKKzdyyz1z7ubNauWcpghLbcX6wudLKIsv 1479 uxgjjjf9BzG4vL4scMU82qfVzOMul41Tmkl13BQtWCM0Q2HrE7YgIr0vzrXeUwcJ 1480 StAt7+yIoBTyolw4RxU56EM6DUo6lddlWOaGDNahI67LMjHbSFziYSGxUYeduumU 1481 Xq+gS1dypB+nU14qj37cMkLLbNxu1g4d04ghj55h2bGKPGw5ovbnW4/AaHKZmntD 1482 poGStNDiyrcHHT7bszg+uAYIcjidpaqPHnl8qu31TFR7S9FLqyR00RoCZOE0/fls 1483 m3OivE7pARqWW5LJKG630612DvgVcT/Sy/WYKMXRoEsE0iSLE5niNirZZiTamwtz 1484 8NQl6R6AV7GQQMbFlJxl0zlrXBJZ0fQw0Rih8KnBZ7C807Udn4eCYav+L5/+8wb/ 1485 v3755731HwG/rv9wlCQw4ob/GPaE/78c+s/jlAA9xgkfSgnQY5zwoZQAPcoJj+o/ 1486 T/XwUz38VA8/1cPfl3r4U/6/xC+joG7qPAqqj8r/t9f97vkfRXGKIG/vf5Io8aT/ 1487 fhTr8v1d2IQ/fp3+xUOw21fxy6ZN724/BVUexT9+82zwza9Rs7sL5niIRxQZkySF 1488 wHcohkzoDXdnZ6c/mKDIhI/DCTpO9ATB75DFHYFMBM2+u3v+JB99i+P//kt+/JrT 1489 //fqPwhMvH3/m0DJ+/d/Cewp/j+GjTE7+TTQx3wPe/kl0T6xpNUMfQk/h9w8uHvz 1490 bWar1gRZjJ9eoi/xH4ZtUEfZq+siE/BQqYMu23bIeIoWDC/4pu2DdtvdTajRw7cj 1491 gEzoJpz86HH8+cMfHoP0VUBGcyJKnkN2czcBt0Y+nPMoMD2cNrZqjsEIReHPITY4 1492 xneTrwSm5xATVNULib2bfB7Xxh+s+HA3eQ1vzyHpdYjcTT4BRJMhR8vbh7u1fVnL 1493 bBYwuVjY6GCiK9DTbZMTm/lxK08ZFbvmGwrVsc20Ws3jJl9X7XNo8tb85akPYTaP 1494 +IUgDIA49+iOsZ0hgtcCrMjLbD8mz826Pq104G8jn/M6d2kApZhxZrcxF5+9Fp0M 1495 +iq4ejvZL4Qd2/Bs6OjBTjaLnFstlRrBTsCXolOyuGqvPvm0Ry+kOhnHODse993d 1496 bPbuhMxuz4bHAWnq43jGCzWu02N2N4GfMP27gv+7uOuCNP7Iz/9hfPTd8j8SJ0n0 1497 dhxCUOST/vOE/18P/n8otH8vge1z8d9lAfIN3ON98Q9T5Nv6j8TQW/wj5FP+91HM 1498 EgHye5+r/X//1QRPonmyuP0xL6KSKCbRLRXEczJOgnmCJeOO3M4RLIafiP87Fv95 1499 Wsfbjx7/6P3/f1/HPwnf4p8gyaf4/xj2q3/52//yz3/21z//8+Xv/P0PfuOnPxv+ 1500 6d9+/fyjX/uVv/nZz6N/+KPf/Y8//ff5X/xP1Ef/ufzf//rkj/1/vfvv3/rH+V/9 1501 5i/+5O9+0Pxt/lNN/ckvDv/XztnGthDHcVwkIo5GgphFws1DkCX2v6fetVF0LXbm 1502 brc+t69cHzbtddfT62oVIvHKCyR4g3hamMQrBJlXEi9MmLAICRLCWxERDxPihWuL 1503 1WwrmdZDfp9XTdpeepd+v73/9/vr/+LSA92nat90516uGKjt7HOGromrJ5785EzK 1504 8+07ZrYozOnFB/sOWieZLpkS4da9ddO5M++ePK2t6z/+ngIF/nX6Xx5TI9XVP8N+ 1505 0z+LCvM/FINA/9VgnCFGCBtnctGI/UpcATccFdN/XM3GM5WpgMrpn0HUF/0zyFiz 1506 5fXPGpYA+q8CY5c8Y7RDw/ofiqAJxoLzoo/3jNQCUVZEWhFVaIHK5w3WrM1Yfads 1507 Xj2WtuMkZ0EcTTOkufQhL+K8ROOjHcKE6TZ3TNfjKRV3OyUTFrGVfUfGhvKr/g6b 1508 3BmNp3DaQrAk7vJIDXaflH9CtqUzWoesWREuOQRvA2d8ef/xkGC4/itRAZWd/0Xm 1509 of1/CLL4/29Y/1eFomDxH4T+VedjJH+j6WjEIJArJnjlMr+v2WBFkr7vPGqkXHK0 1510 pqjEvIoxoRzJWEs/3WiXYuV3hZEjx9P1ql1pSjdRaqZD7mpPI8IjdHk6MgmJFezu 1511 Lcm46Ip2ai6eyGpKwJUNBbqIhGxRkNpI6qUlj0j567OE5NRzFCnIm0NxJDD+tjVK 1512 oCvc7lGloB8l+FQz1yTkgoTPw8baM0hR6EC6ea2jKehf5yg9VlIXLI519KbN9cH1 1513 IY8gu10tKcHbuCmu+PiE2srllJjT7A2ILbk2fozCaITTH9YYeXKacXllTTOumZwx 1514 jLlBj2o/5q4EzZowEwY/AX/C/ytRAZXv/6mh/octzP/QsP8H+P9/4f9gfsA/5P+V 1515 qADLzn8iYmj9T+f9nzEzsP9HVSj0f8Ozn2U2nEEswbahMJItZkJmiDbDSCNsNMpG 1516 OEbOz+nKZDSGSBnU/5/pvwIV4M/3f4b+2cL+PyQL/V9VmLqA+6gtmnf+/bGHh/uw 1517 t/cpQlQiqy5MaJ4SZmrUnhnMlUM1awf91wOPBoUlkxXT49TZe69e9G/fnTgdHrjt 1518 28bXXLs888jg7Lvk0vqrt27s8bb0nujlFz3benNW3YPAxp5zdxrn7kp82Bnc0Lff 1519 +XyaNCe8z7Xw6HRy39OPrbp44zUo8G/U/++tAH++/2OMl+bzfxbB/Hd1GGcmJWLj 1520 DKKS2K+kT3C3AQAAAAAAAAAAAAAAAAAAAAAAUI7Ptcw1rAB4AAA= 1521 -- END MESSAGE ARCHIVE -- 1523 Appendix C. Changelog 1525 NOTE TO THE RFC-EDITOR: Please remove this section prior to 1526 publication as an RFC. 1528 Changes from draft-ietf-sip-identity-03: 1529 - Softened requirement for TLS and direct connections; now 1530 SHOULD-strength, SIPS and Digest auth-int listed as alternatives. 1531 - Added non-normative section about authentication service 1532 behavior for backwards-direction requests within a dialog 1533 - Added support for CID URI in Identity Info 1534 - Added new response codes (436 and 437) corresponding to error 1535 cases for an unsupported URI scheme and an unsupported 1536 certificate, respectively 1538 Changes from draft-ietf-sip-identity-02: 1539 - Extracted text relating to providing identity in SIP responses; 1540 this text will appear in a separate draft 1541 - Added compliance testing/example section 1542 - Added CSeq to the signature of the Identity header to prevent a 1543 specific cut-and-paste attack; also added addr-spec of the To 1544 header to the signature of the Identity header for similar reasons 1545 - Added text about why neither Via headers nor display-names are 1546 protected by this mechanism 1547 - Added bit-exact reference files for compliance testing 1548 - Added privacy considerations 1550 Changes from draft-ietf-sip-identity-01: 1551 - Completely changed underlying mechanism - instead of using an 1552 AIB, the mechanism now recommends the use of the Identity header 1553 and Identity-Info header 1554 - Numerous other changes resulting from the above 1555 - Various other editorial corrections 1557 Changes from draft-peterson-sip-identity-01: 1558 - Split off child draft-ietf-sip-authid-body-00 for defining of 1559 the AIB 1560 - Clarified scope in introduction 1561 - Removed a lot of text that was redundant with RFC3261 1562 (especially about authentication practices) 1563 - Added mention of content indirection mechanism for adding token 1564 to requests and responses 1565 - Improved Security Considerations (added piece about credential 1566 strength) 1568 Changes from draft-peterson-sip-identity-00: 1569 - Added a section on authenticated identities in responses 1570 - Removed hostname convention for authentication services 1571 - Added text about using 'message/sip' or 'message/sipfrag' in 1572 authenticated identity bodies, also RECOMMENDED a few more headers 1573 in sipfrags to increase reference integrity 1574 - Various other editorial corrections 1576 Intellectual Property Statement 1578 The IETF takes no position regarding the validity or scope of any 1579 Intellectual Property Rights or other rights that might be claimed to 1580 pertain to the implementation or use of the technology described in 1581 this document or the extent to which any license under such rights 1582 might or might not be available; nor does it represent that it has 1583 made any independent effort to identify any such rights. Information 1584 on the procedures with respect to rights in RFC documents can be 1585 found in BCP 78 and BCP 79. 1587 Copies of IPR disclosures made to the IETF Secretariat and any 1588 assurances of licenses to be made available, or the result of an 1589 attempt made to obtain a general license or permission for the use of 1590 such proprietary rights by implementers or users of this 1591 specification can be obtained from the IETF on-line IPR repository at 1592 http://www.ietf.org/ipr. 1594 The IETF invites any interested party to bring to its attention any 1595 copyrights, patents or patent applications, or other proprietary 1596 rights that may cover technology that may be required to implement 1597 this standard. Please address the information to the IETF at 1598 ietf-ipr@ietf.org. 1600 Disclaimer of Validity 1602 This document and the information contained herein are provided on an 1603 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1604 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1605 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1606 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1607 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1610 Copyright Statement 1612 Copyright (C) The Internet Society (2005). This document is subject 1613 to the rights, licenses and restrictions contained in BCP 78, and 1614 except as set forth therein, the authors retain all their rights. 1616 Acknowledgment 1618 Funding for the RFC Editor function is currently provided by the 1619 Internet Society.