RFC 8224
Authenticated Identity Management in the Session Initiation Protocol (SIP)
Internet Engineering Task Force (IETF) J. Peterson Request for Comments: 8224 NeuStar Obsoletes: 4474 C. Jennings Category: Standards Track Cisco ISSN: 2070-1721 E. Rescorla RTFM, Inc. C. Wendt Comcast February 2018 Authenticated Identity Management in the Session Initiation Protocol (SIP)Abstract
The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8224.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................3 2. Terminology .....................................................4 3. Architectural Overview ..........................................5 4. Identity Header Field Syntax ....................................7 4.1. PASSporT Construction ......................................8 4.1.1. Example Full and Compact Forms of PASSporT in Identity ........................................10 5. Example of Operations ..........................................11 5.1. Example Identity Header Construction ......................13 6. Signature Generation and Validation ............................14 6.1. Authentication Service Behavior ...........................14 6.1.1. Handling Repairable Errors .........................16 6.2. Verifier Behavior .........................................17 6.2.1. Authorization of Requests ..........................19 6.2.2. Failure Response Codes Sent by a Verification Service ...............................19 6.2.3. Handling Retried Requests ..........................21 6.2.4. Handling the Full Form of PASSporT .................21 7. Credentials ....................................................22 7.1. Credential Use by the Authentication Service ..............22 7.2. Credential Use by the Verification Service ................23 7.3. "info" Parameter URIs .....................................24 7.4. Credential System Requirements ............................25 8. Identity Types .................................................26 8.1. Differentiating Telephone Numbers from URIs ...............26 8.2. Authority for Telephone Numbers ...........................27 8.3. Telephone Number Canonicalization Procedures ..............28 8.4. Authority for Domain Names ................................29 8.5. URI Normalization .........................................30 9. Extensibility ..................................................31 10. Backwards Compatibility with RFC 4474 .........................32
11. Privacy Considerations ........................................32 12. Security Considerations .......................................34 12.1. Protected Request Fields .................................34 12.1.1. Protection of the To Header and Retargeting .......36 12.2. Unprotected Request Fields ...............................37 12.3. Malicious Removal of Identity Headers ....................37 12.4. Securing the Connection to the Authentication Service ....38 12.5. Authorization and Transitional Strategies ................39 12.6. Display-Names and Identity ...............................40 13. IANA Considerations ...........................................40 13.1. SIP Header Fields ........................................40 13.2. SIP Response Codes .......................................41 13.3. Identity-Info Parameters .................................41 13.4. Identity-Info Algorithm Parameter Values .................41 14. Changes from RFC 4474 .........................................41 15. References ....................................................42 15.1. Normative References .....................................42 15.2. Informative References ...................................43 Acknowledgments ...................................................46 Authors' Addresses ................................................461. Introduction
This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP) [RFC3261]. An identity, for the purposes of this document, is defined as either o a canonical address-of-record (AoR) SIP URI employed to reach a user (such as "sip:alice@atlanta.example.com") or o a telephone number, which commonly appears either in a tel URI [RFC3966] or as the user portion of a SIP URI. [RFC3261] specifies several places within a SIP request where users can express an identity for themselves, most prominently the user-populated From header field. However, in the absence of some sort of cryptographic authentication mechanism, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately. This leaves SIP vulnerable to a category of abuses such as impersonation attacks that facilitate or enable robocalling, voicemail hacking, swatting, and related problems as described in [RFC7340]. Ideally, a cryptographic approach to identity can provide a much stronger assurance of identity than the Caller ID services that the telephone network provides today, and one less vulnerable to spoofing.
[RFC3261] encourages user agents (UAs) to implement a number of potential authentication mechanisms, including Digest authentication, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes as well). However, few SIP UAs today support the end-user certificates necessary to authenticate themselves (via S/MIME, for example), and for its part Digest authentication is limited by the fact that the originator and destination must share a prearranged secret. Practically speaking, originating UAs need to be able to securely communicate their users' identities to destinations with which they have no previous association. As an initial attempt to address this gap, [RFC4474] specified a means of signing portions of SIP requests in order to provide an identity assurance. However, [RFC4474] was in several ways misaligned with deployment realities (see [SIP-RFC4474-CONCERNS]). Most significantly, [RFC4474] did not deal well with telephone numbers as identifiers, despite their enduring use in SIP deployments. [RFC4474] also provided a signature over material that intermediaries in existing deployments commonly altered. This specification therefore deprecates the syntax and behavior specified by [RFC4474], reconsidering the problem space in light of the threat model in [RFC7375] and aligning the signature format with PASSporT (Personal Assertion Token) [RFC8225]. Backwards-compatibility considerations are given in Section 10.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. In addition, this document uses three terms specific to the mechanism: o Identity: An identifier for the user of a communications service; for the purposes of SIP, either a SIP URI or a telephone number. Identities are derived from an "identity field" in a SIP request such as the From header field. o Authentication Service: A logical role played by a SIP entity that adds Identity headers to SIP requests. o Verification Service (or "Verifier"): A logical role played by a SIP entity that validates Identity headers in a SIP request.
3. Architectural Overview
The identity architecture for SIP defined in this specification depends on a logical "authentication service" that validates outgoing requests. An authentication service may be implemented either as part of a UA or as a proxy server; typically, it is a component of a network intermediary like a proxy to which originating UAs send unsigned requests. Once the originator of the message has been authenticated, through prearranged means with the authentication service, the authentication service then creates and adds an Identity header field to the request. This requires computing cryptographic information -- including a digital signature over some components of messages -- that lets other SIP entities verify that the sending user has been authenticated and its claim of a particular identity has been authorized. These "verification services" validate the signature and enable policy decisions to be made based on the results of the validation. Policy decisions made after validation depend heavily on the verification service's trust for the credentials that the authentication service uses to sign requests. As robocalling, voicemail hacking, and swatting usually involve impersonation of telephone numbers, credentials that will be trusted by relying parties to sign for telephone numbers are a key component of the architecture. Authority over telephone numbers is, however, not as easy to establish on the Internet as authority over traditional domain names. This document assumes the existence of credentials for establishing authority over telephone numbers for cases where the telephone number is the identity of the user, but does not mandate or specify a credential system; [RFC8226] describes a credential system compatible with this architecture. Although addressing the vulnerabilities in the Secure Telephone Identity Revisited (STIR) problem statement [RFC7340] and threat model mostly requires dealing with telephone number as identities, SIP must also handle signing for SIP URIs as identities. This is typically easier to deal with, as these identities are issued by organizations that have authority over Internet domains. When a new user becomes associated with example.com, for example, the administrator of the SIP service for that domain can issue them an identity in that namespace, such as sip:alice@example.com. Alice may then send REGISTER requests to example.com that make her UAs eligible to receive requests for sip:alice@example.com. In other cases, Alice may herself be the owner of her own domain and may issue herself identities as she chooses. But ultimately, it is the controller of the SIP service at example.com that must be responsible for authorizing the use of names in the example.com domain. Therefore, for the purposes of SIP as defined in [RFC3261], the necessary
credentials needed to prove that a user is authorized to use a particular From header field must ultimately derive from the domain owner: either (1) a UA gives requests to the domain name owner in order for them to be signed by the domain owner's credentials or (2) the UA must possess credentials that prove that the domain owner has given the UA the right to a name. In order to share a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context, an authentication service constructs tokens based on the PASSporT format [RFC8225], which is special encoding of a JSON [RFC8259] object comprising values derived from certain header field values in the SIP request. The authentication service computes a signature over those JSON elements as PASSporT specifies. An encoding of the resulting PASSporT is then placed in the SIP Identity header field. In order to assist in the validation of the Identity header field, this specification also describes a parameter of the Identity header field that can be used by the recipient of a request to recover the credentials of the signer. Note that the scope of this document is limited to providing an identity assurance for SIP requests; solving this problem for SIP responses is outside the scope of this work (see [RFC4916]). Future work might specify ways that a SIP implementation could gateway PASSporTs to other protocols.
4. Identity Header Field Syntax
The Identity and Identity-Info header fields that were previously defined in [RFC4474] are deprecated by this document. This revised specification collapses the grammar of Identity-Info into the Identity header field via the "info" parameter. Note that unlike the prior specification in [RFC4474], the Identity header field is now allowed to appear more than one time in a SIP request. The revised grammar for the Identity header field builds on the ABNF [RFC5234] in [RFC3261], Section 25. It is as follows: Identity = "Identity" HCOLON signed-identity-digest SEMI ident-info *( SEMI ident-info-params ) signed-identity-digest = 1*(base64-char / ".") ident-info = "info" EQUAL ident-info-uri ident-info-uri = LAQUOT absoluteURI RAQUOT ident-info-params = ident-info-alg / ident-type / ident-info-extension ident-info-alg = "alg" EQUAL token ident-type = "ppt" EQUAL token ident-info-extension = generic-param base64-char = ALPHA / DIGIT / "/" / "+" In addition to the "info" parameter, and the "alg" parameter previously defined in [RFC4474], this specification defines the optional "ppt" parameter (PASSporT Type). The "absoluteURI" portion of ident-info-uri MUST contain a URI; see Section 7.3 for more on choosing how to advertise credentials through this parameter. The signed-identity-digest contains a base64 encoding of a PASSporT [RFC8225], which secures the request with a signature that PASSporT generates over the JSON header and payload objects; some of those header and claim element values will mirror values of the SIP request.
4.1. PASSporT Construction
For SIP implementations to populate the PASSporT header JSON object with fields from a SIP request, the following elements MUST be placed as the values corresponding to the designated JSON keys: o First, per the baseline PASSporT specification [RFC8225], the JSON "typ" key MUST have the value "passport". o Second, the JSON key "alg" MUST mirror the value of the optional "alg" parameter in the SIP Identity header field. Note that if the "alg" parameter is absent from the Identity header, the default value is "ES256". o Third, the JSON key "x5u" MUST have a value equivalent to the quoted URI in the "info" parameter, per the simple string comparison rules of [RFC3986], Section 6.2.1. o Fourth, if a PASSporT extension is in use, then the optional JSON key "ppt" MUST be present and have a value equivalent to the quoted value of the "ppt" parameter of the Identity header field. An example of the PASSporT header JSON object without any extension is: { "typ":"passport", "alg":"ES256", "x5u":"https://www.example.com/cert.cer" } To populate the PASSporT payload JSON object from a SIP request, the following elements MUST be placed as values corresponding to the designated JSON keys: o First, the JSON "orig" object MUST be populated. If the originating identity is a telephone number, then the array MUST be populated with a JSON object containing a "tn" element with a value set to the value of the quoted originating identity, a canonicalized telephone number (see Section 8.3). Otherwise, the object MUST be populated with a JSON object containing a "uri" element, set to the value of the AoR of the UA sending the message as taken from the addr-spec of the From header field, per the procedures in Section 8.5. o Second, the JSON "dest" array MUST be populated. If the destination identity is a telephone number, then the array MUST be populated with a JSON object containing a "tn" element with a value set to the value of the quoted destination identity, a canonicalized telephone number (see Section 8.3). Otherwise, the
array MUST be populated with a JSON object containing a "uri"
element, set to the value of the addr-spec component of the
To header field, which is the AoR to which the request is being
sent, per the procedures in Section 8.5. Multiple JSON objects
are permitted in "dest" for future compatibility reasons.
o Third, the JSON key "iat" MUST appear. The authentication service
SHOULD set the value of "iat" to an encoding of the value of the
SIP Date header field as a JSON NumericDate (as UNIX time, per
[RFC7519], Section 2), though an authentication service MAY set
the value of "iat" to its own current clock time. If the
authentication service uses its own clock time, then the use of
the full form of PASSporT is REQUIRED. In either case, the
authentication service MUST NOT generate a PASSporT for a SIP
request if the Date header is outside of its local policy for
freshness (sixty seconds is RECOMMENDED).
o Fourth, if the request contains a Session Description Protocol
(SDP) message body and if that SDP contains one or more
"a=fingerprint" attributes, then the JSON key "mky" MUST appear
with the algorithm(s) and value(s) of the fingerprint attributes
(if they differ), following the format given in [RFC8225],
Section 5.2.2.
For example:
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]},
"iat":1443208345 }
For information on the security properties of these SIP message
elements and why their inclusion mitigates replay attacks, see
Section 12. Note that future extensions to PASSporT could introduce
new claims and that further SIP procedures could be required to
extract information from the SIP request to populate the values of
those claims; see Section 9 of this document.
The "orig" and "dest" arrays may contain identifiers of heterogeneous
type; for example, the "orig" array might contain a "tn" claim, while
the "dest" contains a "uri" claim. Also note that in some cases, the
"dest" array may be populated with more than one value. This could,
for example, occur when multiple "dest" identities are specified in a
meshed conference. Defining how a SIP implementation would align
multiple destination identities in PASSporT with such systems is left
as a subject for future specifications.
After these two JSON objects, the header and the payload, have been constructed and base64-encoded, they must each be hashed and signed per [RFC8225], Section 6. The header, payload, and signature components comprise a full PASSporT object. The resulting PASSporT may be carried in SIP in either (1) a full form, which includes the header and payload as well as the signature or (2) a compact form, which only carries the signature per [RFC8225], Section 7. The hashing and signing algorithm is specified by the "alg" parameter of the Identity header field and the mirrored "alg" parameter of PASSporT. All implementations of this specification MUST support the required signing algorithms of PASSporT. At present, there is one mandatory-to-support value for the "alg" parameter: "ES256", as defined in [RFC7519], which connotes an Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 digital signature.4.1.1. Example Full and Compact Forms of PASSporT in Identity
As Appendix F of the JSON Web Signature (JWS) specification [RFC7515] notes, there are cases where "it is useful to integrity-protect content that is not itself contained in a JWS." Since the fields that make up the majority of the PASSporT header and payload have values replicated in the SIP request, the SIP usage of PASSporT may exclude the base64-encoded version of the header and payload JSON objects from the Identity header field and instead present a detached signature: what PASSporT calls its compact form; see [RFC8225], Section 7. When an authentication service constructs an Identity header, the contents of the signed-identity-digest field MUST contain either a full or compact PASSporT. Use of the compact form is RECOMMENDED in order to reduce message size, but note that extensions often require the full form (see Section 9). For example, a full form of PASSporT in an Identity header might look as follows (backslashes shown for line folding only): Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \ kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \ /biloxi.cert>
The compact form of the same PASSporT object would appear in the Identity header as: Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \ pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \ info=<https://biloxi.example.org/biloxi.cert>5. Example of Operations
This section provides an informative (non-normative) high-level example of the operation of the mechanisms described in this document. Imagine a case where Bob, who has the home proxy of example.com and the AoR sip:12155551212@example.com;user=phone, wants to communicate with Alice at sip:alice@example.com. They have no prior relationship, and Alice implements best practices to prevent impersonation attacks. Bob's UA generates an INVITE and places his AoR in the From header field of the request. He then sends an INVITE to an authentication service proxy for his domain. ............................ .............................. . . . . . +-------+ . . +-------+ . . Signs for | | . Signed . | | . . 12125551xxx| Auth |------------> | Verif | . . | Svc | . INVITE . | Svc | . . | Proxy | . . | Proxy | . . > +-------+ . . +-------+ \ . . / | . -> \ . . / | . --. \ . . / | . -- . \ . . / | . -- . \ . . / +-------+. -- . \ . . / | |.<- . \ . . / | Cert |. . > . . +-------+ | Store |. . +-------+ . . | | | |. . | | . . | Bob | +-------+. . | Alice | . . | UA | . . | UA | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ ..............................
The proxy authenticates Bob and validates that he is authorized to assert the identity that he populated in the From header field. The proxy authentication service then constructs a PASSporT that contains a JSON representation of values that mirror certain parts of the SIP request, including the identity in the From header field value. As a part of generating the PASSporT, the authentication service signs a hash of that JSON header and payload with the private key associated with the appropriate credential for the identity (in this example, a certificate with authority to sign for numbers in a range from 12155551000 to 12155551999), and the signature is inserted by the proxy server into the Identity header field value of the request as a compact form of PASSporT. Alternatively, the JSON header and payload themselves might also have been included in the object when using the full form of PASSporT. The proxy authentication service, as the holder of a private key with authority over Bob's telephone number, is asserting that the originator of this request has been authenticated and that he is authorized to claim the identity that appears in the From header field. The proxy inserts an "info" parameter into the Identity header field that tells Alice how to acquire keying material necessary to validate its credentials (a public key), in case she doesn't already have it. When Alice's domain receives the request, a proxy verification service validates the signature provided in the Identity header field and then determines that the authentication service credentials demonstrate authority over the identity in the From header field. This same validation operation might be performed by a verification service in Alice's UA server (UAS). Ultimately, this valid request is rendered to Alice. If the validation were unsuccessful, some other treatment could be applied by the receiving domain or Alice's UA.
5.1. Example Identity Header Construction
For the following SIP request: INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Alice <sip:alice@example.com> From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774> Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2015 19:12:25 GMT Contact: <sip:12155551212@gateway.example.com> Content-Type: application/sdp Content-Length: ... v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 An authentication service will create a corresponding PASSporT object. The properly serialized PASSporT header and payload JSON objects would look as follows. For the header, the values chosen by the authentication service at "example.com" might read: {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/ passport.cer"} The serialized payload will derive values from the SIP request (the From, To, and Date header field values) as follows: {"dest":{"uri":["sip:alice@example.com"]},"iat":1443208345, "orig":{"tn":"12155551212"}} The authentication service would then generate the signature over the object, following the procedures in [RFC8225], Section 6. That signature would look as follows: rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ ojNCpTzO3QfPOlckGaS6hEck7w
An authentication service signing this request and using the compact
form of PASSporT would thus generate and add to the request an
Identity header field of the following form:
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://cert.example.org/passport.cer>
(page 14 continued on part 2)
