SIP WG J. Peterson Internet-Draft NeuStar Expires:
August 2, 2003 February 2003November 15, 2004 C. Jennings Cisco Systems May 17, 2004 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) draft-ietf-sip-identity-01draft-ietf-sip-identity-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 2, 2003.November 15, 2004. Copyright Notice Copyright (C) The Internet Society (2003).(2004). All Rights Reserved. Abstract The existing security mechanisms for expressing identityin the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securelyare inadequate for cryptographically assuring the identity of the originator of a request.end users that originate SIP requests and responses, especially in an interdomain context. This document recommends practices and conventions for authenticatingidentifying end users,users in SIP messages, and proposes a way to distribute cryptographically secure authenticated identities within SIP messages.identities. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 53 3. Using an Authentication ServiceBackground . . . . . . . . . . . . . . . 5 4. How to Share Verified Identities. . . . . . . . . . . 3 4. Requirements . . . . 5 4.1 Body Added by Client. . . . . . . . . . . . . . . . . . . . . 7 4.2 Body Added by Authentication Service5 5. Overview of Operations . . . . . . . . . . . . . 8 4.3 Using Content Indirection. . . . . . . 6 6. User Agent Behavior: Sending Messages . . . . . . . . . . . . 8 5. Identity in Responses7 7. Authentication Service Behavior . . . . . . . . . . . . . . . 7 7.1 UAs acting as an Authentication service . . . . . . . . . . . 9 6. Receiving an Authentication Token8. Verifying Identity . . . . . . . . . . . . . . 10 6.1 Authentication Service Handling of Authentication Tokens. . . 10 7. Selective Sharing of Identity. . . . . 9 9. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 10 7.1 Requesting Privacy10. Header Syntax . . . . . . . . . . . . . . . . . . . . . . 11 8.. . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9.13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 Author's Address .16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 1417 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 1417 Normative References . . . . . . . . . . . . . . . . . . . . . 1316 Informative References . . . . . . . . . . . . . . . . . . . . 1316 B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 1417 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 1619 1. Introduction This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP ). An identity, for the purposes of this document, is defined as a canonical SIP address-of-record URI employed to reach a user (such as 'sip:firstname.lastname@example.org'). RFC3261 enumerates a number of places within a SIP request that a user can express an identity for themselves, notably the user- populated From header field. However, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately withoutaccurately, in the absence of some sort of cryptographic authentication mechanism. Today,RFC3261 specifies a number of security mechanisms that can be usedemployed by SIP UAs, including Digest, TLS and S/MIME (and implementations(implementations may support other security schemes as well). However, few SIP user agents today cansupport the end-user certificates necessary to authenticate themselves via TLS or S/MIME, and furthermore Digest authentication is limited by the fact that the originator and destination must share a pre-arranged secret. It is desirable for SIP user agents to be able to send requests to destinations with they have no previous association - just as in the telephone network today, one can receive a call from someone with whom one has no previous association, and still have a reasonable assurance that their displayed Caller-ID is accurate. Many2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119  and indicate requirement levels for compliant SIP implementations. 3. Background All RFC3261-compliant SIP user agents todaysupport a means of authenticating themselves to a SIP registrar - commonly with a shared secret (Digest authentication, which MUST be supported by SIP user agents, is typically used for this purpose). Registration allows a user agent to express that it is the proper entity to which requests should be sent for a particular address-of-record SIP URI. Coincidentally, the address-of-record URI of a SIP user is also the URI with which a SIP UAuser commonly populates the From header of requests from that user- in other words, the address-of-record is an identity. So in this contextcontext, users already have a means of providing their identity, which makes good sense: since the contents of a From header field are essentially a 'return address' for SIP requests, being able to prove that you are eligible to receive requests for that 'return address' should be identical to proving that you are authorized to assert this identity. However, the credentials with which a user agent proves their identity to a registrar that they are, for example, an authorized recipient of requests for 'sip:email@example.com' will notcannot be acceptedvalidated by a user agent or proxy server in anotheroutside your local domain - these credentials are currently only useful for localregistration. WhatFor the purposes of determining whether or not the 'return address' of a request can legitimately be asserted as the identity of the user, SIP entities in other domains really want to know about your identity isrequire an assurance that you are capablethe sender of authenticating yourselfa message is capable of authenticating themselves to a registrar in yourtheir own domain. Ideally, then, thereSIP user agents should behave some way of proving to remote domainsrecipients of SIP messages that yourtheir local domain has authenticated you.them. In the absence of end- userend-user certificates in user agents, it is possible to implement a mediated authentication architecture for SIP in which requests are sent to a server in the user's local domain which authenticates themsuch requests (using the same practices by which the domain would authenticate REGISTER requests). Once a requestmessage has been authenticated, the local domain then needs some way to communicate to remote domains that it has sanctionedother SIP entities the request.sending user has been authenticated. This draft addresses how that identityimprimatur of authentication can couldbe securelyshared. RFC3261 already describes an architecture very similar to this in Section 220.127.116.11, in which a user agent authenticates itself to a local proxy server which in turn authenticates itself to a remote proxy server via mutual TLS, creating a two-link chain of transitive authentication between the originator and the remote domain. While this works well in some architectures, there are a few respects in which this is impractical. For one, ittransitive trust in inherently weaker than an assertion that can be validated end-to-end. It is possible for SIP requests to cross multiple intermediaries in separate administrative domains, in which case transitive trust becomes fareven less compelling. It also requires intermediaries to act as proxies, rather than redirecting requests to their destinations (redirection lightens loads on SIP intermediaries). Both of these limitations result from the fact that authentication takes place outside the application, at the transport layer, rather than within SIP itself.One solution to this problem is to use 'trusted' SIP intermediaries that assert an identity for users in the form of a privileged SIP header. A mechanism for doing so (with the P-Asserted-Identity header) is given in . However, this solution allows only hop-by- hop trust between intermediaries, not end-to-end cryptographic authentication, and it assumes a managed network of nodes with strict mutual trust relationships, an assumption that is incompatible with widespread Internet deployment. The desired mediated authentication architecture has quite a bit in common with the problem space of Kerberos . Ideally, there should beAccordingly, a waynew tactic is required for sharing a user to authenticate themselves to the local domain, and receive some kind of token that they can share with recipientscryptographic assurance of requests that lets them know that the user has been authenticated by the local domain. However, Kerberos supportend-user identity in SIP user agents is not widespread, and moreover SIP uses other means (such as Digest) to perform key authentication functions already. An ideal solution would adapt existing SIP security mechanisms to address this problem. Therefore,an intradomain context. Furthermore, this document defines anew logical rolemechanism must work for both SIP network intermediaries called an 'authentication service'. Oncerequests and responses. However, there is an authentication service has verified theadditional wrinkle specific to providing identity of the originator ofin a request, as described above, it createsresponse. While the original address-of- record to which a cryptographic token that containsrequest is sent is stored in the authenticated identityTo header field of the user, and which has some reference integrity withrequest, it is possible, due to retargeting at intermediaries, it is possible that the request itself. This token can thenwill be addedforwarded to an entity that has a SIP request and inspected by recipientsdifferent AoR (i.e. identity). Since the To header is not changed in responses to a SIP request, the UAC has no way of discovering that new AoR. This is generally known as the "response identity" or "connected party" problem. 4. Requirements This draft addresses the following requirements: The mechanism must allow a UAC to provide a strong cryptographic identity assurance to the UAS in a request. The mechanism must allow a UAS to provide a strong cryptographic identity assurance to the UAC in a response. User agents that receive identity assurances must be able to validate these assurances without performing any network lookup. Proxy servers must be capable of adding this identity assurance to requests or responses. The mechanism must prevent replay of the identity assurance by an attacker. The mechanism must be capable of protecting the integrity of SIP message bodies (to ensure that media offers and answers are linked to the signaling identity). It must be possible for a user to have multiple AoRs (i.e. accounts or aliases) under which it is known at a domain, and for the UAC to assert one identity while authenticating itself as another, related, identity, as permitted by the local policy of the domain. It must be possible, in cases where a request has been retargeted to a different AoR than the one designated in the To header field, for the UAC to ascertain the AoR to which the request has been sent. 5. Overview of Operations This section provides an informative (non-normative) high-level overview of the mechanisms described in this document. Imagine the case where Alice, who has the home proxy of example.com and the address-of-record sip:firstname.lastname@example.org, wants to communicate with sip:email@example.com. Alice generates an INVITE and places her identity in the From header field of the request. She then sends an INVITE over TLS to an authentication service proxy for her domain. The authentication service authenticates Alice (possibly by sending a Digest authentication challenge) and validates that she is authorized to populate the value of the From header field (which may be Alice's AoR, or it may be some other value that the policy of the proxy server permits her to use). It then computes a hash over some particular headers, including the From header field and the bodies in the message. This hash is signed with the certificate for the domain (example.com, in Alice's case) and inserted in a header field (the new Identity header) in the SIP message. The proxy, as the holder the private key of its domain, is asserting that the originator of this request has been authenticated and that she is authorized to claim the identity (the SIP address-of-record) which appears in the From header field. The proxy also inserts a companion header field that tells Bob how to acquire its certificate, if he doesn't already have it. When Bob returns a response to the INVITE (such as a 200 OK), a similar set of steps happen. Bob's home proxy asserts his identity in the response. In this instance, the proxy has to insert the header directly into the request - redirection of responses is not possible. When Alice receives the response, she verifies Bob's identity. If Alice's request for Bob were retargeted, one of two things might happened. If it were retargeted to a domain that was also the responsibility of Bob's home proxy (for example, retargeted from sip:firstname.lastname@example.org to sip:email@example.com), then the request would proceed normally and receive an Identity. If Bob's home proxy would retarget the request to some other domain (e.g. sip:bob@example.ORG), then his home proxy would redirect the request rather than proxying it, and Alice would send a new request that could receive a response with an Identity from the new domain. 6. User Agent Behavior: Sending Messages This mechanism requires one important change to existing user agent behavior for sending requests and responses: user agents using this mechanism to send requests or responses MUST support TLS; moreover, they MUST be capable of establishing a persistent TLS connection with a proxy server that acts as an authentication service. Additionally, there are several practices that should be highlighted in the context of this identity solution. When a UAC sends a request, it MUST accurately populate the header field that asserts its identity (for a SIP request, this is the From header field). In a request it MUST set the URI portion of its From header to match a SIP, SIPS or TEL URI AoR under which the UAC can register (including anonymous URIs, as described in RFC 3323 ). The UAC MUST also be capable of sending requests through an 'outbound' proxy (the authentication service), and of course MUST support the Digest authentication mechanism described in RFC3261. Because this mechanism does not provide integrity protection for the first hop to the authentication service, the UAC MUST send requests to an authentication service only over a TLS connection. Additionally, in order to provide identity for responses, user agents MUST form a persistent TLS connection to a proxy server when a REGISTER is sent. Since a UAS cannot send a response that does not replicate the contents of the To and From header fields in the corresponding request, UAS response-sending behavior is unchanged. Again, because this mechanism does not provide integrity protection for the first hop of the response path, the UAS SHOULD send responses only over a TLS connection. 7. Authentication Service Behavior The authentication service authenticates the identity of the request who needmessage sender and validates that the identity given in the message can legitimately be asserted by the sender. Then it computes a cryptographic guaranteesignature over the canonical form of several headers and all the bodies, and inserts this signature into the message. First, an authentication service MUST extract the identity of the user. One possible format for such tokens issender. For requests, it inspects the Authenticated Identity Body (AIB) described in . Other token formats are a matterFrom header field; for further investigation. Throughoutresponses, the To header field (henceforth the result of this document,inspection will be referred to as the use"identity field). If the identity field contains a SIP or SIPS URI, the authentication service MUST extract the hostname portion of AIB formatthe URI in that header field, and compare this to the domain(s) for which it is responsible. If the tokenidentity field uses the TEL URI scheme, the policy of the authentication service determines whether or not it is considered exclusively. Only tokens thatresponsible for this identity. Some example policies are suitable to be carrieddescribed in a MIME body are considered[TODO]. If the authentication service is not responsible for the identity in this document. 2. Terminology In this document,question, it MAY handle the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpretedrequest as described in RFC2119  and indicate requirement levelsa normal proxy server; see below for compliant SIP implementations. 3. Using an Authentication Service A SIP user agents sends requests tomore information on authentication service handling of an existing Identity header. Second, the authentication service must determine whether or not the sender of the request is authorized to claim the identity given in the identity field. In order to receive an authentication token for the request. How exactlydo so, the association with anauthentication service is learned or configured is an implementation-specific matter forMUST authenticate the user agent - itsender of the message. Some possible ways in which this authentication might be implementedperformed include: For requests, challenging the request with a pre-loaded Route header. The guidelines given407 response code using the Digest authentication scheme (or viewing a Proxy- Authentication header sent in RFC3261 Sections 18.104.22.168the request which was sent in anticipation of a challenge using cached credentials, as described in RFC 3261 Section 22.3) For requests and 22.214.171.124 should be used when connecting to anresponses that are sent over a persistent TLS connection, relying on some prior authentication service; ideally, anthat was performed at the formation of the connection (most likely, the authentication service should be one hop away from a user agent, it should usepreviously challenged a lower-layer security protocol such asREGISTER request sent after the TLS connection was formed, or IPSec to authenticatepossibly a prior challenged INVITE that was sent over the authentication service before providing credentials (especially shared secrets). This document places no requirements on how an authentication services authenticates requests. Since Digest authentication MUST be supported by all SIP entities,TLS connection) Authorization of the useassertion of Digest for this purposea particular username in the From header field of a SIP message is RECOMMENDEDa matter of local policy for compatibility withthe maximum set of user agents. 4. How to Share Verified Identities When an authenticationauthorization service has authenticatedwhich depends greatly on the user, it must construct an identity URI for that user that will be containedmanner in the token. Itwhich authentication is performed. A RECOMMENDED that these identities takepolicy is as follows: the formusername asserted during Digest authentication MUST correspond exactly to the username in the From header field of the SIP address-of-record URI (as opposed to contact addresses), as theymessage. However, there are definedmany cases in Section 10 of RFC3261;which a user might manage multiple accounts in other words, URIs ofthe form 'sip:firstname.lastname@example.org'. This identity must be expressed insame administrative domain. Accordingly, provided the authentication token that will be signedservice is aware of the relationships between these accounts, it might allow a user providing credentials for one account to assert a username associated with another account controlled by the authentication service. For example,user name. Furthermore, if the Authenticated Identity Body (AIB) format describedAoR asserted in the From header field is used,anonymous (per RFC3323), then for an INVITE this identity would be storedthe proxy should authenticate that the user is any valid user in the domain and insert the signature over the From header field within a 'message/sip' or 'message/sipfrag'  body that will be signed byas usual. Third, the authentication service. Onceservice MUST form the tokenidentity signature, as described in Section 10, and add an Identity header to the request containing this signature. After the Identity header has been created,added to the server MUST signrequest, the token.authentication service MUST also add an Identity- Info header. The subject of theIdentity-Info header contains a URI from which its certificate SHOULDcan be assignedacquired. Details are provided in one ofsection Section 10. Finally, the two following ways: Anauthentication service MAY use a common certificate, suchMUST forward the message normally. 7.1 UAs acting as an Authentication service There are some instances in which a site certificate,user agent may hold the private key of the domain Certificate for its administrative domain. The subjectAltNameaddress-of-record. In these cases, the UA MAY perform the services, and add the headers, that the authentication service would normally add. 8. Verifying Identity When a user agent or proxy server receives a SIP message containing an Identity header, it can inspect the signature to verify the identity of this certificatethe sender of the message. If an Identity header is not present in a request, and one is required by local policy, then a 428 Use Identity response is sent. If an Identity header is not present in a response, and one is required by local policy, then the recipient of the response MUST correspond withcommunicate this lapse to its user, and MAY immediately terminate any created dialog or ignore transactions, as policy dictates. In order to verify the host portionidentity of the From header fieldsender of a message, the identity in the authentication token (if the identity were 'sip:email@example.com', the subjectAltName ofuser agent or proxy server MUST first acquire the certificate would be 'atlanta.com');for the signing domain. Implementations supporting this specification should be the same certificate that the authentication service provides when proving its own identity (via TLS orhave some similar protocol). An authentication service MAY hold a certificate corresponding to each user in its administrativemeans of retaining domain certificates (in other words, aaccordance with normal practices for certificate whose subjectAltName contains a URI equivalentlifetimes and revocation) in order to prevent themselves from needlessly downloading the address-of-record URI ofsame certificate every time a request from the user). Insame domain is received. Certificates retained in this case,manner should be indexed by the appropriate certificate forURI given in the authenticated user will beIdentity-Info header field value. Provided that the domain certificate used to sign the authentication token. Maintaining individual certificates for each userthis message is RECOMMENDED, since the name subordination rules involved with the use of a commonunknown, SIP entities discover this certificate for the domain can become complicated. After the authentication token has been signed, the authentication token MUST somehow be integrated with any existing MIME bodies in the request, if necessaryby transitioningdereferencing the outermost MIME body to a 'multipart/mixed' format, beforeIdentity-Info header. The client processes this certificate in the request can be forwarded. Three options are considered forusual ways including checking that it has not expired, that an authentication token could be added to a SIP message: one in which the authentication service pushesthe tokenchain is valid back to a trusted CA, and that it does not appear on revocation lists. Subsequently, the client for resubmission, one in whichrecipient MUST verify the authentication service addssignature in the token itself,Identity header, and one in whichcompare the client anticipates a URI at whichidentity of the authentication service will makesigner (the subjectAltName of the token available. Authentication services MUST supportcertificate) with the domain portion of the URI in the mechanismFrom header field of the request as described in Section 4.1 and MAY support11. Additionally, the mechanismDate, Contact and Call-ID headers MUST be analyzed in Section 4.2;the mechanismmanner described in Section 4.3 is included11; recipients that wish to illustrate a future direction. 4.1 Body Added by Client In this case, the authentication service returnsverify Identity signatures MUST support all of the authentication tokenoperations described there. Any discrepancies or violations MUST be reported to the originating user agent, promptinguser. When the originating user agent to retry theof a request with the authentication token attached. No existing SIP mechanism can perform this function. Therefore, this document definesreceives a 428 "Use Authentication Token"response code. After a user has been authenticated (in the Digest example, with the 407 response)containing an authentication service sends a 428 with a MIME bodyAuthenticated Identity Body (AIB, see ), it SHOULD compare the identity in order to request that a user agent addthe enclosed MIME body to their request and retryFrom header field of the request. A 428 MUST have at most a single MIME body. This MIME body MUST be signed byAIB of the authentication service. The useresponse with the original value of 428 without any MIME body is also definedthe To header field in this document. It can be sent by any server to reject a request becausethe request does not contain an authentication token. Arequest. If these represent different identities, the user agent receiving this rejectionSHOULD retry their request through the same server after acquiring a token from an authentication service. In order to signal to the authentication services and other intermediaries thatrender the originating user agent supportsidentity in the receiptAIB of the 428response code,to its user. Note that a new option-tag has been defined, the 'auth-id' option-tag. User agents SHOULD supply the 'auth-id' option-tagdiscrepancy in these identity fields is not necessary an indication of a security breach; normal retargeting may simply have directed the request to a Supported header whenever they provide credentialsdifferent final destination. Implementers therefore may consider it unnecessary to alert the user of a server (for example,security violation in Digest authentication, wheneverthis case. 9. Proxy Server Behavior In most respects, a Proxy- Authorization header is added toproxy server behaves normally when it receives a request). Using the 428SIP request or response code may introduce extra round-trip times for messages, delaying the setup of requests.containing an Identity header. This mechanism is fully backwards-compatible with existing RFC3261 proxy behavior. However, there are some circumstances under which extra RTTs may not impede performance. If the originating user agent possessesif a non-stale nonce (assuming Digest authentication) from theproxy intends to act as an authentication service,service for responses to requests it can pre- emptively includereceives, it must exhibit some additional behavior to ensure that retargeting requests are handled properly. Essentially, a Proxy-Authorization header, eliminating one RTT (the one resulting fromproxy server MUST NOT provide an Identity header for a 407). With regardrequest that it retargets to a different administrative domain. It is the second RTT, noteresponsibility of that administrative domain to provide its own identity assertion, if it can. However, proxying the request needn't necessarily go through the authentication service again once the authentication token has been added - it could go directlyto a remote domain where identity services may be provided has its destination, which reduceown problems - the impactoriginator of the second RTT. There are two good reasonsrequest has no way to think thatknow whether the originating user agent should berequest was legitimately retargeted, or if any responses it receives from the party responsiblenew domain are spoofed or otherwise illegitimate. It is thus much more secure for addingthe authentication tokenproxy server to the request. Firstly, because this gives the client the opportunityredirect in cases where it might otherwise retarget. If a proxy server intends to inspect the body itself (perhaps onlyact as an authentication service for a response to see whether or nota SIP request that it is encrypted; see ) in order to verify thatforwarding, it MUST do ALL of the following: Ascertain if it is responsible for the authenticated identity corresponds withdomain indicated in the provided credentials andRequest-URI field of the user's preferences. Secondly,request. If not, it MUST forward the client can provide a signature overrequest normally. If so, it must then: Determine the entire bodyroute set of targets to which this request might be forwarded. From that target list, the message (eitherproxy must determine which contact addresses are associated with S/MIME or some header-based mechanism) sopersistent TLS connections that have been established to the final recipient of messages can be assured thatproxy server. It places all information insuch targets (if any) into a primary route set for the body is there atcall, and places remaining targets into a secondary route set for the originator's behest. 4.2 Body Added by Authentication Service Another possibility is thatcall. It performs this operations irrespective of any qvalues associated with the authentication service could addcontact addresses. The proxy then MUST follow normal administrative policies for forwarding the bodyrequest to any targets in the request itself before forwardingprimary route set (which may involve qvalue calculations or any other behaviors described in RFC3261). Before the request. However,proxy forwards any responses to this request upstream, the authentication service role is usually played by entities thatproxy server MUST act as proxy servers for most requests, and proxy servers cannot modify message bodies (see RFC3261 Section 16.6). In order to addan authentication token, the authenticationservice needs to act as a transparent back-to-back user agent, effectively terminating the request(as described in Section 7), adding an Identity and re-originating it with a new body appended to any existing MIME bodies (again, transposing to various MIME multipart forms as necessary). This mechanism has some potential advantages over pushingIdentity-Info header. If there are no appropriate responses from the authentication token back toprimary route set for the originating user agent. For one,proxy server to forward upstream, it saves one additional round-trip time that would be used by the 428 response. It also requires no new SIP mechanisms, whereas the 428 response necessitates option-tag support. However, there are proposed SIP integrity mechanisms that place a signature overmoves on to the entire message body in a SIP message header. Were asecondary route set (essentially, the proxy server forks sequentially, exploring the primary route set as one cluster, and then moves on to modifythe body of a message that was protected by such signature, that would be perceivedsecondary set). The proxy server is unable to act as an integrity violation by downstream recipients ofauthentication service for those contact addresses. Accordingly, the message. Presumably,proxy server MUST NOT explore these route targets itself; instead, it MUST redirect the request with a back-to-back user agent function would have3xx class response containing the contact addresses that constitute the secondary route set. In order to sacrifice this end-to-end integrity. The notionbuild the primary route set for the call, the location service associated with the domain of the proxy server MUST implement additional intelligence to determine which contact addresses are associated with a transparent back-to-back user agentpersistent TLS connection - this is also ill-defined,used to determine when the server should act as a proxy and when it is questionable if any SIP intermediariesshould interfere with SIP message bodies. 4.3 Using Content Indirection Work is currently underway inredirect. When the SIP WG to define a content indirection  mechanism for SIP, a mechanism by which a MIME body inregistrar receives a SIPREGISTER request can refer, with a URL, toover a document thatpersistent TLS connection, it hosted somewhereMUST compare any contact addresses appearing in Contact header fields to the network. This raises another interesting possibility for authentication token transporttopmost Via header field in SIP. A SIP user agent could create a content indirection MIME body (usingthe RFC2017  URL MIME External-Body Access-Type) that contains a URL that identities a resource controlled byREGISTER request. If the authentication service, anticipating thathost portion of a contact address matches the authentication service will makehostname given in the authentication token available attopmost Via header field, then that URL. This URL couldcontact address is said to be pushed by"associated" with the authentication service topersistent TLS connection over which the UACREGISTER was received. Location services must mark or flag these contact addresses accordingly, and remember the identity that the user provided when they were authenticated during registration. Only these contact addresses are added to the authentication service challenges the UAC (asprimary route set by a new header in the 407 response). Onceproxy server that wishes to act as an authentication service has validatedfor responses. Additionally, domain policy may require proxy servers to inspect and verify the request, it simply makesidentity provided in SIP requests. The proxy server may wish to ascertain the authentication token available atidentity of the anticipated URL; recipientssender of the message would then dereferenceto provide spam prevention or call control services. Even if a proxy server does not act as an authentication service, it MAY verify the URLsignature present in order to inspectan Identity header before it makes a forwarding decision for a request. Proxy servers MUST NOT remove or modify the token.Identity or Identity-Info headers. 10. Header Syntax This approach could allow user agents to have full control over the integritydocument specifies two new SIP headers: Identity and Identity- Info. Each of these headers can appear only once in a SIP requests, while still requiring the extra RTT caused bymessage. Identity = "Identity" HCOLON signed-identity-digest signed-identity-digest = LDQUOT 32LHEX RDQUOT Identity-Info = "Identity-Info" HCOLON ident-info Ident-info = LAQUOT absoluteURI RAQUOT To create the usecontents of the 428 response code. It also has numerous advantages over other wayssigned-identity-digest, the following elements of handling authentication tokens issued fora SIP response messages (see Section 5). 5. Identitymessage MUST placed in Responses Many ofthe practices describedstring in the preceding sections can be applied to responses as well as requests, with some important differences. Primarily, the distinction is thatorder specified here, separated by a response cannot be challengedcolon: The AoR of the UA sending the message, or resubmitted inthe same manner as'identity field'. For a request, and therefore the mechanism in Section 4.1 is not usable. However, when a user agent registers under a particular identity, and thereby becomes eligible to receive requests and send responses associated with that identity, it provides credentials that prove its identity, and thus if the registrarthis is co-located withthe proxy that receives requestsaddr-spec from the From header field; for responses, the user's administrative domain, isaddr-spec of the To header field. This needs to be in a reasonable positionlower case and to actbe represented as an authentication servicea SIP URI. The callid from Call-Id header field. The Date header field, with exactly one space each for responses. Note thateach SP and the identityweekday and month items case set as shown in an authentication tokenBNF in a response almost certainly will not correspond with3261. The first letter is upper case and the identity asserted inrest of the Fromletters are lower case. The addr-spec component of the Contact header field value. The body content of the response (which is copied from the request);message with the identitybits exactly as they are in the authentication token represents a different entity.message. For many requests, the identity inmore information on the authentication tokensecurity properties of a response will correspond tothese headers, and why their inclusion mitigates replay attacks, see . The precise formulation of this digest-string is, therefore: digest-string = addr-spec HCOLON callid HCOLON SIP-Date HCOLON addr-spec HCOLON message-body Note again that the Tofirst addr-spec MUST be taken from the From header field ofvalue, and the request, but there are numerous legitimate ways that requests can be retargeted in which this will notsecond addr-spec from the Contact header field value. After the digest-string is formed, it MUST be hashed and signed with the case. An authentication service that also actscertificate for the domain, as a registrar and inbound proxy can add to a response an authentication token that corresponds tofollows: compute the identityresults of signing this string with sha1WithRSAEncryption as described in RFC 3370 and base64 encode the originator of that responseresults as specified in roughlyRFC 3548. Put the same manner describedresult in Section 4.2 -the authentication service addsIdentity header. Note on this choice: Assuming a 1024 bit RSA key, the authentication token toraw signature will result in about 170 octets of base64 encoded data. For comparison's sake, a typical HTTP Digest Authorization header (such as those used in RFC3261) with no cnonce is around 180 octets. From a speed point of view, a 2.8GHz Intel processor does somewhere in the range of 250 RSA 1024 bits signs per second or 1200 RSA 512 bits signs; verifies are roughly 10 times faster. Hardware accelerator cards are available that speed this up. The Identity-Info header MUST contain either an HTTPS URI or a response beforeSIPS URI. If it forwardscontains an HTTPS URI, the response towardsURI must dereference to a resource that contains a single MIME body containing the originatorcertificate of the request. Thereauthentication service. If it is no way for ana SIPS URI, then the authentication service to perform a functionintends for responses comparablea user agent that wishes to fetch the mechanism described in Section 4.1; however, content indirection (see Section 4.3 could provide an alternativecertificate to form a TLS connection to that would allowURI, acquire the clientcertificate during normal TLS negotiation, and close the connection. This document adds the following entries to retain end-to-end integrity properties on responses. 6. Receiving an Authentication Token The manner inTable 2 of : Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- Identity a - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - - Identity-Info a - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - - 11. Security Considerations This document describes a mechanism which an authentication token is handled is dependent onprovides a signature over the natureContact, Date, Call-ID, and 'identity fields' (addr-spec of the token itself; rulesFrom header field for handling the Authenticated Identity Body (AIB) format are given . 6.1 Authentication Service Handlingrequests, and To header field for responses) of Authentication TokensSIP intermediaries generally should not attempt to inspect MIME bodies; followingmessages. While a signature over the rules of RFC3261 Section 16.6, MIME bodies mayidentity field alone would be encrypted end-to-end or have other properties thatsufficient to secure a URI alone, the additional headers provide replay protection and reference integrity necessary to make them unsuitable for consumption by intermediaries. However, intermediariessure that implementthe authentication service logical role MAY inspect MIME bodiesIdentity header will not be used in ordercut-and-paste attacks. In general, the considerations related to find one with a Content- Dispositionthe security of 'auth-id'. Forthese headers are the most part,same as those given in RFC3261 for including headers in tunneled 'message/sip' MIME bodies (see Section 23 in particular). The identity field indicates the actual value of an authenticatedidentity is not likely to beof interest to a proxy server, though it MAY refuse to process a request that does not contain a valid authentication token (usingthe 428 request,sender of the message. The Date and Contact headers provide reference integrity and replay protection, as described in RFC3261 Section 4.1). However, authentication services MAY additionally maintain lists23.4.2. Implementations of known problem usersthis specification MUST NOT consider valid a request with an outdated Date header field (the RECOMMENDED interval is that are banned from making requests to their administrative domain, for example, and subsequently reject some requests after comparing their authenticated identities to such access control lists. 7. Selective Sharing of Identity Most ofthe time, there is no need to restrictDate header must indicate a time within 3600 seconds of the propagationreceipt of verified identitiesa message). Implementations MUST also record Call-IDs received in the network. User agentsvalid requests containing an Identity header, and intermediaries benefit from receiving verified identities. However, in some cases intermediaries might want to restrictMUST remember those Call-IDs for at least the distributionduration of identity information, for examplea single Date interval (i.e. 3600 seconds). Accordingly, if o the authenticated identity body containsan identity thatIdentity header is only meaningful as an internal identifierreplayed within a particular service provider's network, or, o the originating user agent has requested privacy, andthe unrestricted distribution of the authenticated identity body would violateDate interval, receivers will recognize that request. Ifit is not appropriate to share an authenticated identityinvalid because of a user has requested privacy,Call-ID duplication; if an authenticated identity body SHOULD NOT be created and distributed. However, in some cases there may be other entities in the administrative domain ofIdentity header is replayed after the authentication serviceDate interval, receivers will recognize that are consumers of the authenticated identity. If, for example, each of these servers needed to challenge the user individually for identity,it might significantly delay the processing ofis invalid because the request. For that reason, it may be appropriateDate is stale. The Contact header field is included to circulate authenticated identity bodies among a controlled set of entities. Fortie the Identity header to a particular device instance that purpose,generated the request. Were an encryption mechanism for authenticated identities is required. 7.1 Requesting Privacy When users authenticate themselvesactive attacker to intercept a request containing an authentication service, they MAY explicitly notifyIdentity header, and cut-and-paste the serviceIdentity header field into their own request (reusing the identity fields, Contact, Date and Call-ID fields that appear in the original message), they dowould not wish their authenticated identity tobe circulated. Usually,eligible to receive SIP requests from the called user in question would also be taking other stepsagent, since those requests are routed to preserve their privacy (perhaps by including an anonymous From header inthe SIP request, and following other standard privacy practices). Authentication services MUST supportURI identified in the privacyContact header field. This mechanism described in RFC3323 . Users requesting privacy shouldalso supportprovides a signature over the mechanisms describedbodies of SIP requests. The most important reason for doing so is to protect SDP bodies carried in that document. In particular, this document uses an identity-specific priv-value that can appearSIP requests. There is little purpose in establishing the Privacy header, a valueidentity of 'id', which was registered by RFC3325 . This Privacy value requeststhe user agent that provided the results of authentication should not be shared bysignaling if a man-in-the-middle can change the authenticating intermediary. An authentication service SHOULD NOT createSDP and direct media to an alternate address. Note however that this is not perfect end- to-end security. The authentication tokenservice itself, when instantiated at a intermediary, can change the SDP (and SIP headers, for that matter) before providing a request when 'id' privacy has been requested. If suchsignature. Thus, while this mechanism reduces the chance that a token is created,man-in-the-middle will interfere with sessions, it MUST be encrypted or rendered confidential indoes not eliminate it entirely. Since it is assumed that the manner most appropriateuser trusts their local domain to the token. Guidelinesvouch for encrypting AIBs are given in , and these mechanisms MUST be supported by any authenticationtheir security, they must also trust the service that uses AIBs. 8. Security Considerationsnot to violate the integrity of their message bodies without good reason. Users SHOULD NOT provide credentials to an authentication service to which they cannot initiate a direct connection, preferably one secured by a network or transport layer security protocol such asTLS. If a user does not receive a certificate from the authentication service over this lower-layer protocolTLS that corresponds to the expected domain (especially when they receive a challenge via a mechanism such as Digest), then it is possible that a rogue server is attempting to pose as a authentication service for a domain that it does not control, possibly in an attempt to collect shared secrets for that domain. If a user cannot connect directly to the desired authentication service, the user SHOULD at least use a SIPS URI to ensure that mutual TLS authentication will be used to reach the remote server. Relying on an authentication tokenIdentity header generated by a remote administrative domain assumes that the issuing domain uses some trustworthy practice to authenticate its users. However, it is possible that some domains will implement policies that effectively make users unaccountable (such as accepting unauthenticated registrations from arbitrary users). Therefore, it is RECOMMENDED that authentication tokens contain some indication of the specific practice (for example, Digest) that was used to authenticate this request as a rough indicator of credential strength. No mannerThe value of describing authentication practicesan Identity header for such domains is specified in this document. Ifquestionable. Since a commondomain certificate is used by an authentication service (rather than individual certificates for each identity), certain problems can arise with name subordination. For example, if an authentication service holds a common certificate for the hostname 'sip.atlanta.com', can it legitimately sign a token containing an identity of 'sip:firstname.lastname@example.org'? It is difficult for the recipient of a request to ascertain whether or not 'sip.atlanta.com' is authoritative for the 'atlanta.com' domain unless the recipient has some foreknowledge of the administration of 'atlanta.com'. Therefore, it is RECOMMENDRECOMMENDED that user agent recipients of authentication tokens notify end users if there is ANY discrepancy between the subjectAltName of the signers certificate and the identity within the authentication token. Authentication tokens MUST have some form of replay protection. The best protection is to copyMinor discrepancies MAY be characterized as such. Additionally, relying parties MAY follow the SIP requestprocedures in its entirety (viaRFC3264 to look up on the 'message/sip' MIME type) intodomain portion of the authentication token -identity in that way, it will be clear that this token has been issuedthe From header field in the DNS, and compare the SIP services listed for this request, since collectivelythat domain with the headerssubjectAltName of a SIP request provide a unique identifier. However, SIP requeststhe certificate; this can be large, and it is reasonable to include onlygive the relying party a subsetbetter sense of the canonical SIP headers in a request (using the 'message/sipfrag' MIME type) as long as certain critical headers are provided. For further discussion of this issue, including guidelinesservices for including particular headers in a sipfrag, see .that domain. Because the commondomain certificates that can be used by authentication services need to assert only the hostname of the authentication service, existing certificate authorities can provide adequate certificates for this mechanism. However, not all proxy servers and user agents will be able support the root certificates of all certificate authorities, and moreover there are some significant differences in the policies by which certificate authorities issue their certificates. This document makes no recommendations for the usage of particular certificate authorities, nor does it describe any particular policies that certificate authorities should follow, but it is anticipated that operational experience will create de facto standards for the purposes of authentication services. Some federations of service providers, for example, might only trust certificates that have been provided by a certificate authority operated by the federation. 9.12. IANA Considerations This document specifies two new SIP headers: Identity and Identity- Info. Their syntax is given in Section 10. This document requests that IANA add these headers to the SIP header registry. This document also defines a new SIP statusresponse code, '428 Use Authentication Token'. The use of this status code is further428 "Use Identity", as described in Section 4.1.8. Normative References  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997.  Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.  Peterson, J., "SIP Authenticated Identity Body (AIB) Format", draft-ietf-sip-authid-body-01 (work in progress), October 2002. Informative References  Kohl, J. and C. Neumann, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.  Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.  Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.  Olson, S., "A Mechanism for Content Indirection in SIP Messages", draft-ietf-sip-content-indirect-mech-01 (work in progress), August 2002.  Freed, N., "Definition of the URL MIME External-Body Access- Type", RFC 2017, November 1996. Author's AddressAuthors' Addresses Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: email@example.com URI: http://www.neustar.biz/ Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 902-3341 EMail: firstname.lastname@example.org Appendix A. Acknowledgments The authors would like to thank Eric Rescorla, Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for their comments. Cullen Jennings assisted greatly in the development of the content indirection mechanism considered in Section 4.3.Appendix B. Changelog Changes from draft-ietf-sip-identity-01: - Completely changed underlying mechanism - instead of using an AIB, the mechanism now recommends the use of the Identity header and Identity-Info header - Numerous other changes resulting from the above - Various other editorial corrections Changes from draft-peterson-sip-identity-01: - Split off child draft-ietf-sip-authid-body-00 for defining of the AIB - Clarified scope in introduction - Removed a lot of text that was redundant with RFC3261 (especially about authentication practices) - Added mention of content indirection mechanism for adding token to requests and responses - Improved Security Considerations (added piece about credential strength) Changes from draft-peterson-sip-identity-00: - Added a section on authenticated identities in responses - Removed hostname convention for authentication services - Added text about using 'message/sip' or 'message/sipfrag' in authenticated identity bodies, also RECOMMENDED a few more headers in sipfrags to increase reference integrity - Various other editorial corrections Full Copyright Statement Copyright (C) The Internet Society (2003).(2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.