draft-ietf-sipbrandy-rtpsec-03.txt   draft-ietf-sipbrandy-rtpsec-04.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Best Current Practice E. Rescorla Intended status: Best Current Practice E. Rescorla
Expires: May 3, 2018 R. Barnes Expires: November 2, 2018 Mozilla
Mozilla R. Barnes
Cisco
R. Housley R. Housley
Vigilsec Vigil Security
October 30, 2017 May 1, 2018
Best Practices for Securing RTP Media Signaled with SIP Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-03.txt draft-ietf-sipbrandy-rtpsec-04.txt
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
skipping to change at page 1, line 43 skipping to change at page 1, line 44
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 May 3, 2018. This Internet-Draft will expire on November 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 28 skipping to change at page 2, line 33
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.1. Comprehensive Protection . . . . . . . . . . . . . . . . 3
3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . 8 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 9
6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9
7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 10
8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. Informative References . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
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, ranging from Digest authentication for
authenticating entities with a shared secret, to TLS for transport authenticating entities with a shared secret, to TLS for transport
security, to S/MIME (optionally) for body security. SIP is security, to 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
skipping to change at page 3, line 38 skipping to change at page 3, line 44
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]).
3.1. 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: SIP, the Session
Description Protocol (SDP), and the Real-time Protocol, in particular Description Protocol (SDP) [RFC4566], and the Real-time Protocol
its secure profile SRTP. Broadly, it is the responsibility of SIP to (RTP) [RFC3550], in particular its secure profile Secure RTP (SRTP)
provide integrity protection for the media keying attributes conveyed [RFC3711]. Broadly, it is the responsibility of SIP to provide
by SDP, and those attributes will in turn identify the keys used by integrity protection for the media keying attributes conveyed by SDP,
endpoints in the RTP media session(s) that SDP negotiates. In that and those attributes will in turn identify the keys used by endpoints
way, once SIP and SDP have exchanged the necessary information to in the RTP media session(s) that SDP negotiates. Note that this
initiate a session, media endpoints will have a strong assurance that framework does not apply to keys that also require confidentiality
the keys they exchange have not been tampered with by third parties, protection in the signaling layer, such as the SDP "k=" line, which
and that end-to-end confidentiality is available. MUST NOT be used in conjunction with this profile. 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.
Our current target mechanism for establishing the identity of the To establishing the identity of the endpoints of a SIP session, this
endpoints of a SIP session is the use of STIR specification uses STIR [RFC8224]. The STIR Identity header has been
[I-D.ietf-stir-rfc4474bis]. 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 only provides a signature
over the "a=fingerprint" attribute, which is a key fingerprint over the "a=fingerprint" attribute, which is a key fingerprint
utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers
comprehensive protection for SIP sessions, in concert with SDP and comprehensive protection for SIP sessions, in concert with SDP and
SRTP, when DTLS-SRTP is the media security service. The underlying SRTP, when DTLS-SRTP is the media security service. The underlying
PASSporT [I-D.ietf-stir-passport] object used by STIR is extensible, PASSporT [RFC8225] object used by STIR is extensible, however, and it
however, and it would be possible to provide signatures over other would be possible to provide signatures over other SDP attributes
SDP attributes that contain alternate keying material. A profile for that contain alternate keying material. A profile for using STIR to
using STIR to provide media confidentiality is given in Section 4. provide media confidentiality is given in Section 4.
3.2. Opportunistic Security 3.2. Opportunistic Security
Work is already underway on defining approaches to opportunistic Work is already underway on defining approaches to opportunistic
media security for SIP in [I-D.johnston-dispatch-osrtp], which builds 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 on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The
major protocol change proposed by that draft is to signal the use of major protocol change proposed by that specification is to signal the
opportunistic encryption by negotiating the AVP profile in SDP, use of opportunistic encryption by negotiating the AVP profile in
rather than the SAVP profile (as specified in [RFC3711]) that would SDP, rather than the SAVP profile (as specified in [RFC3711]) that
ordinarily be used when negotiating SRTP. would ordinarily be used when negotiating SRTP.
Opportunistic encryption approaches typically have no integrity Opportunistic encryption approaches typically have no integrity
protection for the keying material in SDP. Sending SIP over TLS hop- protection for the keying material in SDP. Sending SIP over TLS hop-
by-hop between user agents and any intermediaries will reduce the by-hop between user agents and any intermediaries will reduce the
prospect that active attackers can alter keys for session requests on prospect that active attackers can alter keys for session requests on
the wire. However, opportunistic confidentiality for media will the wire. However, opportunistic confidentiality for media will
prevent passive attacks of the form most common in the threat of prevent passive attacks of the form most common in the threat of
pervasive monitoring. pervasive monitoring.
4. STIR Profile for Endpoint Authentication and Verification Services 4. STIR Profile for Endpoint Authentication and Verification Services
STIR [I-D.ietf-stir-rfc4474bis] defines the Identity header field for STIR [RFC8224] defines the Identity header field for SIP, which
SIP, which provides a cryptographic attestation of the source of provides a cryptographic attestation of the source of communications.
communications. This profile assumes that a STIR verification This profile of STIR assumes that a STIR verification service will
service will act in concert with an SRTP media endpoint to ensure act in concert with an SRTP media endpoint to ensure that the key
that the key fingerprints, as given in SDP, match the keys exchanged fingerprints, as given in SDP, match the keys exchanged to establish
to establish DTLS-SRTP. To satisfy this condition, the verification DTLS-SRTP. To satisfy this condition, the verification service
service function would in this case be implemented in the SIP UAS, function would in this case be implemented in the SIP UAS, which
which would be composed with the media endpoint. If the STIR would be composed with the media endpoint. If the STIR
authentication service or verification service functions are authentication service or verification service functions are
implemented at an intermediary rather than an endpoint, this implemented at an intermediary rather than an endpoint, this
introduces the possibility that the intermediary could act as a man introduces the possibility that the intermediary could act as a man
in the middle, altering key fingerprints. As this attack is not in in the middle, altering key fingerprints. As this attack is not in
STIR's core threat model, which focuses on impersonation rather than STIR's core threat model, which focuses on impersonation rather than
man-in-the-middle attacks, STIR offers no specific protections man-in-the-middle attacks, STIR offers no specific protections
against such interference. The SIPBRANDY deployment profile of STIR against such interference.
for media confidentiality thus shifts these responsibilities to the
endpoints rather than the intermediaries. The SIPBRANDY deployment profile of STIR for media confidentiality
thus shifts these responsibilities to the endpoints rather than the
intermediaries. While intermediaries MAY provide the verification
service function of STIR for SIPBRANDY transactions, intermediaries
supporting this specification MUST NOT block or otherwise redirects
calls if they do not trust the signing 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 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 [I-D.ietf-stir-rfc4474bis]. verification service roles described in [RFC8224]. STIR
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 adding the "msec" header element defined in this
specification to the PASSporT header. Implementations MUST provide specification to the PASSporT header. Implementations MUST provide
key fingerprints in SDP and the appropriate signatures over them per key fingerprints in SDP and the appropriate signatures over them per
[I-D.ietf-stir-passport]. [RFC8225].
When generating either an offer or an answer, compliant When generating either an offer or an answer, 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 must acquire the credentials needed to sign for agent, SIP endpoints will need to acquire the credentials needed to
their own identity. That identity is typically carried in the From sign for their own identity. That identity is typically carried in
header field of a SIP request, and either contains a greenfield SIP the From header field of a SIP request, and either contains a
URI (e.g. "sip:alice@example.com") or a telephone number, which can greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone
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"). "sip:+17004561212@example.com;user=phone"). [RFC8224] Section 8
[I-D.ietf-stir-rfc4474bis] Section 8 contains guidance for separating contains guidance for separating the two, and determining what sort
the two, and determining what sort of credential is needed to sign of credential is needed to sign for each.
for each.
To date, few commercial certificate authorities issue certificates To date, few commercial certificate authorities issue certificates
for SIP URIs or telephone numbers; though work is ongoing on systems for SIP URIs or telephone numbers; though work is ongoing on systems
for this purpose (such as [I-D.peterson-acme-telephone]) it is not for this purpose (such as [I-D.ietf-acme-telephone]) it is not mature
mature enough to be recommended as a best practice. This is one enough to be recommended as a best practice. This is one reason why
reason why the STIR standard is architected to permit intermediaries the STIR standard is architected to permit intermediaries to act as
to act as an authentication service on behalf of an entire domain, an authentication service on behalf of an entire domain, just as in
just as in SIP an proxy server can provide domain-level SIP service. SIP an proxy server can provide domain-level SIP service. While
While certificate authorities that offered proof-of-possession certificate authorities that offered proof-of-possession certificates
certificates similar to those used in the email world could be similar to those used in the email world could be offered for SIP,
offered for SIP, either for greenfield identifiers or for telephone either for greenfield identifiers or for telephone numbers, this
numbers, this specification does not require their use. specification 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 for media permits the use of self-signed keys. This profile of STIR therefore
confidentiality therefore relaxes the authority requirements of relaxes the authority requirements of [RFC8224] to allow the use of
[I-D.ietf-stir-rfc4474bis] to allow the use of self-signed keys for self-signed keys for authentication services that are composed with
authentication services that are composed with user agents, by user agents, by generating a certificate (per the guidance of
generating a certificate (per the guidance of [RFC8226]) with a subject corresponding to the user's identity. Such
[I-D.ietf-stir-certificates]) with a subject corresponding to the a credential could be used for trust on first use (see [RFC7435]) by
user's identity. Such a credential could be used for trust on first relying parties. Note that relying parties SHOULD NOT use
use (see [RFC7435]) by relying parties. Note that relying parties certificate revocation mechanisms or real-time certificate
SHOULD NOT use certificate revocation mechanisms or real-time verification systems for self-signed certificates as they will not
certificate verification systems for self-signed certificates as they increase confidence in the certificate.
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 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.
skipping to change at page 6, line 33 skipping to change at page 6, line 50
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 certificate authorities that issue
credentials to end user devices going forward. credentials to end user 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. Per the recommendations of
[RFC3323], this may involve using an identity such as [RFC3323], this may involve using an identity such as
"anonymous@anonymous.invalid" in the identity fields of a SIP "anonymous@anonymous.invalid" in the identity fields of a SIP
request. [I-D.ietf-stir-rfc4474bis] does not currently permit request. [RFC8224] does not currently permit authentication services
authentication services to sign for requests that supply this to sign for requests that supply this identity. It does however
identity. It does however permit signing for valid domains, such as permit signing for valid domains, such as "anonymous@example.com," as
"anonymous@example.com," as a way of implementation an anonymization a way of implementation an anonymization service as specified in
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 new 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 [I-D.ietf-stir-rfc4474bis] provides integrity protection for the STIR [RFC8224] provides integrity protection for the SDP bodies of
SDP bodies of SIP requests, but not SIP responses. When a session is SIP requests, but not SIP responses. When a session is established,
established, therefore, any SDP body carried by a 200 class response therefore, any SDP body carried by a 200 class response in the
in the backwards direction will not be protected by an authentication backwards direction will not be protected by an authentication
service and cannot be verified. Thus, sending a secured SDP body in service and cannot be verified. Thus, sending a secured SDP body in
the backwards direction will require an extra RTT, typically a the backwards direction will require an extra RTT, typically a
request sent in the backwards direction. request sent in the backwards direction.
The problem of providing "Connected Identity" for the original The problem of providing "Connected Identity" for the original
RFC4474 was explored in [RFC4916], which uses a provisional or mid- RFC4474 was explored in [RFC4916], which uses a provisional or mid-
dialog UPDATE request in the backwards direction to convey an dialog UPDATE request in the backwards direction to convey an
Identity header for the recipient of an INVITE. The procedures in Identity header for the recipient of an INVITE. The procedures in
that specification are largely compatible with the revision of the that specification are largely compatible with the revision of the
Identity header in [I-D.ietf-stir-rfc4474bis]. However, the Identity header in [RFC8224]. However, the following updates to
following updates to [RFC4916] are required: [RFC4916] are required:
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 MUST be sent during dialog establishment, following the
receipt of a PRACK after a provisional 1xx response. receipt of a PRACK after a provisional 1xx response.
For use with this STIR Profile for media confidentiality, the UAS For use with this STIR Profile for media confidentiality, the UAS
that responds to the INVITE request MUST act as an authentication that responds to the INVITE request MUST act as an authentication
service for the UPDATE sent in the backwards direction. service for the UPDATE sent in the backwards direction.
The text in RFC4916 Section 4.4.1 regarding the receipt at a UAC The text in RFC4916 Section 4.4.1 regarding the receipt at a UAC
of error codes 428, 436, 437 and 438 in response to a mid-dialog of error codes 428, 436, 437 and 438 in response to a mid-dialog
request RECOMMENDS treating the dialog as terminated. request RECOMMENDS treating the dialog as terminated. [RFC8224]
[I-D.ietf-stir-rfc4474bis] allows the retransmission of requests allows the retransmission of requests with repairable error
with repairable error conditions (see section 6.1.1) in a way that conditions (see section 6.1.1) in a way that can override that
can override that SHOULD in RFC4916. In particular, an SHOULD in RFC4916. In particular, an authentication service MAY
authentication service MAY retry a mid-dialog as retry a mid-dialog as [RFC8224] allows rather than treating the
[I-D.ietf-stir-rfc4474bis] allows rather than treating the dialog dialog as terminated, though note that only one such retry is
as terminated, though note that only one such retry is permitted. permitted.
The examples in RFC4916 are based on the original RFC4474, and The examples in RFC4916 are based on the original RFC4474, and
will not match signatures using [I-D.ietf-stir-rfc4474bis]. will not match signatures using [RFC8224].
Future work may be done to revise RFC4916 for STIR; that work should Future work may be done to revise RFC4916 for STIR; that work should
take into account any impacts on the profile described in this take into account any impacts on the profile described in this
document. The use of RFC4916 has some further interactions with ICE; document. The use of RFC4916 has some further interactions with ICE;
see Section 7. see Section 7.
4.4. Authorization Decisions 4.4. Authorization Decisions
[I-D.ietf-stir-rfc4474bis] grants STIR verification services a great [RFC8224] grants STIR verification services a great deal of latitude
deal of latitude when making authorization decisions based on the when making authorization decisions based on the presence of the
presence of the Identity header field. It is largely a matter of Identity header field. It is largely a matter of local policy
local policy whether an endpoint rejects a call based on absence of whether an endpoint rejects a call based on absence of an Identity
an Identity header field, or even the presence of a header that fails header field, or even the presence of a header that fails an
an integrity check against the request. integrity check against the request.
For this profile, however, a compliant verification service that For this profile, however, a compliant verification service that
receives a dialog-forming SIP request containing an Identity header receives a dialog-forming SIP request containing an Identity header
with a PASSporT type of "msec", after validating the request per the with a PASSporT type of "msec", after validating the request per the
steps described in [I-D.ietf-stir-rfc4474bis] Section 6.2, MUST steps described in [RFC8224] Section 6.2, MUST reject the request if
reject the request if there is any failure in that validation process there is any failure in that validation process with the appropriate
with the appropriate status code per Section 6.2.2. If the request status code per Section 6.2.2. If the request is valid, then if a
is valid, then if a terminating user accepts the request, it MUST terminating user accepts the request, it MUST then follow the steps
then follow the steps in Section 4.3 to act as an authentication in Section 4.3 to act as an authentication service and send a signed
service and send a signed request with the "msec" PASSPorT type in request with the "msec" PASSPorT type in its Identity header as well,
its Identity header as well, in order to enable end-to-end in order to enable end-to-end bidirectional confidentiality.
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 in a SIP request with an unrecognized PASSporT type
will simply ignore that Identity header, an authentication service will simply ignore that Identity header, an authentication service
will know whether or not the terminating side supports "msec" based will know whether or not the terminating side supports "msec" based
on whether or not its user agent receives a signed request in the on whether or not its user agent receives a signed request in the
backwards direction per Section 4.3. If no such requests are backwards direction per Section 4.3. If no such requests are
skipping to change at page 9, line 5 skipping to change at page 9, line 17
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.johnston-dispatch-osrtp], opportunistic approaches considered
include DTLS-SRTP, security descriptions [RFC4568], and ZRTP include DTLS-SRTP, security descriptions [RFC4568], and ZRTP
[RFC6189]. [RFC6189].
DTLS-SRTP is the only Standards Track Internet protocol for media Support for DTLS-SRTP is REQUIRED by this specification.
security. For that reason, this specification REQUIRES support for
DTLS-SRTP.
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
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
skipping to change at page 11, line 17 skipping to change at page 11, line 22
This specification defines a new values for the PASSporT Type This specification defines a new values for the PASSporT Type
registry called "msec," and the IANA is requested to add that to the registry called "msec," and the IANA is requested to add that to the
registry with a value pointing to [RFCThis]. registry with a value pointing to [RFCThis].
11. Security Considerations 11. 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.
12. Informative References 12. References
[I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-14 (work in progress), October 2017.
[I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) usage for Trickle ICE",
draft-ietf-mmusic-trickle-ice-sip-10 (work in progress),
October 2017.
[I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir-
certificates-14 (work in progress), May 2017.
[I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in
progress), February 2017.
[I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017.
[I-D.johnston-dispatch-osrtp]
Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T.
Stach, "An Opportunistic Approach for Secure Real-time
Transport Protocol (OSRTP)", draft-johnston-dispatch-
osrtp-02 (work in progress), February 2016.
[I-D.kaplan-mmusic-best-effort-srtp]
Audet, F. and H. Kaplan, "Session Description Protocol
(SDP) Offer/Answer Negotiation For Best-Effort Secure
Real-Time Transport Protocol", draft-kaplan-mmusic-best-
effort-srtp-01 (work in progress), October 2006.
[I-D.peterson-acme-telephone] 12.1. Normative References
Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-peterson-acme-
telephone-00 (work in progress), October 2016.
[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 12, line 37 skipping to change at page 11, line 47
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, Initiation Protocol (SIP)", RFC 3323,
DOI 10.17487/RFC3323, November 2002, DOI 10.17487/RFC3323, November 2002,
<https://www.rfc-editor.org/info/rfc3323>. <https://www.rfc-editor.org/info/rfc3323>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<https://www.rfc-editor.org/info/rfc4568>. <https://www.rfc-editor.org/info/rfc4568>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <https://www.rfc-editor.org/info/rfc4916>. 2007, <https://www.rfc-editor.org/info/rfc4916>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
skipping to change at page 14, line 10 skipping to change at page 13, line 28
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <https://www.rfc-editor.org/info/rfc7675>. October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
<https://www.rfc-editor.org/info/rfc7879>. <https://www.rfc-editor.org/info/rfc7879>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
12.2. Informative References
[I-D.ietf-acme-telephone]
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-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-20 (work in progress), March 2018.
[I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Trickle ICE",
draft-ietf-mmusic-trickle-ice-sip-14 (work in progress),
February 2018.
[I-D.johnston-dispatch-osrtp]
Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T.
Stach, "An Opportunistic Approach for Secure Real-time
Transport Protocol (OSRTP)", draft-johnston-dispatch-
osrtp-02 (work in progress), February 2016.
[I-D.kaplan-mmusic-best-effort-srtp]
Audet, F. and H. Kaplan, "Session Description Protocol
(SDP) Offer/Answer Negotiation For Best-Effort Secure
Real-Time Transport Protocol", draft-kaplan-mmusic-best-
effort-srtp-01 (work in progress), October 2006.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: jon.peterson@neustar.biz Email: jon.peterson@team.neustar
Eric Rescorla Eric Rescorla
Mozilla Mozilla
Email: ekr@rtfm.com Email: ekr@rtfm.com
Richard Barnes Richard Barnes
Mozilla Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
Russ Housley Russ Housley
Vigilsec Vigil Security, LLC
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 39 change blocks. 
164 lines changed or deleted 181 lines changed or added

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