Re: [AVT] question on draft-mattsson-srtp-store-and-forward-00.txt

[Randell Jesup <rjesup at wgate.com>]

Rolf Blom J <rolf.j.blom at ericsson.com> writes:
>Thanks for all your comments. They really highlight the problems we have
>seen when we tried to design our solution for end-to-end security combined
>with hop-by-hop security in a store and forward application.
>
>We want to point out that the voice mail application is just one example
>application but we use it because it exhibits many of the problems
>encountered  including those that you have pointed ourt. Thus it is an
>excellent starting point for deriving requirements. If we can design a
>solution fulfilling those requirements we believe that all important store
>and forward applications would also be covered. In the next version of the
>draft we will expand on these other applications.
>
>We also want to make it clear that SRTP Store and Forward is intended for
>services where end-to-end security is the driving requirement. This means
>that users would be willing/have to abstain from services relying on the
>availability of plaintext, e.g for trancoding, speed-up, slow-down, etc.
>However, skipping in the media stream and other random seek functions
>would be possible with the proposed solution.

If you can't modify the timestamps and sequence numbers (and you can't if
you store-and-forward SRTP/SRTCP packets), skipping and seek are
problematic at best unless you also control the endpoint.  The only way I
see to do it is with a re-INVITE to effectively start a "new" stream
whenever you do any sort of "jump" in the stream.  Also, the re-INVITE
might not work if the endpoint responds with the same RTP port - it may
interpret the packets as out-of-order packets from the original INVITE
session.

That said, many RTP stacks (in order to deal with talking to other,
poorly-compliant clients) allow for resetting sequence and timestamp values
when the other side "jumps" (a rather arbitrary decision) - but a client
implementing strict security (or an SRTP library that's fairly strict about
replay attacks) might still refuse to do so.  Even if it does accept a
"jump", it may take a number of packets in a row before it does, and short
"jumps" would be assumed to be network issues.

>It will of course be necessary to have a hint track associated with the
>recorded encrypted media which would be used when retransmitting it.  We
>did not mention the need for the hint track as we wanted to focus on the
>pure security and SRTP issues.
>
>In the solution sketch the media payload is encrypted independently of the
>transport (RTP headers), and thus fulfills exactly the requirement stated
>by David Oran ("This makes any content privacy and integrity properties
>have to be independent of the transport privacy and integrity
>properties")  When protected media is forwarded with hop-by-hop protection
>a new and independent RTP/SRTP session will be initiated.

If the payload is encrypted separately from the headers in the initial
recording, this solves many of the above problems - but now the initial
connection (and the connection to the playback UA) are no longer SRTP (or
are SRTP, but containing an already-encrypted payload, thus
doubly-encrypting it, or by specifying a NULL encryption for the SRTP layer
- just authentication - to avoid double-encryption).

Note that these solutions all require endpoints that implement a new
set of RFCs/etc to support this, even to leave the message.


-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt