draft-ietf-sipbrandy-osrtp-05.txt   draft-ietf-sipbrandy-osrtp-06.txt 
SIPBRANDY Working Group A. Johnston SIPBRANDY Working Group A. Johnston
Internet-Draft Rowan University Internet-Draft Villanova University
Intended status: Informational B. Aboba Intended status: Informational B. Aboba
Expires: March 18, 2019 Microsoft Expires: June 1, 2019 Microsoft
A. Hutton A. Hutton
Atos Atos
R. Jesske R. Jesske
Deutsche Telekom Deutsche Telekom
T. Stach T. Stach
Unaffiliated Unaffiliated
September 14, 2018 November 28, 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-05 draft-ietf-sipbrandy-osrtp-06
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 March 18, 2019. This Internet-Draft will expire on June 1, 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 46 skipping to change at page 2, line 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 [RFC3551] or the RTP/AVPF profile [RFC4585]. Comprehensive
[RFC3711], negotiated with a secure profile, such as SAVP or SAVPF protection is Secure RTP [RFC3711], negotiated with a secure profile,
[RFC5124]. OSRTP allows SRTP to be negotiated with the RTP/AVP such as SAVP or SAVPF [RFC5124]. OSRTP allows SRTP to be negotiated
profile, with fallback to RTP if SRTP is not supported. with the RTP/AVP profile, with fallback to RTP if SRTP is not
supported.
There have been some extensions to SDP to allow profiles to be There have been some extensions to SDP to allow profiles to be
negotiated such as SDP Capabilities Negotiation (capneg) [RFC5939] . negotiated such as SDP Capabilities Negotiation (capneg) [RFC5939] .
However, these approaches are complex and have very limited However, these approaches are complex and have very limited
deployment in communication systems. Other key management protocols deployment in communication systems. Other key management protocols
for SRTP have been developed which by design use OS, such as ZRTP for SRTP have been developed which by design use OS, such as ZRTP
[RFC6189]. This approach for OSRTP is based on [RFC6189]. This approach for OSRTP is based on
[I-D.kaplan-mmusic-best-effort-srtp] where it was called "best effort [I-D.kaplan-mmusic-best-effort-srtp] where it was called "best effort
SRTP". [I-D.kaplan-mmusic-best-effort-srtp] has a full discussion of SRTP". [I-D.kaplan-mmusic-best-effort-srtp] has a full discussion of
the motivation and requirements for opportunistic secure media. the motivation and requirements for opportunistic secure media.
OSRTP uses the presence of SRTP keying-related attributes in an SDP OSRTP uses the presence of SRTP keying-related attributes in an SDP
offer to indicate support for opportunistic secure media. The offer to indicate support for opportunistic secure media. The
skipping to change at page 4, line 10 skipping to change at page 4, line 13
SDP session. SDP session.
It is important to note that OSRTP makes no changes, and has no 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 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 of RTP, such as SAVP or SAVPF. As discussed in [RFC7435], this is
the "comprehensive protection" for media mode. the "comprehensive protection" for media mode.
3.1. Generating the Initial OSRTP Offer 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] or the RTP/AVPF profile [RFC4585] but
is not specific to any key management technique for SRTP. For includes SRTP keying attributes. OSRTP is not specific to any key
example: management technique for SRTP. For 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.
skipping to change at page 4, line 40 skipping to change at page 4, line 43
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 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 SRTP keying attributes then the associated
attributes or the SAVP (or UDP/TLS/RTP/SAVP(F)) profile with SRTP SRTP key management approach is followed and SRTP media is used for
keying attributes, then that particular SRTP key management approach this session. If the SRTP key management fails, the media session
is followed and SRTP media is used for this session. If the SRTP key MUST fail.
management fails, the media session MUST fail.
3.4. Modifying the Session 3.4. Modifying the Session
When an offerer generates a subsequent offer it should do so When an offerer generates a subsequent offer it should do so
following the principles of [RFC6337] meaning that the decision to following the principles of [RFC6337] meaning that the decision to
create an OSRTP type offer or something else should not be influenced create an OSRTP type offer or something else should not be influenced
by what was previously negotiated. For example if a previous OSRTP by what was previously negotiated. For example if a previous OSRTP
offer did not result in SRTP being established the offerer may try 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]. again and generate a new OSRTP offer as specified in section [3.1].
skipping to change at page 7, line 15 skipping to change at page 7, line 15
[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>.
[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>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
skipping to change at page 8, line 24 skipping to change at page 8, line 28
[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>.
Authors' Addresses Authors' Addresses
Alan Johnston Alan Johnston
Rowan University Villanova University
Glassboro, NJ Villanova, PA
USA USA
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Bernard Aboba Bernard Aboba
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
 End of changes. 11 change blocks. 
20 lines changed or deleted 25 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/