draft-ietf-sipbrandy-rtpsec-08.txt   rfc8862.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft Neustar Request for Comments: 8862 Neustar
Intended status: Best Current Practice R. Barnes BCP: 228 R. Barnes
Expires: October 27, 2019 Cisco Category: Best Current Practice Cisco
R. Housley ISSN: 2070-1721 R. Housley
Vigil Security Vigil Security
April 25, 2019 January 2021
Best Practices for Securing RTP Media Signaled with SIP Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-08
Abstract Abstract
Although the Session Initiation Protocol (SIP) includes a suite of Although the Session Initiation Protocol (SIP) includes a suite of
security services that has been expanded by numerous specifications security services that has been expanded by numerous specifications
over the years, there is no single place that explains how to use SIP over the years, there is no single place that explains how to use SIP
to establish confidential media sessions. Additionally, existing to establish confidential media sessions. Additionally, existing
mechanisms have some feature gaps that need to be identified and mechanisms have some feature gaps that need to be identified and
resolved in order for them to address the pervasive monitoring threat resolved in order for them to address the pervasive monitoring threat
model. This specification describes best practices for negotiating model. This specification describes best practices for negotiating
confidential media with SIP, including a comprehensive protection confidential media with SIP, including a comprehensive protection
solution that binds the media layer to SIP layer identities. solution that binds the media layer to SIP layer identities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 27, 2019. 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/rfc8862.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 3. Security at the SIP and SDP Layer
4. STIR Profile for Endpoint Authentication and Verification 4. STIR Profile for Endpoint Authentication and Verification
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Services
4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Credentials
4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 4.2. Anonymous Communications
4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7 4.3. Connected Identity Usage
4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8 4.4. Authorization Decisions
5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8 5. Media Security Protocols
6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9 6. Relayed Media and Conferencing
7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9 7. ICE and Connected Identity
8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10 8. Best Current Practices
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] includes a suite of The Session Initiation Protocol (SIP) [RFC3261] includes a suite of
security services, including Digest authentication, for security services, including Digest Authentication [RFC7616] for
authenticating entities with a shared secret, TLS for transport authenticating entities with a shared secret, TLS [RFC8446] for
security, and S/MIME (optionally) for body security. SIP is transport security, and (optionally) S/MIME [RFC8551] for body
frequently used to establish media sessions, in particular audio or security. SIP is frequently used to establish media sessions -- in
audiovisual sessions, which have their own security mechanisms particular, audio or audiovisual sessions, which have their own
available, such as Secure RTP [RFC3711]. However, the practices security mechanisms available, such as the Secure Real-time Transport
needed to bind security at the media layer to security at the SIP Protocol (SRTP) [RFC3711]. However, the practices needed to bind
layer, to provide an assurance that protection is in place all the security at the media layer to security at the SIP layer, to provide
way up the stack, rely on a great many external security mechanisms an assurance that protection is in place all the way up the stack,
and practices. This document provides documentation to explain their rely on a great many external security mechanisms and practices.
optimal use as a best practice. This document provides documentation to explain their optimal use as
a best practice.
Revelations about widespread pervasive monitoring of the Internet Revelations about widespread pervasive monitoring of the Internet
have led to a greater desire to protect Internet communications have led to a greater desire to protect Internet communications
[RFC7258]. In order to maximize the use of security features, [RFC7258]. In order to maximize the use of security features,
especially of media confidentiality, opportunistic measures serve as especially of media confidentiality, opportunistic measures serve as
a stopgap when a full suite of services cannot be negotiated all the a stopgap when a full suite of services cannot be negotiated all the
way up the stack. Opportunistic media security for SIP is described way up the stack. Opportunistic media security for SIP is described
in [I-D.ietf-sipbrandy-osrtp], which builds on the prior efforts of in [RFC8643], which builds on the prior efforts of
[I-D.kaplan-mmusic-best-effort-srtp]. With opportunistic encryption, [Best-Effort-SRTP]. With opportunistic encryption, there is an
there is an attempt to negotiate the use of encryption, but if the attempt to negotiate the use of encryption, but if the negotiation
negotiation fails, then cleartext is used. Opportunistic encryption fails, then cleartext is used. Opportunistic encryption approaches
approaches typically have no integrity protection for the keying typically have no integrity protection for the keying material.
material.
This document contains the SIPBRANDY profile of STIR [RFC8224] for This document contains the SIP Best-practice Recommendations Against
media confidentiality, providing a comprehensive security solution Network Dangers to privacY (SIPBRANDY) profile of Secure Telephone
for SIP media that includes integrity protection for keying material Identity Revisited (STIR) [RFC8224] for media confidentiality,
and offers application-layer assurance that media confidentiality is providing a comprehensive security solution for SIP media that
place. Various specifications that user agents must implement to includes integrity protection for keying material and offers
application-layer assurance that media confidentiality is in place.
Various specifications that User Agents (UAs) must implement to
support media confidentiality are given in the sections below; a support media confidentiality are given in the sections below; a
summary of the best current practices appears in Section 8. summary of the best current practices appears in Section 8.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Security at the SIP and SDP layer 3. Security at the SIP and SDP Layer
There are two approaches to providing confidentiality for media There are two approaches to providing confidentiality for media
sessions set up with SIP: comprehensive protection and opportunistic sessions set up with SIP: comprehensive protection and opportunistic
security (as defined in [RFC7435]). This document only addresses security (as defined in [RFC7435]). This document only addresses
comprehensive protection. comprehensive protection.
Comprehensive protection for media sessions established by SIP Comprehensive protection for media sessions established by SIP
requires the interaction of three protocols: Session Initiation requires the interaction of three protocols: the Session Initiation
Protocol (SIP) [RFC3261], the Session Description Protocol (SDP) Protocol (SIP) [RFC3261], the Session Description Protocol (SDP)
[RFC4566], and the Real-time Protocol (RTP) [RFC3550], in particular [RFC4566], and the Real-time Transport Protocol (RTP) [RFC3550] --
its secure profile Secure RTP (SRTP) [RFC3711]. Broadly, it is the in particular, its secure profile SRTP [RFC3711]. Broadly, it is the
responsibility of SIP to provide integrity protection for the media responsibility of SIP to provide integrity protection for the media
keying attributes conveyed by SDP, and those attributes will in turn keying attributes conveyed by SDP, and those attributes will in turn
identify the keys used by endpoints in the RTP media session(s) that identify the keys used by endpoints in the RTP media session(s) that
SDP negotiates. SDP negotiates.
Note that this framework does not apply to keys that also require Note that this framework does not apply to keys that also require
confidentiality protection in the signaling layer, such as the SDP confidentiality protection in the signaling layer, such as the SDP
"k=" line, which MUST NOT be used in conjunction with this profile. "k=" line, which MUST NOT be used in conjunction with this profile.
In that way, once SIP and SDP have exchanged the necessary In that way, once SIP and SDP have exchanged the necessary
information to initiate a session, media endpoints will have a strong information to initiate a session, media endpoints will have a strong
assurance that the keys they exchange have not been tampered with by assurance that the keys they exchange have not been tampered with by
third parties, and that end-to-end confidentiality is available. third parties and that end-to-end confidentiality is available.
To establishing the identity of the endpoints of a SIP session, this To establish the identity of the endpoints of a SIP session, this
specification uses STIR [RFC8224]. The STIR Identity header has been specification uses STIR [RFC8224]. The STIR Identity header has been
designed to prevent a class of impersonation attacks that are designed to prevent a class of impersonation attacks that are
commonly used in robocalling, voicemail hacking, and related threats. commonly used in robocalling, voicemail hacking, and related threats.
STIR generates a signature over certain features of SIP requests, STIR generates a signature over certain features of SIP requests,
including header field values that contain an identity for the including header field values that contain an identity for the
originator of the request, such as the From header field or P- originator of the request, such as the From header field or
Asserted-Identity field, and also over the media keys in SDP if they P-Asserted-Identity field, and also over the media keys in SDP if
are present. As currently defined, STIR provides a signature over they are present. As currently defined, STIR provides a signature
the "a=fingerprint" attribute, which is a fingerprint of the key used over the "a=fingerprint" attribute, which is a fingerprint of the key
by DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive used by DTLS-SRTP [RFC5763]; consequently, STIR only offers
protection for SIP sessions in concert with SDP and SRTP when DTLS- comprehensive protection for SIP sessions in concert with SDP and
SRTP is the media security service. The underlying PASSporT SRTP when DTLS-SRTP is the media security service. The underlying
[RFC8225] object used by STIR is extensible, however, and it would be Personal Assertion Token (PASSporT) object [RFC8225] used by STIR is
possible to provide signatures over other SDP attributes that contain extensible, however, and it would be possible to provide signatures
alternate keying material. A profile for using STIR to provide media over other SDP attributes that contain alternate keying material. A
confidentiality is given in Section 4. profile for using STIR to provide media confidentiality is given in
Section 4.
4. STIR Profile for Endpoint Authentication and Verification Services 4. STIR Profile for Endpoint Authentication and Verification Services
STIR [RFC8224] defines the Identity header field for SIP, which STIR [RFC8224] defines the Identity header field for SIP, which
provides a cryptographic attestation of the source of communications. provides a cryptographic attestation of the source of communications.
This document includes a profile of STIR, called the SIPBRANDY This document includes a profile of STIR, called the SIPBRANDY
profile, where the STIR verification service will act in concert with profile, where the STIR verification service will act in concert with
an SRTP media endpoint to ensure that the key fingerprints, as given an SRTP media endpoint to ensure that the key fingerprints, as given
in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy
this condition, the verification service function would in this case this condition, the verification service function would in this case
skipping to change at page 5, line 4 skipping to change at line 192
which focuses on impersonation rather than man-in-the-middle attacks, which focuses on impersonation rather than man-in-the-middle attacks,
STIR offers no specific protections against such interference. STIR offers no specific protections against such interference.
The SIPBRANDY profile for media confidentiality thus shifts these The SIPBRANDY profile for media confidentiality thus shifts these
responsibilities to the endpoints rather than the intermediaries. responsibilities to the endpoints rather than the intermediaries.
While intermediaries MAY provide the verification service function of While intermediaries MAY provide the verification service function of
STIR for SIPBRANDY transactions, the verification needs to be STIR for SIPBRANDY transactions, the verification needs to be
repeated at the endpoint to obtain end-to-end assurance. repeated at the endpoint to obtain end-to-end assurance.
Intermediaries supporting this specification MUST NOT block or Intermediaries supporting this specification MUST NOT block or
otherwise redirect calls if they do not trust the signing credential. otherwise redirect calls if they do not trust the signing credential.
The SIPBRANDY profile is based on an end-to-end trust model, so it is The SIPBRANDY profile is based on an end-to-end trust model, so it is
up to the endpoints to determine if they support signing credentials, up to the endpoints to determine if they support signing credentials,
not intermediaries. not intermediaries.
In order to be compliant with best practices for SIP media In order to be compliant with best practices for SIP media
confidentiality with comprehensive protection, user agent confidentiality with comprehensive protection, UA implementations
implementations MUST implement both the authentication service and MUST implement both the authentication service and verification
verification service roles described in [RFC8224]. STIR service roles described in [RFC8224]. STIR authentication services
authentication services MUST signal their compliance with this MUST signal their compliance with this specification by including the
specification by including the "msec" claim defined in this "msec" claim defined in this specification to the PASSporT payload.
specification to the PASSporT payload. Implementations MUST provide Implementations MUST provide key fingerprints in SDP and the
key fingerprints in SDP and the appropriate signatures over them as appropriate signatures over them as specified in [RFC8225].
specified in [RFC8225].
When generating either an offer or an answer [RFC3264], compliant When generating either an offer or an answer [RFC3264], compliant
implementations MUST include an "a=fingerprint" attribute containing implementations MUST include an "a=fingerprint" attribute containing
the fingerprint of an appropriate key (see Section 4.1). the fingerprint of an appropriate key (see Section 4.1).
4.1. Credentials 4.1. Credentials
In order to implement the authentication service function in the user In order to implement the authentication service function in the UA,
agent, SIP endpoints will need to acquire the credentials needed to SIP endpoints will need to acquire the credentials needed to sign for
sign for their own identity. That identity is typically carried in their own identity. That identity is typically carried in the From
the From header field of a SIP request, and either contains a header field of a SIP request and contains either a greenfield SIP
greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone URI (e.g., "sip:alice@example.com") or a telephone number (which can
number, which can appear in a variety of ways (e.g. appear in a variety of ways, e.g.,
"sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224] "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224]
contains guidance for separating the two, and determining what sort contains guidance for separating the two and determining what sort of
of credential is needed to sign for each. credential is needed to sign for each.
To date, few commercial certification authorities (CAs) issue To date, few commercial certification authorities (CAs) issue
certificates for SIP URIs or telephone numbers; though work is certificates for SIP URIs or telephone numbers; though work is
ongoing on systems for this purpose (such as ongoing on systems for this purpose (such as [ACME-Auth-Token]), it
[I-D.ietf-acme-authority-token]) it is not yet mature enough to be is not yet mature enough to be recommended as a best practice. This
recommended as a best practice. This is one reason why STIR permits is one reason why STIR permits intermediaries to act as an
intermediaries to act as an authentication service on behalf of an authentication service on behalf of an entire domain, just as in SIP
entire domain, just as in SIP a proxy server can provide domain-level a proxy server can provide domain-level SIP service. While CAs that
SIP service. While CAs that offer proof-of-possession certificates offer proof-of-possession certificates similar to those used for
similar to those used for email could be offered for SIP, either for email could be offered for SIP -- for either greenfield identifiers
greenfield identifiers or for telephone numbers, this specification or telephone numbers -- this specification does not require their
does not require their use. use.
For users who do not possess such certificates, DTLS-SRTP [RFC5763] For users who do not possess such certificates, DTLS-SRTP [RFC5763]
permits the use of self-signed public keys. This profile of STIR permits the use of self-signed public keys. The profile of STIR in
employs more relaxed authority requirements of [RFC8224] to allow the this document, called the SIPBRANDY profile, employs the more relaxed
use of self-signed public keys for authentication services that are authority requirements of [RFC8224] to allow the use of self-signed
composed with user agents, by generating a certificate (per the public keys for authentication services that are composed with UAs,
guidance in [RFC8226]) with a subject corresponding to the user's by generating a certificate (per the guidance in [RFC8226]) with a
identity. To obtain comprehensive protection with a self-signed subject corresponding to the user's identity. To obtain
certificate, some out-of-band verification is needed as well. Such a comprehensive protection with a self-signed certificate, some out-of-
credential could be used for trust on first use (see [RFC7435]) by band verification is needed as well. Such a credential could be used
relying parties. Note that relying parties SHOULD NOT use for trust on first use (see [RFC7435]) by relying parties. Note that
certificate revocation mechanisms or real-time certificate relying parties SHOULD NOT use certificate revocation mechanisms or
verification systems for self-signed certificates as they will not real-time certificate verification systems for self-signed
increase confidence in the certificate. certificates, as they will not increase confidence in the
certificate.
Users who wish to remain anonymous can instead generate self-signed Users who wish to remain anonymous can instead generate self-signed
certificates as described in Section 4.2. certificates as described in Section 4.2.
Generally speaking, without access to out-of-band information about Generally speaking, without access to out-of-band information about
which certificates were issued to whom, it will be very difficult for which certificates were issued to whom, it will be very difficult for
relying parties to ascertain whether or not the signer of a SIP relying parties to ascertain whether or not the signer of a SIP
request is genuinely an "endpoint." Even the term "endpoint" is a request is genuinely an "endpoint". Even the term "endpoint" is a
problematic one, as SIP user agents can be composed in a variety of problematic one, as SIP UAs can be composed in a variety of
architectures and may not be devices under direct user control. architectures and may not be devices under direct user control.
While it is possible that techniques based on certificate While it is possible that techniques based on certificate
transparency [RFC6962] or similar practices could help user agents to transparency [RFC6962] or similar practices could help UAs to
recognize one another's certificates, those operational systems will recognize one another's certificates, those operational systems will
need to ramp up with the CAs that issue credentials to end user need to ramp up with the CAs that issue credentials to end-user
devices going forward. devices going forward.
4.2. Anonymous Communications 4.2. Anonymous Communications
In some cases, the identity of the initiator of a SIP session may be In some cases, the identity of the initiator of a SIP session may be
withheld due to user or provider policy. Following the withheld due to user or provider policy. Following the
recommendations of [RFC3323], this may involve using an identity such recommendations of [RFC3323], this may involve using an identity such
as "anonymous@anonymous.invalid" in the identity fields of a SIP as "anonymous@anonymous.invalid" in the identity fields of a SIP
request. [RFC8224] does not currently permit authentication services request. [RFC8224] does not currently permit authentication services
to sign for requests that supply this identity. It does however to sign for requests that supply this identity. It does, however,
permit signing for valid domains, such as "anonymous@example.com," as permit signing for valid domains, such as "anonymous@example.com", as
a way of implementation an anonymization service as specified in a way of implementing an anonymization service as specified in
[RFC3323]. [RFC3323].
Even for anonymous sessions, providing media confidentiality and Even for anonymous sessions, providing media confidentiality and
partial SDP integrity is still desirable. This specification partial SDP integrity is still desirable. One-time self-signed
RECOMMENDS using one-time self-signed certificates for anonymous certificates for anonymous communications SHOULD include a
communications, with a subjectAltName of subjectAltName of "sip:anonymous@anonymous.invalid". After a session
"sip:anonymous@anonymous.invalid". After a session is terminated, is terminated, the certificate SHOULD be discarded, and a new one,
the certificate SHOULD be discarded, and a new one, with fresh keying with fresh keying material, SHOULD be generated before each future
material, SHOULD be generated before each future anonymous call. As anonymous call. As with self-signed certificates, relying parties
with self-signed certificates, relying parties SHOULD NOT use SHOULD NOT use certificate revocation mechanisms or real-time
certificate revocation mechanisms or real-time certificate certificate verification systems for anonymous certificates, as they
verification systems for anonymous certificates as they will not will not increase confidence in the certificate.
increase confidence in the certificate.
Note that when using one-time anonymous self-signed certificates, any Note that when using one-time anonymous self-signed certificates, any
man in the middle could strip the Identity header and replace it with man in the middle could strip the Identity header and replace it with
one signed by its own one-time certificate, changing the "mkey" one signed by its own one-time certificate, changing the "mky"
parameters of PASSporT and any "a=fingerprint" attributes in SDP as parameters of PASSporT and any "a=fingerprint" attributes in SDP as
it chooses. This signature only provides protection against non- it chooses. This signature only provides protection against
Identity aware entities that might modify SDP without altering the non-Identity-aware entities that might modify SDP without altering
PASSporT conveyed in the Identity header. the PASSporT conveyed in the Identity header.
4.3. Connected Identity Usage 4.3. Connected Identity Usage
STIR [RFC8224] provides integrity protection for the fingerprint STIR [RFC8224] provides integrity protection for the fingerprint
attributes in SIP request bodies, but not SIP responses. When a attributes in SIP request bodies but not SIP responses. When a
session is established, therefore, any SDP body carried by a 200 session is established, therefore, any SDP body carried by a
class response in the backwards direction will not be protected by an 200-class response in the backwards direction will not be protected
authentication service and cannot be verified. Thus, sending a by an authentication service and cannot be verified. Thus, sending a
secured SDP body in the backwards direction will require an extra secured SDP body in the backwards direction will require an extra
RTT, typically a request sent in the backwards direction. RTT, typically a request sent in the backwards direction.
The problem of providing "Connected Identity" in [RFC4474], which is [RFC4916] explored the problem of providing "connected identity" to
obsoleted by STIR, was explored in [RFC4916], which uses a implementations of [RFC4474] (which is obsoleted by [RFC8224]);
provisional or mid-dialog UPDATE request in the backwards direction [RFC4916] uses a provisional or mid-dialog UPDATE request in the
to convey an Identity header field for the recipient of an INVITE. backwards (reverse) direction to convey an Identity header field for
The procedures in that specification are largely compatible with the the recipient of an INVITE. The procedures in [RFC4916] are largely
revision of the Identity header in STIR [RFC8224]. However, the compatible with the revision of the Identity header in [RFC8224].
following need to be considered: However, the following need to be considered:
The UPDATE carrying signed SDP with a fingerprint in the backwards * The UPDATE carrying signed SDP with a fingerprint in the backwards
direction needs to be sent during dialog establishment, following direction needs to be sent during dialog establishment, following
the receipt of a PRACK after a provisional 1xx response. the receipt of a Provisional Response Acknowledgement (PRACK)
after a provisional 1xx response.
For use with this SIPBRANDY profile for media confidentiality, the * For use with this SIPBRANDY profile for media confidentiality, the
UAS that responds to the INVITE request needs to act as an UAS that responds to the INVITE request needs to act as an
authentication service for the UPDATE sent in the backwards authentication service for the UPDATE sent in the backwards
direction. direction.
The text in Section 4.4.1 of [RFC4916] regarding the receipt at a * Per the text in Section 4.4.1 of [RFC4916] regarding the receipt
UAC of error codes 428, 436, 437 and 438 in response to a mid- at a User Agent Client (UAC) of error code 428, 436, 437, or 438
dialog request RECOMMENDS treating the dialog as terminated. in response to a mid-dialog request, it is RECOMMENDED that the
However, Section 6.1.1 of [RFC8224] allows the retransmission of dialog be treated as terminated. However, Section 6.1.1 of
requests with repairable error conditions. In particular, an [RFC8224] allows the retransmission of requests with repairable
authentication service might retry a mid-dialog rather than error conditions. In particular, an authentication service might
treating the dialog as terminated, although only one such retry is retry a mid-dialog rather than treating the dialog as terminated,
permitted. although only one such retry is permitted.
Note that the examples in [RFC4916] are based on the original * Note that the examples in [RFC4916] are based on [RFC4474] and
[RFC4474], and will not match signatures using STIR [RFC8224]. will not match signatures using [RFC8224].
Future work may be done to revise [RFC4916] for STIR; that work Future work may be done to revise [RFC4916] for STIR; that work
should take into account any impacts on the SIPBRANDY profile should take into account any impacts on the SIPBRANDY profile
described in this document. The use of [RFC4916] has some further described in this document. The use of [RFC4916] has some further
interactions with ICE; see Section 7. interactions with Interactive Connectivity Establishment (ICE)
[RFC8445]; see Section 7.
4.4. Authorization Decisions 4.4. Authorization Decisions
[RFC8224] grants STIR verification services a great deal of latitude [RFC8224] grants STIR verification services a great deal of latitude
when making authorization decisions based on the presence of the when making authorization decisions based on the presence of the
Identity header field. It is largely a matter of local policy Identity header field. It is largely a matter of local policy
whether an endpoint rejects a call based on absence of an Identity whether an endpoint rejects a call based on the absence of an
header field, or even the presence of a header that fails an Identity header field, or even the presence of a header that fails an
integrity check against the request. integrity check against the request.
For this SIPBRANDY profile of STIR, however, a compliant verification For this SIPBRANDY profile of STIR, however, a compliant verification
service that receives a dialog-forming SIP request containing an service that receives a dialog-forming SIP request containing an
Identity header with a PASSporT type of "msec", after validating the Identity header with a PASSporT type of "msec", after validating the
request per the steps described in Section 6.2 of [RFC8224], MUST request per the steps described in Section 6.2 of [RFC8224], MUST
reject the request if there is any failure in that validation process reject the request if there is any failure in that validation process
with the appropriate status code per Section 6.2.2. If the request with the appropriate status code per Section 6.2.2 of [RFC8224]. If
is valid, then if a terminating user accepts the request, it MUST the request is valid, then if a terminating user accepts the request,
then follow the steps in Section 4.3 to act as an authentication it MUST then follow the steps in Section 4.3 to act as an
service and send a signed request with the "msec" PASSPorT type in authentication service and send a signed request with the "msec"
its Identity header as well, in order to enable end-to-end PASSporT type in its Identity header as well, in order to enable
bidirectional confidentiality. end-to-end bidirectional confidentiality.
For the purposes of this profile, the "msec" PASSporT type can be For the purposes of this profile, the "msec" PASSporT type can be
used by authentication services in one of two ways: as a mandatory used by authentication services in one of two ways: as a mandatory
request for media security, or as a merely opportunistic request for request for media security or as a merely opportunistic request for
media security. As any verification service that receives an media security. As any verification service that receives an
Identity header field in a SIP request with an unrecognized PASSporT Identity header field in a SIP request with an unrecognized PASSporT
type will simply ignore that Identity header, an authentication type will simply ignore that Identity header, an authentication
service will know whether or not the terminating side supports "msec" service will know whether or not the terminating side supports "msec"
based on whether or not its user agent receives a signed request in based on whether or not its UA receives a signed request in the
the backwards direction per Section 4.3. If no such requests are backwards direction per Section 4.3. If no such requests are
received, the UA may do one or two things: shut down the dialog, if received, the UA may do one of two things: shut down the dialog, if
the policy of the UA requires that "msec" be supported by the the policy of the UA requires that "msec" be supported by the
terminating side for this dialog; or, if policy permits (e.g., an terminating side for this dialog; or, if policy permits (e.g., an
explicit acceptance by the user), allow the dialog to continue explicit acceptance by the user), allow the dialog to continue
without media security. without media security.
5. Media Security Protocols 5. Media Security Protocols
As there are several ways to negotiate media security with SDP, any As there are several ways to negotiate media security with SDP, any
of which might be used with either opportunistic or comprehensive of which might be used with either opportunistic or comprehensive
protection, further guidance to implementers is needed. In protection, further guidance to implementers is needed. In
[I-D.ietf-sipbrandy-osrtp], opportunistic approaches considered [RFC8643], opportunistic approaches considered include DTLS-SRTP,
include DTLS-SRTP, security descriptions [RFC4568], and ZRTP security descriptions [RFC4568], and ZRTP [RFC6189].
[RFC6189].
Support for DTLS-SRTP is REQUIRED by this specification. Support for DTLS-SRTP is REQUIRED by this specification.
The "mkey" claim of PASSporT provides integrity protection for The "mky" claim of PASSporT provides integrity protection for
"a=fingerprint" attributes in SDP, including cases where multiple "a=fingerprint" attributes in SDP, including cases where multiple
"a=fingerprint" attributes appear in the same SDP. "a=fingerprint" attributes appear in the same SDP.
6. Relayed Media and Conferencing 6. Relayed Media and Conferencing
Providing end-to-end media confidentiality for SIP is complicated by Providing end-to-end media confidentiality for SIP is complicated by
the presence of many forms of media relays. While many media relays the presence of many forms of media relays. While many media relays
merely proxy media to a destination, others present themselves as merely proxy media to a destination, others present themselves as
media endpoints and terminate security associations before re- media endpoints and terminate security associations before
originating media to its destination. re-originating media to its destination.
Centralized conference bridges are one type of entity that typically Centralized conference bridges are one type of entity that typically
terminates a media session in order to mux media from multiple terminates a media session in order to mux media from multiple
sources and then to re-originate the muxed media to conference sources and then to re-originate the muxed media to conference
participants. In many such implementations, only hop-by-hop media participants. In many such implementations, only hop-by-hop media
confidentiality is possible. Work is ongoing to specify a means to confidentiality is possible. Work is ongoing to specify a means to
encrypt both the hop-by-hop media between a user agent and a encrypt both (1) the hop-by-hop media between a UA and a centralized
centralized server as well as the end-to-end media between user server and (2) the end-to-end media between UAs, but it is not
agents, but is not sufficiently mature at this time to make a sufficiently mature at this time to become a best practice. Those
recommendation for a best practice here. Those protocols are protocols are expected to identify their own best-practice
expected to identify their own best practice recommendations as they recommendations as they mature.
mature.
Another class of entities that might relay SIP media are back-to-back Another class of entities that might relay SIP media are Back-to-Back
user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], User Agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879],
it may be possible for those devices to act as media relays while it may be possible for B2BUAs to act as media relays while still
still permitting end-to-end confidentiality between user agents. permitting end-to-end confidentiality between UAs.
Ultimately, if an endpoint can decrypt media it receives, then that Ultimately, if an endpoint can decrypt media it receives, then that
endpoint can forward the decrypted media without the knowledge or endpoint can forward the decrypted media without the knowledge or
consent of the media's originator. No media confidentiality consent of the media's originator. No media confidentiality
mechanism can protect against these sorts of relayed disclosures, or mechanism can protect against these sorts of relayed disclosures or
trusted entities that can decrypt media and then record a copy to be against a legitimate endpoint that can legitimately decrypt media and
sent elsewhere (see [RFC7245]). record a copy to be sent elsewhere (see [RFC7245]).
7. ICE and Connected Identity 7. ICE and Connected Identity
Providing confidentiality for media with comprehensive protection Providing confidentiality for media with comprehensive protection
requires careful timing of when media streams should be sent and when requires careful timing of when media streams should be sent and when
a user interface should signify that confidentiality is in place. a user interface should signify that confidentiality is in place.
In order to best enable end-to-end connectivity between user agents, In order to best enable end-to-end connectivity between UAs and to
and to avoid media relays as much as possible, implementations of avoid media relays as much as possible, implementations of this
this specification MUST support ICE [RFC8445]. To speed up call specification MUST support ICE [RFC8445] [RFC8839]. To speed up call
establishment, it is RECOMMENDED that implementations support trickle establishment, it is RECOMMENDED that implementations support Trickle
ICE [I-D.ietf-mmusic-trickle-ice-sip]. ICE [RFC8838] [RFC8840].
Note that in the comprehensive protection case, the use of Connected Note that in the comprehensive protection case, the use of connected
Identity [RFC4916] with ICE entails that the answer containing the identity [RFC4916] with ICE implies that the answer containing the
key fingerprints, and thus the STIR signature, will come in an UPDATE key fingerprints, and thus the STIR signature, will come in an UPDATE
sent in the backwards direction, a provisional response, and a sent in the backwards direction, a provisional response, and a PRACK,
provisional acknowledgment (PRACK), rather than in any earlier SDP rather than in any earlier SDP body. Only at such a time as that
body. Only at such a time as that UPDATE is received will the media UPDATE is received will the media keys be considered exchanged in
keys be considered exchanged in this case. this case.
Similarly, in order to prevent, or at least mitigate, the denial-of- Similarly, in order to prevent, or at least mitigate, the denial-of-
service attack described in Section 19.5.1 of [RFC8445], this service attack described in Section 19.5.1 of [RFC8445], this
specification incorporates best practices for ensuring that specification incorporates best practices for ensuring that
recipients of media flows have consented to receive such flows. recipients of media flows have consented to receive such flows.
Implementations of this specification MUST implement the STUN usage Implementations of this specification MUST implement the Session
for consent freshness defined in [RFC7675]. Traversal Utilities for NAT (STUN) usage for consent freshness
defined in [RFC7675].
8. Best Current Practices 8. Best Current Practices
The following are the best practices for SIP user agents to provide The following are the best practices for SIP UAs to provide media
media confidentiality for SIP sessions. confidentiality for SIP sessions.
Implementations MUST support the STIR endpoint profile given in * Implementations MUST support the SIPBRANDY profile as defined in
Section 4, and signal that in PASSporT with the "msec" header Section 4 and signal such support in PASSporT via the "msec"
element. header element.
Implementations MUST follow the authorization decision behavior in * Implementations MUST follow the authorization decision behavior
Section 4.4. described in Section 4.4.
Implementations MUST support DTLS-SRTP for key-management, as * Implementations MUST support DTLS-SRTP for management of keys, as
described in Section 5. described in Section 5.
Implementations MUST support the ICE, and the STUN consent freshness * Implementations MUST support ICE and the STUN consent freshness
mechanism, as specified in Section 7. mechanism, as specified in Section 7.
9. IANA Considerations 9. IANA Considerations
This specification defines a new value for the Personal Assertion This specification defines a new value for the "Personal Assertion
Token (PASSporT) Extensions registry called "msec," and the IANA is Token (PASSporT) Extensions" registry called "msec". IANA has added
requested to add that entry to the registry with a value pointing to the entry to the registry with a value pointing to this document.
[RFCThis].
10. Security Considerations 10. Security Considerations
This document describes the security features that provide media This document describes the security features that provide media
sessions established with SIP with confidentiality, integrity, and sessions established with SIP with confidentiality, integrity, and
authentication. authentication.
11. Acknowledgments 11. References
We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell
for contributions to this problem statement and framework. We thank
Liang Xia and Alissa Cooper for their careful review.
12. References
12.1. Normative References
[I-D.ietf-mmusic-trickle-ice-sip] 11.1. Normative References
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Incremental
Provisioning of Candidates for the Interactive
Connectivity Establishment (Trickle ICE)", draft-ietf-
mmusic-trickle-ice-sip-18 (work in progress), June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
skipping to change at page 13, line 24 skipping to change at line 576
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
12.2. Informative References [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", RFC 8838,
DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/info/rfc8838>.
[I-D.ietf-acme-authority-token] [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME A., and R. Shpount, "Session Description Protocol (SDP)
Challenges Using an Authority Token", draft-ietf-acme- Offer/Answer Procedures for Interactive Connectivity
authority-token-03 (work in progress), March 2019. Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[I-D.ietf-sipbrandy-osrtp] [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. Session Initiation Protocol (SIP) Usage for Incremental
Stach, "An Opportunistic Approach for Secure Real-time Provisioning of Candidates for the Interactive
Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-08 Connectivity Establishment (Trickle ICE)", RFC 8840,
(work in progress), March 2019. DOI 10.17487/RFC8840, January 2021,
<https://www.rfc-editor.org/info/rfc8840>.
[I-D.kaplan-mmusic-best-effort-srtp] 11.2. Informative References
Audet, F. and H. Kaplan, "Session Description Protocol
[ACME-Auth-Token]
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Challenges Using an Authority Token", Work in Progress,
Internet-Draft, draft-ietf-acme-authority-token-05, 9
March 2020, <https://tools.ietf.org/html/draft-ietf-acme-
authority-token-05>.
[Best-Effort-SRTP]
Kaplan, H. and F. Audet, "Session Description Protocol
(SDP) Offer/Answer Negotiation For Best-Effort Secure (SDP) Offer/Answer Negotiation For Best-Effort Secure
Real-Time Transport Protocol", draft-kaplan-mmusic-best- Real-Time Transport Protocol", Work in Progress, Internet-
effort-srtp-01 (work in progress), October 2006. Draft, draft-kaplan-mmusic-best-effort-srtp-01, 25 October
2006, <https://tools.ietf.org/html/draft-kaplan-mmusic-
best-effort-srtp-01>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>. <https://www.rfc-editor.org/info/rfc4474>.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP", Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011, RFC 6189, DOI 10.17487/RFC6189, April 2011,
skipping to change at page 14, line 18 skipping to change at line 636
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session "An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
2014, <https://www.rfc-editor.org/info/rfc7245>. 2014, <https://www.rfc-editor.org/info/rfc7245>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8643] Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T.
Stach, "An Opportunistic Approach for Secure Real-time
Transport Protocol (OSRTP)", RFC 8643,
DOI 10.17487/RFC8643, August 2019,
<https://www.rfc-editor.org/info/rfc8643>.
Acknowledgements
We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell
for contributions to this problem statement and framework. We thank
Liang Xia and Alissa Cooper for their careful review.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
Email: jon.peterson@team.neustar Email: jon.peterson@team.neustar
Richard Barnes Richard Barnes
Cisco Cisco
 End of changes. 68 change blocks. 
251 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/