[AVT] [Action] Review AVT announcement

[Rolf Blom <[e-mail]>]

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" rel="nofollow">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" rel="nofollow">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