idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- 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 (February 2003) is 7734 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) == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-01 -- 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 (==), 3 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: August 2, 2003 February 2003 6 Enhancements for Authenticated Identity Management in the Session 7 Initiation Protocol (SIP) 8 draft-ietf-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 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 August 2, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). 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 Client . . . . . . . . . . . . . . . . . . . . . 7 53 4.2 Body Added by Authentication Service . . . . . . . . . . . . . 8 54 4.3 Using Content Indirection . . . . . . . . . . . . . . . . . . 8 55 5. Identity in Responses . . . . . . . . . . . . . . . . . . . . 9 56 6. Receiving an Authentication Token . . . . . . . . . . . . . . 10 57 6.1 Authentication Service Handling of Authentication Tokens . . . 10 58 7. Selective Sharing of Identity . . . . . . . . . . . . . . . . 10 59 7.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 11 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 63 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 64 Normative References . . . . . . . . . . . . . . . . . . . . . 13 65 Informative References . . . . . . . . . . . . . . . . . . . . 13 66 B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 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 (Digest 98 authentication, which MUST be supported by SIP user agents, is 99 typically used for this purpose). Registration allows a user agent 100 to express that it is the proper entity to which requests should be 101 sent for a particular address-of-record SIP URI. 103 Coincidentally, the address-of-record URI of a SIP user is also the 104 URI with which a SIP UA populates the From header of requests from 105 that user - in other words, the address-of-record is an identity. So 106 in this context users already have a means of providing their 107 identity, which makes good sense: since the contents of a From header 108 field are essentially a 'return address' for SIP requests, being able 109 to prove that you are eligible to receive requests for that 'return 110 address' should be identical to proving that you are authorized to 111 assert this identity. 113 However, the credentials with which a user agent proves to a 114 registrar that they are, for example, an authorized recipient of 115 requests for 'sip:alice@atlanta.com' will not be accepted by a server 116 in another domain - these credentials are currently only useful for 117 local registration. What other domains really want to know about 118 your identity is that you are capable of authenticating yourself in 119 your own domain. 121 Ideally, then, there should be some way of proving to remote domains 122 that your local domain has authenticated you. In the absence of end- 123 user certificates in user agents, it is possible to implement a 124 mediated authentication architecture for SIP in which requests are 125 sent to a server in the user's local domain which authenticates them 126 (using the same practices by which the domain would authenticate 127 REGISTER requests). Once a request has been authenticated, the local 128 domain then needs some way to communicate to remote domains that it 129 has sanctioned the request. This draft addresses how that identity 130 can could be securely shared. 132 RFC3261 already describes an architecture very similar to this in 133 Section 26.3.2.2, in which a user agent authenticates itself to a 134 local proxy server which in turn authenticates itself to a remote 135 proxy server via mutual TLS, creating a two-link chain of transitive 136 authentication between the originator and the remote domain. While 137 this works well in some architectures, there are a few respects in 138 which this is impractical. For one, it is possible for SIP requests 139 to cross multiple intermediaries in separate administrative domains, 140 in which case transitive trust becomes far less compelling. It also 141 requires intermediaries to act as proxies, rather than redirecting 142 requests to their destinations (redirection lightens loads on SIP 143 intermediaries). Both of these limitations result from the fact that 144 authentication takes place outside the application, at the transport 145 layer, rather than within SIP itself. 147 One solution to this problem is to use 'trusted' SIP intermediaries 148 that assert an identity for users in the form of a privileged SIP 149 header. A mechanism for doing so (with the P-Asserted-Identity 150 header) is given in [6]. However, this solution allows only hop-by- 151 hop trust between intermediaries, not end-to-end cryptographic 152 authentication, and it assumes a managed network of nodes with strict 153 mutual trust relationships, an assumption that is incompatible with 154 widespread Internet deployment. 156 The desired mediated authentication architecture has quite a bit in 157 common with the problem space of Kerberos [5]. Ideally, there should 158 be a way for a user to authenticate themselves to the local domain, 159 and receive some kind of token that they can share with recipients of 160 requests that lets them know that the user has been authenticated by 161 the local domain. However, Kerberos support in SIP user agents is 162 not widespread, and moreover SIP uses other means (such as Digest) to 163 perform key authentication functions already. An ideal solution 164 would adapt existing SIP security mechanisms to address this problem. 166 Therefore, this document defines a new logical role for SIP network 167 intermediaries called an 'authentication service'. Once an 168 authentication service has verified the identity of the originator of 169 a request, as described above, it creates a cryptographic token that 170 contains the authenticated identity of the user, and which has some 171 reference integrity with the request itself. This token can then be 172 added to a SIP request and inspected by recipients of the request who 173 need a cryptographic guarantee of the identity of the user. 175 One possible format for such tokens is the Authenticated Identity 176 Body (AIB) described in [4]. Other token formats are a matter for 177 further investigation. Throughout this document, the use of AIB 178 format for the token is considered exclusively. Only tokens that are 179 suitable to be carried in a MIME body are considered in this 180 document. 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 learned or 195 configured is an implementation-specific matter for the user agent - 196 it might be implemented with a pre-loaded Route header. The 197 guidelines given in RFC3261 Sections 26.3.2.1 and 26.3.2.2 should be 198 used when connecting to an authentication service; ideally, an 199 authentication service should be one hop away from a user agent, it 200 should use a lower-layer security protocol such as TLS or IPSec to 201 authenticate the authentication service before providing credentials 202 (especially 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 RECOMMENDED for compatibility with the maximum set of user agents. 209 4. How to Share Verified Identities 211 When an authentication service has authenticated the user, it must 212 construct an identity URI for that user that will be contained in the 213 token. It is RECOMMENDED that these identities take the form of SIP 214 address-of-record URI (as opposed to contact addresses), as they are 215 defined in Section 10 of RFC3261; in other words, URIs of the form 216 'sip:alice@atlanta.com'. 218 This identity must be expressed in the authentication token that will 219 be signed by the authentication service. For example, if the 220 Authenticated Identity Body (AIB) format described in [4] is used, 221 then for an INVITE this identity would be stored in the From header 222 field within a 'message/sip' or 'message/sipfrag' [7] body that will 223 be signed by the authentication service. 225 Once the token has been created, the server MUST sign the token. The 226 subject of the certificate SHOULD be assigned in one of the two 227 following ways: 229 An authentication service MAY use a common certificate, such as a 230 site 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 234 'sip:alice@atlanta.com', the subjectAltName of the certificate 235 would be 'atlanta.com'); this should be the same certificate that 236 the authentication service provides when proving its own identity 237 (via TLS or some similar protocol). 239 An authentication service MAY hold a certificate corresponding to 240 each user in its administrative domain (in other words, a 241 certificate whose subjectAltName contains a URI equivalent to the 242 address-of-record URI of the user). In this case, the appropriate 243 certificate for the authenticated user will be used to sign the 244 authentication token. Maintaining individual certificates for 245 each user is RECOMMENDED, since the name subordination rules 246 involved with the use of a common certificate for the domain can 247 become complicated. 249 After the authentication token has been signed, the authentication 250 token MUST somehow be integrated with any existing MIME bodies in the 251 request, if necessary by transitioning the outermost MIME body to a 252 'multipart/mixed' format, before the request can be forwarded. Three 253 options are considered for ways that an authentication token could be 254 added to a SIP message: one in which the authentication service 255 pushes the token back to the client for resubmission, one in which 256 the authentication service adds the token itself, and one in which 257 the client anticipates a URI at which the authentication service will 258 make the token available. Authentication services MUST support the 259 mechanism in Section 4.1 and MAY support the mechanism in Section 260 4.2; the mechanism in Section 4.3 is included to illustrate a future 261 direction. 263 4.1 Body Added by Client 265 In this case, the authentication service returns the authentication 266 token to the originating user agent, prompting the user agent to 267 retry the request with the authentication token attached. No 268 existing SIP mechanism can perform this function. Therefore, this 269 document defines a 428 "Use Authentication Token" response code. 271 After a user has been authenticated (in the Digest example, with the 272 407 response) an authentication service sends a 428 with a MIME body 273 in order to request that a user agent add the enclosed MIME body to 274 their request and retry the request. A 428 MUST have at most a 275 single MIME body. This MIME body MUST be signed by the 276 authentication service. 278 The use of 428 without any MIME body is also defined in this 279 document. It can be sent by any server to reject a request because 280 the request does not contain an authentication token. A user agent 281 receiving this rejection SHOULD retry their request through the same 282 server after acquiring a token from an authentication service. 284 In order to signal to the authentication services and other 285 intermediaries that the originating user agent supports the receipt 286 of the 428 response code, a new option-tag has been defined, the 287 'auth-id' option-tag. User agents SHOULD supply the 'auth-id' 288 option-tag in a Supported header whenever they provide credentials to 289 a server (for example, in Digest authentication, whenever a Proxy- 290 Authorization header is added to a request). 292 Using the 428 response code may introduce extra round-trip times for 293 messages, delaying the setup of requests. However, there are some 294 circumstances under which extra RTTs may not impede performance. If 295 the originating user agent possesses a non-stale nonce (assuming 296 Digest authentication) from the authentication service, it can pre- 297 emptively include a Proxy-Authorization header, eliminating one RTT 298 (the one resulting from a 407). With regard to the second RTT, note 299 that the request needn't necessarily go through the authentication 300 service again once the authentication token has been added - it could 301 go directly to its destination, which reduce the impact of the second 302 RTT. 304 There are two good reasons to think that the originating user agent 305 should be the party responsible for adding the authentication token 306 to the request. Firstly, because this gives the client the 307 opportunity to inspect the body itself (perhaps only to see whether 308 or not it is encrypted; see [4]) in order to verify that the 309 authenticated identity corresponds with the provided credentials and 310 the user's preferences. Secondly, the client can provide a signature 311 over the entire body of the message (either with S/MIME or some 312 header-based mechanism) so that the final recipient of messages can 313 be assured that all information in the body is there at the 314 originator's behest. 316 4.2 Body Added by Authentication Service 318 Another possibility is that the authentication service could add the 319 body to the request itself before forwarding the request. However, 320 the authentication service role is usually played by entities that 321 act as proxy servers for most requests, and proxy servers cannot 322 modify message bodies (see RFC3261 Section 16.6). In order to add an 323 authentication token, the authentication service needs to act as a 324 transparent back-to-back user agent, effectively terminating the 325 request and re-originating it with a new body appended to any 326 existing MIME bodies (again, transposing to various MIME multipart 327 forms as necessary). 329 This mechanism has some potential advantages over pushing the 330 authentication token back to the originating user agent. For one, it 331 saves one additional round-trip time that would be used by the 428 332 response. It also requires no new SIP mechanisms, whereas the 428 333 response necessitates option-tag support. 335 However, there are proposed SIP integrity mechanisms that place a 336 signature over the entire message body in a SIP message header. Were 337 a server to modify the body of a message that was protected by such 338 signature, that would be perceived as an integrity violation by 339 downstream recipients of the message. Presumably, a back-to-back 340 user agent function would have to sacrifice this end-to-end 341 integrity. The notion of a transparent back-to-back user agent is 342 also ill-defined, and it is questionable if any SIP intermediaries 343 should interfere with SIP message bodies. 345 4.3 Using Content Indirection 347 Work is currently underway in the SIP WG to define a content 348 indirection [8] mechanism for SIP, a mechanism by which a MIME body 349 in a SIP request can refer, with a URL, to a document that it hosted 350 somewhere in the network. This raises another interesting 351 possibility for authentication token transport in SIP. 353 A SIP user agent could create a content indirection MIME body (using 354 the RFC2017 [9] URL MIME External-Body Access-Type) that contains a 355 URL that identities a resource controlled by the authentication 356 service, anticipating that the authentication service will make the 357 authentication token available at that URL. This URL could be pushed 358 by the authentication service to the UAC when the authentication 359 service challenges the UAC (as a new header in the 407 response). 360 Once an authentication service has validated the request, it simply 361 makes the authentication token available at the anticipated URL; 362 recipients of the message would then dereference the URL in order to 363 inspect the token. 365 This approach could allow user agents to have full control over the 366 integrity of SIP requests, while still requiring the extra RTT caused 367 by the use of the 428 response code. It also has numerous advantages 368 over other ways of handling authentication tokens issued for SIP 369 response messages (see Section 5). 371 5. Identity in Responses 373 Many of the practices described in the preceding sections can be 374 applied to responses as well as requests, with some important 375 differences. Primarily, the distinction is that a response cannot be 376 challenged or resubmitted in the same manner as a request, and 377 therefore the mechanism in Section 4.1 is not usable. However, when 378 a user agent registers under a particular identity, and thereby 379 becomes eligible to receive requests and send responses associated 380 with that identity, it provides credentials that prove its identity, 381 and thus if the registrar is co-located with the proxy that receives 382 requests for the user's administrative domain, is in a reasonable 383 position to act as an authentication service for responses. 385 Note that the identity in an authentication token in a response 386 almost certainly will not correspond with the identity asserted in 387 the From header field of the response (which is copied from the 388 request); the identity in the authentication token represents a 389 different entity. For many requests, the identity in the 390 authentication token of a response will correspond to the To header 391 field of the request, but there are numerous legitimate ways that 392 requests can be retargeted in which this will not be the case. 394 An authentication service that also acts as a registrar and inbound 395 proxy can add to a response an authentication token that corresponds 396 to the identity of the originator of that response in roughly the 397 same manner described in Section 4.2 - the authentication service 398 adds the authentication token to a response before it forwards the 399 response towards the originator of the request. There is no way for 400 an authentication service to perform a function for responses 401 comparable to the mechanism described in Section 4.1; however, 402 content indirection (see Section 4.3 could provide an alternative 403 that would allow the client to retain end-to-end integrity properties 404 on responses. 406 6. Receiving an Authentication Token 408 The manner in which an authentication token is handled is dependent 409 on the nature of the token itself; rules for handling the 410 Authenticated Identity Body (AIB) format are given [4]. 412 6.1 Authentication Service Handling of Authentication Tokens 414 SIP intermediaries generally should not attempt to inspect MIME 415 bodies; following the rules of RFC3261 Section 16.6, MIME bodies may 416 be encrypted end-to-end or have other properties that make them 417 unsuitable for consumption by intermediaries. However, 418 intermediaries that implement the authentication service logical role 419 MAY inspect MIME bodies in order to find one with a Content- 420 Disposition of 'auth-id'. 422 For the most part, the actual value of an authenticated identity is 423 not likely to be of interest to a proxy server, though it MAY refuse 424 to process a request that does not contain a valid authentication 425 token (using the 428 request, as described in Section 4.1). However, 426 authentication services MAY additionally maintain lists of known 427 problem users that are banned from making requests to their 428 administrative domain, for example, and subsequently reject some 429 requests after comparing their authenticated identities to such 430 access control lists. 432 7. Selective Sharing of Identity 434 Most of the time, there is no need to restrict the propagation of 435 verified identities in the network. User agents and intermediaries 436 benefit from receiving verified identities. However, in some cases 437 intermediaries might want to restrict the distribution of identity 438 information, for example if 440 o the authenticated identity body contains an identity that is only 441 meaningful as an internal identifier within a particular service 442 provider's network, or, 444 o the originating user agent has requested privacy, and the 445 unrestricted distribution of the authenticated identity body would 446 violate that request. 448 If it is not appropriate to share an authenticated identity because a 449 user has requested privacy, an authenticated identity body SHOULD NOT 450 be created and distributed. However, in some cases there may be 451 other entities in the administrative domain of the authentication 452 service that are consumers of the authenticated identity. If, for 453 example, each of these servers needed to challenge the user 454 individually for identity, it might significantly delay the 455 processing of the request. For that reason, it may be appropriate to 456 circulate authenticated identity bodies among a controlled set of 457 entities. For that purpose, an encryption mechanism for 458 authenticated identities is required. 460 7.1 Requesting Privacy 462 When users authenticate themselves to an authentication service, they 463 MAY explicitly notify the service that they do not wish their 464 authenticated identity to be circulated. Usually, the user in 465 question would also be taking other steps to preserve their privacy 466 (perhaps by including an anonymous From header in the SIP request, 467 and following other standard privacy practices). 469 Authentication services MUST support the privacy mechanism described 470 in RFC3323 [3]. Users requesting privacy should also support the 471 mechanisms described in that document. 473 In particular, this document uses an identity-specific priv-value 474 that can appear in the Privacy header, a value of 'id', which was 475 registered by RFC3325 [6]. This Privacy value requests that the 476 results of authentication should not be shared by the authenticating 477 intermediary. An authentication service SHOULD NOT create an 478 authentication token for a request when 'id' privacy has been 479 requested. If such a token is created, it MUST be encrypted or 480 rendered confidential in the manner most appropriate to the token. 481 Guidelines for encrypting AIBs are given in [4], and these mechanisms 482 MUST be supported by any authentication service that uses AIBs. 484 8. Security Considerations 486 Users SHOULD NOT provide credentials to an authentication service to 487 which they cannot initiate a direct connection, preferably one 488 secured by a network or transport layer security protocol such as 489 TLS. If a user does not receive a certificate from the 490 authentication service over this lower-layer protocol that 491 corresponds to the expected domain (especially when they receive a 492 challenge via a mechanism such as Digest), then it is possible that a 493 rogue server is attempting to pose as a authentication service for a 494 domain that it does not control, possibly in an attempt to collect 495 shared secrets for that domain. If a user cannot connect directly to 496 the desired authentication service, the user SHOULD at least use a 497 SIPS URI to ensure that mutual TLS authentication will be used to 498 reach the remote server. 500 Relying on an authentication token generated by a remote 501 administrative domain assumes that the domain uses some trustworthy 502 practice to authenticate its users. However, it is possible that 503 some domains will implement policies that effectively make users 504 unaccountable (such as accepting unauthenticated registrations from 505 arbitrary users). Therefore, it is RECOMMENDED that authentication 506 tokens contain some indication of the specific practice (for example, 507 Digest) that was used to authenticate this request as a rough 508 indicator of credential strength. No manner of describing 509 authentication practices is specified in this document. 511 If a common certificate is used by an authentication service (rather 512 than individual certificates for each identity), certain problems can 513 arise with name subordination. For example, if an authentication 514 service holds a common certificate for the hostname 515 'sip.atlanta.com', can it legitimately sign a token containing an 516 identity of 'sip:alice@atlanta.com'? It is difficult for the 517 recipient of a request to ascertain whether or not 'sip.atlanta.com' 518 is authoritative for the 'atlanta.com' domain unless the recipient 519 has some foreknowledge of the administration of 'atlanta.com'. 520 Therefore, it is RECOMMEND that user agent recipients of 521 authentication tokens notify end users if there is ANY discrepancy 522 between the subjectAltName of the signers certificate and the 523 identity within the authentication token. 525 Authentication tokens MUST have some form of replay protection. The 526 best protection is to copy the SIP request in its entirety (via the 527 'message/sip' MIME type) into the authentication token - in that way, 528 it will be clear that this token has been issued for this request, 529 since collectively the headers of a SIP request provide a unique 530 identifier. However, SIP requests can be large, and it is reasonable 531 to include only a subset of the SIP headers in a request (using the 532 'message/sipfrag' MIME type) as long as certain critical headers are 533 provided. For further discussion of this issue, including guidelines 534 for including particular headers in a sipfrag, see [4]. 536 Because the common certificates that can be used by authentication 537 services need to assert only the hostname of the authentication 538 service, existing certificate authorities can provide adequate 539 certificates for this mechanism. However, not all proxy servers and 540 user agents will be able support the root certificates of all 541 certificate authorities, and moreover there are some significant 542 differences in the policies by which certificate authorities issue 543 their certificates. This document makes no recommendations for the 544 usage of particular certificate authorities, nor does it describe any 545 particular policies that certificate authorities should follow, but 546 it is anticipated that operational experience will create de facto 547 standards for the purposes of authentication services. Some 548 federations of service providers, for example, might only trust 549 certificates that have been provided by a certificate authority 550 operated by the federation. 552 9. IANA Considerations 554 This document defines a new SIP status code, '428 Use Authentication 555 Token'. The use of this status code is further described in Section 556 4.1. 558 Normative References 560 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 561 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 562 Session Initiation Protocol", RFC 3261, June 2002. 564 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 565 levels", RFC 2119, March 1997. 567 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 568 Protocol (SIP)", RFC 3323, November 2002. 570 [4] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 571 draft-ietf-sip-authid-body-01 (work in progress), October 2002. 573 Informative References 575 [5] Kohl, J. and C. Neumann, "The Kerberos Network Authentication 576 Service (V5)", RFC 1510, September 1993. 578 [6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to 579 the Session Initiation Protocol (SIP) for Asserted Identity 580 within Trusted Networks", RFC 3325, November 2002. 582 [7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 583 November 2002. 585 [8] Olson, S., "A Mechanism for Content Indirection in SIP 586 Messages", draft-ietf-sip-content-indirect-mech-01 (work in 587 progress), August 2002. 589 [9] Freed, N., "Definition of the URL MIME External-Body Access- 590 Type", RFC 2017, November 1996. 592 Author's Address 594 Jon Peterson 595 NeuStar, Inc. 596 1800 Sutter St 597 Suite 570 598 Concord, CA 94520 599 US 601 Phone: +1 925/363-8720 602 EMail: jon.peterson@neustar.biz 603 URI: http://www.neustar.biz/ 605 Appendix A. Acknowledgments 607 The authors would like to thank Eric Rescorla, Rohan Mahy, Robert 608 Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for 609 their comments. Cullen Jennings assisted greatly in the development 610 of the content indirection mechanism considered in Section 4.3. 612 Appendix B. Changelog 614 Changes from draft-peterson-sip-identity-01: 616 - Split off child draft-ietf-sip-authid-body-00 for defining of 617 the AIB 619 - Clarified scope in introduction 621 - Removed a lot of text that was redundant with RFC3261 622 (especially about authentication practices) 624 - Added mention of content indirection mechanism for adding token 625 to requests and responses 627 - Improved Security Considerations (added piece about credential 628 strength) 630 Changes from draft-peterson-sip-identity-00: 632 - Added a section on authenticated identities in responses 634 - Removed hostname convention for authentication services 636 - Added text about using 'message/sip' or 'message/sipfrag' in 637 authenticated identity bodies, also RECOMMENDED a few more headers 638 in sipfrags to increase reference integrity 639 - Various other editorial corrections 641 Full Copyright Statement 643 Copyright (C) The Internet Society (2003). All Rights Reserved. 645 This document and translations of it may be copied and furnished to 646 others, and derivative works that comment on or otherwise explain it 647 or assist in its implementation may be prepared, copied, published 648 and distributed, in whole or in part, without restriction of any 649 kind, provided that the above copyright notice and this paragraph are 650 included on all such copies and derivative works. However, this 651 document itself may not be modified in any way, such as by removing 652 the copyright notice or references to the Internet Society or other 653 Internet organizations, except as needed for the purpose of 654 developing Internet standards in which case the procedures for 655 copyrights defined in the Internet Standards process must be 656 followed, or as required to translate it into languages other than 657 English. 659 The limited permissions granted above are perpetual and will not be 660 revoked by the Internet Society or its successors or assigns. 662 This document and the information contained herein is provided on an 663 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 664 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 665 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 666 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 667 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Acknowledgement 671 Funding for the RFC Editor function is currently provided by the 672 Internet Society.