idnits 2.17.1 draft-peterson-sip-identity-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The 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 (July 1, 2002) is 7967 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-peterson-sip-privacy - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-03) exists of draft-sparks-sip-mimetypes-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar 4 Expires: December 30, 2002 July 1, 2002 6 Enhancements for Authenticated Identity Management in the Session 7 Initiation Protocol (SIP) 8 draft-peterson-sip-identity-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 30, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 The existing mechanisms for expressing identity in the Session 40 Initiation Protocol oftentimes do not permit an administrative domain 41 to verify securely the identity of the originator of a request. This 42 document recommends practices and conventions for authenticating end 43 users, and proposes a way to distribute secure authenticated 44 identities within SIP messages. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 3. Sending Requests through an Authentication Service . . . . . . 7 51 4. Authentication Practices . . . . . . . . . . . . . . . . . . . 8 52 4.1 Issuing Challenges with Realms . . . . . . . . . . . . . . . . 8 53 4.2 Determining Identity with Credentials . . . . . . . . . . . . 9 54 4.3 Analyzing Requests . . . . . . . . . . . . . . . . . . . . . . 9 55 4.4 Accounting for Authentication . . . . . . . . . . . . . . . . 10 56 4.5 Forwarding the Request . . . . . . . . . . . . . . . . . . . . 10 57 5. Sharing Verified Identities . . . . . . . . . . . . . . . . . 11 58 5.1 Authenticated Identity within a Body . . . . . . . . . . . . . 11 59 5.2 Body Added by Authentication Service . . . . . . . . . . . . . 12 60 5.3 Body Added by Client . . . . . . . . . . . . . . . . . . . . . 13 61 5.4 Example of a Request with an Authenticated Identity Body . . . 14 62 6. Receiving an Authenticated Identity . . . . . . . . . . . . . 16 63 6.1 Proxy Server Handling . . . . . . . . . . . . . . . . . . . . 17 64 6.2 User Agent Handling . . . . . . . . . . . . . . . . . . . . . 17 65 7. Identity in Responses . . . . . . . . . . . . . . . . . . . . 19 66 8. Selective Sharing of Identity . . . . . . . . . . . . . . . . 20 67 8.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 20 68 8.2 Encryption of Identity . . . . . . . . . . . . . . . . . . . . 21 69 8.3 Example of Encryption . . . . . . . . . . . . . . . . . . . . 21 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 73 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 74 B. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 75 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 C. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 29 79 1. Introduction 81 This document provides enhancements to the existing mechanisms for 82 authenticated identity management in the Session Initiation Protocol 83 (SIP [1]). 85 The baseline SIP protocol allows a user agent to express the identity 86 of its user in a number of headers. The primary place for identity 87 information asserted by the sender of a request is the From header. 88 The From header field contains a URI (like 'sip:alice@atlanta.com') 89 and an optional display-name (like "Alice") that identifies the 90 originator of the request. A user may have many identities that are 91 used in different contexts. 93 Typically, this URI is an address-of-record that can be dereferenced 94 in order to contact the originator of the request; specifically, it 95 is usually the same address-of-record under which a user registers 96 their devices in order to receive incoming requests. This address- 97 of-record is assigned and maintained by the administrator of the SIP 98 service in the domain identified by the host portion of the address- 99 of-record (which may have any of a number of relationships with the 100 end user). However, the From field of a request can usually be set 101 arbitrarily by the user of a SIP user agent; the From header of a 102 message provides no internal assurance that the originating user can 103 legitimately claim this identity. Nevertheless many SIP user agents 104 will obligingly display the contents of the From field as the 105 identity of the originator of a received request (as a sort of 106 'Caller-ID' function). 108 To satisfy the requirement for a more reliable way of identifying 109 parties in a SIP session, a number of cryptographic authentication 110 systems are described in the SIP standard, including mechanisms based 111 on HTTP Digest, S/MIME and transport or network layer security. 112 Among other things, these mechanisms allow a server to verify that a 113 user agent can legitimately assert a specific identity. Whether or 114 not the recipient of these credentials can verify them is based on 115 whether the credentials are asymmetric, and publicly verifiable by 116 third parties, or symmetric, and verifiable only by parties that have 117 a pre-existing relationship with the user. 119 Symmetric: Authentication with symmetric keys usually entails the 120 transmission of some sort of secret credentials (typically a 121 username and password) from the client to the server. Secrets- 122 based authentication assumes a pre-existing relationship (an 123 agreement on a secret) between the client that originates a 124 request and the server that responds with a challenge. Useful 125 secrets-based authentication schemes use cryptography to conceal 126 the credentials so they can not be observed and reused by 127 eavesdroppers on the network. Secrets are usually memorized by 128 end users, and thus do not necessitate any special configuration 129 of user agents. 131 Asymmetric: Asymmetric credentials require a Public Key 132 Infrastructure (PKI) that manages public and private keys. PKI- 133 based authentication usually relies on a certificate authority 134 that issues a custom certificate to each entity that would like to 135 prove its identity, and a common root certificate to each entity 136 that would like to verify the identity of others. In this system 137 there is no need for any pre-existing relationship between the 138 clients and servers (unless in the absence of a certificate 139 authority self-signed certificates are used). However, PKI has to 140 date only been effective in asserting the identity of a hostname - 141 there is a widespread belief that implementing a PKI for 142 certificates that assert the identity of individuals is currently 143 impractical. Each host MUST be configured with any certificate 144 that asserts its identity. 146 Most user agents authenticate themselves with shared secrets. In 147 baseline SIP, the Digest authentication method (which is required for 148 all user agents and servers) allows users to provide a username and 149 password to authenticate themselves in the context of a particular 150 realm (for example, the identity 'alice' within the realm 151 'atlanta.com' might have the password 'x63Mdo+'). 153 Digest therefore works well for functions like SIP registration, in 154 which the target of a request is a server within the realm in which a 155 user can prove an identity. However, the credentials with which a 156 user proves that they are 'sip:alice@atlanta.com' cannot be verified 157 by a server in another realm, like biloxi.com - Alice shares the 158 secret with atlanta.com, not biloxi.com. Thus, if Alice were to send 159 a request to a proxy server in the biloxi.com realm, biloxi.com has 160 no way of determining whether or not Alice can legitimately claim the 161 identity 'sip:alice@atlanta.com'. biloxi.com is then left only with 162 the unreliable From field for ascertaining the identity of the 163 originator of interdomain requests. 165 However, were Alice to proxy her request through an atlanta.com proxy 166 server, atlanta.com might be able to verify her identity before 167 passing the request to its destination, biloxi.com. Therefore, this 168 document proposes a new logical role for network intermediaries 169 called an authentication service. The authentication service role 170 would most likely be instantiated by the local outbound proxy server 171 within an administrative domain. Once an authentication service has 172 verified the identity of the originator of a request, it can add the 173 result of the authentication process to the request for the benefit 174 of downstream recipients. 176 User agents can be configured, statically or on a per-call basis, to 177 send requests through an authentication service. After a request has 178 passed through an authentication service in a given domain (e.g. 179 atlanta.com) downstream recipients (e.g. in biloxi.com) will be able 180 to determine that atlanta.com asserts a specific authenticated 181 identity for the originator of this message, like 182 'sip:alice@atlanta.com'. 184 In some cases, this authenticated identity can be distributed by the 185 authentication service to any potential recipients of the request 186 without restriction. In other cases, for reasons of network policy, 187 or user privacy constraints, the distribution of the authenticated 188 identity will be restricted. 190 In summary, the identity that appears in the From field of a SIP 191 request provides a way that the originator can be canonically reached 192 (and therefore provides some accountability for that user). The best 193 way for a SIP user to prove that they can legitimately claim an 194 identity is to provide the same credentials they would need to 195 provide in order to register to receive requests for that identity. 196 For that purpose, this document defines an authentication service 197 that verifies the credentials of an end user in their local 198 administrative domain before sending requests to their destinations. 199 This authentication service can then sign the identity that results 200 from this authentication and make this identity available to 201 recipients of the request, thereby proving that the administrative 202 domain responsible for the originating user registers has verified 203 that user's identity. Effectively, this allows a user's 204 authentication with a single server to be bootstrapped into a 205 publicly-verifiable authentication. 207 By way of example, the manner in which a user authenticates 208 themselves to an authentication service is in this document 209 restricted to the mechanisms that are available in [1], specifically 210 the Digest authentication scheme, as it is common to all SIP- 211 compliant endpoints. However, these mechanisms have no dependency on 212 any particular authentication scheme. 214 2. Terminology 216 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 217 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 218 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 219 described in RFC2119 [2] and indicate requirement levels for 220 compliant SIP implementations. 222 3. Sending Requests through an Authentication Service 224 An authentication service is a logical role played by a network 225 intermediary, such as a SIP proxy server. Commonly, the 226 authentication service function will be instantiated by a local 227 outbound proxy server. Authentication services are capable of 228 verifying the identity of users through some means. Authentication 229 services are also capable of sharing this verified identity in a 230 secure manner. 232 Requests from a user agent are sent through an authentication service 233 because the user agent is configured (with a pre-loaded Route header, 234 perhaps) to send all requests through the service. 236 A user has some incentive to send calls through an authentication 237 service, in that: 239 Authentication services help to prevent identity theft, and the 240 many potential annoyances that could result from being 241 impersonated, and, 243 Administrative domains could implement policies that reject 244 requests from users that have not gone through an authentication 245 service appropriate for the administrative domain listed in the 246 From header of their messages. 248 Optimally, a user should be able to send SIP messages to their 249 authentication service directly, without going through any SIP proxy 250 servers, since many authentication systems (including Digest) are not 251 optimally secure when handled by intermediaries. An authentication 252 service will frequently be co-located with a user agent's first-hop 253 local outbound proxy. 255 4. Authentication Practices 257 When a user first forms a connection to a SIP entity that implements 258 the authentication service role, the user SHOULD make use of network 259 or transport layer security, preferably contacting the authentication 260 service without going through any intermediaries. This document 261 recommends the use of Transport Layer Security (TLS) to connect to 262 the authentication service. This in turn allows the authentication 263 service to potentially offer a certificate directly to the end user, 264 as well as ensuring confidentiality, integrity, and replay protection 265 during the challenge phase. If the user agent is more than one hop 266 away from the authentication service, it may make sense to use the 267 SIPS URI scheme to improve the security of requests routed through 268 the authentication service. 270 Any entity that implements the authentication service role MUST 271 possess a certificate that has been issued by a certificate 272 authority. The SubjectAltName of the certificate SHOULD be the 273 fully-qualified domain name of the device on which the authentication 274 service is running. Only one logical authentication service SHOULD 275 operate in a given administrative domain. The manner in which an 276 authentication service can be recognized to be the canonical 277 authority for an administrative domain is currently an open issue. 279 4.1 Issuing Challenges with Realms 281 Obviously, all authentication services have their own sets of users 282 and corresponding credentials; when a user is challenged by an 283 authentication service, that user selects credentials that are 284 appropriate for the service in question. For the purposes of this 285 document, following the terminology in Digest authentication, an 286 authentication service has a 'realm' which provides a context in 287 which a user is asked to authenticate. For example, when an 288 authentication service challenges a user for Digest authentication 289 with the 407 status code, the challenge MUST be sent for a realm 290 corresponding to the hostname of the authentication service. Note 291 that a user agent SHOULD consider it a cause for concern (though not 292 necessarily an error condition) if the realm of a challenge does not 293 correspond both with the hostname of the authentication service and 294 any certificate presented by the authentication service on connection 295 - users SHOULD be notified of this occurrence. 297 Once again, note that Digest authentication is used merely by way of 298 example. Other mechanisms within SIP, or out-of-band mechanisms, 299 could be used to authenticate the user. If these authentication 300 systems do not explicitly support the concept of realms, the realm in 301 which a challenge occurs should be understood by the user agent to be 302 the hostname of the authentication service. Any method of 303 authentication used by an authentication service, MUST therefore have 304 a means of communicating, at the very least, its hostname to a user. 305 If these authentication systems do not support credentials that 306 express a specific username, then a username SHOULD be taken by the 307 authentication service from the username portion of the URI in the 308 From header field of the SIP request. 310 4.2 Determining Identity with Credentials 312 If a user agent is challenged (in SIP Digest, for example, with a 401 313 or 407 response code) and it has access to credentials for the realm 314 in question, these credentials will be provided in a resubmission of 315 the request to the authentication service. In Digest, the 316 authentication service MUST extract and verify these credentials from 317 the resubmission of the request. 319 The username associated with these credentials SHOULD be combined 320 with the name of the administrative domain of the authentication 321 service in order to form the authenticated identity of the user. For 322 example, if the credentials were valid for the username 'alice', for 323 an authentication service within the atlanta.com administrative 324 domain, the authenticated identity would be 'sip:alice@atlanta.com'. 325 An authentication service MAY also have a particular display-name 326 which it associates with particular users that will be included in 327 the authenticated identity. 329 Note that some user agents MAY provide 'anonymous' credentials with 330 no password in a resubmission of a request after a challenge. 331 Whether or not an authentication service considers this to be a 332 successful authentication is a matter of local policy, but the 333 authentication service SHOULD NOT assert this 'anonymous' identity to 334 others in the manner described in Section 5. 336 The credentials that a user provides to an authentication service 337 SHOULD be the same credentials that are provided when the user 338 registers in this administrative domain. 340 4.3 Analyzing Requests 342 Some authentication services MAY wish to inspect the contents of the 343 From header of an outbound request. Depending on the policy of the 344 authentication service, it might not be appropriate for the From 345 header to differ from the authenticated identity that the service has 346 verified. Some authentication services MAY reject requests (with a 347 403 Forbidden) that assert an inappropriate identity in the From. 349 Authentication services MAY also place restrictions on the display- 350 name as well as the URI associated with the From header. 352 Note that some users MAY supply an anonymous From header (see [3]) 353 for some requests. Authentication services generally SHOULD NOT 354 consider this to conflict with any identity information learned in 355 the authentication process. For more information on the obligations 356 of authentication services with respect to privacy, see Section 8.1. 358 It may not be necessary for an authentication service to prevent the 359 arbitrary assignment of the From field if the authentication service 360 has another way of sharing authenticated identity information (see 361 Section 5). Steps for reconciling the user-asserted From header with 362 authenticated identity data are given in Section 6.2. 364 4.4 Accounting for Authentication 366 Authentication services MAY record the successful authentication of a 367 request, including its dialog identifiers and Request-URI, in order 368 to provide some accountability when administrative requests are made 369 for information about the parties participating in a particular 370 session. Some mechanisms by which a user is authenticated and 371 authorized may also persist accounting data about the request, 372 although such mechanisms are outside the scope of this document. 374 Authentication services MAY also wish to log failed authentication 375 attempts, especially those that reflect repeated attempts to try 376 different credentials for the same username. 378 4.5 Forwarding the Request 380 Once an authentication service has authenticated the originator of a 381 request, if it does not wish to provide any further identification 382 services, it MUST subsequently forward the request in accordance with 383 the conventional request routing logic in the SIP specification. 385 If the authentication services also wishes to share the authenticated 386 identity it has verified, it can use the mechanisms described in 387 Section 5. 389 5. Sharing Verified Identities 391 Authenticated identities SHOULD be shared unless the authentication 392 service has a reason to do otherwise. By authenticating themselves, 393 originating users must understand that they are giving the 394 authentication service the right to share the provided identity with 395 others. If they wish to prevent this, users MUST request privacy for 396 their authentication information (see Section 8.1). 398 Note that the practices described in this section can also be 399 leveraged by a logical authentication service that is instantiated by 400 a user agent, provided the user agent holds a certificate that is 401 publicly verifiable. 403 5.1 Authenticated Identity within a Body 405 As a way of sharing authenticated identity among parties in the 406 network, a special type of MIME body, which will subsequently be 407 referred to as an 'authenticated identity body', is defined in this 408 section. An authenticated identity body allows an authentication 409 service to cryptographically sign the identity of the originator of 410 the message in question. 412 An authenticated identity body is a MIME body of type 'message/sip' 413 or 'message/sipfrag' (see [4]). This body MUST have a Content- 414 Disposition disposition-type of 'auth-id', a new value defined in 415 this document specifically for authenticated identity bodies. The 416 Content-Disposition header SHOULD also contain a 'handling' parameter 417 indicating that this MIME body is optional. 419 Authenticated identity bodies of the 'message/sipfrag' MIME type MUST 420 contain the following headers: From, Date and Call-ID; they SHOULD 421 also contain the To, Contact and Cseq header. The From header field 422 MUST be populated by the authentication service with the 423 authenticated identity itself, as discussed above in Section 4.2; if 424 the authentication service verifies the display-name of the From 425 header field, it MUST be included in the authenticated identity body, 426 and if it does not verify the display-name of the From header field 427 it MUST NOT be included. Authenticated identity bodies MAY contain 428 any other headers that help to uniquely identify the transaction or 429 provide related reference integrity. An example of an authenticated 430 identity body is: 432 Content-Type: message/sipfrag 433 Content-Disposition: auth-id; handling=optional 435 From: Alice 436 To: Bob 437 Contact: 438 Date: Thu, 21 Feb 2002 13:02:03 GMT 439 Call-ID: a84b4c76e66710 440 Cseq: 314159 INVITE 442 Once the authenticated identity body has been fully populated, it 443 MUST be signed by the authentication service that has created it. An 444 unsigned authenticated identity body MUST NOT be honored by any 445 recipients. An authenticated identity body MUST be signed with the 446 public key corresponding to the same certificate that the 447 authentication service uses to authenticate itself for the purposes 448 of transport of network layer security such as TLS (see Section 4). 449 A full example of a message with a signed authenticated identity MIME 450 body is given in Section 5.4. 452 After the authenticated body has been signed, some entity SHOULD 453 added it to any existing MIME bodies in the request, if necessary by 454 transitioning the outermost MIME body to a 'multipart/mixed' format. 455 But which participant in the dialog should add the authenticated 456 identity body, the authentication service or the originating user 457 agent? Both options are considered in the following sections. 458 Authentication services MUST support the mechanism in Section 5.3 and 459 MAY support the mechanism in Section 5.2. 461 5.2 Body Added by Authentication Service 463 The first possibility is that the authentication service could add 464 the body to the request itself before forwarding the request. 465 However, the authentication service role is usually played by 466 entities that act as proxy servers for most requests, and proxy 467 servers cannot modify message bodies. In order to add an 468 authenticated identity body, the authentication service needs to act 469 as a transparent back-to-back user agent, effectively terminating the 470 request and re-originating it with a new body appended to any 471 existing MIME bodies. 473 This mechanism has some potential advantages over sending the 474 authenticated identity body back to the originating user agent. For 475 one, it saves on additional round-trip times for signaling that 476 result from passing the body back to the user agent. It also 477 requires no new SIP mechanisms, whereas any method of asking a user 478 agent to include a body in a resubmission to the current request 479 would introduce new protocol requirements. 481 However, there are proposed SIP integrity mechanisms that place a 482 signature over the entire message body in a SIP message header. Were 483 a server to add to the body of a message that was protected by such 484 signature, that could be perceived as an integrity violation by 485 downstream recipients of the message. 487 5.3 Body Added by Client 489 Alternatively, the authentication service could in some fashion 490 return the authenticated identity MIME body to the originating user 491 agent, prompting the user agent to retry the request with the 492 authenticated identity MIME body attached. No existing SIP mechanism 493 performs this function. Therefore, this document defines a 428 "Use 494 Authenticated Identity" response code. 496 An authentication service sends a 428 with a MIME body in order to 497 request that a user agent add the enclosed MIME body to their request 498 and retry the request. A 428 MUST have at most a single MIME body. 499 This MIME body MUST be signed by the authentication service. 501 The use of 428 without any MIME body is also defined in this 502 document. It can be sent by any server to reject a request because 503 the request does not contain an authenticated identity body. A user 504 agent receiving this rejection SHOULD retry their request through an 505 authentication service. 507 In order to signal to the authentication services that the 508 originating user agent supports the receipt of the 428 response code, 509 a new option-tag has been defined, the 'auth-id' option-tag. User 510 agents SHOULD supply the 'auth-id' option-tag in a Supported header 511 whenever they provide credentials to a server (for example, in Digest 512 authentication, whenever a Proxy-Authorization header is added to a 513 request). 515 Using the 428 response code may introduce extra round-trip times for 516 messages, delaying the setup of requests (one RTT for the 407, 517 another for the 428). However, there are some circumstances under 518 which extra RTTs may not impede performance. If the originating user 519 agent possesses a non-stale nonce (assuming Digest authentication) 520 from the authentication service, it can pre-emptively include a 521 Proxy-Authorization header, eliminating one RTT. With regard to the 522 second RTT, note that the request needn't necessarily go through the 523 authentication service again once the authenticated identity body has 524 been added - it could go directly to its destination, which reduce 525 the impact of the second RTT. 527 There are two reasons why the originating user agent should be the 528 party responsible for adding the authenticated identity body to the 529 request. Firstly, because this gives the client the opportunity to 530 inspect the body itself (perhaps only to see whether or not it is 531 encrypted; see Section 8.2) in order to verify that the authenticated 532 identity corresponds with the provided credentials and the user's 533 preferences. Secondly, the client can provide a signature over the 534 entire body of the message (either with S/MIME or some header-based 535 mechanism) so that the final recipient of messages can be assured 536 that all information in the body is there at the originator's behest. 538 5.4 Example of a Request with an Authenticated Identity Body 540 The following shows a full SIP INVITE request with an authenticated 541 identity body (one that has been added by the originating user 542 agent): 544 INVITE sip:bob@biloxi.com SIP/2.0 545 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 546 To: Bob 547 From: Alice ;tag=1928301774 548 Call-ID: a84b4c76e66710 549 CSeq: 314159 INVITE 550 Max-Forwards: 70 551 Date: Thu, 21 Feb 2002 13:02:03 GMT 552 Contact: 553 Content-Type: multipart/mixed; boundary=unique-boundary-1 555 --unique-boundary-1 557 Content-Type: application/sdp 558 Content-Length: 147 560 v=0 561 o=UserA 2890844526 2890844526 IN IP4 here.com 562 s=Session SDP 563 c=IN IP4 pc33.atlanta.com 564 t=0 0 565 m=audio 49172 RTP/AVP 0 566 a=rtpmap:0 PCMU/8000 568 --unique-boundary-1 569 Content-Type: multipart/signed; 570 protocol="application/pkcs7-signature"; 571 micalg=sha1; boundary=boundary42 572 Content-Length: 608 574 --boundary42 575 Content-Type: message/sipfrag 576 Content-Disposition: auth-id; handling=optional 577 From: Alice 578 To: Bob 579 Contact: 580 Date: Thu, 21 Feb 2002 13:02:03 GMT 581 Call-ID: a84b4c76e66710 582 Cseq: 314159 INVITE 584 --boundary42 585 Content-Type: application/pkcs7-signature; name=smime.p7s 586 Content-Transfer-Encoding: base64 587 Content-Disposition: attachment; filename=smime.p7s; 588 handling=required 590 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 591 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 592 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 593 7GhIGfHfYT64VQbnj756 595 --boundary42-- 597 --unique-boundary-1-- 599 6. Receiving an Authenticated Identity 601 There are a number of ways that identity information can be presented 602 in a SIP request, and all of them must be reconcilable - that is, 603 there must be a way to arrive at the identity that should be 604 displayed to the user as the caller's identity, and so forth. 606 It is therefore RECOMMENDED in this document that these forms of 607 identity be reduced into two broad categories: suspect and valid 608 identities. All of the following SHOULD be considered suspect by 609 recipients: 611 o Recipients may receive a normal From header field in the SIP 612 message - unsigned and unverified. All SIP requests must contain 613 such a header, but in some cases it may not purport to contain a 614 usable value (it may assert an anonymous identity), and no other 615 identity might be asserted by the request. 617 o Recipients may receive a From header in an authenticated identity 618 body that was signed by a self-signed certificate that is 619 unrecognized and/or untrusted by the user, or signed by an 620 authentication service using a certificate authority that the user 621 cannot verify. 623 o Recipients may receive a From header in an authenticated identity 624 body that has been signed by an authentication service with a 625 valid certificate, but which has internal consistency problems: 626 the hostname asserted by the certificate may not correspond to the 627 domain in the From header, the Date may be obviously stale, the 628 Call-ID may be a repeat of a recently received value, or mandatory 629 headers may be missing from the authenticated identity body. 631 Recipients may also unknowingly receive From headers in encrypted 632 bodies which they cannot decrypt (see Section 8.2) that, of course, 633 cannot be usable identities. 635 The following are identities that SHOULD be considered valid by a 636 recipient: 638 o Recipients may receive a From header in an authenticated identity 639 body that has been signed by a self-signed certificate that is 640 recognized and trusted by the recipient. 642 o Recipients may receive a From header in an authenticated identity 643 body that has been signed by an end-user certificate issued by a 644 certificate authority that is recognized and trusted by the 645 recipient. 647 o Recipients may receive a From header in an authenticated identity 648 body that has been signed by an authentication service that 649 properly follows the practices described in Section 4. 651 The exact behavior that is followed on receipt of a suspect or valid 652 identity varies with the role of the recipient. 654 6.1 Proxy Server Handling 656 Proxy servers generally should not attempt to inspect MIME bodies. 657 However, intermediaries that implement the authentication service 658 logical role MAY inspect MIME bodies in order to find one with a 659 Content-Disposition of 'auth-id'. 661 For the most part, the actual value of an authenticated identity is 662 not likely to be of interest to a proxy server, though it MAY refuse 663 to process a request that does not contain a valid authenticated 664 identity body (using the 428 request, as described in Section 5.3). 665 However, proxy servers MAY additionally maintain lists of known 666 problem users that are banned from making requests, for example, and 667 subsequently reject some requests after comparing their authenticated 668 identities to this list. 670 6.2 User Agent Handling 672 A user agent needs to determine which identity for the originator of 673 a request should be displayed to the user, perhaps as a 'Caller-ID' 674 function. The following is a RECOMMENDED set of precedence rules for 675 arriving at a single identity that should be displayed. 677 If one valid form of identity is present, the user agent displays 678 that identity. If both valid forms of identity are present, the 679 authenticated identity (rather than a recognized self-signed S/MIME 680 signature) is preferred, but both potentially are viewable by a user. 682 If neither of the valid forms of identity are available, the user 683 agent displays the normal From field in the SIP message, but other 684 identities are viewable by a user. However, if that From field would 685 display an anonymous identity, the user agent SHOULD display another 686 value instead (probably an identity in a signed S/MIME body). 688 When it displays an identity to its user, a user agent SHOULD also 689 have some way of designating between a valid and suspect identity 690 that is easy for the user to distinguish. 692 Note that user agents also need to determine the identity of the 693 originator of a request for the purposes of per-user blocking or 694 screening before the user is alerted and any identity is displayed. 696 Generally, if any of the asserted identities in a request match an 697 identity that is blocked, the user should not be alerted and the 698 request SHOULD be rejected. 700 7. Identity in Responses 702 Many of the practices described in the preceding sections can be 703 applied to responses as well as requests, with some important 704 differences. Primarily, the distinction is that a response cannot be 705 challenged or resubmitted in the same manner as a request. However, 706 when a user agent registers under a particular identity, and thereby 707 becomes eligible to receive requests and send responses associated 708 with that identity, it provides credentials that prove its identity, 709 and thus the registrar is in a reasonable position to act as an 710 authentication service for responses. 712 An authentication service that acts as a registrar can add to a 713 response an authenticated identity body that corresponds to the 714 identity of the originator of that response in roughly the same 715 manner described in Section 5.2 - the authentication service adds the 716 authenticated identity body to a response before it forwards the 717 response towards the originator of the request. There is no way for 718 an authentication service to perform a function for responses 719 comparable to the mechanism described in Section 5.3. 721 The same rules for the creation of the authentication identity body 722 for requests given in Section 5.1 apply to responses, including the 723 mandatory and optional inclusion of various headers in 724 'message/sipfrag' bodies, with the following exception - when the 725 authentication service creates the authenticated identity body, it 726 should substitute the actual identity of the user (derived, as 727 described in Section 4.2, from the username and realm for which the 728 user has registered) for any conflicting value in the To header field 729 of the response before signing the response. 731 When the originating user agent of a request receives a response 732 containing an authenticated identity body, it SHOULD compare the 733 identity in the To header field of the authenticated identity body of 734 the response with the original value of the To header field in the 735 request. If these represent different identities, the user agent 736 SHOULD render the identity in the authenticated identity body of the 737 response to its user. Note that a discrepancy in these identity 738 fields is not necessary an indication of a security breach; normal 739 retargeting may simply have directed the request to a different final 740 destination. User agents might furthermore indicate that this 741 identity is suspect or valid in accordance with the guidelines given 742 in Section 6. 744 8. Selective Sharing of Identity 746 Most of the time, there is no need to restrict the propagation of 747 verified identities in the network. User agents and intermediaries 748 benefit from receiving verified identities. However, in some cases 749 intermediaries wish to restrict the distribution of identity 750 information, for example if 752 o the authenticated identity body contains an identity that is only 753 meaningful as an internal identifier within a particular service 754 provider's network, or, 756 o the originating user agent has requested privacy, and the 757 unregulated distribution of the authenticated identity body would 758 violate that request. 760 If it is not appropriate to share an authenticated identity, an 761 authenticated identity body SHOULD NOT be created and distributed. 762 However, in some cases there may be other entities in the 763 administrative domain of the authentication service that are 764 consumers of the authenticated identity. If, for example, each of 765 these servers needed to challenge the user individually for identity, 766 it might significantly delay the processing of the request. For that 767 reason, it may be appropriate to circulate authenticated identity 768 bodies among a controlled set of entities. For that purpose, an 769 encryption mechanism for authenticated identities is provided. 771 8.1 Requesting Privacy 773 When users provide credentials to an authentication service, they MAY 774 explicitly notify the service that they do not wish their 775 authenticated identity to be circulated. Usually, the user in 776 question would also be taking other steps to preserve their privacy 777 (perhaps by including an anonymous From header). 779 Therefore, authentication services MUST support the privacy 780 mechanisms described in [3]. Users requesting privacy should also 781 support the mechanisms described in that document. 783 In particular, this document uses an identity-specific priv-value 784 that can appear in the Privacy header, a value of 'id'. This Privacy 785 value requests that the results of authentication should not be 786 shared by the authenticating server. An authentication service 787 SHOULD NOT create an authenticated identity body for a request when 788 'id' privacy has been requested. If such a body is created, it MUST 789 be encrypted. 791 8.2 Encryption of Identity 793 Many SIP entities that support the use of S/MIME for signatures will 794 also support S/MIME encryption. Encryption of a body prevents any 795 parties other those that hold the decryption key from inspecting the 796 body. Note that the key used for encryption SHOULD be unrelated to 797 the public key in a certificate that is used by an authentication 798 service to prove its identity. 800 While encryption of an authenticated identity body entails that only 801 the holder of a specific key can decrypt the body, that single key 802 could be distributed throughout a network of hosts that exist under 803 common policies. The security of the body is therefore predicated on 804 the secure distribution of the key. However, for some networks (in 805 which there are federations of trusted hosts under a common policy), 806 the widespread distribution of a decryption key could be appropriate. 807 Some telephone networks, for example, might require this model. 809 When an authenticated identity is encrypted, the authenticated 810 identity body SHOULD always be encrypted before it is signed. Note 811 that this means that the recipients of the request, even if they are 812 unable to inspect the authenticated identity body, will still be able 813 to see which authentication service signed that body (although it 814 will not necessarily be obvious that the body contains an 815 authenticated identity). An example of a signed and encrypted 816 authenticated identity MIME body follows: 818 8.3 Example of Encryption 820 The following is an example of an encrypted and signed authenticated 821 identity body (without any of the preceding SIP headers). In a 822 rendition of this body sent over the wire, the text wrapped in 823 asterisks would be encrypted. 825 Content-Type: multipart/signed; 826 protocol="application/pkcs7-signature"; 827 micalg=sha1; boundary=boundary42 828 Content-Length: 568 830 --boundary42 832 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 833 name=smime.p7m 834 Content-Transfer-Encoding: base64 835 Content-Disposition: attachment; filename=smime.p7m 836 handling=required 837 Content-Length: 231 839 *********************************************************** 840 * Content-Type: message/sipfrag * 841 * Content-Disposition: auth-id; handling=optional * 842 * * 843 * From: sip:alice@atlanta.com * 844 * Call-ID: a84b4c76e66710 * 845 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 846 *********************************************************** 848 --boundary42 850 Content-Type: application/pkcs7-signature; name=smime.p7s 851 Content-Transfer-Encoding: base64 852 Content-Disposition: attachment; filename=smime.p7s; 853 handling=required 855 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 856 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 857 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 858 7GhIGfHfYT64VQbnj756 860 --boundary42-- 862 9. Security Considerations 864 Users SHOULD NOT provide credentials to an authentication service to 865 which they cannot initiate a direct connection, preferably one 866 secured by a network or transport layer security protocol such as 867 TLS. If a user does not receive a certificate from the 868 authentication service over this lower-layer protocol that 869 corresponds to the realm in a challenge, then it is possible that a 870 rogue server is attempting to pose as a authentication service for a 871 realm that it does not control, possibly in an attempt to collect 872 valid user passwords for that realm. 874 If a user cannot connect directly to the desired authentication 875 service, the user SHOULD at least use a SIPS URI to ensure that 876 mutual TLS will be used to reach the remote server. 878 The certificates that are required to operate an authentication 879 service need to assert only the hostname of the authentication 880 service, and for that reason, existing certificate authorities could 881 provide adequate certificates for this mechanism. However, not all 882 proxy servers and user agents will be able support the root 883 certificates of all certificate authorities, and moreover there are 884 some significant differences in the policies by which certificate 885 authorities issue their certificates. This document makes no 886 recommendations for the usage of particular certificate authorities, 887 nor does it describe any particular policies that certificate 888 authorities should follow, but it is anticipated that operational 889 experience will create de facto standards for the purposes of 890 authentication services. Some federations of service providers, for 891 example, might only trust certificates that have been provided by a 892 certificate authority operated by the federation. 894 10. IANA Considerations 896 This document defines a new MIME Content-Disposition disposition-type 897 value of 'auth-id'. This value is reserved for MIME bodies that 898 contain an authenticated identity, as described in section Section 899 5.1. 901 This document also defines a new SIP status code, 428 Use 902 Authenticated Identity. The use of this status code is further 903 described below in Section 5.3. 905 Finally, this document also uses a new priv-value for the Privacy 906 header specified in [3], the token 'id'. This is further described 907 in Section 8.1. 909 References 911 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 912 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 913 Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work 914 in progress), February 2002. 916 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 917 levels", RFC 2119, March 1997. 919 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 920 Protocol (SIP)", draft-peterson-sip-privacy-00 (work in 921 progress), April 2002. 923 [4] Sparks, R., "Internet Media Types message/sip and 924 message/sipfrag", draft-sparks-sip-mimetypes-01 (work in 925 progress), March 2002. 927 Author's Address 929 Jon Peterson 930 NeuStar, Inc. 931 1800 Sutter St 932 Suite 570 933 Concord, CA 94520 934 US 936 Phone: +1 925/363-8720 937 EMail: jon.peterson@neustar.biz 938 URI: http://www.neustar.biz/ 940 Appendix A. Acknowledgments 942 The authors would like to thank Eric Rescorla, Rohan Mahy, Robert 943 Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for 944 their comments. 946 Appendix B. To Do 948 S/MIME authentication: If the authentication between the client and 949 server is performed with S/MIME, possibly using a shared secret, a 950 number of optimizations could be realized for this mechanism 951 (essentially, the client could provide a version of the token that 952 it asks the server to sign and/or encrypt). 954 Priority of encryption/signing: When privacy is requested, should an 955 auth service encrypt then sign, or sign then encrypt? In the 956 former case, you may lose some integrity protection. In the 957 latter case, the certificate of the authentication service is 958 associated with the message. Need more analysis - sign then 959 encrypt may be preferable. 961 Identifying a canonical auth service: A lot of resistance was offered 962 to the concept of a hostname convention for authentication 963 services. However, there must be some way for a recipient of an 964 authenticated identity body to know that it was generated by a 965 (the?) canonical authentication service of a particular 966 administrative domain. How can this be communicated? Perhaps with 967 a certificate attribute? 969 Assertion roles: Do we need a way to tie an authenticated identity 970 body to a particular form of identity (called, calling, 971 forwarding, referring, etc)? Currently, an authenticated identity 972 body represents the identity of the originator of the message. 974 Appendix C. Changelog 976 Changes from draft-peterson-sip-identity-00: 978 - Added a section on authenticated identities in responses 980 - Removed hostname convention for authentication services 982 - Added text about using 'message/sip' or 'message/sipfrag' in 983 authenticated identity bodies, also RECOMMENDED a few more headers 984 in sipfrags to increase reference integrity 986 - Various other editorial corrections 988 Full Copyright Statement 990 Copyright (C) The Internet Society (2002). All Rights Reserved. 992 This document and translations of it may be copied and furnished to 993 others, and derivative works that comment on or otherwise explain it 994 or assist in its implementation may be prepared, copied, published 995 and distributed, in whole or in part, without restriction of any 996 kind, provided that the above copyright notice and this paragraph are 997 included on all such copies and derivative works. However, this 998 document itself may not be modified in any way, such as by removing 999 the copyright notice or references to the Internet Society or other 1000 Internet organizations, except as needed for the purpose of 1001 developing Internet standards in which case the procedures for 1002 copyrights defined in the Internet Standards process must be 1003 followed, or as required to translate it into languages other than 1004 English. 1006 The limited permissions granted above are perpetual and will not be 1007 revoked by the Internet Society or its successors or assigns. 1009 This document and the information contained herein is provided on an 1010 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1011 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1012 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1013 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1014 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1016 Acknowledgement 1018 Funding for the RFC Editor function is currently provided by the 1019 Internet Society.