Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8224

Authenticated Identity Management in the Session Initiation Protocol (SIP)

Pages: 46
Proposed Standard
Errata
Obsoletes:  4474
Updated by:  8946
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC8224 - Page 1
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.
Top   ToC   RFC8224 - Page 2
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
Top   ToC   RFC8224 - Page 3
   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 ................................................46

1. 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.
Top   ToC   RFC8224 - Page 4
   [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.
Top   ToC   RFC8224 - Page 5

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
Top   ToC   RFC8224 - Page 6
   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.
Top   ToC   RFC8224 - Page 7

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.
Top   ToC   RFC8224 - Page 8

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
Top   ToC   RFC8224 - Page 9
      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.
Top   ToC   RFC8224 - Page 10
   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>
Top   ToC   RFC8224 - Page 11
   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 . ............................ ..............................
Top   ToC   RFC8224 - Page 12
   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.
Top   ToC   RFC8224 - Page 13

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
Top   ToC   RFC8224 - Page 14
   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)

Next Section