draft-ietf-sipbrandy-osrtp-03.txt   draft-ietf-sipbrandy-osrtp-04.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: March 22, 2018 Microsoft Expires: September 16, 2018 Microsoft
A. Hutton A. Hutton
Unify / Atos Atos
R. Jesske R. Jesske
Deutsche Telekom Deutsche Telekom
T. Stach T. Stach
Unaffiliated Unaffiliated
September 18, 2017 March 15, 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-03 draft-ietf-sipbrandy-osrtp-04
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 22, 2018. This Internet-Draft will expire on September 16, 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 4, line 39 skipping to change at page 4, line 39
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
channel does not need to be used with OSRTP if it is not channel does not need to be used with OSRTP if it is not
available. available.
For SDP Security Descriptions key agreement [RFC4568], an For SDP Security Descriptions key agreement [RFC4568], an
authenticated signaling channel does not need to be used with authenticated signaling channel does not need to be used with
OSRTP if it is not available, although an encrypted signaling OSRTP if it is not available, although an encrypted signaling
channel must still be used. The use of SDP Security Descriptions channel must still be used.
using the RTP/AVP profile is defined in
[I-D.mmusic-opportunistic-negotiation].
For ZRTP key agreement [RFC6189], the security considerations are For ZRTP key agreement [RFC6189], the security considerations are
unchanged, since ZRTP does not rely on the security of the unchanged, since ZRTP does not rely on the security of the
signaling channel. signaling channel.
As discussed in [RFC7435], OSRTP is used in cases where support for As discussed in [RFC7435], OSRTP is used in cases where support for
encryption by the other party is not known in advance, and not encryption by the other party is not known in advance, and not
required. For cases where it is known that the other party supports required. For cases where it is known that the other party supports
SRTP or SRTP needs to be used, OSRTP MUST NOT be used. Instead, a SRTP or SRTP needs to be used, OSRTP MUST NOT be used. Instead, a
secure profile of RTP is used in the offer. secure profile of RTP is used in the offer.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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, and Richard Barnes for their
comments. comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.mmusic-opportunistic-negotiation]
Hutton, A., Jesske, R., Johnston, A., Salgueiro, G., and
B. Aboba, "Negotiating SRTP and RTCP Feedback using the
RTP/AVP Profile", draft-mmusic-opportunistic-
negotiation-00 (work in progress), June 2017.
[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>.
[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>.
skipping to change at page 8, line 13 skipping to change at page 8, line 13
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
Email: bernard.aboba@gmail.com Email: bernard.aboba@gmail.com
Andrew Hutton Andrew Hutton
Unify / Atos Atos
4 Triton Square 4 Triton Square
London NW1 3HG London NW1 3HG
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
 End of changes. 9 change blocks. 
16 lines changed or deleted 8 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/