Subject: [AVT] [Action] Review AVT announcement

From: Rolf Blom <[email-masked]>
Date: Mon, 09 Mar 2009 16:58:47 +0100

Hi All,

We have submitted a version 02 of draft-mattsson-srtp-store-and-forward
and a version 00 of draft-naslund-srtp-saf.

http://www.ietf.org/internet-drafts/draft-mattsson-srtp-store-and-forward-02.txt

http://www.ietf.org/internet-drafts/draft-naslund-srtp-saf-00.txt

The main changes in draft-mattsson-srtp-store-and-forward
are:

1. New title "SRTP Store-and-Forward Use Cases and Requirements".

2.
New intended status: Informational.

3. Removal of
details of the transform used for e2e media protection. This is now
included in draft-naslund-srtp-saf.

4.
Clarifying the concept of store-and-forward e2e sessions defined as the
set of
store-and-forward e2e protected data produced under a single e2e
context.

5. Addition of an appendix outlining example key
management for media distribution and answering machine applications.

A very
brief presentation of the new draft-naslund-srtp-saf is:

1. Title: The Use of
the Secure Real-time Transport Protocol (SRTP) in Store-and-Forward
Applications.

2. Intended status: Standard Track.

3. Contains a detailed specification of SRTP store and forward.

4. The extensions to RFC 3711 defined are conceptually almost identical
to the SRTP extensions previously defined in [RFC4383], which adds
source origin authentication support to SRTP.

5. Reuses the defined default transforms of RFC 3711 for e2e protection.

6. Abstract

This memo describes the use of so called store-and-forward

cryptographic transforms within the Secure Real-time Transport

Protocol (SRTP).  The motivation is to support use cases when two

end-points communicate via one (or more) store-and-forward

middleboxes that are not fully trusted to access the media content.

One of the main aspects of the transform is to make the

confidentiality and message authentication independent of the RTP

header.  Another central aspect is to make identification of the

cryptographic context (keys etc.) independent of RTP transport

parameters.  Besides the security of the end-points, also trust

assumptions regarding the store-and-forward middleboxes are

addressed.

We welcome all comments

Regards

Rolf