idnits 2.17.1 draft-peterson-sip-identity-00.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 (March 2002) is 8077 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: August 30, 2002 March 2002 6 Enhancements for Authenticated Identity Management in the Session 7 Initiation Protocol (SIP) 8 draft-peterson-sip-identity-00 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 August 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 . . . . . . . . . . . . . . . . . . . . . 12 61 5.4 Example of a Request with an Authenticated Identity Body . . . 13 62 6. Receiving an Authenticated Identity . . . . . . . . . . . . . 15 63 6.1 Proxy Server Handling . . . . . . . . . . . . . . . . . . . . 16 64 6.2 User Agent Handling . . . . . . . . . . . . . . . . . . . . . 16 65 7. Selective Sharing of Identity . . . . . . . . . . . . . . . . 17 66 7.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 17 67 7.2 Encryption of Identity . . . . . . . . . . . . . . . . . . . . 18 68 7.3 Example of Encryption . . . . . . . . . . . . . . . . . . . . 18 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 72 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 73 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 B. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 75 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25 77 1. Introduction 79 This document provides enhancements to the existing mechanisms for 80 authenticated identity management in the Session Initiation Protocol 81 (SIP [1]). 83 The baseline SIP protocol allows a user agent to express the identity 84 of its user in a number of headers. The primary place for identity 85 information asserted by the sender of a request is the From header. 86 The From header field contains a URI (like 'sip:alice@atlanta.com') 87 and an optional display-name (like "Alice") that identifies the 88 originator of the request. A user may have many identities that are 89 used in different contexts. 91 Typically, this URI is an address-of-record that can be dereferenced 92 in order to contact the originator of the request; specifically, it 93 is usually the same address-of-record under which a user registers 94 their devices in order to receive incoming requests. This address- 95 of-record is assigned and maintained by the administrator of the SIP 96 service in the domain identified by the host portion of the address- 97 of-record (which may have any of a number of relationships with the 98 end user). However, the From field of a request can usually be set 99 arbitrarily by the user of a SIP user agent; the From header of a 100 message provides no internal assurance that the originating user can 101 legitimately claim this identity. Nevertheless many SIP user agents 102 will obligingly display the contents of the From field as the 103 identity of the originator of a received request (as a sort of 104 'Caller-ID' function). 106 To satisfy the requirement for a more reliable way of identifying 107 parties in a SIP session, a number of cryptographic authentication 108 systems are described in the SIP standard, including mechanisms based 109 on HTTP Digest, S/MIME and transport or network layer security. 110 Among other things, these mechanisms allow a server to verify that a 111 user agent can legitimately assert a specific identity. Whether or 112 not the recipient of these credentials can verify them is based on 113 whether the credentials are asymmetric, and publicly verifiable by 114 third parties, or symmetric, and verifiable only by parties that have 115 a pre-existing relationship with the user. 117 Symmetric: Authentication with symmetric keys usually entails the 118 transmission of some sort of secret credentials (typically a 119 username and password) from the client to the server. Secrets- 120 based authentication assumes a pre-existing relationship (an 121 agreement on a secret) between the client that originates a 122 request and the server that responds with a challenge. Useful 123 secrets-based authentication schemes use cryptography to conceal 124 the credentials so they can not be observed and reused by 125 eavesdroppers on the network. Secrets are usually memorized by 126 end users, and thus do not necessitate any special configuration 127 of user agents. 129 Asymmetric: Asymmetric credentials require a Public Key 130 Infrastructure (PKI) that manages public and private keys. PKI- 131 based authentication usually relies on a certificate authority 132 that issues a custom certificate to each entity that would like to 133 prove its identity, and a common root certificate to each entity 134 that would like to verify the identity of others. In this system 135 there is no need for any pre-existing relationship between the 136 clients and servers (unless in the absence of a certificate 137 authority self-signed certificates are used). However, PKI has to 138 date only been effective in asserting the identity of a hostname - 139 there is a widespread belief that implementing a PKI for 140 certificates that assert the identity of individuals is 141 impractical. Each host MUST be configured with any certificate 142 that asserts its identity. 144 Most user agents authenticate themselves with shared secrets. In 145 baseline SIP, the Digest authentication method (which is required for 146 all user agents and servers) allows users to provide a username and 147 password to authenticate themselves in the context of a particular 148 realm (for example, the identity 'alice' within the realm 149 'atlanta.com' might have the password 'x63Mdo+'). 151 Digest therefore works well for functions like SIP registration, in 152 which the target of a request is a server within the realm in which a 153 user can prove an identity. However, the credentials with which a 154 user proves that they are 'sip:alice@atlanta.com' cannot be verified 155 by a server in another realm, like biloxi.com - Alice shares the 156 secret with atlanta.com, not biloxi.com. Thus, if Alice were to send 157 a request to a proxy server in the biloxi.com realm, biloxi.com has 158 no way of determining whether or not Alice can legitimately claim the 159 identity 'sip:alice@atlanta.com'. biloxi.com is then left only with 160 the unreliable From field for ascertaining the identity of the 161 originator of interdomain requests. 163 However, were Alice to proxy her request through an atlanta.com proxy 164 server, atlanta.com might be able to verify her identity before 165 passing the request to its destination, biloxi.com. Therefore, this 166 document proposes a new logical role for network intermediaries 167 called an authentication service. The authentication service role 168 would most likely be instantiated by the local outbound proxy server 169 within an administrative domain. Once an authentication service has 170 verified the identity of the originator of a request, it can add the 171 result of the authentication process to the request for the benefit 172 of downstream recipients. 174 User agents can be configured, statically or on a per-call basis, to 175 send requests through an authentication service. After a request has 176 passed through an authentication service in a given domain (e.g. 177 atlanta.com) downstream recipients (e.g. in biloxi.com) will be able 178 to determine that atlanta.com asserts a specific authenticated 179 identity for the originator of this message, like 180 'sip:alice@atlanta.com'. 182 In some cases, this authenticated identity can be distributed by the 183 authentication service to any potential recipients of the request 184 without restriction. In other cases, for reasons of network policy, 185 or user privacy constraints, the distribution of the authenticated 186 identity will be restricted. 188 In summary, the identity that appears in the From field of a SIP 189 request provides a way that the originator can be canonically reached 190 (and therefore provides some accountability for that user). The best 191 way for a SIP user to prove that they can legitimately claim an 192 identity is to provide the same credentials they would need to 193 provide in order to register to receive requests for that identity. 194 For that purpose, this document defines an authentication service 195 that verifies the credentials of an end user in their local 196 administrative domain before sending requests to their destinations. 197 This authentication service can then sign the identity that results 198 from this authentication and make this identity available to 199 recipients of the request, thereby proving that the administrative 200 domain responsible for the originating user registers has verified 201 that user's identity. Effectively, this allows a user's 202 authentication with a single server to be bootstrapped into a 203 publicly-verifiable authentication. 205 In this document, the manner in which a user authenticates themselves 206 to an authentication service is (by way of example) restricted to the 207 mechanisms that are available in [1], specifically the Digest 208 authentication scheme, as it is common to all SIP-compliant 209 endpoints. However, for the most part these mechanisms have no 210 dependency on any particular authentication scheme. 212 2. Terminology 214 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 215 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 216 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 217 described in RFC2119 [2] and indicate requirement levels for 218 compliant SIP implementations. 220 3. Sending Requests through an Authentication Service 222 An authentication service is a logical role played by a network 223 intermediary, such as a SIP proxy server. Commonly, the 224 authentication service function will be instantiated by a local 225 outbound proxy server. Authentication services are capable of 226 verifying the identity of users through some means. Authentication 227 services are also capable of sharing this verified identity in a 228 secure manner. 230 Requests from a user agent are sent through an authentication service 231 because the user agent is configured (with a pre-loaded Route header, 232 perhaps) to send all requests through the service. 234 A user has some incentive to send calls through an authentication 235 service, in that: 237 Authentication services help to prevent identity theft, and the 238 many potential annoyances that could result from being 239 impersonated, and, 241 Administrative domains could implement policies that reject 242 requests from users that have not gone through an authentication 243 service appropriate for the administrative domain listed in the 244 From header of their messages. 246 Optimally, a user should be able to send SIP messages to their 247 authentication service directly, without going through any SIP proxy 248 servers, since many authentication systems (including Digest) are not 249 optimally secure when handled by intermediaries. An authentication 250 service will frequently be co-located with a user agent's first-hop 251 local outbound proxy. 253 4. Authentication Practices 255 When a user first forms a connection to a SIP entity that implements 256 the authentication service role, the user SHOULD make use of network 257 or transport layer security, preferably contacting the authentication 258 service without going through any intermediaries. This document 259 recommends the use of Transport Layer Security (TLS) to connect to 260 the authentication service. This in turn allows the authentication 261 service to potentially offer a certificate directly to the end user, 262 as well as ensuring confidentiality, integrity, and replay protection 263 during the challenge phase. If the user agent is more than one hop 264 away from the authentication service, it may make sense to use the 265 SIPS URI scheme to improve the security of requests routed through 266 the authentication service. 268 Any entity that implements the authentication service role MUST 269 possess a certificate that has been issued by a certificate 270 authority. The SubjectAltName of the certificate SHOULD be the 271 fully-qualified domain name of the device on which the authentication 272 service is running. This document recommends the use of a hostname 273 convention for authentication services. Only one logical 274 authentication service SHOULD operate in a given administrative 275 domain. This authentication service SHOULD have a hostname that 276 corresponds to the name of its domain, prepended with 'sip'; for 277 'atlanta.com', the authentication service SHOULD exist at a host 278 reachable at 'sip.atlanta.com', and SHOULD provide a certificate that 279 asserts this hostname 'sip.atlanta.com'. 281 4.1 Issuing Challenges with Realms 283 Obviously, all authentication services have their own sets of users 284 and corresponding credentials; when a user is challenged by an 285 authentication service, that user selects credentials that are 286 appropriate for the service in question. For the purposes of this 287 document, following the terminology in Digest authentication, an 288 authentication service has a 'realm' which provides a context in 289 which a user is asked to authenticate. For example, when an 290 authentication service challenges a user for Digest authentication 291 with the 407 status code, the challenge MUST be sent for a realm 292 corresponding to the hostname of the authentication service. Note 293 that a user agent SHOULD consider it a cause for concern (though not 294 necessarily an error condition) if the realm of a challenge does not 295 correspond both with the hostname of the authentication service and 296 any certificate presented by the authentication service on connection 297 - users SHOULD be notified of this occurrence. 299 Once again, note that Digest authentication is used merely by way of 300 example. Other mechanisms within SIP, or out-of-band mechanisms, 301 could be used to authenticate the user. If these authentication 302 systems do not explicitly support the concept of realms, the realm in 303 which a challenge occurs should be understood by the user agent to be 304 the hostname of the authentication service. Any method of 305 authentication used by an authentication service, MUST therefore have 306 a means of communicating, at the very least, its hostname to a user. 307 If these authentication systems do not support credentials that 308 express a specific username, then a username SHOULD be taken by the 309 authentication service from the username portion of the URI in the 310 From header field of the SIP request. 312 4.2 Determining Identity with Credentials 314 If a user agent is challenged and it has access to credentials for 315 the realm in question, these credentials will be provided in a 316 resubmission of the request to the authentication service. In 317 Digest, for example, the authentication service MUST extract and 318 verify these credentials from the resubmission of the request. 320 The username associated with these credentials SHOULD be combined 321 with the name of the realm (the hostname of the service) in order to 322 form the authenticated identity of the user - however, the prepended 323 'sip' portion of the hostname SHOULD be removed. For example, if the 324 credentials were valid for the username 'alice', for an 325 authentication service at 'sip.atlanta.com', the authenticated 326 identity would be 'sip:alice@atlanta.com'. An authentication service 327 MAY also have a particular display-name which it associates with 328 particular users that will be included in the authenticated identity. 330 Note that some user agents MAY provide 'anonymous' credentials with 331 no password in a resubmission of a request after a challenge. 332 Whether or not an authentication service considers this to be a 333 successful authentication is a matter of local policy, but the 334 authentication service SHOULD NOT assert this 'anonymous' identity to 335 others in the manner described in Section 5. 337 The credentials that a user provides to an authentication service 338 SHOULD be the same credentials that are provided when the user 339 registers in this administrative domain. 341 4.3 Analyzing Requests 343 Some authentication services MAY wish to inspect the contents of the 344 From header of an outbound request. Depending on the policy of the 345 authentication service, it might not be appropriate for the From 346 header to differ from the authenticated identity that the service has 347 verified. Some authentication services MAY reject requests (with a 348 403 Forbidden) that assert an inappropriate identity in the From. 350 Authentication services MAY also place restrictions on the display- 351 name as well as the URI associated with the From header. 353 Note that some users MAY supply an anonymous From header (see [3]) 354 for some requests. Authentication services generally SHOULD NOT 355 consider this to conflict with any identity information learned in 356 the authentication process. For more information on the obligations 357 of authentication services with respect to privacy, see Section 7.1. 359 It may not be necessary for an authentication service to prevent the 360 arbitrary assignment of the From field if the authentication service 361 has another way of sharing authenticated identity information (see 362 Section 5). Steps for reconciling the user-asserted From header with 363 authenticated identity data are given in Section 6.2. 365 4.4 Accounting for Authentication 367 Authentication services MAY record the successful authentication of a 368 request, including its dialog identifiers and Request-URI, in order 369 to provide some accountability when administrative requests are made 370 for information about the parties participating in a particular 371 session. Some mechanisms by which a user is authenticated and 372 authorized may also persist accounting data about the request, 373 although such mechanisms are outside the scope of this document. 375 Authentication services MAY also wish to log failed authentication 376 attempts, especially those that reflect repeated attempts to try 377 different credentials for the same username. 379 4.5 Forwarding the Request 381 Once an authentication service has authenticated the originator of a 382 request, if it does not wish to provide any further services, it MUST 383 forward the request in accordance with the conventional request 384 routing logic in the SIP specification. 386 If on the other hand the authentication services wishes to share the 387 authenticated identity it has verified, it can use the mechanisms 388 described in Section 5. 390 5. Sharing Verified Identities 392 Authenticated identities SHOULD be shared unless the authentication 393 service has a reason to do otherwise. By authenticating themselves, 394 originating users must understand that they are giving the 395 authentication service the right to share the provided identity with 396 others. If they wish to prevent this, users MUST request privacy for 397 their authentication information (see Section 7.1). 399 5.1 Authenticated Identity within a Body 401 As a way of sharing authenticated identity among parties in the 402 network, a special type of MIME body, which will subsequently be 403 referred to as an 'authenticated identity body', is defined in this 404 section. 406 An authenticated identity body is a MIME body of type 407 'message/sipfrag' (see [4]). This body MUST have a Content- 408 Disposition disposition-type of 'auth-id', a new value defined in 409 this document specifically for authenticated identity bodies. The 410 Content-Disposition header SHOULD also contain a 'handling' parameter 411 indicating that this MIME body is optional. 413 Authenticated identity bodies MUST contain the following headers: 414 From, Date and Call-ID. The From header field MUST be populated by 415 the authentication service with the authenticated identity itself, as 416 discussed above in Section 4.2. Authenticated identity bodies MAY 417 contain other headers that help to uniquely identify the transaction. 418 An example of an authenticated identity body is: 420 Content-Type: message/sipfrag 421 Content-Disposition: auth-id; handling=optional 423 From: sip:alice@atlanta.com 424 Date: Thu, 21 Feb 2002 13:02:03 GMT 425 Call-ID: a84b4c76e66710 427 Once the authenticated identity body has been fully populated, it 428 MUST be signed by the authentication service that has created it. An 429 unsigned authenticated identity body MUST NOT be honored by any 430 recipients. An authenticated identity body MUST be signed with the 431 same certificate that the authentication service uses to authenticate 432 itself for the purposes of transport of network layer security such 433 as TLS (see Section 4). A full example of a message with a signed 434 authenticated identity MIME body is given in Section 5.4. 436 After the authenticated body has been signed, some entity SHOULD 437 added it to any existing MIME bodies in the request, if necessary by 438 transitioning the outermost MIME body to a 'multipart/mixed' format. 439 But which participant in the dialog should add the authenticated 440 identity body, the authentication service or the originating user 441 agent? Both options are considered in the following sections. 442 Authentication services MUST support the mechanism in Section 5.3 and 443 MAY support the mechanism in Section 5.2. 445 5.2 Body Added by Authentication Service 447 The first possibility is that the authentication service could add 448 the body to the request itself before forwarding the request. 449 However, the authentication service role is usually played by 450 entities that act as proxy servers for most requests, and proxy 451 servers cannot modify message bodies. In order to add an 452 authenticated identity body, the authentication service needs to act 453 as a transparent back-to-back user agent, effectively terminating the 454 request and re-originating it with a new body appended to any 455 existing MIME bodies. 457 This mechanism has some potential advantages over sending the 458 authenticated identity body back to the originating user agent. For 459 one, it saves on additional round-trip times for signaling that 460 result from passing the body back to the user agent. It also 461 requires no new SIP mechanisms, whereas any method of asking a user 462 agent to include a body in a resubmission to the current request 463 would introduce new protocol requirements. 465 However, there are proposed SIP integrity mechanisms that place a 466 signature over the entire message body in a SIP message header. Were 467 a server to add to the body of a message that was protected by such 468 signature, that could be perceived as an integrity violation by 469 downstream recipients of the message. 471 5.3 Body Added by Client 473 Alternatively, the authentication service could in some fashion 474 return the authenticated identity MIME body to the originating user 475 agent, prompting the user agent to retry the request with the 476 authenticated identity MIME body attached. No existing SIP mechanism 477 performs this function. Therefore, this document defines a 428 "Use 478 Authenticated Identity" response code. 480 An authentication service sends a 428 with a MIME body in order to 481 request that a user agent add the enclosed MIME body to their request 482 and retry the request. A 428 MUST have at most a single MIME body. 483 This MIME body MUST be signed by the authentication service. 485 The use of 428 without any MIME body is also defined in this 486 document. It can be sent by any server to reject a request because 487 the request does not contain an authenticated identity body. A user 488 agent receiving this rejection SHOULD retry their request through an 489 authentication service. 491 In order to signal to the authentication services that the 492 originating user agent supports the receipt of the 428 response code, 493 a new option-tag has been defined, the 'auth-id' option-tag. User 494 agents SHOULD supply the 'auth-id' option-tag in a Supported header 495 whenever they provide credentials to a server (for example, in Digest 496 authentication, whenever a Proxy-Authorization header is added to a 497 request). 499 Using the 428 response code may introduce extra round-trip times for 500 messages, delaying the setup of requests (one RTT for the 407, 501 another for the 428). However, there are some circumstances under 502 which extra RTTs may not impede performance. If the originating user 503 agent possesses a non-stale nonce (assuming Digest authentication) 504 from the authentication service, it can pre-emptively include a 505 Proxy-Authorization header, eliminating one RTT. With regard to the 506 second RTT, note that the request needn't necessarily go through the 507 authentication service again once the authenticated identity body has 508 been added - it could go directly to its destination, which reduce 509 the impact of the second RTT. 511 There are two reasons why the originating user agent should be the 512 party responsible for adding the authenticated identity body to the 513 request. Firstly, because this gives the client the opportunity to 514 inspect the body itself (perhaps only to see whether or not it is 515 encrypted; see Section 7.2) in order to verify that the authenticated 516 identity corresponds with the provided credentials and the user's 517 preferences. Secondly, the client can provide a signature over the 518 entire body of the message (either with S/MIME or some header-based 519 mechanism) so that the final recipient of messages can be assured 520 that all information in the body is there at the originator's behest. 522 5.4 Example of a Request with an Authenticated Identity Body 524 The following shows a full SIP INVITE request with an authenticated 525 identity body (one that has been added by the originating user 526 agent): 528 INVITE sip:bob@biloxi.com SIP/2.0 529 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 530 To: Bob 531 From: Alice ;tag=1928301774 532 Call-ID: a84b4c76e66710 533 CSeq: 314159 INVITE 534 Max-Forwards: 70 535 Date: Thu, 21 Feb 2002 13:02:03 GMT 536 Contact: 537 Content-Type: multipart/mixed; boundary=unique-boundary-1 539 --unique-boundary-1 541 Content-Type: application/sdp 542 Content-Length: 147 544 v=0 545 o=UserA 2890844526 2890844526 IN IP4 here.com 546 s=Session SDP 547 c=IN IP4 pc33.atlanta.com 548 t=0 0 549 m=audio 49172 RTP/AVP 0 550 a=rtpmap:0 PCMU/8000 552 --unique-boundary-1 553 Content-Type: multipart/signed; 554 protocol="application/pkcs7-signature"; 555 micalg=sha1; boundary=boundary42 556 Content-Length: 568 558 --boundary42 559 Content-Type: message/sipfrag 560 Content-Disposition: auth-id; handling=optional 562 From: Alice 563 Date: Thu, 21 Feb 2002 13:02:03 GMT 564 Call-ID: a84b4c76e66710 566 --boundary42 567 Content-Type: application/pkcs7-signature; name=smime.p7s 568 Content-Transfer-Encoding: base64 569 Content-Disposition: attachment; filename=smime.p7s; 570 handling=required 572 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 573 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 574 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 575 7GhIGfHfYT64VQbnj756 577 --boundary42-- 579 --unique-boundary-1-- 581 6. Receiving an Authenticated Identity 583 There are a number of ways that identity information can be presented 584 in a SIP request, and all of them must be reconcilable - that is, 585 there must be a way to arrive at the identity that should be 586 displayed to the user as the caller's identity, and so forth. 588 It is therefore RECOMMENDED in this document that these forms of 589 identity be reduced into two broad categories: suspect and valid 590 identities. All of the following SHOULD be considered suspect by 591 recipients: 593 o Recipients may receive a normal From header in the SIP message 594 body - unsigned and unverified. All requests must contain such a 595 header, but in some cases it may not purport to contain a usable 596 value (it may assert an anonymous identity). 598 o Recipients may receive a From header in an S/MIME body that was 599 signed by a self-signed certificate that is unrecognized and/or 600 untrusted by the user, or signed by an authentication service 601 using a certificate authority that the user cannot verify. 603 o Recipients may receive a From header in an S/MIME body that has 604 been signed by an authentication service with a valid certificate, 605 but which has internal consistency problems: the hostname asserted 606 by the certificate may not correspond to the domain in the From 607 header, the Date may be obviously stale, mandatory headers may be 608 missing from the authenticated identity body, or the hostname 609 asserted by the certificate may not correspond with the naming 610 conventions recommended in Section 4. 612 Recipients may also unknowingly receive From headers in encrypted 613 bodies which they cannot decrypt (see Section 7.2) that, of course, 614 cannot be usable identities. 616 The following are identities that SHOULD be considered valid by a 617 recipient: 619 o Recipients may receive an S/MIME body containing a From header 620 that has been signed by a self-signed certificate that is 621 recognized and trusted by the recipient. 623 o Recipients may receive an S/MIME body containing a From header 624 that has been signed by an authentication service that properly 625 follows the practices described in Section 4. 627 The exact behavior that is followed on receipt of a suspect or valid 628 identity varies with the role of the recipient. 630 6.1 Proxy Server Handling 632 Proxy servers generally should not attempt to inspect MIME bodies. 633 However, intermediaries that implement the authentication service 634 logical role MAY inspect MIME bodies in order to find one with a 635 Content-Disposition of 'auth-id'. 637 For the most part, the actual value of an authenticated identity is 638 not likely to be of interest to a proxy server, though it MAY refuse 639 to process a request that does not contain a valid authenticated 640 identity body (using the 438 request, as described in Section 5.3). 641 However, proxy servers MAY additionally maintain lists of known 642 problem users that are banned from making requests, for example, and 643 subsequently reject some requests after comparing their authenticated 644 identities to this list. 646 6.2 User Agent Handling 648 A user agent needs to determine which identity for the originator of 649 a request should be displayed to the user, perhaps as a 'Caller-ID' 650 function. The following is a RECOMMENDED set of precedence rules for 651 arriving at a single identity that should be displayed. 653 If one valid form of identity is present, the user agent displays 654 that identity. If both valid forms of identity are present, the 655 authenticated identity (rather than a recognized self-signed S/MIME 656 signature) is preferred, but both potentially are viewable by a user. 658 If neither of the valid forms of identity are available, the user 659 agent displays the normal From field in the SIP message, but other 660 identities are viewable by a user. However, if that From field would 661 display an anonymous identity, the user agent SHOULD display another 662 value instead (probably an identity in a signed S/MIME body). 664 When it displays an identity to its user, a user agent SHOULD also 665 have some way of designating between a valid and suspect identity 666 that is easy for the user to distinguish. 668 Note that user agents also need to determine the identity of the 669 originator of a request for the purposes of per-user blocking or 670 screening before the user is alerted and any identity is displayed. 671 Generally, if any of the asserted identities in a request match an 672 identity that is blocked, the user should not be alerted and the 673 request SHOULD be rejected. 675 7. Selective Sharing of Identity 677 Most of the time, there is no need to restrict the propagation of 678 verified identities in the network. User agents and intermediaries 679 benefit from receiving verified identities. However, in some cases 680 intermediaries wish to restrict the distribution of identity 681 information, for example if 683 o the authenticated identity body contains an identity that is only 684 meaningful as an internal identifier within a particular service 685 provider's network, or, 687 o the originating user agent has requested privacy, and the 688 unregulated distribution of the authenticated identity body would 689 violate that request. 691 If it is not appropriate to share an authenticated identity, an 692 authenticated identity body SHOULD NOT be created and distributed. 693 However, in some cases there may be other entities in the 694 administrative domain of the authentication service that are 695 consumers of the authenticated identity. If, for example, each of 696 these servers needed to challenge the user individually for identity, 697 it might significantly delay the processing of the request. For that 698 reason, it may be appropriate to circulate authenticated identity 699 bodies among a controlled set of entities. For that purpose, an 700 encryption mechanism for authenticated identities is provided. 702 7.1 Requesting Privacy 704 When users provide credentials to an authentication service, they MAY 705 explicitly notify the service that they do not wish their 706 authenticated identity to be circulated. Usually, the user in 707 question would also be taking other steps to preserve their privacy 708 (perhaps by including an anonymous From header). 710 Therefore, authentication services MUST support the privacy 711 mechanisms described in [3]. Users requesting privacy should also 712 support the mechanisms described in that document. 714 In particular, this document defines a new priv-value that can appear 715 in the Privacy header, a value of 'auth'. This Privacy value 716 requests that the results of authentication should not be shared by 717 the authenticating server. An authentication service SHOULD NOT 718 create an authenticated identity body for a request when 'auth' 719 privacy has been requested. If such a body is created, it MUST be 720 encrypted. 722 7.2 Encryption of Identity 724 Many SIP entities that support the use of S/MIME for signatures will 725 also support S/MIME encryption. Encryption of a body prevents any 726 parties other those that hold the decryption key from inspecting the 727 body. Note that the key used for encryption SHOULD be unrelated to 728 the public key in a certificate that is used by an authentication 729 service to prove its identity. 731 While encryption of an authenticated identity body entails that only 732 the holder of a specific key can decrypt the body, that single key 733 could be distributed throughout a network of hosts that exist under 734 common policies. The security of the body is therefore predicated on 735 the secure distribution of the key. However, for some networks (in 736 which there are federations of trusted hosts under a common policy), 737 the widespread distribution of a decryption key could be appropriate. 738 Some telephone networks, for example, might require this model. 740 When an authenticated identity is encrypted, the authenticated 741 identity body SHOULD always be encrypted before it is signed. Note 742 that this means that the recipients of the request, even if they are 743 unable to inspect the authenticated identity body, will still be able 744 to see which authentication service signed that body (although it 745 will not necessarily be obvious that the body contains an 746 authenticated identity). An example of a signed and encrypted 747 authenticated identity MIME body follows: 749 7.3 Example of Encryption 751 The following is an example of an encrypted and signed authenticated 752 identity body (without any of the preceding SIP headers). In a 753 rendition of this body sent over the wire, the text wrapped in 754 asterisks would be encrypted. 756 Content-Type: multipart/signed; 757 protocol="application/pkcs7-signature"; 758 micalg=sha1; boundary=boundary42 759 Content-Length: 568 761 --boundary42 763 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 764 name=smime.p7m 765 Content-Transfer-Encoding: base64 766 Content-Disposition: attachment; filename=smime.p7m 767 handling=required 768 Content-Length: 231 770 *********************************************************** 771 * Content-Type: message/sipfrag * 772 * Content-Disposition: auth-id; handling=optional * 773 * * 774 * From: sip:alice@atlanta.com * 775 * Call-ID: a84b4c76e66710 * 776 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 777 *********************************************************** 779 --boundary42 781 Content-Type: application/pkcs7-signature; name=smime.p7s 782 Content-Transfer-Encoding: base64 783 Content-Disposition: attachment; filename=smime.p7s; 784 handling=required 786 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 787 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 788 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 789 7GhIGfHfYT64VQbnj756 791 --boundary42-- 793 8. Security Considerations 795 Users SHOULD NOT provide credentials to an authentication service to 796 which they cannot initiate a direct connection, preferably one 797 secured by a network or transport layer security protocol such as 798 TLS. If a user does not receive a certificate from the 799 authentication service over this lower-layer protocol that 800 corresponds to the realm in a challenge, then it is possible that a 801 rogue server is attempting to pose as a authentication service for a 802 realm that it does not control, possibly in an attempt to collect 803 valid user passwords for that realm. 805 If a user cannot connect directly to the desired authentication 806 service, the user SHOULD at least use a SIPS URI to ensure that 807 mutual TLS will be used to reach the remote server. 809 The certificates that are required to operate an authentication 810 service need to assert only the hostname of the authentication 811 service, and for that reason, existing certificate authorities could 812 provide adequate certificates for this mechanism. However, not all 813 proxy servers and user agents will be able support the root 814 certificates of all certificate authorities, and moreover there are 815 some significant differences in the policies by which certificate 816 authorities issue their certificates. This document makes no 817 recommendations for the usage of particular certificate authorities, 818 nor does it describe any particular policies that certificate 819 authorities should follow, but it is anticipated that operational 820 experience will create de facto standards for the purposes of 821 authentication services. Some federations of service providers, for 822 example, might only trust certificates that have been provided by a 823 certificate authority operated by the federation. 825 9. IANA Considerations 827 This document defines a new MIME Content-Disposition disposition-type 828 value of 'auth-id'. This value is reserved for MIME bodies that 829 contain an authenticated identity, as described in section Section 830 5.1. 832 This document also defines a new SIP status code, 428 Use 833 Authenticated Identity. The use of this status code is further 834 described below in Section 5.3. 836 Finally, this document also defines a new value for the Privacy 837 header specified in [3], with a value 'auth'. This is further 838 described in Section 7.1. 840 References 842 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 843 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 844 Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work 845 in progress), February 2002. 847 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 848 levels", RFC 2119, March 1997. 850 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 851 Protocol (SIP)", draft-peterson-sip-privacy-00 (work in 852 progress), April 2002. 854 [4] Sparks, R., "Internet Media Types message/sip and 855 message/sipfrag", draft-sparks-sip-mimetypes-01 (work in 856 progress), March 2002. 858 Author's Address 860 Jon Peterson 861 NeuStar, Inc. 862 1800 Sutter St 863 Suite 570 864 Concord, CA 94520 865 US 867 Phone: +1 925/363-8720 868 EMail: jon.peterson@neustar.biz 869 URI: http://www.neustar.biz/ 871 Appendix A. Acknowledgments 873 The authors would like to thank Eric Rescorla for his comments. 875 Appendix B. To Do 877 S/MIME authentication: If the authentication between the client and 878 server is performed with S/MIME, possibly using a shared secret, a 879 number of optimizations could be realized for this mechanism 880 (essentially, the client could provide a version of the token that 881 it asks the server to sign and/or encrypt). 883 Priority of encryption/signing: When privacy is requested, should an 884 auth service encrypt then sign, or sign then encrypt? In the 885 former case, you may lose some integrity protection. In the 886 latter case, the certificate of the authentication service is 887 associated with the message. Need more analysis - sign then 888 encrypt may be preferable. 890 Full Copyright Statement 892 Copyright (C) The Internet Society (2002). All Rights Reserved. 894 This document and translations of it may be copied and furnished to 895 others, and derivative works that comment on or otherwise explain it 896 or assist in its implementation may be prepared, copied, published 897 and distributed, in whole or in part, without restriction of any 898 kind, provided that the above copyright notice and this paragraph are 899 included on all such copies and derivative works. However, this 900 document itself may not be modified in any way, such as by removing 901 the copyright notice or references to the Internet Society or other 902 Internet organizations, except as needed for the purpose of 903 developing Internet standards in which case the procedures for 904 copyrights defined in the Internet Standards process must be 905 followed, or as required to translate it into languages other than 906 English. 908 The limited permissions granted above are perpetual and will not be 909 revoked by the Internet Society or its successors or assigns. 911 This document and the information contained herein is provided on an 912 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 913 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 914 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 915 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 916 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 918 Acknowledgement 920 Funding for the RFC Editor function is currently provided by the 921 Internet Society.