idnits 2.17.1 draft-ietf-sip-identity-02.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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 570 has weird spacing: '... where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 2004) is 7281 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) -- Looks like a reference, but probably isn't: 'TODO' on line 311 == Unused Reference: '5' is defined on line 717, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 724, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 727, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 731, but no explicit reference was found in the text == 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: 2 errors (**), 0 flaws (~~), 10 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: November 15, 2004 C. Jennings 5 Cisco Systems 6 May 17, 2004 8 Enhancements for Authenticated Identity Management in the Session 9 Initiation Protocol (SIP) 10 draft-ietf-sip-identity-02 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 15, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The existing security mechanisms in the Session Initiation Protocol 42 are inadequate for cryptographically assuring the identity of the end 43 users that originate SIP requests and responses, especially in an 44 interdomain context. This document recommends practices and 45 conventions for identifying end users in SIP messages, and proposes a 46 way to distribute cryptographically secure authenticated identities. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Overview of Operations . . . . . . . . . . . . . . . . . . . . 6 55 6. User Agent Behavior: Sending Messages . . . . . . . . . . . . 7 56 7. Authentication Service Behavior . . . . . . . . . . . . . . . 7 57 7.1 UAs acting as an Authentication service . . . . . . . . . . . 9 58 8. Verifying Identity . . . . . . . . . . . . . . . . . . . . . . 9 59 9. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 10 60 10. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 61 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 64 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 65 Normative References . . . . . . . . . . . . . . . . . . . . . 16 66 Informative References . . . . . . . . . . . . . . . . . . . . 16 67 B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 70 1. Introduction 72 This document provides enhancements to the existing mechanisms for 73 authenticated identity management in the Session Initiation Protocol 74 (SIP [1]). An identity, for the purposes of this document, is 75 defined as a canonical SIP address-of-record URI employed to reach a 76 user (such as 'sip:alice@atlanta.com'). 78 RFC3261 enumerates a number of places within a SIP request that a 79 user can express an identity for themselves, notably the user- 80 populated From header field. However, the recipient of a SIP request 81 has no way to verify that the From header field has been populated 82 accurately, in the absence of some sort of cryptographic 83 authentication mechanism. 85 RFC3261 specifies a number of security mechanisms that can be 86 employed by SIP UAs, including Digest, TLS and S/MIME 87 (implementations may support other security schemes as well). 88 However, few SIP user agents today support the end-user certificates 89 necessary to authenticate themselves via TLS or S/MIME, and 90 furthermore Digest authentication is limited by the fact that the 91 originator and destination must share a pre-arranged secret. It is 92 desirable for SIP user agents to be able to send requests to 93 destinations with they have no previous association - just as in the 94 telephone network today, one can receive a call from someone with 95 whom one has no previous association, and still have a reasonable 96 assurance that their displayed Caller-ID is accurate. 98 2. Terminology 100 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 102 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 103 described in RFC2119 [2] and indicate requirement levels for 104 compliant SIP implementations. 106 3. Background 108 All RFC3261-compliant SIP user agents support a means of 109 authenticating themselves to a SIP registrar - commonly with a shared 110 secret (Digest authentication, which MUST be supported by SIP user 111 agents, is typically used for this purpose). Registration allows a 112 user agent to express that it is the proper entity to which requests 113 should be sent for a particular address-of-record SIP URI. 115 Coincidentally, the address-of-record URI of a SIP user is also the 116 URI with which a user commonly populates the From header of requests 117 - in other words, the address-of-record is an identity. So in this 118 context, users already have a means of providing their identity, 119 which makes good sense: since the contents of a From header field are 120 essentially a 'return address' for SIP requests, being able to prove 121 that you are eligible to receive requests for that 'return address' 122 should be identical to proving that you are authorized to assert this 123 identity. 125 However, the credentials with which a user agent proves their 126 identity to a registrar cannot be validated by a user agent or proxy 127 server outside your local domain - these credentials are currently 128 only useful for registration. For the purposes of determining 129 whether or not the 'return address' of a request can legitimately be 130 asserted as the identity of the user, SIP entities in other domains 131 require an assurance that the sender of a message is capable of 132 authenticating themselves to a registrar in their own domain. 134 Ideally, then, SIP user agents should have some way of proving to 135 recipients of SIP messages that their local domain has authenticated 136 them. In the absence of end-user certificates in user agents, it is 137 possible to implement a mediated authentication architecture for SIP 138 in which requests are sent to a server in the user's local domain 139 which authenticates such requests (using the same practices by which 140 the domain would authenticate REGISTER requests). Once a message has 141 been authenticated, the local domain then needs some way to 142 communicate to other SIP entities the sending user has been 143 authenticated. This draft addresses how that imprimatur of 144 authentication can be shared. 146 RFC3261 already describes an architecture very similar to this in 147 Section 26.3.2.2, in which a user agent authenticates itself to a 148 local proxy server which in turn authenticates itself to a remote 149 proxy server via mutual TLS, creating a two-link chain of transitive 150 authentication between the originator and the remote domain. While 151 this works well in some architectures, there are a few respects in 152 which this is impractical. For one, transitive trust in inherently 153 weaker than an assertion that can be validated end-to-end. It is 154 possible for SIP requests to cross multiple intermediaries in 155 separate administrative domains, in which case transitive trust 156 becomes even less compelling. It also requires intermediaries to act 157 as proxies, rather than redirecting requests to their destinations 158 (redirection lightens loads on SIP intermediaries). 160 One solution to this problem is to use 'trusted' SIP intermediaries 161 that assert an identity for users in the form of a privileged SIP 162 header. A mechanism for doing so (with the P-Asserted-Identity 163 header) is given in [6]. However, this solution allows only hop-by- 164 hop trust between intermediaries, not end-to-end cryptographic 165 authentication, and it assumes a managed network of nodes with strict 166 mutual trust relationships, an assumption that is incompatible with 167 widespread Internet deployment. 169 Accordingly, a new tactic is required for sharing a cryptographic 170 assurance of end-user identity in an intradomain context. 171 Furthermore, this new mechanism must work for both SIP requests and 172 responses. However, there is an additional wrinkle specific to 173 providing identity in a response. While the original address-of- 174 record to which a request is sent is stored in the To header field of 175 the request, it is possible, due to retargeting at intermediaries, it 176 is possible that the request will be forwarded to an entity that has 177 a different AoR (i.e. identity). Since the To header is not changed 178 in responses to a SIP request, the UAC has no way of discovering that 179 new AoR. This is generally known as the "response identity" or 180 "connected party" problem. 182 4. Requirements 184 This draft addresses the following requirements: 186 The mechanism must allow a UAC to provide a strong cryptographic 187 identity assurance to the UAS in a request. 189 The mechanism must allow a UAS to provide a strong cryptographic 190 identity assurance to the UAC in a response. 192 User agents that receive identity assurances must be able to 193 validate these assurances without performing any network lookup. 195 Proxy servers must be capable of adding this identity assurance to 196 requests or responses. 198 The mechanism must prevent replay of the identity assurance by an 199 attacker. 201 The mechanism must be capable of protecting the integrity of SIP 202 message bodies (to ensure that media offers and answers are linked 203 to the signaling identity). 205 It must be possible for a user to have multiple AoRs (i.e. 206 accounts or aliases) under which it is known at a domain, and for 207 the UAC to assert one identity while authenticating itself as 208 another, related, identity, as permitted by the local policy of 209 the domain. 211 It must be possible, in cases where a request has been retargeted 212 to a different AoR than the one designated in the To header field, 213 for the UAC to ascertain the AoR to which the request has been 214 sent. 216 5. Overview of Operations 218 This section provides an informative (non-normative) high-level 219 overview of the mechanisms described in this document. 221 Imagine the case where Alice, who has the home proxy of example.com 222 and the address-of-record sip:alice@example.com, wants to communicate 223 with sip:bob@example.org. 225 Alice generates an INVITE and places her identity in the From header 226 field of the request. She then sends an INVITE over TLS to an 227 authentication service proxy for her domain. 229 The authentication service authenticates Alice (possibly by sending a 230 Digest authentication challenge) and validates that she is authorized 231 to populate the value of the From header field (which may be Alice's 232 AoR, or it may be some other value that the policy of the proxy 233 server permits her to use). It then computes a hash over some 234 particular headers, including the From header field and the bodies in 235 the message. This hash is signed with the certificate for the domain 236 (example.com, in Alice's case) and inserted in a header field (the 237 new Identity header) in the SIP message. The proxy, as the holder 238 the private key of its domain, is asserting that the originator of 239 this request has been authenticated and that she is authorized to 240 claim the identity (the SIP address-of-record) which appears in the 241 From header field. The proxy also inserts a companion header field 242 that tells Bob how to acquire its certificate, if he doesn't already 243 have it. 245 When Bob returns a response to the INVITE (such as a 200 OK), a 246 similar set of steps happen. Bob's home proxy asserts his identity 247 in the response. In this instance, the proxy has to insert the 248 header directly into the request - redirection of responses is not 249 possible. When Alice receives the response, she verifies Bob's 250 identity. 252 If Alice's request for Bob were retargeted, one of two things might 253 happened. If it were retargeted to a domain that was also the 254 responsibility of Bob's home proxy (for example, retargeted from 255 sip:bob@example.com to sip:carol@example.com), then the request would 256 proceed normally and receive an Identity. If Bob's home proxy would 257 retarget the request to some other domain (e.g. 258 sip:bob@example.ORG), then his home proxy would redirect the request 259 rather than proxying it, and Alice would send a new request that 260 could receive a response with an Identity from the new domain. 262 6. User Agent Behavior: Sending Messages 264 This mechanism requires one important change to existing user agent 265 behavior for sending requests and responses: user agents using this 266 mechanism to send requests or responses MUST support TLS; moreover, 267 they MUST be capable of establishing a persistent TLS connection with 268 a proxy server that acts as an authentication service. Additionally, 269 there are several practices that should be highlighted in the context 270 of this identity solution. 272 When a UAC sends a request, it MUST accurately populate the header 273 field that asserts its identity (for a SIP request, this is the From 274 header field). In a request it MUST set the URI portion of its From 275 header to match a SIP, SIPS or TEL URI AoR under which the UAC can 276 register (including anonymous URIs, as described in RFC 3323 [3]). 277 The UAC MUST also be capable of sending requests through an 278 'outbound' proxy (the authentication service), and of course MUST 279 support the Digest authentication mechanism described in RFC3261. 280 Because this mechanism does not provide integrity protection for the 281 first hop to the authentication service, the UAC MUST send requests 282 to an authentication service only over a TLS connection. 283 Additionally, in order to provide identity for responses, user agents 284 MUST form a persistent TLS connection to a proxy server when a 285 REGISTER is sent. 287 Since a UAS cannot send a response that does not replicate the 288 contents of the To and From header fields in the corresponding 289 request, UAS response-sending behavior is unchanged. Again, because 290 this mechanism does not provide integrity protection for the first 291 hop of the response path, the UAS SHOULD send responses only over a 292 TLS connection. 294 7. Authentication Service Behavior 296 The authentication service authenticates the identity of the message 297 sender and validates that the identity given in the message can 298 legitimately be asserted by the sender. Then it computes a signature 299 over the canonical form of several headers and all the bodies, and 300 inserts this signature into the message. 302 First, an authentication service MUST extract the identity of the 303 sender. For requests, it inspects the From header field; for 304 responses, the To header field (henceforth the result of this 305 inspection will be referred to as the "identity field). If the 306 identity field contains a SIP or SIPS URI, the authentication service 307 MUST extract the hostname portion of the URI in that header field, 308 and compare this to the domain(s) for which it is responsible. If 309 the identity field uses the TEL URI scheme, the policy of the 310 authentication service determines whether or not it is responsible 311 for this identity. Some example policies are described in [TODO]. 312 If the authentication service is not responsible for the identity in 313 question, it MAY handle the request as a normal proxy server; see 314 below for more information on authentication service handling of an 315 existing Identity header. 317 Second, the authentication service must determine whether or not the 318 sender of the request is authorized to claim the identity given in 319 the identity field. In order to do so, the authentication service 320 MUST authenticate the sender of the message. Some possible ways in 321 which this authentication might be performed include: 323 For requests, challenging the request with a 407 response code 324 using the Digest authentication scheme (or viewing a Proxy- 325 Authentication header sent in the request which was sent in 326 anticipation of a challenge using cached credentials, as described 327 in RFC 3261 Section 22.3) 329 For requests and responses that are sent over a persistent TLS 330 connection, relying on some prior authentication that was 331 performed at the formation of the connection (most likely, the 332 authentication service previously challenged a REGISTER request 333 sent after the TLS connection was formed, or possibly a prior 334 challenged INVITE that was sent over the TLS connection) 336 Authorization of the assertion of a particular username in the From 337 header field of a SIP message is a matter of local policy for the 338 authorization service which depends greatly on the manner in which 339 authentication is performed. A RECOMMENDED policy is as follows: the 340 username asserted during Digest authentication MUST correspond 341 exactly to the username in the From header field of the SIP message. 342 However, there are many cases in which a user might manage multiple 343 accounts in the same administrative domain. Accordingly, provided 344 the authentication service is aware of the relationships between 345 these accounts, it might allow a user providing credentials for one 346 account to assert a username associated with another account 347 controlled by the user name. Furthermore, if the AoR asserted in the 348 From header field is anonymous (per RFC3323), then the proxy should 349 authenticate that the user is any valid user in the domain and insert 350 the signature over the From header field as usual. 352 Third, the authentication service MUST form the identity signature, 353 as described in Section 10, and add an Identity header to the request 354 containing this signature. After the Identity header has been added 355 to the request, the authentication service MUST also add an Identity- 356 Info header. The Identity-Info header contains a URI from which its 357 certificate can be acquired. Details are provided in section Section 358 10. 360 Finally, the authentication service MUST forward the message 361 normally. 363 7.1 UAs acting as an Authentication service 365 There are some instances in which a user agent may hold the private 366 key of the domain Certificate for its address-of-record. In these 367 cases, the UA MAY perform the services, and add the headers, that the 368 authentication service would normally add. 370 8. Verifying Identity 372 When a user agent or proxy server receives a SIP message containing 373 an Identity header, it can inspect the signature to verify the 374 identity of the sender of the message. If an Identity header is not 375 present in a request, and one is required by local policy, then a 428 376 Use Identity response is sent. If an Identity header is not present 377 in a response, and one is required by local policy, then the 378 recipient of the response MUST communicate this lapse to its user, 379 and MAY immediately terminate any created dialog or ignore 380 transactions, as policy dictates. 382 In order to verify the identity of the sender of a message, the user 383 agent or proxy server MUST first acquire the certificate for the 384 signing domain. Implementations supporting this specification should 385 have some means of retaining domain certificates (in accordance with 386 normal practices for certificate lifetimes and revocation) in order 387 to prevent themselves from needlessly downloading the same 388 certificate every time a request from the same domain is received. 389 Certificates retained in this manner should be indexed by the URI 390 given in the Identity-Info header field value. 392 Provided that the domain certificate used to sign this message is 393 unknown, SIP entities discover this certificate by dereferencing the 394 Identity-Info header. The client processes this certificate in the 395 usual ways including checking that it has not expired, that the chain 396 is valid back to a trusted CA, and that it does not appear on 397 revocation lists. 399 Subsequently, the recipient MUST verify the signature in the Identity 400 header, and compare the identity of the signer (the subjectAltName of 401 the certificate) with the domain portion of the URI in the From 402 header field of the request as described in Section 11. 403 Additionally, the Date, Contact and Call-ID headers MUST be analyzed 404 in the manner described in Section 11; recipients that wish to verify 405 Identity signatures MUST support all of the operations described 406 there. Any discrepancies or violations MUST be reported to the user. 408 When the originating user agent of a request receives a response 409 containing an Authenticated Identity Body (AIB, see [4]), it SHOULD 410 compare the identity in the From header field of the AIB of the 411 response with the original value of the To header field in the 412 request. If these represent different identities, the user agent 413 SHOULD render the identity in the AIB of the response to its user. 414 Note that a discrepancy in these identity fields is not necessary an 415 indication of a security breach; normal retargeting may simply have 416 directed the request to a different final destination. Implementers 417 therefore may consider it unnecessary to alert the user of a security 418 violation in this case. 420 9. Proxy Server Behavior 422 In most respects, a proxy server behaves normally when it receives a 423 SIP request or response containing an Identity header. This 424 mechanism is fully backwards-compatible with existing RFC3261 proxy 425 behavior. However, if a proxy intends to act as an authentication 426 service for responses to requests it receives, it must exhibit some 427 additional behavior to ensure that retargeting requests are handled 428 properly. Essentially, a proxy server MUST NOT provide an Identity 429 header for a request that it retargets to a different administrative 430 domain. It is the responsibility of that administrative domain to 431 provide its own identity assertion, if it can. However, proxying the 432 request to a remote domain where identity services may be provided 433 has its own problems - the originator of the request has no way to 434 know whether the request was legitimately retargeted, or if any 435 responses it receives from the new domain are spoofed or otherwise 436 illegitimate. It is thus much more secure for the proxy server to 437 redirect in cases where it might otherwise retarget. 439 If a proxy server intends to act as an authentication service for a 440 response to a SIP request that it is forwarding, it MUST do ALL of 441 the following: 443 Ascertain if it is responsible for the domain indicated in the 444 Request-URI field of the request. If not, it MUST forward the 445 request normally. If so, it must then: 447 Determine the route set of targets to which this request might be 448 forwarded. From that target list, the proxy must determine which 449 contact addresses are associated with persistent TLS connections 450 that have been established to the proxy server. It places all 451 such targets (if any) into a primary route set for the call, and 452 places remaining targets into a secondary route set for the call. 453 It performs this operations irrespective of any qvalues associated 454 with the contact addresses. 456 The proxy then MUST follow normal administrative policies for 457 forwarding the request to any targets in the primary route set 458 (which may involve qvalue calculations or any other behaviors 459 described in RFC3261). Before the proxy forwards any responses to 460 this request upstream, the proxy server MUST act as an 461 authentication service (as described in Section 7), adding an 462 Identity and Identity-Info header. 464 If there are no appropriate responses from the primary route set 465 for the proxy server to forward upstream, it moves on to the 466 secondary route set (essentially, the proxy server forks 467 sequentially, exploring the primary route set as one cluster, and 468 then moves on to the secondary set). The proxy server is unable 469 to act as an authentication service for those contact addresses. 470 Accordingly, the proxy server MUST NOT explore these route targets 471 itself; instead, it MUST redirect the request with a 3xx class 472 response containing the contact addresses that constitute the 473 secondary route set. 475 In order to build the primary route set for the call, the location 476 service associated with the domain of the proxy server MUST implement 477 additional intelligence to determine which contact addresses are 478 associated with a persistent TLS connection - this is used to 479 determine when the server should act as a proxy and when it should 480 redirect. When the SIP registrar receives a REGISTER request over a 481 persistent TLS connection, it MUST compare any contact addresses 482 appearing in Contact header fields to the topmost Via header field in 483 the REGISTER request. If the host portion of a contact address 484 matches the hostname given in the topmost Via header field, then that 485 contact address is said to be "associated" with the persistent TLS 486 connection over which the REGISTER was received. Location services 487 must mark or flag these contact addresses accordingly, and remember 488 the identity that the user provided when they were authenticated 489 during registration. Only these contact addresses are added to the 490 primary route set by a proxy server that wishes to act as an 491 authentication service for responses. 493 Additionally, domain policy may require proxy servers to inspect and 494 verify the identity provided in SIP requests. The proxy server may 495 wish to ascertain the identity of the sender of the message to 496 provide spam prevention or call control services. Even if a proxy 497 server does not act as an authentication service, it MAY verify the 498 signature present in an Identity header before it makes a forwarding 499 decision for a request. Proxy servers MUST NOT remove or modify the 500 Identity or Identity-Info headers. 502 10. Header Syntax 504 This document specifies two new SIP headers: Identity and Identity- 505 Info. Each of these headers can appear only once in a SIP message. 507 Identity = "Identity" HCOLON signed-identity-digest 508 signed-identity-digest = LDQUOT 32LHEX RDQUOT 510 Identity-Info = "Identity-Info" HCOLON ident-info 511 Ident-info = LAQUOT absoluteURI RAQUOT 513 To create the contents of the signed-identity-digest, the following 514 elements of a SIP message MUST placed in the string in the order 515 specified here, separated by a colon: 517 The AoR of the UA sending the message, or the 'identity field'. 518 For a request, this is the addr-spec from the From header field; 519 for responses, the addr-spec of the To header field. This needs 520 to be in lower case and to be represented as a SIP URI. 522 The callid from Call-Id header field. 524 The Date header field, with exactly one space each for each SP and 525 the weekday and month items case set as shown in BNF in 3261. The 526 first letter is upper case and the rest of the letters are lower 527 case. 529 The addr-spec component of the Contact header field value. 531 The body content of the message with the bits exactly as they are 532 in the message. 534 For more information on the security properties of these headers, and 535 why their inclusion mitigates replay attacks, see [4]. The precise 536 formulation of this digest-string is, therefore: 538 digest-string = addr-spec HCOLON callid HCOLON SIP-Date 539 HCOLON addr-spec HCOLON message-body 541 Note again that the first addr-spec MUST be taken from the From 542 header field value, and the second addr-spec from the Contact header 543 field value. 545 After the digest-string is formed, it MUST be hashed and signed with 546 the certificate for the domain, as follows: compute the results of 547 signing this string with sha1WithRSAEncryption as described in RFC 548 3370 and base64 encode the results as specified in RFC 3548. Put the 549 result in the Identity header. 551 Note on this choice: Assuming a 1024 bit RSA key, the raw signature 552 will result in about 170 octets of base64 encoded data. For 553 comparison's sake, a typical HTTP Digest Authorization header (such 554 as those used in RFC3261) with no cnonce is around 180 octets. From 555 a speed point of view, a 2.8GHz Intel processor does somewhere in the 556 range of 250 RSA 1024 bits signs per second or 1200 RSA 512 bits 557 signs; verifies are roughly 10 times faster. Hardware accelerator 558 cards are available that speed this up. 560 The Identity-Info header MUST contain either an HTTPS URI or a SIPS 561 URI. If it contains an HTTPS URI, the URI must dereference to a 562 resource that contains a single MIME body containing the certificate 563 of the authentication service. If it is a SIPS URI, then the 564 authentication service intends for a user agent that wishes to fetch 565 the certificate to form a TLS connection to that URI, acquire the 566 certificate during normal TLS negotiation, and close the connection. 568 This document adds the following entries to Table 2 of [1]: 570 Header field where proxy ACK BYE CAN INV OPT REG 571 ------------ ----- ----- --- --- --- --- --- --- 572 Identity a - o - o o - 574 SUB NOT REF INF UPD PRA 575 --- --- --- --- --- --- 576 o o o - - - 577 Identity-Info a - o - o o - 579 SUB NOT REF INF UPD PRA 580 --- --- --- --- --- --- 581 o o o - - - 583 11. Security Considerations 585 This document describes a mechanism which provides a signature over 586 the Contact, Date, Call-ID, and 'identity fields' (addr-spec of the 587 From header field for requests, and To header field for responses) of 588 SIP messages. While a signature over the identity field alone would 589 be sufficient to secure a URI alone, the additional headers provide 590 replay protection and reference integrity necessary to make sure that 591 the Identity header will not be used in cut-and-paste attacks. In 592 general, the considerations related to the security of these headers 593 are the same as those given in RFC3261 for including headers in 594 tunneled 'message/sip' MIME bodies (see Section 23 in particular). 596 The identity field indicates the identity of the sender of the 597 message. The Date and Contact headers provide reference integrity 598 and replay protection, as described in RFC3261 Section 23.4.2. 599 Implementations of this specification MUST NOT consider valid a 600 request with an outdated Date header field (the RECOMMENDED interval 601 is that the Date header must indicate a time within 3600 seconds of 602 the receipt of a message). Implementations MUST also record Call-IDs 603 received in valid requests containing an Identity header, and MUST 604 remember those Call-IDs for at least the duration of a single Date 605 interval (i.e. 3600 seconds). Accordingly, if an Identity header is 606 replayed within the Date interval, receivers will recognize that it 607 is invalid because of a Call-ID duplication; if an Identity header is 608 replayed after the Date interval, receivers will recognize that it is 609 invalid because the Date is stale. The Contact header field is 610 included to tie the Identity header to a particular device instance 611 that generated the request. Were an active attacker to intercept a 612 request containing an Identity header, and cut-and-paste the Identity 613 header field into their own request (reusing the identity fields, 614 Contact, Date and Call-ID fields that appear in the original 615 message), they would not be eligible to receive SIP requests from the 616 called user agent, since those requests are routed to the URI 617 identified in the Contact header field. 619 This mechanism also provides a signature over the bodies of SIP 620 requests. The most important reason for doing so is to protect SDP 621 bodies carried in SIP requests. There is little purpose in 622 establishing the identity of the user agent that provided the 623 signaling if a man-in-the-middle can change the SDP and direct media 624 to an alternate address. Note however that this is not perfect end- 625 to-end security. The authentication service itself, when 626 instantiated at a intermediary, can change the SDP (and SIP headers, 627 for that matter) before providing a signature. Thus, while this 628 mechanism reduces the chance that a man-in-the-middle will interfere 629 with sessions, it does not eliminate it entirely. Since it is 630 assumed that the user trusts their local domain to vouch for their 631 security, they must also trust the service not to violate the 632 integrity of their message bodies without good reason. 634 Users SHOULD NOT provide credentials to an authentication service to 635 which they cannot initiate a direct connection, preferably one 636 secured by TLS. If a user does not receive a certificate from the 637 authentication service over this TLS that corresponds to the expected 638 domain (especially when they receive a challenge via a mechanism such 639 as Digest), then it is possible that a rogue server is attempting to 640 pose as a authentication service for a domain that it does not 641 control, possibly in an attempt to collect shared secrets for that 642 domain. If a user cannot connect directly to the desired 643 authentication service, the user SHOULD at least use a SIPS URI to 644 ensure that mutual TLS authentication will be used to reach the 645 remote server. 647 Relying on an Identity header generated by a remote administrative 648 domain assumes that the issuing domain uses some trustworthy practice 649 to authenticate its users. However, it is possible that some domains 650 will implement policies that effectively make users unaccountable 651 (such as accepting unauthenticated registrations from arbitrary 652 users). The value of an Identity header for such domains is 653 questionable. 655 Since a domain certificate is used by an authentication service 656 (rather than individual certificates for each identity), certain 657 problems can arise with name subordination. For example, if an 658 authentication service holds a common certificate for the hostname 659 'sip.atlanta.com', can it legitimately sign a token containing an 660 identity of 'sip:alice@atlanta.com'? It is difficult for the 661 recipient of a request to ascertain whether or not 'sip.atlanta.com' 662 is authoritative for the 'atlanta.com' domain unless the recipient 663 has some foreknowledge of the administration of 'atlanta.com'. 664 Therefore, it is RECOMMENDED that user agent recipients of 665 authentication tokens notify end users if there is ANY discrepancy 666 between the subjectAltName of the signers certificate and the 667 identity within the authentication token. Minor discrepancies MAY be 668 characterized as such. Additionally, relying parties MAY follow the 669 procedures in RFC3264 to look up on the domain portion of the 670 identity in the From header field in the DNS, and compare the SIP 671 services listed for that domain with the subjectAltName of the 672 certificate; this can give the relying party a better sense of the 673 canonical SIP services for that domain. 675 Because the domain certificates that can be used by authentication 676 services need to assert only the hostname of the authentication 677 service, existing certificate authorities can provide adequate 678 certificates for this mechanism. However, not all proxy servers and 679 user agents will be able support the root certificates of all 680 certificate authorities, and moreover there are some significant 681 differences in the policies by which certificate authorities issue 682 their certificates. This document makes no recommendations for the 683 usage of particular certificate authorities, nor does it describe any 684 particular policies that certificate authorities should follow, but 685 it is anticipated that operational experience will create de facto 686 standards for the purposes of authentication services. Some 687 federations of service providers, for example, might only trust 688 certificates that have been provided by a certificate authority 689 operated by the federation. 691 12. IANA Considerations 693 This document specifies two new SIP headers: Identity and Identity- 694 Info. Their syntax is given in Section 10. This document requests 695 that IANA add these headers to the SIP header registry. 697 This document also defines a new SIP response code, 428 "Use 698 Identity", as described in Section 8. 700 Normative References 702 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 703 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 704 Session Initiation Protocol", RFC 3261, June 2002. 706 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 707 levels", RFC 2119, March 1997. 709 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 710 Protocol (SIP)", RFC 3323, November 2002. 712 [4] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 713 draft-ietf-sip-authid-body-01 (work in progress), October 2002. 715 Informative References 717 [5] Kohl, J. and C. Neumann, "The Kerberos Network Authentication 718 Service (V5)", RFC 1510, September 1993. 720 [6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to 721 the Session Initiation Protocol (SIP) for Asserted Identity 722 within Trusted Networks", RFC 3325, November 2002. 724 [7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 725 November 2002. 727 [8] Olson, S., "A Mechanism for Content Indirection in SIP 728 Messages", draft-ietf-sip-content-indirect-mech-01 (work in 729 progress), August 2002. 731 [9] Freed, N., "Definition of the URL MIME External-Body Access- 732 Type", RFC 2017, November 1996. 734 Authors' Addresses 736 Jon Peterson 737 NeuStar, Inc. 738 1800 Sutter St 739 Suite 570 740 Concord, CA 94520 741 US 743 Phone: +1 925/363-8720 744 EMail: jon.peterson@neustar.biz 745 URI: http://www.neustar.biz/ 747 Cullen Jennings 748 Cisco Systems 749 170 West Tasman Drive 750 MS: SJC-21/2 751 San Jose, CA 95134 752 USA 754 Phone: +1 408 902-3341 755 EMail: fluffy@cisco.com 757 Appendix A. Acknowledgments 759 The authors would like to thank Eric Rescorla, Rohan Mahy, Robert 760 Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for 761 their comments. 763 Appendix B. Changelog 765 Changes from draft-ietf-sip-identity-01: 767 - Completely changed underlying mechanism - instead of using an 768 AIB, the mechanism now recommends the use of the Identity header 769 and Identity-Info header 771 - Numerous other changes resulting from the above 773 - Various other editorial corrections 775 Changes from draft-peterson-sip-identity-01: 777 - Split off child draft-ietf-sip-authid-body-00 for defining of 778 the AIB 780 - Clarified scope in introduction 781 - Removed a lot of text that was redundant with RFC3261 782 (especially about authentication practices) 784 - Added mention of content indirection mechanism for adding token 785 to requests and responses 787 - Improved Security Considerations (added piece about credential 788 strength) 790 Changes from draft-peterson-sip-identity-00: 792 - Added a section on authenticated identities in responses 794 - Removed hostname convention for authentication services 796 - Added text about using 'message/sip' or 'message/sipfrag' in 797 authenticated identity bodies, also RECOMMENDED a few more headers 798 in sipfrags to increase reference integrity 800 - Various other editorial corrections 802 Full Copyright Statement 804 Copyright (C) The Internet Society (2004). All Rights Reserved. 806 This document and translations of it may be copied and furnished to 807 others, and derivative works that comment on or otherwise explain it 808 or assist in its implementation may be prepared, copied, published 809 and distributed, in whole or in part, without restriction of any 810 kind, provided that the above copyright notice and this paragraph are 811 included on all such copies and derivative works. However, this 812 document itself may not be modified in any way, such as by removing 813 the copyright notice or references to the Internet Society or other 814 Internet organizations, except as needed for the purpose of 815 developing Internet standards in which case the procedures for 816 copyrights defined in the Internet Standards process must be 817 followed, or as required to translate it into languages other than 818 English. 820 The limited permissions granted above are perpetual and will not be 821 revoked by the Internet Society or its successors or assigns. 823 This document and the information contained herein is provided on an 824 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 825 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 826 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 827 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 828 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 830 Acknowledgement 832 Funding for the RFC Editor function is currently provided by the 833 Internet Society.