idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 28, 2002) is 7822 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) -- Unexpected draft version: The latest known version of draft-ietf-sip-privacy-general is -01, but you're referring to -02. == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-00 -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '5') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: April 28, 2003 October 28, 2002 6 Enhancements for Authenticated Identity Management in the Session 7 Initiation Protocol (SIP) 8 draft-ietf-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 http:// 26 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 April 28, 2003. 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 cryptographically secure 44 authenticated identities within SIP messages. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Using an Authentication Service . . . . . . . . . . . . . . . 5 51 4. How to Share Verified Identities . . . . . . . . . . . . . . . 5 52 4.1 Body Added by Authentication Service . . . . . . . . . . . . . 6 53 4.2 Body Added by Client . . . . . . . . . . . . . . . . . . . . . 7 54 4.3 Using Content Indirection . . . . . . . . . . . . . . . . . . 8 55 5. Identity in Responses . . . . . . . . . . . . . . . . . . . . 9 56 6. Receiving an Authentication Token . . . . . . . . . . . . . . 9 57 6.1 Authentication Service Handling of Authentication Tokens . . . 9 58 7. Selective Sharing of Identity . . . . . . . . . . . . . . . . 10 59 7.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 10 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 63 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 64 Normative References . . . . . . . . . . . . . . . . . . . . . 12 65 Informative References . . . . . . . . . . . . . . . . . . . . 13 66 B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 69 1. Introduction 71 This document provides enhancements to the existing mechanisms for 72 authenticated identity management in the Session Initiation Protocol 73 (SIP) [1]. An identity, for the purposes of this document, is 74 defined as a canonical SIP URI employed to reach a user (such as 75 'sip:alice@atlanta.com'). 77 RFC3261 enumerates a number of places within a SIP request that a 78 user can express an identity for themselves, notably the From header 79 field. However, the recipient of a SIP request has no way to verify 80 that the From header field has been populated appropriately without 81 some sort of cryptographic authentication mechanism. 83 Today, RFC3261 specifies a number of security mechanisms that can be 84 used by SIP UAs, including Digest, TLS and S/MIME (and 85 implementations may support other security schemes as well). 86 However, few SIP user agents today can support the end-user 87 certificates necessary to authenticate themselves via TLS or S/MIME, 88 and Digest authentication is limited by the fact that the originator 89 and destination must share a secret. It is desirable for SIP user 90 agents to be able to send requests to destinations with they have no 91 previous association - just as in the telephone network today, one 92 can receive a call from someone with whom one has no previous 93 association, and still have a reasonable assurance that their 94 displayed Caller-ID is accurate. 96 Many SIP user agents today support a means of authenticating 97 themselves to a SIP registrar - commonly with a shared secret 98 (Digest, which MUST be supported by SIP user agents, is typically 99 used for this purpose). Registration allows a user agent to express 100 that it is the proper place to which requests should be sent for a 101 particular address-of-record SIP URI. However, the credentials with 102 which a user agent proves to a registrar that they are, for example, 103 an authorized recipient of requests for 'sip:alice@atlanta.com' 104 cannot be shared with a server in another domain - these credentials 105 are currently only useful for local registration. 107 Coincidentally, the address-of-record URI of a SIP user is also the 108 URI with which a SIP UA populates the From header of requests from 109 that user - in other words, the address-of-record is an identity. So 110 it turns out that users already have a means of providing their 111 identity, if only to a registrar; in fact, since the contents of a 112 From header field are essentially a 'return address' for SIP 113 requests, being able to prove that you are eligible to receive 114 requests for that 'return address' is identical to proving that you 115 are authorized to assert this identity. In other words, the best way 116 for a SIP user to prove that they can legitimately claim an identity 117 is to provide the same credentials they would need to provide in 118 order to register to receive requests for that identity; the two have 119 the same security properties. Since the operator of the registrar 120 controls the namespace of local SIP users (assigning the user portion 121 of SIP URIs in the domain), it is the ideal arbiter for identity in 122 SIP. 124 In the absence of end-user certificates in user agents, it is 125 possible to implement a mediated authentication architecture for SIP 126 in which requests are sent to a server in the user's local domain 127 which authenticates them (using the same practices by which the 128 domain would authenticate REGISTER requests). Once a request has 129 been authenticated, the local domain then needs some way to 130 communicate to remote domains that it has sanctioned the request. 131 This draft addresses how that identity can could be securely shared. 133 RFC3261 already describes an architecture very similar to this in 134 Section 26.3.2.2, in which a user agent authenticates itself to a 135 local proxy server which in turn authenticates itself to a remote 136 proxy server via mutual TLS, creating a two-link chain of transitive 137 authentication between the originator and the remote domain. While 138 this works well in some architectures, there are a few respects in 139 which this is impractical. For one, it is possible for SIP requests 140 to cross multiple intermediaries in separate administrative domains, 141 in which case transitive trust becomes far less compelling. It also 142 requires intermediaries to act as proxies, rather than redirecting 143 requests to their destinations (redirection lightens loads on SIP 144 intermediaries). Both of these limitations result from the fact that 145 authentication takes place outside the application, at the transport 146 layer, rather than within SIP itself. 148 One solution to this problem is to use 'trusted' SIP intermediaries 149 that assert an identity for users in the form of a privileged SIP 150 header. A mechanism for doing so (with the P-Asserted-Identity 151 header) is given in [6]. However, this solution allows only hop-by- 152 hop trust between intermediaries, not end-to-end cryptographic 153 authentication, and it assumes a managed network of nodes with strict 154 mutual trust relationships, an assumption that is incompatible with 155 widespread Internet deployment. 157 The desired mediated authentication architecture has quite a bit in 158 common with the problem space of Kerberos [5]. Ideally, there should 159 be a way for a user to authenticate themselves to the local domain, 160 and receive some kind of token that they can share with recipients of 161 requests that lets them know that the user has been authenticated by 162 the local domain. However, Kerberos support in SIP user agents is 163 not widespread, and moreover SIP uses other means (such as Digest) to 164 perform key authentication functions already. An ideal solution 165 would adapt existing SIP security mechanisms to address this problem. 167 Therefore, this document defines a new logical role for SIP network 168 intermediaries (typically proxy servers) called an 'authentication 169 service'. Once an authentication service has verified the identity 170 of the originator of a request, as describe above, it creates a 171 cryptographic token that contains the authenticated identity of the 172 user, and which has some reference integrity with the request itself. 173 This token can then be added to a SIP request and inspected by 174 recipients of the request who would like a cryptographic guarantee of 175 the identity of the user. 177 One possible format for such tokens is the Authenticated Identity 178 Body (AIB) described in [4]. Other plausible token formats are a 179 matter for further investigation. Throughout this document, the use 180 of the AIB format as a token is considered exclusively. 182 2. Terminology 184 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 185 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 186 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 187 described in RFC2119 [2] and indicate requirement levels for 188 compliant SIP implementations. 190 3. Using an Authentication Service 192 A SIP user agents sends requests to an authentication service in 193 order to receive an authentication token for the request. How 194 exactly the association with an authentication service is configured 195 is an implementation-specific matter for the user agent - it might be 196 implemented with a pre-loaded Route header. The guidelines given in 197 RFC3261 Sections 26.3.2.1 and 26.3.2.2 should be used when connecting 198 to an authentication service; ideally, an authentication service 199 should be one hop away from a user agent, it should use a lower-layer 200 security protocol such as TLS or IPSec to authenticate the 201 authentication service before providing credentials (especially 202 shared secrets). 204 This document places no requirements on how an authentication 205 services authenticates requests. Since Digest authentication MUST be 206 supported by all SIP entities, the use of Digest for this purpose is 207 likely. 209 4. How to Share Verified Identities 211 When an authentication service has authenticated the user, it must 212 construct an identity for that user that will be contained in the 213 token. It is RECOMMENDED that these identities take the form of 214 addresses-of-record, as they are defined in Section 10 of RFC3261; in 215 other words, URIs of the form 'sip:alice@atlanta.com'. 217 This identity must be expressed in the authentication token that will 218 be signed by the authentication service. For example, if the 219 Authentication Identity Body (AIB) format described in [4] is used, 220 this identity would be stored in the From header field within a 221 'message/sip' or 'message/sipfrag' [7] body that will be signed by 222 the authentication service. 224 In some cases, an authentication service will hold a certificate 225 corresponding to each user in its administrative domain (in other 226 words, a certificate whose subjectAltName contains a URI equivalent 227 to the address-of-record URI of the user). The appropriate 228 certificate for the authenticated user will be used to sign the 229 authentication token. However, an authentication service MAY instead 230 use a common certificate for its administrative domain. The 231 subjectAltName of this certificate MUST correspond with the host 232 portion of the From header field of the identity in the 233 authentication token (if the identity were 'sip:alice@atlanta.com', 234 the subjectAltName of the certificate would be 'atlanta.com'); this 235 should be the same certificate that the authentication service 236 provides when proving its own identity (via TLS or some similar 237 protocol). Maintaining individual certificates for each user is 238 RECOMMENDED, since the name subordination rules involved with the use 239 of a common certificate for the domain can become complicated. 241 After the authentication token has been signed, the authentication 242 token MUST be added to any existing MIME bodies in the request, if 243 necessary by transitioning the outermost MIME body to a 'multipart/ 244 mixed' format. Two options are considered for ways that an 245 authentication token could be added to a SIP message: one in which 246 the authentication service adds the token itself, and one in which it 247 pushes the token back to the client, essentially asking the client to 248 include the token in a retry of the request. Another possibility, 249 using content indirection, is mentioned as a direction for future 250 work. Authentication services MUST support the mechanism in Section 251 4.2 and MAY support the mechanism in Section 4.1. 253 4.1 Body Added by Authentication Service 255 The first possibility is that the authentication service could add 256 the body to the request itself before forwarding the request. 257 However, the authentication service role is usually played by 258 entities that act as proxy servers for most requests, and proxy 259 servers cannot modify message bodies (see RFC3261 Section 16.6). In 260 order to add an authentication token, the authentication service 261 needs to act as a transparent back-to-back user agent, effectively 262 terminating the request and re-originating it with a new body 263 appended to any existing MIME bodies (again, transposing to various 264 MIME multipart forms as necessary). 266 This mechanism has some potential advantages over push the 267 authentication token back to the originating user agent. For one, it 268 saves on additional round-trip times for signaling that result from 269 passing the body back to the user agent. It also requires no new SIP 270 mechanisms, whereas any method of asking a user agent to include a 271 body in a resubmission to the current request would introduce new 272 protocol requirements. 274 However, there are proposed SIP integrity mechanisms that place a 275 signature over the entire message body in a SIP message header. Were 276 a server to modify the body of a message that was protected by such 277 signature, that would be perceived as an integrity violation by 278 downstream recipients of the message. Presumably, a back-to-back 279 user agent function would have to sacrifice this end-to-end 280 integrity. 282 4.2 Body Added by Client 284 Alternatively, the authentication service could in some fashion 285 return the authentication token to the originating user agent, 286 prompting the user agent to retry the request with the authentication 287 token attached. No existing SIP mechanism performs this function. 288 Therefore, this document defines a 428 "Use Authentication Token" 289 response code. 291 An authentication service sends a 428 with a MIME body in order to 292 request that a user agent add the enclosed MIME body to their request 293 and retry the request. A 428 MUST have at most a single MIME body. 294 This MIME body MUST be signed by the authentication service. 296 The use of 428 without any MIME body is also defined in this 297 document. It can be sent by any server to reject a request because 298 the request does not contain an authentication token. A user agent 299 receiving this rejection SHOULD retry their request through an 300 authentication service. 302 In order to signal to the authentication services that the 303 originating user agent supports the receipt of the 428 response code, 304 a new option-tag has been defined, the 'auth-id' option-tag. User 305 agents SHOULD supply the 'auth-id' option-tag in a Supported header 306 whenever they provide credentials to a server (for example, in Digest 307 authentication, whenever a Proxy-Authorization header is added to a 308 request). 310 Using the 428 response code may introduce extra round-trip times for 311 messages, delaying the setup of requests (one RTT for the 407, 312 another for the 428). However, there are some circumstances under 313 which extra RTTs may not impede performance. If the originating user 314 agent possesses a non-stale nonce (assuming Digest authentication) 315 from the authentication service, it can pre-emptively include a 316 Proxy-Authorization header, eliminating one RTT. With regard to the 317 second RTT, note that the request needn't necessarily go through the 318 authentication service again once the authentication token has been 319 added - it could go directly to its destination, which reduce the 320 impact of the second RTT. 322 There are two reasons why the originating user agent should be the 323 party responsible for adding the authentication token to the request. 324 Firstly, because this gives the client the opportunity to inspect the 325 body itself (perhaps only to see whether or not it is encrypted; see 326 [4]) in order to verify that the authenticated identity corresponds 327 with the provided credentials and the user's preferences. Secondly, 328 the client can provide a signature over the entire body of the 329 message (either with S/MIME or some header-based mechanism) so that 330 the final recipient of messages can be assured that all information 331 in the body is there at the originator's behest. 333 4.3 Using Content Indirection 335 Work [8] is currently underway in the SIP WG to define a content 336 indirection mechanism for SIP, a mechanism by which a MIME body in a 337 SIP request can refer, with a URL, to a document that it hosted 338 somewhere in the network. This raises another interesting 339 possibility for authentication token management. 341 A SIP user agent could create a content indirection MIME body (using 342 the RFC2017 [9] URL MIME External-Body Access-Type) that contains a 343 URL that identities a resource controlled by the authentication 344 service, anticipating that the authentication service will make the 345 authentication token available at that URL. Authentication services 346 could define a standard way to anticipate URIs for a particular 347 request (for example, an HTTP URL could be structured with a hostname 348 corresponding to the authentication service, and a path corresponding 349 to a unique identifier selected by the user agent for this request: 350 http://auth-serv.biz/12345678901234567890). Once an authentication 351 service has validated the request, it simply makes the authentication 352 token available at the anticipated URL; recipients of the message 353 would then dereference the URL in order to inspect the token. 355 This approach could allow user agents to have full control over the 356 integrity of SIP requests, while still not requiring the extra RTT 357 caused by the use of the 428 response code. It also has numerous 358 advantages over other ways of handling authentication tokens issued 359 for SIP response messages (see Section 5). 361 5. Identity in Responses 363 Many of the practices described in the preceding sections can be 364 applied to responses as well as requests, with some important 365 differences. Primarily, the distinction is that a response cannot be 366 challenged or resubmitted in the same manner as a request. However, 367 when a user agent registers under a particular identity, and thereby 368 becomes eligible to receive requests and send responses associated 369 with that identity, it provides credentials that prove its identity, 370 and thus the registrar is in a reasonable position to act as an 371 authentication service for responses. 373 Note that the identity in an authentication token in a response 374 almost certainly will not correspond with identity asserted in the 375 From header field of the response (which is copied from the Request); 376 the identity in the authentication token represents a different 377 entity. In many network implementations, the identity in the 378 authentication token of a response will correspond to the To header 379 field of the request, but there are numerous legitimate architectures 380 (which contain redirections) in which this will not be the case. 382 An authentication service that acts as a registrar can add to a 383 response an authentication token that corresponds to the identity of 384 the originator of that response in roughly the same manner described 385 in Section 4.1 - the authentication service adds the authentication 386 token to a response before it forwards the response towards the 387 originator of the request. There is no way for an authentication 388 service to perform a function for responses comparable to the 389 mechanism described in Section 4.2; however, content indirection (see 390 Section 4.3 could provide an alternative that would allow the client 391 to retain end-to-end integrity properties on responses. 393 6. Receiving an Authentication Token 395 The manner in which an authentication token is handled is dependent 396 on the nature of the token itself; for rules for handling the 397 Authentication Identity Body (AIB) format, see [4]. 399 6.1 Authentication Service Handling of Authentication Tokens 401 SIP intermediaries generally should not attempt to inspect MIME 402 bodies; following the rules of RFC3261 Section 16.6, MIME bodies may 403 be encrypted end-to-end or have other properties that make them 404 unsuitable for consumption by intermediaries. However, 405 intermediaries that implement the authentication service logical role 406 MAY inspect MIME bodies in order to find one with a Content- 407 Disposition of 'auth-id'. 409 For the most part, the actual value of an authenticated identity is 410 not likely to be of interest to a proxy server, though it MAY refuse 411 to process a request that does not contain a valid authentication 412 token (using the 428 request, as described in Section 4.2). However, 413 proxy servers MAY additionally maintain lists of known problem users 414 that are banned from making requests to their administrative domain, 415 for example, and subsequently reject some requests after comparing 416 their authenticated identities to such access control lists. 418 7. Selective Sharing of Identity 420 Most of the time, there is no need to restrict the propagation of 421 verified identities in the network. User agents and intermediaries 422 benefit from receiving verified identities. However, in some cases 423 intermediaries might want to restrict the distribution of identity 424 information, for example if 426 o the authenticated identity body contains an identity that is only 427 meaningful as an internal identifier within a particular service 428 provider's network, or, 430 o the originating user agent has requested privacy, and the 431 unrestricted distribution of the authenticated identity body would 432 violate that request. 434 If it is not appropriate to share an authenticated identity, an 435 authenticated identity body SHOULD NOT be created and distributed. 436 However, in some cases there may be other entities in the 437 administrative domain of the authentication service that are 438 consumers of the authenticated identity. If, for example, each of 439 these servers needed to challenge the user individually for identity, 440 it might significantly delay the processing of the request. For that 441 reason, it may be appropriate to circulate authenticated identity 442 bodies among a controlled set of entities. For that purpose, an 443 encryption mechanism for authenticated identities is required. 445 7.1 Requesting Privacy 447 When users authenticate themselves to an authentication service, they 448 MAY use SIP to explicitly notify the service that they do not wish 449 their authenticated identity to be circulated. Usually, the user in 450 question would also be taking other steps to preserve their privacy 451 (perhaps by including an anonymous From header in the SIP request, 452 and following other standard privacy practices). 454 Authentication services MUST support the privacy mechanism described 455 in [3]. Users requesting privacy should also support the mechanisms 456 described in that document. 458 In particular, this document uses an identity-specific priv-value 459 that can appear in the Privacy header, a value of 'id', which was 460 registered by [6]. This Privacy value requests that the results of 461 authentication should not be shared by the authenticating server. An 462 authentication service SHOULD NOT create an authentication token for 463 a request when 'id' privacy has been requested. If such a token is 464 created, it MUST be encrypted or rendered confidential in the manner 465 most appropriate to the token. Guidelines for encrypting AIBs are 466 given in [4], and these mechanisms MUST be supported by any 467 authentication service that uses AIBs. 469 8. Security Considerations 471 Users SHOULD NOT provide credentials to an authentication service to 472 which they cannot initiate a direct connection, preferably one 473 secured by a network or transport layer security protocol such as 474 TLS. If a user does not receive a certificate from the 475 authentication service over this lower-layer protocol that 476 corresponds to the expected domain (especially when they receive a 477 challenge via a mechanism such as Digest), then it is possible that a 478 rogue server is attempting to pose as a authentication service for a 479 domain that it does not control, possibly in an attempt to collect 480 shared secrets for that domain. If a user cannot connect directly to 481 the desired authentication service, the user SHOULD at least use a 482 SIPS URI to ensure that mutual TLS authentication will be used to 483 reach the remote server. 485 Relying on an authentication token generated by a remote 486 administrative domain assumes that the domain uses some trustworthy 487 practice to authenticate its users. However, it is possible that 488 some domains will implement policies that effectively make users 489 unaccountable (such as accepting unauthenticated registrations from 490 arbitrary users). Therefore, it is RECOMMENDED that authentication 491 tokens contain some indication of the specific practice (for example, 492 Digest) that was used to authenticate this request as a rough 493 indicator of credential strength. 495 If a common certificate is used by an authentication service (rather 496 than individual certificates for each identity), certain problems can 497 arise with name subordination. For example, if an authentication 498 service holds a common certificate for the hostname 499 'sip.atlanta.com', can it legitimately sign a token containing an 500 identity of 'sip:alice@atlanta.com'? It is difficult for the 501 recipient of a request to ascertain whether or not 'sip.atlanta.com' 502 is authoritative for the 'atlanta.com' domain unless the recipient 503 has some foreknowledge of the administration of 'atlanta.com'. 504 Therefore, it is RECOMMEND that user agent recipients of 505 authentication tokens notify end users if there is ANY discrepancy 506 between the subjectAltName of the signers certificate and the 507 identity within the authentication token. 509 Authentication tokens MUST have some form of replay protection. The 510 best protection is to copy the SIP request in its entirety (via the 511 'message/sip' MIME type) into the authentication token - in that way, 512 it will be clear that this token has been issued for this request, 513 since collectively the headers of a SIP request provide a unique 514 identifier. However, SIP requests can be large, and it is reasonable 515 to include only a subset of the SIP headers in a request (using the 516 'message/sipfrag' MIME type) as long as certain critical headers are 517 provided. For further discussion of this issue, including guidelines 518 for including particular headers in a sipfrag, see [4]. 520 Because the common certificates that can be used by authentication 521 services need to assert only the hostname of the authentication 522 service, existing certificate authorities can provide adequate 523 certificates for this mechanism. However, not all proxy servers and 524 user agents will be able support the root certificates of all 525 certificate authorities, and moreover there are some significant 526 differences in the policies by which certificate authorities issue 527 their certificates. This document makes no recommendations for the 528 usage of particular certificate authorities, nor does it describe any 529 particular policies that certificate authorities should follow, but 530 it is anticipated that operational experience will create de facto 531 standards for the purposes of authentication services. Some 532 federations of service providers, for example, might only trust 533 certificates that have been provided by a certificate authority 534 operated by the federation. 536 9. IANA Considerations 538 This document defines a new SIP status code, '428 Use Authentication 539 Token'. The use of this status code is further described in Section 540 4.2. 542 Normative References 544 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 545 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 546 Session Initiation Protocol", RFC 3261, June 2002. 548 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 549 levels", RFC 2119, March 1997. 551 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 552 Protocol (SIP)", draft-ietf-sip-privacy-general-02 (work in 553 progress), June 2002. 555 [4] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 556 draft-ietf-sip-authid-body-00 (work in progress), October 2002. 558 Informative References 560 [5] Kohl, J. and C. Neumann, "The Kerberos Network Authentication 561 Service (V5)", RFC 1510, September 1993. 563 [6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to 564 the Session Initiation Protocol (SIP) for Asserted Identity 565 within Trusted Networks", draft-ietf-sip-asserted-identity-02 566 (work in progress), June 2002. 568 [7] Sparks, R., "Internet Media Type message/sipfrag", draft-ietf- 569 sip-sipfrag-00 (work in progress), September 2002. 571 [8] Olson, S., "A Mechanism for Content Indirection in SIP 572 Messages", draft-ietf-sip-content-indirect-mech-01 (work in 573 progress), August 2002. 575 [9] Freed, N., "Definition of the URL MIME External-Body Access- 576 Type", RFC 2017, November 1996. 578 Author's Address 580 Jon Peterson 581 NeuStar, Inc. 582 1800 Sutter St 583 Suite 570 584 Concord, CA 94520 585 US 587 Phone: +1 925/363-8720 588 EMail: jon.peterson@neustar.biz 589 URI: http://www.neustar.biz/ 591 Appendix A. Acknowledgments 593 The authors would like to thank Eric Rescorla, Rohan Mahy, Robert 594 Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for 595 their comments. Cullen Jennings assisted greatly in the development 596 of the content indirection mechanism considered in Section 4.3. 598 Appendix B. Changelog 600 Changes from draft-peterson-sip-identity-01: 602 - Split off child draft-ietf-sip-authid-body-00 for defining of 603 the AIB 605 - Clarified scope in introduction 607 - Removed a lot of text that was redundant with RFC3261 608 (especially about authentication practices) 610 - Added mention of content indirection mechanism for adding token 611 to requests and responses 613 - Improved Security Considerations (added piece about credential 614 strength) 616 Changes from draft-peterson-sip-identity-00: 618 - Added a section on authenticated identities in responses 620 - Removed hostname convention for authentication services 622 - Added text about using 'message/sip' or 'message/sipfrag' in 623 authenticated identity bodies, also RECOMMENDED a few more headers 624 in sipfrags to increase reference integrity 626 - Various other editorial corrections 628 Full Copyright Statement 630 Copyright (C) The Internet Society (2002). All Rights Reserved. 632 This document and translations of it may be copied and furnished to 633 others, and derivative works that comment on or otherwise explain it 634 or assist in its implementation may be prepared, copied, published 635 and distributed, in whole or in part, without restriction of any 636 kind, provided that the above copyright notice and this paragraph are 637 included on all such copies and derivative works. However, this 638 document itself may not be modified in any way, such as by removing 639 the copyright notice or references to the Internet Society or other 640 Internet organizations, except as needed for the purpose of 641 developing Internet standards in which case the procedures for 642 copyrights defined in the Internet Standards process must be 643 followed, or as required to translate it into languages other than 644 English. 646 The limited permissions granted above are perpetual and will not be 647 revoked by the Internet Society or its successors or assigns. 649 This document and the information contained herein is provided on an 650 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 651 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 652 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 653 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 654 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 656 Acknowledgement 658 Funding for the RFC Editor function is currently provided by the 659 Internet Society.