Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
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 3 of 3 – Pages 32 to 46
First   Prev   None

Top   ToC   RFC8224 - Page 32   prevText

10. Backwards Compatibility with RFC 4474

This specification introduces several significant changes from the version of the Identity header field defined by [RFC4474]. However, due to the problems enumerated in [SIP-RFC4474-CONCERNS], it is not believed that the original Identity header field has seen any deployment, or even implementation in deployed products. As such, this mechanism contains no provisions for signatures generated with this specification to work with implementations compliant with [RFC4474], nor does it contain any related backwards- compatibility provisions. Hypothetically, were an implementation compliant with [RFC4474] to receive messages containing this revised version of the Identity header field, it would likely fail the request with a 436 response code due to the absence of an Identity-Info header field (Section 4). Implementations of this specification, for debugging purposes, might interpret a 436 with a reason phrase of "Bad Identity Info" (previously "Bad Identity-Info"; see Section 13.2) as an indication that the request has failed because it reached a (hypothetical) verification service that is compliant with [RFC4474].

11. Privacy Considerations

The purpose of this mechanism is to provide a reliable identification of the originator of a SIP request, specifically a cryptographic assurance that an authority asserts the originator can claim the URI the identity stipulated in the request. This URI may contain or imply a variety of personally identifying information, including the name of a human being, their place of work or service provider, and, possibly, further details. The intrinsic privacy risks associated with that URI are, however, no different from those of baseline SIP. Per the guidance in [RFC6973], implementers should make users aware of the privacy trade-off of providing secure identity. The identity mechanism presented in this document is compatible with the standard SIP practices for privacy described in [RFC3323]. A SIP proxy server can act as both a privacy service as described in [RFC3323] and an authentication service. Since a UA can provide any From header field value that the authentication service is willing to authorize, there is no reason why private SIP URIs that contain legitimate domains (e.g., sip:anonymous@example.com) cannot be signed by an authentication service. The construction of the Identity header field is the same for private URIs as it is for any other sort of URIs. Similar practices could be used to support opportunistic signing of SIP requests for UA-integrated authentication services with self-signed certificates, though that is outside the scope of this specification and is left as a matter for future investigation.
Top   ToC   RFC8224 - Page 33
   Note, however, that even when using anonymous SIP URIs, an
   authentication service must possess a certificate corresponding to
   the host portion of the addr-spec of the From header field value of
   the request; accordingly, using domains like "anonymous.invalid"
   will not be usable by privacy services that simultaneously act as
   authentication services.  The assurance offered by the usage of
   anonymous URIs with a valid domain portion is "this is a known user
   in my domain that I have authenticated, but I am keeping its identity
   private."

   It is worth noting two features of this more anonymous form of
   identity.  One can eliminate any identifying information in a domain
   through the use of the domain "anonymous.invalid", but we must then
   acknowledge that it is difficult for a domain to be both anonymous
   and authenticated.  The use of the domain "anonymous.invalid" entails
   that no corresponding authority for the domain can exist, and as a
   consequence, authentication service functions for that domain are
   meaningless.  The second feature is more germane to the threats this
   document mitigates [RFC7375].  None of the relevant attacks, all of
   which rely on the attacker taking on the identity of a victim or
   hiding their identity using someone else's identity, are enabled by
   an anonymous identity.  As such, the inability to assert an authority
   over an anonymous domain is irrelevant to our threat model.

   [RFC3325] defines the "id" priv-value token, which is specific to the
   P-Asserted-Identity header field.  The sort of assertion provided by
   the P-Asserted-Identity header field is very different from the
   Identity header field presented in this document.  It contains
   additional information about the originator of a message that may go
   beyond what appears in the From header field; P-Asserted-Identity
   holds a definitive identity for the originator that is somehow known
   to a closed network of intermediaries.  Presumably, that network will
   use this identity for billing or security purposes.  The danger of
   this network-specific information leaking outside of the closed
   network motivated the "id" priv-value token.  The "id" priv-value
   token has no implications for the Identity header field, and privacy
   services MUST NOT remove the Identity header field when a priv-value
   of "id" appears in a Privacy header field.

   The full form of the PASSporT object provides the complete JSON
   objects used to generate the signed-identity-digest of the Identity
   header field value, including the canonicalized form of the telephone
   number of the originator of a call if the signature is over a
   telephone number.  In some contexts, local policy may require a
   canonicalization that differs substantially from the original From
   header field.  Depending on those policies, potentially the full form
   of PASSporT might divulge information about the originating network
   or user that might not appear elsewhere in the SIP request.  Were it
Top   ToC   RFC8224 - Page 34
   to be used to reflect the contents of the P-Asserted-Identity header
   field, for example, then the object would need to be converted to the
   compact form when the P-Asserted-Identity header is removed to avoid
   any such leakage outside of a trust domain.  Since, in those
   contexts, the canonical form of the originator's identity could not
   be reassembled by a verifier and thus the Identity signature
   validation process would fail, using P-Asserted-Identity with the
   full form of PASSporT in this fashion is NOT RECOMMENDED outside of
   environments where SIP requests will never leave the trust domain.
   As a side note, history shows that closed networks never stay closed
   and one should design their implementation assuming connectivity to
   the broader Internet.

   Finally, note that unlike [RFC3325], the mechanism described in this
   specification adds no information to SIP requests that has privacy
   implications -- apart from disclosing that an authentication service
   is willing to sign for an originator.

12. Security Considerations

This document describes a mechanism that provides a signature over the Date header field of SIP requests, parts of the To and From header fields, and (when present) any media keying material in the message body. In general, the considerations related to the security of these header fields are the same as those given in [RFC3261] for including header fields in tunneled "message/sip" MIME bodies (see Section 23 of [RFC3261] in particular). This section details the individual security properties obtained by including each of these header fields within the signature; collectively, this set of header fields provides the necessary properties to prevent impersonation. It addresses the solution-specific attacks against in-band solutions enumerated in [RFC7375], Section 4.1.

12.1. Protected Request Fields

The From header field value (in ordinary operations) indicates the identity of the originator of the message; for the purposes of this document, either the SIP AoR URI or an embedded telephone number provides the identity of a SIP user. Note that in some deployments the identity of the originator may reside in P-Asserted-Identity instead. The originator's identity is the key piece of information that this mechanism secures; the remainder of the signed parts of a SIP request are present to provide reference integrity and to prevent certain types of cut-and-paste attacks. The Date header field value protects against cut-and-paste attacks, as described in [RFC3261], Section 23.4.2. That specification recommends that implementations notify the user of a potential
Top   ToC   RFC8224 - Page 35
   security issue if the signed Date header field value is stale by an
   hour or more.  To prevent cut-and-paste of recently observed
   messages, this specification instead RECOMMENDS a shorter interval of
   sixty seconds.  Implementations of this specification MUST NOT deem
   valid a request with an outdated Date header field.  Note that per
   the behavior described in [RFC3893], Section 10, servers can keep
   state of recently received requests, and thus if an Identity header
   field is replayed by an attacker within the Date interval, verifiers
   can detect that it is spoofed because a message with an identical
   Date from the same source had recently been received.

   It has been observed in the wild that some networks change the Date
   header field value of SIP requests in transit; to accommodate that
   type of scenario, alternative behavior might be necessary.
   Verification services that observe a signature validation failure MAY
   therefore reconstruct the Date header field component of the
   signature from the "iat" carried in the full form of PASSporT:
   provided that time recorded by "iat" falls within the local policy
   for freshness that would ordinarily apply to the Date header, the
   verification service MAY treat the signature as valid, provided it
   keeps adequate state to detect recent replays.  Note that this will
   require the inclusion of the full form of the PASSporT object by
   authentication services in networks where such failures are observed.

   The To header field value provides the identity of the SIP user that
   this request originally targeted.  Covering the identity in the To
   header field with the Identity signature serves two purposes.  First,
   it prevents cut-and-paste attacks in which an Identity header field
   from a legitimate request for one user is cut-and-pasted into a
   request for a different user.  Second, it preserves the starting URI
   scheme of the request; this helps prevent downgrade attacks against
   the use of SIPS.  The To identity offers additional protection
   against cut-and-paste attacks beyond the Date header field.  For
   example, without a signature over the To identity, an attacker who
   receives a call from a target could immediately cut-and-paste the
   Identity and From header field value from that INVITE into a new
   request to the target's voicemail service within the Date interval,
   and the voicemail service would have no way of knowing that the
   Identity header field it received had been originally signed for a
   call intended for a different number.  However, note the caveats
   below in Section 12.1.1.

   When signing a request that contains a fingerprint of keying material
   in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a
   signature over that fingerprint.  This signature prevents certain
   classes of impersonation attacks in which an attacker forwards or
   cut-and-pastes a legitimate request.  Although the target of the
   attack may accept the request, the attacker will be unable to
Top   ToC   RFC8224 - Page 36
   exchange media with the target, as they will not possess a key
   corresponding to the fingerprint.  For example, there are some
   baiting attacks, launched with the REFER method or through social
   engineering, where the attacker receives a request from the target
   and reoriginates it to a third party.  These might not be prevented
   by only a signature over the From, To, and Date, but they could be
   prevented by securing a fingerprint for DTLS-SRTP.  While this is a
   different form of impersonation than is commonly used for
   robocalling, ultimately there is little purpose in establishing the
   identity of the user that originated a SIP request if this assurance
   is not coupled with a comparable assurance over the contents of the
   subsequent media communication.  This signature also reduces the
   potential for active eavesdropping attacks against the SIP media.  In
   environments where DTLS-SRTP is unsupported, however, no field is
   signed and no protections are provided.

12.1.1. Protection of the To Header and Retargeting

Armed with the original value of the To header field, the recipient of a request may be tempted to compare it to their own identity in order to determine whether or not the identity information in this call might have been replayed. However, any request may be legitimately retargeted as well, and as a result legitimate requests may reach a SIP endpoint whose user is not identified by the URI designated in the To header field value. It is therefore difficult for any verifier to decide whether or not some prior retargeting was "legitimate". Retargeting can also cause confusion when identity information is provided for requests sent in the backwards direction in a dialog, as the dialog identifiers may not match credentials held by the ultimate target of the dialog. For further information on the problems of response identity, see [SIP-RETARGET]. Any means for authentication services or verifiers to anticipate retargeting is outside the scope of this document and is likely to have the same applicability to response identity as it does to requests in the backwards direction within a dialog. Consequently, no special guidance is given for implementers here regarding the "connected party" problem (see [RFC4916]); authentication service behavior is unchanged if retargeting has occurred for a dialog- forming request. Ultimately, the authentication service provides an Identity header field for requests in the dialog only when the user is authorized to assert the identity given in the From header field, and if they are not, an Identity header field is not provided. And per the threat model of [RFC7375], resolving problems with "connected" identity has little bearing on detecting robocalling or related impersonation attacks.
Top   ToC   RFC8224 - Page 37

12.2. Unprotected Request Fields

[RFC4474] originally provided protections for Contact, Call-ID, and CSeq. This document removes protection for these fields. The absence of these header field values creates some opportunities for determined attackers to impersonate based on cut-and-paste attacks; however, the absence of these header field values does not seem impactful to the primary focus of this document, which is the prevention of the simple unauthorized claiming of an identity for the purposes of robocalling, voicemail hacking, or swatting. It might seem attractive to provide a signature over some of the information present in the Via header field value(s). For example, without a signature over the sent-by field of the topmost Via header field, an attacker could remove that Via header field and insert its own in a cut-and-paste attack, which would cause all responses to the request to be routed to a host of the attacker's choosing. However, a signature over the topmost Via header field does not prevent attacks of this nature, since the attacker could leave the topmost Via intact and merely insert a new Via header field directly after it, which would cause responses to be routed to the attacker's host "on their way" to the valid host; the end result would be exactly the same. Although it is possible that an intermediary-based authentication service could guarantee that no Via hops are inserted between the sending UA and the authentication service, it could not prevent an attacker from adding a Via hop after the authentication service and thereby preempting responses. It is necessary for the proper operation of SIP for subsequent intermediaries to be capable of inserting such Via header fields, and thus it cannot be prevented. As such, though it is desirable, securing Via is not possible through the sort of identity mechanism described in this document; the best known practice for securing Via is the use of SIPS.

12.3. Malicious Removal of Identity Headers

In the end analysis, the Identity header field cannot protect itself. Any attacker could remove the header field from a SIP request and modify the request arbitrarily afterwards. However, this mechanism is not intended to protect requests from men-in-the-middle who interfere with SIP messages; it is intended only to provide a way that the originators of SIP requests can prove that they are who they claim to be. At best, by stripping identity information from a request, a man-in-the-middle could make it impossible to distinguish any illegitimate messages he would like to send from those messages sent by an authorized user. However, it requires a considerably greater amount of energy to mount such an attack than it does to mount trivial impersonations by just copying someone else's
Top   ToC   RFC8224 - Page 38
   From header field.  This mechanism provides a way that an authorized
   user can provide a definitive assurance of his identity that an
   unauthorized user, an impersonator, cannot.

12.4. Securing the Connection to the Authentication Service

In the absence of UA-based authentication services, the assurance provided by this mechanism is strongest when a UA forms a direct connection, preferably one secured by TLS, to an intermediary-based authentication service. The reasons for this are twofold: o If a user does not receive a certificate from the authentication service over the TLS connection that corresponds to the expected domain (especially when the user receives a challenge via a mechanism such as Digest), then it is possible that a rogue server is attempting to pose as an authentication service for a domain that it does not control, possibly in an attempt to collect shared secrets for that domain. A similar practice could be used for telephone numbers, though the application of certificates for telephone numbers to TLS is left as a matter for future study. o Without TLS, the various header field values and the body of the request will not have integrity protection when the request arrives at an authentication service. Accordingly, a prior legitimate or illegitimate intermediary could modify the message arbitrarily. Of these two concerns, the first is most material to the intended scope of this mechanism. This mechanism is intended to prevent impersonation attacks, not man-in-the-middle attacks; integrity over parts of the header and body is provided by this mechanism only to prevent replay attacks. However, it is possible that applications relying on the presence of the Identity header field could leverage this integrity protection for services other than replay protection. Accordingly, direct TLS connections SHOULD be used between the UA client (UAC) and the authentication service whenever possible. The opportunistic nature of this mechanism, however, makes it very difficult to constrain UAC behavior, and moreover there will be some deployment architectures where a direct connection is simply infeasible and the UAC cannot act as an authentication service itself. Accordingly, when a direct connection and TLS are not possible, a UAC should use the SIPS mechanism, Digest "auth-int" for body integrity, or both when it can. The ultimate decision to add an Identity header field to a request lies with the authentication service, of course; domain policy must identify those cases where the UAC's security association with the authentication service is too weak.
Top   ToC   RFC8224 - Page 39

12.5. Authorization and Transitional Strategies

Ultimately, the worth of an assurance provided by an Identity header field is limited by the security practices of the authentication service that issues the assurance. Relying on an Identity header field generated by a remote administrative domain assumes that the issuing domain uses recommended administrative practices to authenticate its users. However, it is possible that some authentication services will implement policies that effectively make users unaccountable (e.g., ones that accept unauthenticated registrations from arbitrary users). The value of an Identity header field from such authentication services is questionable. While there is no magic way for a verifier to distinguish "good" from "bad" signers by inspecting a SIP request, it is expected that further work in authorization practices could be built on top of this identity solution; without such an identity solution, many promising approaches to authorization policy are impossible. That much said, it is RECOMMENDED that authentication services based on proxy servers employ strong authentication practices. One cannot expect the Identity header field to be supported by every SIP entity overnight. This leaves the verifier in a difficult position; when it receives a request from a given SIP user, how can it know whether or not the originator's domain supports Identity? In the absence of ubiquitous support for Identity, some transitional strategies are necessary. o A verifier could remember when it receives a request from a domain or telephone number that uses Identity and, in the future, view messages received from that source without an Identity header field with skepticism. o A verifier could consult some sort of directory that indicates whether a given caller should have a signed identity. There are a number of potential ways in which this could be implemented. This is left as a subject for future work. In the long term, some sort of identity mechanism, either the one documented in this specification or a successor, must become mandatory-to-use for SIP; that is the only way to guarantee that this protection can always be expected by verifiers. Finally, it is worth noting that the presence or absence of the Identity header fields cannot be the sole factor in making an authorization decision. Permissions might be granted to a message on the basis of the specific verified Identity or really on any other aspect of a SIP request. Authorization policies are outside the
Top   ToC   RFC8224 - Page 40
   scope of this specification, but this specification advises any
   future authorization work not to assume that messages with valid
   Identity header fields are always good.

12.6. Display-Names and Identity

As a matter of interface design, SIP UAs might render the display-name portion of the From header field of a caller as the identity of the caller; there is a significant precedent in email user interfaces for this practice. Securing the display-name component of the From header field value is outside the scope of this document but may be the subject of future work, such as through the "ppt" name mechanism. In the absence of signing the display-name, authentication services might check and validate it, and compare it to a list of acceptable display-names that may be used by the originator; if the display-name does not meet policy constraints, the authentication service could return a 403 response code. In this case, the reason phrase should indicate the nature of the problem: for example, "Inappropriate Display Name". However, the display-name is not always present, and in many environments the requisite operational procedures for display-name validation may not exist, so no normative guidance is given here.

13. IANA Considerations

IANA has completed a number of actions described in this document. Primarily, the previous references to [RFC4474] in the "Session Initiation Protocol (SIP) Parameters" registry have been updated to point to this document, unless specified otherwise below.

13.1. SIP Header Fields

The Identity-Info header in the SIP "Header Fields" registry has been marked as deprecated by this document. Also, the Identity-Info header reserved the compact form "n" at its time of registration. That compact form has been removed from the registry. The Identity header, however, retains the compact form "y" reserved by [RFC4474].
Top   ToC   RFC8224 - Page 41

13.2. SIP Response Codes

The 436 "Bad Identity-Info" default reason phrase has been changed to "Bad Identity Info" in the SIP "Response Codes" registry. The 437 "Unsupported Certificate" default reason phrase has been changed to "Unsupported Credential".

13.3. Identity-Info Parameters

IANA manages a registry for Identity-Info parameters. Per this specification, IANA has changed the name of this registry to "Identity Parameters". This specification defines one new value for the registry: "info" as defined in Section 7.3.

13.4. Identity-Info Algorithm Parameter Values

IANA managed an "Identity-Info Algorithm Parameter Values" registry; per this specification, IANA has deprecated and closed this registry. Since the algorithms for signing PASSporTs are defined in [RFC8225] rather than in this specification, there is no longer a need for an algorithm parameter registry for the Identity header field.

14. Changes from RFC 4474

The following are salient changes from the original RFC 4474: o The credential mechanism has been generalized; credential enrollment, acquisition, and trust are now outside the scope of this document. o This document reduces the scope of the Identity signature to remove CSeq, Call-ID, Contact, and the message body; signing of key fingerprints in SDP is now included. o The Identity-Info header field has been deprecated, and its components have been relocated into parameters of the Identity header field (which obsoletes the previous version of the header field). o The Identity header field can now appear multiple times in one request.
Top   ToC   RFC8224 - Page 42
   o  The previous signed-identity-digest format has been replaced with
      PASSporT (signing algorithms are now defined in a separate
      specification).

   o  Status code descriptions have been revised.

15. References

15.1. Normative References

[E.164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164/en>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
Top   ToC   RFC8224 - Page 43
   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5922]  Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
              Certificates in the Session Initiation Protocol (SIP)",
              RFC 5922, DOI 10.17487/RFC5922, June 2010,
              <https://www.rfc-editor.org/info/rfc5922>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/info/rfc8225>.

15.2. Informative References

[CIDER] Kaplan, H., "A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER)", Work in Progress, draft-kaplan-stir-cider-00, July 2013. [IRI-COMPARISON] Masinter, L. and M. Duerst, "Comparison, Equivalence and Canonicalization of Internationalized Resource Identifiers", Work in Progress, draft-ietf-iri- comparison-02, October 2012. [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>. [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, DOI 10.17487/RFC3893, September 2004, <https://www.rfc-editor.org/info/rfc3893>.
Top   ToC   RFC8224 - Page 44
   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474,
              DOI 10.17487/RFC4474, August 2006,
              <https://www.rfc-editor.org/info/rfc4474>.

   [RFC4501]  Josefsson, S., "Domain Name System Uniform Resource
              Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006,
              <https://www.rfc-editor.org/info/rfc4501>.

   [RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916,
              June 2007, <https://www.rfc-editor.org/info/rfc4916>.

   [RFC5393]  Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
              Campen, "Addressing an Amplification Vulnerability in
              Session Initiation Protocol (SIP) Forking Proxies",
              RFC 5393, DOI 10.17487/RFC5393, December 2008,
              <https://www.rfc-editor.org/info/rfc5393>.

   [RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
              for Establishing a Secure Real-time Transport Protocol
              (SRTP) Security Context Using Datagram Transport Layer
              Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763,
              May 2010, <https://www.rfc-editor.org/info/rfc5763>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
              August 2012, <https://www.rfc-editor.org/info/rfc6698>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
              Telephone Identity Problem Statement and Requirements",
              RFC 7340, DOI 10.17487/RFC7340, September 2014,
              <https://www.rfc-editor.org/info/rfc7340>.
Top   ToC   RFC8224 - Page 45
   [RFC7375]  Peterson, J., "Secure Telephone Identity Threat Model",
              RFC 7375, DOI 10.17487/RFC7375, October 2014,
              <https://www.rfc-editor.org/info/rfc7375>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
              May 2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", RFC 8226,
              DOI 10.17487/RFC8226, February 2018,
              <https://www.rfc-editor.org/info/rfc8226>.

   [SIP-RETARGET]
              Peterson, J., "Retargeting and Security in SIP: A
              Framework and Requirements", Work in Progress,
              draft-peterson-sipping-retarget-00, February 2005.

   [SIP-RFC4474-CONCERNS]
              Rosenberg, J., "Concerns around the Applicability of
              RFC 4474", Work in Progress, draft-rosenberg-sip-rfc4474-
              concerns-00, February 2008.

   [TS-3GPP.23.228]
              3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
              TS 23.228 7.7.0, March 2007,
              <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
Top   ToC   RFC8224 - Page 46

Acknowledgments

The authors would like to thank Adam Roach, Jim Schaad, Ning Zhang, Syed Ali, Olle Jacobson, Dave Frankel, Robert Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex Bobotek, Paul Kyzivat, Jonathan Lennox, Richard Shockey, Martin Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for their comments.

Authors' Addresses

Jon Peterson Neustar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America Email: jon.peterson@neustar.biz Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada Email: fluffy@cisco.com Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 United States of America Email: ekr@rtfm.com Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 United States of America Email: chris-ietf@chriswendt.net