Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt

From: [email-masked]
Date: Fri, 08 Feb 2013 09:15:14 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)
	Author(s)       : Jonathan Lennox
	Filename        : draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt
	Pages           : 17
	Date            : 2013-02-08

Abstract:
   The Secure Real-Time Transport Protocol (SRTP) provides
   authentication, but not encryption, of the headers of Real-Time
   Transport Protocol (RTP) packets.  However, RTP header extensions may
   carry sensitive information for which participants in multimedia
   sessions want confidentiality.  This document provides a mechanism,
   extending the mechanisms of SRTP, to selectively encrypt RTP header
   extensions in SRTP.

   This document updates RFC 3711, the Secure Real-Time Transport
   Protocol specification, to require that all future SRTP encryption
   transforms specify how RTP header extensions are to be encrypted.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-encrypted-header-ext

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-encrypted-header-ext-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 8 Feb 2013 12:23:50 -0500

Hello, all --

This version of the srtp-encrypted-header-ext draft addresses issues brought up in IESG review: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-encrypted-header-ext/ballot/ .

There are no protocol changes.  The only significant normative change is to make it clear that offering both encrypted and unencrypted forms of the same header extension is only for backward compatibility: you MUST NOT ever negotiate to use, or actually send, both encrypted and unencrypted forms of the same header extension.

See the diff for the full list of changes.

On Feb 8, 2013, at 12:15 PM, <[email-masked]> wrote:

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

--
Jonathan Lennox
[email-masked]