draft-ietf-sipbrandy-osrtp-00.txt   draft-ietf-sipbrandy-osrtp-01.txt 
DISPATCH Working Group A. Johnston SIPBRANDY Working Group A. Johnston
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track B. Aboba Intended status: Standards Track B. Aboba
Expires: February 11, 2017 Microsoft Expires: May 3, 2017 Microsoft
A. Hutton A. Hutton
Unify Unify
L. Liess R. Jesske
Deutsche Telekom Deutsche Telekom
T. Stach T. Stach
Unaffiliated Unaffiliated
August 10, 2016 October 30, 2016
An Opportunistic Approach for Secure Real-time Transport Protocol An Opportunistic Approach for Secure Real-time Transport Protocol
(OSRTP) (OSRTP)
draft-ietf-sipbrandy-osrtp-00 draft-ietf-sipbrandy-osrtp-01
Abstract Abstract
Opportunistic Secure Real-time Transport Protocol (OSRTP) allows Opportunistic Secure Real-time Transport Protocol (OSRTP) allows
encrypted media to be used in environments where support for encrypted media to be used in environments where support for
encryption is not known in advance, and not required. OSRTP is an encryption is not known in advance, and not required. OSRTP is an
implementation of Opportunistic Security, as defined in RFC 7435. implementation of Opportunistic Security, as defined in RFC 7435.
OSRTP does not require advanced SDP extensions or features and is OSRTP does not require advanced SDP extensions or features and is
fully backwards compatible with existing secure and insecure fully backwards compatible with existing secure and insecure
implementations. OSRTP is not specific to any key management implementations. OSRTP is not specific to any key management
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 11, 2017. This Internet-Draft will expire on May 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 4, line 12 skipping to change at page 4, line 12
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.
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 SRTP keying attributes, then that particular the SDP answer contains the AVP (or RTP/AVP) profile with SRTP keying
SRTP key management approach is followed and SRTP media is used for attributes or the SAVP (or UDP/TLS/RTP/SAVP(F)) profile with SRTP
this session. If the SRTP key management fails, the media session keying attributes, then that particular SRTP key management approach
MUST fail. is followed and SRTP media is used for this session. If the SRTP key
management fails, the media session MUST fail.
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.
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
skipping to change at page 8, line 20 skipping to change at page 8, line 20
Email: bernard.aboba@gmail.com Email: bernard.aboba@gmail.com
Andy Hutton Andy Hutton
Unify Unify
Technology Drive Technology Drive
Nottingham NG9 1LA Nottingham NG9 1LA
UK UK
Email: andrew.hutton@unify.com Email: andrew.hutton@unify.com
Laura Liess Roland Jesske
Deutsche Telekom Deutsche Telekom
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: laura.liess.dt@googlemail.com Email: R.Jesske@telekom.de
Thomas Stach Thomas Stach
Unaffiliated Unaffiliated
Email: thomass.stach@gmail.com Email: thomass.stach@gmail.com
 End of changes. 9 change blocks. 
12 lines changed or deleted 13 lines changed or added

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