draft-ietf-sipbrandy-rtpsec-07.txt   draft-ietf-sipbrandy-rtpsec-08.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Updates: 4916 (if approved) R. Barnes Intended status: Best Current Practice R. Barnes
Intended status: Best Current Practice Cisco Expires: October 27, 2019 Cisco
Expires: August 5, 2019 R. Housley R. Housley
Vigil Security Vigil Security
February 01, 2019 April 25, 2019
Best Practices for Securing RTP Media Signaled with SIP Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-07 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 both comprehensive protection confidential media with SIP, including a comprehensive protection
solutions which bind the media to SIP-layer identities as well as solution that binds the media layer to SIP layer identities.
opportunistic security solutions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2019. This Internet-Draft will expire on October 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 20 skipping to change at page 2, line 17
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3
3.1. Comprehensive Protection . . . . . . . . . . . . . . . . 3
3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4
4. STIR Profile for Endpoint Authentication and Verification 4. STIR Profile for Endpoint Authentication and Verification
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6
4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7 4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7
4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8 4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8
5. Media Security Protocols . . . . . . . . . . . . . . . . . . 9 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8
6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9
7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 10 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9
8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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, ranging from Digest authentication for security services, including Digest authentication, for
authenticating entities with a shared secret, to TLS for transport authenticating entities with a shared secret, TLS for transport
security, to S/MIME (optionally) for body security. SIP is security, and S/MIME (optionally) for body security. SIP is
frequently used to establish media sessions, in particular audio or frequently used to establish media sessions, in particular audio or
audiovisual sessions, which have their own security mechanisms audiovisual sessions, which have their own security mechanisms
available, such as Secure RTP [RFC3711]. However, the practices available, such as Secure RTP [RFC3711]. However, the practices
needed to bind security at the media layer to security at the SIP needed to bind security at the media layer to security at the SIP
layer, to provide an assurance that protection is in place all the layer, to provide an assurance that protection is in place all the
way up the stack, rely on a great many external security mechanisms way up the stack, rely on a great many external security mechanisms
and practices, and require a central point of documentation to and practices. This document provides documentation to explain their
explain their optimal use as a best practice. 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 reevaluation of the threat model for Internet have led to a greater desire to protect Internet communications
communications [RFC7258]. In order to maximize the use of security
features, especially of media confidentiality, opportunistic measures
must often serve as a stopgap when a full suite of services cannot be
negotiated all the way up the stack. This document explains the
limitations that may inhibit the use of comprehensive protection, and
provides recommendations for which external security mechanisms
implementers should use to negotiate secure media with SIP. It
moreover gives a gap analysis of the limitations of existing
solutions, and specifies solutions to address them.
Various specifications that user agents must implement to support [RFC7258]. In order to maximize the use of security features,
media confidentiality are given in the sections below; a summary of especially of media confidentiality, opportunistic measures serve as
the best current practices appears in Section 8. a stopgap when a full suite of services cannot be negotiated all the
way up the stack. Opportunistic media security for SIP is described
in [I-D.ietf-sipbrandy-osrtp], which builds on the prior efforts of
[I-D.kaplan-mmusic-best-effort-srtp]. With opportunistic encryption,
there is an attempt to negotiate the use of encryption, but if the
negotiation fails, then cleartext is used. Opportunistic encryption
approaches typically have no integrity protection for the keying
material.
This document contains the SIPBRANDY profile of STIR [RFC8224] for
media confidentiality, providing a comprehensive security solution
for SIP media that includes integrity protection for keying material
and offers application-layer assurance that media confidentiality is
place. Various specifications that user agents must implement to
support media confidentiality are given in the sections below; a
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]). security (as defined in [RFC7435]). This document only addresses
comprehensive protection.
3.1. Comprehensive Protection
Comprehensive protection for media sessions established by SIP Comprehensive protection for media sessions established by SIP
requires the interaction of three protocols: SIP, the Session requires the interaction of three protocols: Session Initiation
Description Protocol (SDP) [RFC4566], and the Real-time Protocol Protocol (SIP) [RFC3261], the Session Description Protocol (SDP)
(RTP) [RFC3550], in particular its secure profile Secure RTP (SRTP) [RFC4566], and the Real-time Protocol (RTP) [RFC3550], in particular
[RFC3711]. Broadly, it is the responsibility of SIP to provide its secure profile Secure RTP (SRTP) [RFC3711]. Broadly, it is the
integrity protection for the media keying attributes conveyed by SDP, responsibility of SIP to provide integrity protection for the media
and those attributes will in turn identify the keys used by endpoints keying attributes conveyed by SDP, and those attributes will in turn
in the RTP media session(s) that SDP negotiates. Note that this identify the keys used by endpoints in the RTP media session(s) that
framework does not apply to keys that also require confidentiality SDP negotiates.
protection in the signaling layer, such as the SDP "k=" line, which
MUST NOT be used in conjunction with this profile. In that way, once Note that this framework does not apply to keys that also require
SIP and SDP have exchanged the necessary information to initiate a confidentiality protection in the signaling layer, such as the SDP
session, media endpoints will have a strong assurance that the keys "k=" line, which MUST NOT be used in conjunction with this profile.
they exchange have not been tampered with by third parties, and that
end-to-end confidentiality is available. In that way, once SIP and SDP have exchanged the necessary
information to initiate a session, media endpoints will have a strong
assurance that the keys they exchange have not been tampered with by
third parties, and that end-to-end confidentiality is available.
To establishing the identity of the endpoints of a SIP session, this To establishing 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 P-
Asserted-Identity field, and also over the media keys in SDP if they Asserted-Identity field, and also over the media keys in SDP if they
are present. As currently defined, STIR only provides a signature are present. As currently defined, STIR provides a signature over
over the "a=fingerprint" attribute, which is a key fingerprint the "a=fingerprint" attribute, which is a fingerprint of the key used
utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers by DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive
comprehensive protection for SIP sessions, in concert with SDP and protection for SIP sessions in concert with SDP and SRTP when DTLS-
SRTP, when DTLS-SRTP is the media security service. The underlying SRTP is the media security service. The underlying PASSporT
PASSporT [RFC8225] object used by STIR is extensible, however, and it [RFC8225] object used by STIR is extensible, however, and it would be
would be possible to provide signatures over other SDP attributes possible to provide signatures over other SDP attributes that contain
that contain alternate keying material. A profile for using STIR to alternate keying material. A profile for using STIR to provide media
provide media confidentiality is given in Section 4. confidentiality is given in Section 4.
3.2. Opportunistic Security
Work is already underway on defining approaches to opportunistic
media security for SIP in [I-D.johnston-dispatch-osrtp], which builds
on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The
major protocol change proposed by that specification is to signal the
use of opportunistic encryption by negotiating the AVP profile in
SDP, rather than the SAVP profile (as specified in [RFC3711]) that
would ordinarily be used when negotiating SRTP.
Opportunistic encryption approaches typically have no integrity
protection for the keying material in SDP. Sending SIP over TLS hop-
by-hop between user agents and any intermediaries will reduce the
prospect that active attackers can alter keys for session requests on
the wire. However, opportunistic confidentiality for media will
prevent passive attacks of the form most common in the threat of
pervasive monitoring.
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 profile of STIR assumes that a STIR verification service will This document includes a profile of STIR, called the SIPBRANDY
act in concert with an SRTP media endpoint to ensure that the key profile, where the STIR verification service will act in concert with
fingerprints, as given in SDP, match the keys exchanged to establish an SRTP media endpoint to ensure that the key fingerprints, as given
DTLS-SRTP. To satisfy this condition, the verification service in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy
function would in this case be implemented in the SIP UAS, which this condition, the verification service function would in this case
would be composed with the media endpoint. If the STIR be implemented in the SIP User Agent Server (UAS), which would be
authentication service or verification service functions are composed with the media endpoint. If the STIR authentication service
implemented at an intermediary rather than an endpoint, this or verification service functions are implemented at an intermediary
introduces the possibility that the intermediary could act as a man rather than an endpoint, this introduces the possibility that the
in the middle, altering key fingerprints. As this attack is not in intermediary could act as a man in the middle, altering key
STIR's core threat model, which focuses on impersonation rather than fingerprints. As this attack is not in STIR's core threat model,
man-in-the-middle attacks, STIR offers no specific protections which focuses on impersonation rather than man-in-the-middle attacks,
against such interference. STIR offers no specific protections against such interference.
The SIPBRANDY deployment profile of STIR for media confidentiality The SIPBRANDY profile for media confidentiality thus shifts these
thus shifts these responsibilities to the endpoints rather than the responsibilities to the endpoints rather than the intermediaries.
intermediaries. While intermediaries MAY provide the verification While intermediaries MAY provide the verification service function of
service function of STIR for SIPBRANDY transactions, the verification STIR for SIPBRANDY transactions, the verification needs to be
needs to be repeated at the endpoint obtain the 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 redirects calls if they do not trust the signing otherwise redirect calls if they do not trust the signing credential.
credential. The SIPBRANDY profile is based on an end-to-end trust
model, so it is up to the endpoints to determine if they support The SIPBRANDY profile is based on an end-to-end trust model, so it is
signing credentials, not intermediaries. up to the endpoints to determine if they support signing credentials,
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, user agent
implementations MUST implement both the authentication service and implementations MUST implement both the authentication service and
verification service roles described in [RFC8224]. STIR verification service roles described in [RFC8224]. STIR
authentication services MUST signal their compliance with this authentication services MUST signal their compliance with this
specification by adding the "msec" header element defined in this specification by including the "msec" claim defined in this
specification to the PASSporT header. Implementations MUST provide specification to the PASSporT payload. Implementations MUST provide
key fingerprints in SDP and the appropriate signatures over them per key fingerprints in SDP and the appropriate signatures over them as
[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 user
agent, SIP endpoints will need to acquire the credentials needed to agent, SIP endpoints will need to acquire the credentials needed to
sign for their own identity. That identity is typically carried in sign for their own identity. That identity is typically carried in
the From header field of a SIP request, and either contains a the From header field of a SIP request, and either contains a
greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone
number, which can appear in a variety of ways (e.g. number, which can 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 credential is needed to sign for each. of 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
[I-D.ietf-acme-telephone]) it is not mature enough to be recommended [I-D.ietf-acme-authority-token]) it is not yet mature enough to be
as a best practice. This is one reason why the STIR standard is recommended as a best practice. This is one reason why STIR permits
architected to permit intermediaries to act as an authentication intermediaries to act as an authentication service on behalf of an
service on behalf of an entire domain, just as in SIP an proxy server entire domain, just as in SIP a proxy server can provide domain-level
can provide domain-level SIP service. While CAs that offer proof-of- SIP service. While CAs that offer proof-of-possession certificates
possession certificates similar to those used in the email world similar to those used for email could be offered for SIP, either for
could be offered for SIP, either for greenfield identifiers or for greenfield identifiers or for telephone numbers, this specification
telephone numbers, this specification does not require their use. does not require their 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 keys. This profile of STIR employs permits the use of self-signed public keys. This profile of STIR
more relaxed authority requirements of [RFC8224] to allow the use of employs more relaxed authority requirements of [RFC8224] to allow the
self-signed keys for authentication services that are composed with use of self-signed public keys for authentication services that are
user agents, by generating a certificate (per the guidance of composed with user agents, by generating a certificate (per the
[RFC8226]) with a subject corresponding to the user's identity. To guidance in [RFC8226]) with a subject corresponding to the user's
obtain comprehensive protection with a self-signed certificate, some identity. To obtain comprehensive protection with a self-signed
out-of-band verification is needed as well. Such a credential could certificate, some out-of-band verification is needed as well. Such a
be used for trust on first use (see [RFC7435]) by relying parties. credential could be used for trust on first use (see [RFC7435]) by
Note that relying parties SHOULD NOT use certificate revocation relying parties. Note that relying parties SHOULD NOT use
mechanisms or real-time certificate verification systems for self- certificate revocation mechanisms or real-time certificate
signed certificates as they will not increase confidence in the verification systems for self-signed certificates as they will not
certificate. 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 user agents 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 user agents 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 certificate authorities that issue need to ramp up with the CAs that issue credentials to end user
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. Per the recommendations of withheld due to user or provider policy. Following the
[RFC3323], this may involve using an identity such as recommendations of [RFC3323], this may involve using an identity such
"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 implementation 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. This specification
RECOMMENDS using one-time self-signed certificates for anonymous RECOMMENDS using one-time self-signed certificates for anonymous
communications, with a subjectAltName of communications, with a subjectAltName of
"sip:anonymous@anonymous.invalid". After a session is terminated, "sip:anonymous@anonymous.invalid". After a session is terminated,
the certificate SHOULD be discarded, and a new one, with new keying the certificate SHOULD be discarded, and a new one, with fresh keying
material, SHOULD be generated before each future anonymous call. As material, SHOULD be generated before each future anonymous call. As
with self-signed certificates, relying parties SHOULD NOT use with self-signed certificates, relying parties SHOULD NOT use
certificate revocation mechanisms or real-time certificate certificate revocation mechanisms or real-time certificate
verification systems for anonymous certificates as they will not verification systems for anonymous certificates as they 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 "mkey"
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 non-
Identity aware entities that might modify SDP without altering the Identity aware entities that might modify SDP without altering the
PASSporT conveyed in the Identity header. PASSporT conveyed in the Identity header.
4.3. Connected Identity Usage 4.3. Connected Identity Usage
STIR [RFC8224] provides integrity protection for the SDP bodies of STIR [RFC8224] provides integrity protection for the fingerprint
SIP requests, but not SIP responses. When a session is established, attributes in SIP request bodies, but not SIP responses. When a
therefore, any SDP body carried by a 200 class response in the session is established, therefore, any SDP body carried by a 200
backwards direction will not be protected by an authentication class response in the backwards direction will not be protected by an
service and cannot be verified. Thus, sending a secured SDP body in authentication service and cannot be verified. Thus, sending a
the backwards direction will require an extra RTT, typically a secured SDP body in the backwards direction will require an extra
request sent in the backwards direction. RTT, typically a request sent in the backwards direction.
The problem of providing "Connected Identity" for the original The problem of providing "Connected Identity" in [RFC4474], which is
RFC4474 was explored in [RFC4916], which uses a provisional or mid- obsoleted by STIR, was explored in [RFC4916], which uses a
dialog UPDATE request in the backwards direction to convey an provisional or mid-dialog UPDATE request in the backwards direction
Identity header for the recipient of an INVITE. The procedures in to convey an Identity header field for the recipient of an INVITE.
that specification are largely compatible with the revision of the The procedures in that specification are largely compatible with the
Identity header in [RFC8224]. However, the following updates to revision of the Identity header in STIR [RFC8224]. However, the
[RFC4916] are required: 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 MUST be sent during dialog establishment, following the direction needs to be sent during dialog establishment, following
receipt of a PRACK after a provisional 1xx response. the receipt of a PRACK after a provisional 1xx response.
For use with this STIR Profile for media confidentiality, the UAS For use with this SIPBRANDY profile for media confidentiality, the
that responds to the INVITE request MUST act as an authentication UAS that responds to the INVITE request needs to act as an
service for the UPDATE sent in the backwards direction. authentication service for the UPDATE sent in the backwards
direction.
The text in Section 4.4.1 of [RFC4916] regarding the receipt at a The text in Section 4.4.1 of [RFC4916] regarding the receipt at a
UAC of error codes 428, 436, 437 and 438 in response to a mid- UAC of error codes 428, 436, 437 and 438 in response to a mid-
dialog request RECOMMENDS treating the dialog as terminated. dialog request RECOMMENDS treating the dialog as terminated.
[RFC8224] allows the retransmission of requests with repairable However, Section 6.1.1 of [RFC8224] allows the retransmission of
error conditions (see Section 6.1.1) in a way that can override requests with repairable error conditions. In particular, an
that SHOULD in [RFC4916]. In particular, an authentication authentication service might retry a mid-dialog rather than
service MAY retry a mid-dialog as [RFC8224] allows rather than treating the dialog as terminated, although only one such retry is
treating the dialog as terminated, though note that only one such permitted.
retry is permitted.
The examples in [RFC4916] are based on the original [RFC4916], and Note that the examples in [RFC4916] are based on the original
will not match signatures using [RFC4474]. [RFC4474], and will not match signatures using STIR [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 profile described in this should take into account any impacts on the SIPBRANDY profile
document. The use of [RFC4916] has some further interactions with described in this document. The use of [RFC4916] has some further
ICE; see Section 7. interactions with ICE; 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 absence of an Identity
header field, or even the presence of a header that fails an header field, or even the presence of a header that fails an
integrity check against the request. integrity check against the request.
For this profile, however, a compliant verification service that For this SIPBRANDY profile of STIR, however, a compliant verification
receives a dialog-forming SIP request containing an Identity header service that receives a dialog-forming SIP request containing an
with a PASSporT type of "msec", after validating the request per the Identity header with a PASSporT type of "msec", after validating the
steps described in Section 6.2 of [RFC8224], MUST reject the request request per the steps described in Section 6.2 of [RFC8224], MUST
if there is any failure in that validation process with the reject the request if there is any failure in that validation process
appropriate status code per Section 6.2.2. If the request is valid, with the appropriate status code per Section 6.2.2. If the request
then if a terminating user accepts the request, it MUST then follow is valid, then if a terminating user accepts the request, it MUST
the steps in Section 4.3 to act as an authentication service and send then follow the steps in Section 4.3 to act as an authentication
a signed request with the "msec" PASSPorT type in its Identity header service and send a signed request with the "msec" PASSPorT type in
as well, in order to enable end-to-end bidirectional confidentiality. its Identity header as well, in order to enable 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 in a SIP request with an unrecognized PASSporT type Identity header field in a SIP request with an unrecognized PASSporT
will simply ignore that Identity header, an authentication service type will simply ignore that Identity header, an authentication
will know whether or not the terminating side supports "msec" based service will know whether or not the terminating side supports "msec"
on whether or not its user agent receives a signed request in the based on whether or not its user agent receives a signed request in
backwards direction per Section 4.3. If no such requests are the 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 or 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.johnston-dispatch-osrtp], opportunistic approaches considered [I-D.ietf-sipbrandy-osrtp], opportunistic approaches considered
include DTLS-SRTP, security descriptions [RFC4568], and ZRTP include DTLS-SRTP, 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 "mkey" 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
skipping to change at page 10, line 16 skipping to change at page 10, line 7
sent elsewhere (see [RFC7245]). 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 user agents,
and to avoid media relays as much as possible, implementations of and to avoid media relays as much as possible, implementations of
this specification must support ICE [RFC8445]. To speed up call this specification MUST support ICE [RFC8445]. 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 [I-D.ietf-mmusic-trickle-ice-sip].
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 entails 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 sent in the backwards direction, a provisional response, and a
acknowledgment (PRACK), rather than in any earlier SDP body. Only at provisional acknowledgment (PRACK), rather than in any earlier SDP
such a time as that UPDATE is received will the media keys be body. Only at such a time as that UPDATE is received will the media
considered exchanged in this case. keys be considered exchanged in 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 STUN usage
for consent freshness defined in [RFC7675]. for consent freshness defined in [RFC7675].
8. Best Current Practices 8. Best Current Practices
skipping to change at page 11, line 5 skipping to change at page 10, line 44
Implementations MUST follow the authorization decision behavior in Implementations MUST follow the authorization decision behavior in
Section 4.4. Section 4.4.
Implementations MUST support DTLS-SRTP for key-management, as Implementations MUST support DTLS-SRTP for key-management, as
described in Section 5. described in Section 5.
Implementations MUST support the ICE, and the STUN consent freshness Implementations MUST support the ICE, and the STUN consent freshness
mechanism, as specified in Section 7. mechanism, as specified in Section 7.
9. Acknowledgments 9. IANA Considerations
We would like to thank Eric Rescorla, Adam Roach, Andrew Hutton, and
Ben Campbell for contributions to this problem statement and
framework.
10. IANA Considerations
This specification defines a new values for the PASSporT Type This specification defines a new value for the Personal Assertion
registry called "msec," and the IANA is requested to add that to the Token (PASSporT) Extensions registry called "msec," and the IANA is
registry with a value pointing to [RFCThis]. requested to add that entry to the registry with a value pointing to
[RFCThis].
11. 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
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. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-mmusic-trickle-ice-sip]
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,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
skipping to change at page 13, line 20 skipping to change at page 13, line 20
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
[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>.
12.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[I-D.ietf-acme-telephone] 12.2. Informative References
Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-ietf-acme-
telephone-01 (work in progress), October 2017.
[I-D.ietf-mmusic-trickle-ice-sip] [I-D.ietf-acme-authority-token]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Session Initiation Protocol (SIP) Usage for Incremental Challenges Using an Authority Token", draft-ietf-acme-
Provisioning of Candidates for the Interactive authority-token-03 (work in progress), March 2019.
Connectivity Establishment (Trickle ICE)", draft-ietf-
mmusic-trickle-ice-sip-18 (work in progress), June 2018.
[I-D.johnston-dispatch-osrtp] [I-D.ietf-sipbrandy-osrtp]
Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T. Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T.
Stach, "An Opportunistic Approach for Secure Real-time Stach, "An Opportunistic Approach for Secure Real-time
Transport Protocol (OSRTP)", draft-johnston-dispatch- Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-08
osrtp-02 (work in progress), February 2016. (work in progress), March 2019.
[I-D.kaplan-mmusic-best-effort-srtp] [I-D.kaplan-mmusic-best-effort-srtp]
Audet, F. and H. Kaplan, "Session Description Protocol Audet, F. and H. Kaplan, "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", draft-kaplan-mmusic-best-
effort-srtp-01 (work in progress), October 2006. effort-srtp-01 (work in progress), October 2006.
[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,
 End of changes. 48 change blocks. 
208 lines changed or deleted 202 lines changed or added

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