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

From: [email-masked]
Date: Mon, 16 Jul 2012 09:14:30 -0700

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-02.txt
	Pages           : 15
	Date            : 2012-07-16

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 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-02

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

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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 16 Jul 2012 12:23:30 -0400

Hello, all --

This revision of the draft incorporates comments received during WGLC.

The main change in this version of the draft is that it now normatively updates RFC 3711 (SRTP), to state that all future SRTP encryption transforms MUST specify how they're to be used with header extension encryption.

The draft now also specifically defines how it's used with SEED (RFC 5669), as well as the NULL cipher.

There aren't any technical changes to the header extension mechanism, though there are a number of clarifications.  See Appendix B.1 for a full change log.

On Jul 16, 2012, at 12:14 PM, <[email-masked]> wrote:

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

--
Jonathan Lennox
[email-masked]