draft-ietf-sipbrandy-osrtp-04.txt   draft-ietf-sipbrandy-osrtp-05.txt 
SIPBRANDY Working Group A. Johnston SIPBRANDY Working Group A. Johnston
Internet-Draft Rowan University Internet-Draft Rowan University
Intended status: Informational B. Aboba Intended status: Informational B. Aboba
Expires: September 16, 2018 Microsoft Expires: March 18, 2019 Microsoft
A. Hutton A. Hutton
Atos Atos
R. Jesske R. Jesske
Deutsche Telekom Deutsche Telekom
T. Stach T. Stach
Unaffiliated Unaffiliated
March 15, 2018 September 14, 2018
An Opportunistic Approach for Secure Real-time Transport Protocol An Opportunistic Approach for Secure Real-time Transport Protocol
(OSRTP) (OSRTP)
draft-ietf-sipbrandy-osrtp-04 draft-ietf-sipbrandy-osrtp-05
Abstract Abstract
Opportunistic Secure Real-time Transport Protocol (OSRTP) is an Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
implementation of the Opportunistic Security mechanism, as defined in implementation of the Opportunistic Security mechanism, as defined in
RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP
allows encrypted media to be used in environments where support for allows encrypted media to be used in environments where support for
encryption is not known in advance, and not required. OSRTP does not encryption is not known in advance, and not required. OSRTP does not
require SDP extensions or features and is fully backwards compatible require SDP extensions or features and is fully backwards compatible
with existing implementations using encrypted and authenticated media with existing implementations using encrypted and authenticated media
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 September 16, 2018. This Internet-Draft will expire on March 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Opportunistic Security for SRTP . . . . . . . . 3 3. SDP Offer/Answer Considerations . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 3.1. Generating the Initial OSRTP Offer . . . . . . . . . . . 4
3.2. Generating the Answer . . . . . . . . . . . . . . . . . . 4
3.3. Offerer Processing the Answer . . . . . . . . . . . . . . 4
3.4. Modifying the Session . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Opportunistic Security [RFC7435] (OS) is an approach to security that Opportunistic Security [RFC7435] (OS) is an approach to security that
defines a third mode for security between "cleartext" and defines a third mode for security between "cleartext" and
"comprehensive protection" that allows encryption and authentication "comprehensive protection" that allows encryption and authentication
to be used if supported but will not result in failures if it is not to be used if supported but will not result in failures if it is not
supported. In terms of secure media, cleartext is RTP [RFC3550] supported. In terms of secure media, cleartext is RTP [RFC3550]
media which is negotiated with the RTP/AVP (Audio Video Profile) media which is negotiated with the RTP/AVP (Audio Video Profile)
profile defined [RFC3551]. Comprehensive protection is Secure RTP profile defined [RFC3551]. Comprehensive protection is Secure RTP
skipping to change at page 3, line 33 skipping to change at page 3, line 37
attempting to transition to fully secure communications. New attempting to transition to fully secure communications. New
applications and new deployments will not use OSRTP. applications and new deployments will not use OSRTP.
2. Requirements Language 2. Requirements Language
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 RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Definition of Opportunistic Security for SRTP 3. SDP Offer/Answer Considerations
This section defines the SDP offer/answer considerations for
opportunistic security.
The procedures are for a specific m- section describing RTP-based
media. If an SDP offer or answer contains multiple such m- sections,
the procedures are applied to each m- section individually.
"Initial OSRTP offer" refers to the offer in which oportunistic
security is offered for an m- section for the first time within an
SDP session.
It is important to note that OSRTP makes no changes, and has no
effect on media sessions in which the offer contains a secure profile
of RTP, such as SAVP or SAVPF. As discussed in [RFC7435], this is
the "comprehensive protection" for media mode.
3.1. Generating the Initial OSRTP Offer
To indicate support for OSRTP in an SDP offer, the offerer uses the To indicate support for OSRTP in an SDP offer, the offerer uses the
RTP/AVP profile [RFC3551] but includes SRTP keying attributes. OSRTP RTP/AVP profile [RFC3551] but includes SRTP keying attributes. OSRTP
is not specific to any key management technique for SRTP. For is not specific to any key management technique for SRTP. For
example: example:
If the offerer supports DTLS-SRTP key agreement [RFC5763], then an If the offerer supports DTLS-SRTP key agreement [RFC5763], then an
a=fingerprint attribute will be present, or a=fingerprint attribute will be present, or
If the offerer supports SDP Security Descriptions key agreement If the offerer supports SDP Security Descriptions key agreement
[RFC4568], then an a=crypto attribute will be present, or [RFC4568], then an a=crypto attribute will be present, or
If the offerer supports ZRTP key agreement [RFC6189], then an If the offerer supports ZRTP key agreement [RFC6189], then an
a=zrtp-hash attribute will be present. a=zrtp-hash attribute will be present.
3.2. Generating the Answer
To accept OSRTP, an answerer receiving an offer indicating support To accept OSRTP, an answerer receiving an offer indicating support
for OSRTP generates an SDP answer containing SRTP keying attributes for OSRTP generates an SDP answer containing SRTP keying attributes
which match one of the keying methods in the offer. The answer MUST which match one of the keying methods in the offer. The answer MUST
NOT contain attributes from more than one keying method, even if the NOT contain attributes from more than one keying method, even if the
offer contained multiple keying method attributes. The selected SRTP offer contained multiple keying method attributes. The selected SRTP
key management approach is followed and SRTP media is used for this key management approach is followed and SRTP media is used for this
session. If the SRTP key management fails for any reason, the media session. If the SRTP key management fails for any reason, the media
session MUST fail. To decline OSRTP, the answerer generates an SDP session MUST fail. To decline OSRTP, the answerer generates an SDP
answer omitting SRTP keying attributes, and the media session answer omitting SRTP keying attributes, and the media session
proceeds with RTP with no encryption or authentication used. proceeds with RTP with no encryption or authentication used.
3.3. Offerer Processing the Answer
If the offerer of OSRTP receives an SDP answer which does not contain If the offerer of OSRTP receives an SDP answer which does not contain
SRTP keying attributes, then the media session proceeds with RTP. If SRTP keying attributes, then the media session proceeds with RTP. If
the SDP answer contains the RTP/AVP profile with SRTP keying the SDP answer contains the RTP/AVP profile with SRTP keying
attributes or the SAVP (or UDP/TLS/RTP/SAVP(F)) profile with SRTP attributes or the SAVP (or UDP/TLS/RTP/SAVP(F)) profile with SRTP
keying attributes, then that particular SRTP key management approach keying attributes, then that particular SRTP key management approach
is followed and SRTP media is used for this session. If the SRTP key is followed and SRTP media is used for this session. If the SRTP key
management fails, the media session MUST fail. management fails, the media session MUST fail.
It is important to note that OSRTP makes no changes, and has no 3.4. Modifying the Session
effect on media sessions in which the offer contains a secure profile
of RTP, such as SAVP or SAVPF. As discussed in [RFC7435], this is When an offerer generates a subsequent offer it should do so
the "comprehensive protection" for media mode. following the principles of [RFC6337] meaning that the decision to
create an OSRTP type offer or something else should not be influenced
by what was previously negotiated. For example if a previous OSRTP
offer did not result in SRTP being established the offerer may try
again and generate a new OSRTP offer as specified in section [3.1].
4. Security Considerations 4. Security Considerations
The security considerations of [RFC7435] apply to OSRTP, as well as The security considerations of [RFC7435] apply to OSRTP, as well as
the security considerations of the particular SRTP key agreement the security considerations of the particular SRTP key agreement
approach used. However, the authentication requirements of a approach used. However, the authentication requirements of a
particular SRTP key agreement approach are relaxed when that key particular SRTP key agreement approach are relaxed when that key
agreement is used with OSRTP. For example: agreement is used with OSRTP. For example:
For DTLS-SRTP key agreement [RFC5763], an authenticated signaling For DTLS-SRTP key agreement [RFC5763], an authenticated signaling
skipping to change at page 5, line 43 skipping to change at page 6, line 25
SIP Forum planned to include support in the SIPconnect 2.0 SIP SIP Forum planned to include support in the SIPconnect 2.0 SIP
trunking recommendation [SIPCONNECT]. There are many deployments of trunking recommendation [SIPCONNECT]. There are many deployments of
ZRTP [RFC6189]. ZRTP [RFC6189].
6. Acknowledgements 6. Acknowledgements
This document is dedicated to our friend and colleague Francois Audet This document is dedicated to our friend and colleague Francois Audet
who is greatly missed in our community. His work on improving who is greatly missed in our community. His work on improving
security in SIP and RTP provided the foundation for this work. security in SIP and RTP provided the foundation for this work.
Thanks to Eric Rescorla, Martin Thomson, and Richard Barnes for their Thanks to Eric Rescorla, Martin Thomson, Christer Holmberg, and
comments. Richard Barnes for their comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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>.
skipping to change at page 7, line 26 skipping to change at page 8, line 5
[IMTC-SIP] [IMTC-SIP]
"Best Practices for SIP Security", IMTC SIP Parity "Best Practices for SIP Security", IMTC SIP Parity
Group http://www.imtc.org/uc/sip-parity-activity-group/, Group http://www.imtc.org/uc/sip-parity-activity-group/,
2011, <http://www.imtc.org>. 2011, <http://www.imtc.org>.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939,
September 2010, <https://www.rfc-editor.org/info/rfc5939>. September 2010, <https://www.rfc-editor.org/info/rfc5939>.
[RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session
Initiation Protocol (SIP) Usage of the Offer/Answer
Model", RFC 6337, DOI 10.17487/RFC6337, August 2011,
<https://www.rfc-editor.org/info/rfc6337>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<https://www.rfc-editor.org/info/rfc6982>. <https://www.rfc-editor.org/info/rfc6982>.
[SIPCONNECT] [SIPCONNECT]
"SIP-PBX / Service Provider Interoperability SIPconnect "SIP-PBX / Service Provider Interoperability SIPconnect
2.0 - Technical Recommendation", SIP Forum http://www.sipf 2.0 - Technical Recommendation", SIP Forum http://www.sipf
orum.org/component/option,com_docman/task,doc_download/ orum.org/component/option,com_docman/task,doc_download/
gid,838/Itemid,261/, 2017, <http://www.sipforum.org>. gid,838/Itemid,261/, 2017, <http://www.sipforum.org>.
skipping to change at page 8, line 14 skipping to change at page 8, line 40
Bernard Aboba Bernard Aboba
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: bernard.aboba@gmail.com Email: bernard.aboba@gmail.com
Andrew Hutton Andrew Hutton
Atos Atos
4 Triton Square Mid City Place
London NW1 3HG London WC1V 6EA
UK UK
Email: andrew.hutton@atos.net Email: andrew.hutton@atos.net
Roland Jesske Roland Jesske
Deutsche Telekom Deutsche Telekom
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: R.Jesske@telekom.de Email: R.Jesske@telekom.de
Thomas Stach Thomas Stach
Unaffiliated Unaffiliated
 End of changes. 15 change blocks. 
20 lines changed or deleted 54 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/