Hi,
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.
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.
Rolf and John
David McGrew wrote:
Hi Dave,
On Jul 29, 2008, at 5:26 AM, David R Oran wrote:
On Jul 29, 2008, at 8:13 AM, Dan Wing wrote:
-----Original Message-----
From: Rolf Blom J [mailto:rolf.j.blom at ericsson.com]
Sent: Tuesday, July 29, 2008 11:09 AM
To: Dan Wing; David McGrew
Cc: AVT
Subject: RE: [AVT] question on
draft-mattsson-srtp-store-and-forward-00.txt
Hello,
We see 2 main reasons why it is not possible to use simple
retransmission of an SRTP stream in a general Store & Forward
scenario.
1) Using simple retransmission of the SRTP stream would only
give end-to-end protection but no transport protection
(hop-by-hop and would thus comply with the assumed trust model.b
2) It would not be possible to perform playback functions
like rewind and fast forward (random seek operations). As we
understand this is the reason for the changes in the
draft-wing-avt-dtls-srtp-key-transport-02 (removal of similar
technique).
draft-mattsson-srtp-store-and-forward says that the fast forward
/ rewind difficulty is resolved by allowing the storage device
(voicemail server) to re-construct the SRTP header.
I'll let Dave Oran (who co-chairs SPEECHSC) why SPEECSH found
a problem with storing and forwarding RTP. However, it is my
understanding that SPEECSH found the problem with *RTP*. If
my understanding is correct, the proposal in
draft-mattsson-srtp-store-and-forward would suffer the same
fate -- because the problem is with RTP (not SRTP).
The problem is partly that the speechsc formulation of the stored media
playback problem is that the playback is in fact not the un-transformed
stored audio/video. With speechsc you can do pitch-preserving
speedup/slowdown, skipping to arbitrary points in the media, etc., all
of which would break both the pre-packetization constraints of how
media is put into back into RTP ater storage, and the security
properties of SRTP (e.g. deletion, modification, etc.).
There has been some research work done on cryptographic transforms that
survive such manipulations, but they are still at the research stage,
and are most definitely not of a form that would just slide into SRTP.
I'd go further and suggest that any privacy homomorphism that could
perform manipulations such as speedup/slowdown would not actually be
able to meet a satisfactory definition of security.
David
This makes any content privacy and integrity
properties have to be independent of the transport privacy and
integrity properties.
A second consideration is that it is often required that the storage
system perform transcoding prior to storage (to save capacity), or
transcoding on playout (to deal with playback clients not supporting
the sender's codec). Both of these will negate the utility of this
scheme.
Given that system builders need to deal with the general case for both
transport, storage, playout, and security, having this capability in
the mix this seems to not help much, if at all
There may be other use cases for which this draft might be a good
solution, but voicemail/videomail storage and playback isn't one of
them.
Cheers, DaveO.
-d
/Rolf and John
-----Original Message-----
From: Dan Wing [mailto:dwing at cisco.com]
Sent: den 29 juli 2008 01:49
To: 'David McGrew'; John Mattsson; Fredrik Lindholm; Yi
Cheng; Rolf Blom J; Mats Näslund; Karl Norrman
Cc: 'AVT'
Subject: RE: [AVT] question on
draft-mattsson-srtp-store-and-forward-00.txt
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
Behalf Of
David McGrew
Sent: Monday, July 28, 2008 8:21 PM
To: john.mattsson at ericsson.com;
fredrik.lindholm at ericsson.com; yi.cheng at ericsson.com; Rolf Blom J
(KI/EAB); "Mats Näslund (KI/EAB)"; Karl Norrman ((KI/EAB))
Cc: AVT
Subject: [AVT] question on
draft-mattsson-srtp-store-and-forward-00.txt
Hello,
Section 3.2.1 says that "The answering machine, acting as a
streaming
server when sending the data to the
callee, will not use the exact
same RTP headers on the outgoing SRTP traffic as was used on the
incoming SRTP traffic. SRTP as specified in [RFC3711] will
not work in
this case, since parts of the RTP
header is input to the
encryption/
authentication transforms."
However, some parts of the RTP header would need to be stored along
with the payloads. Since the answering machine is storing
ciphertext
payloads in this case, it would need to
store and play back the RTP
timestamp field, since otherwise the answering machine could not
effectively determine what values to put into this field. The same
considerations would probably apply to the PT field.
Since some parts of the header necessarily need to be
stored as part
of the solution, why not store the
entire header, then
replay the SRTP
session from the answering machine
exactly as it was sent to it?
This is a simple solution that avoids the need for RTP endpoints to
implement new SRTP transforms and options. It can be
implemented by
the answering machine's RTP/SRTP stack,
without any effect on
signaling or any need for explicit support in any other RTP/SRTP
stack.
A technical similar to that was described in Section 3.4 of
draft-wing-avt-dtls-srtp-key-transport-01
<http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-trans
port-01#section-
3.4>, but I pulled it in the most recent version because in
Philadelphia Dave Oran pointed out that SPEECHSC found that
such audio storage didn't work well (for RTP), and thus would
not work well for SRTP. I am curious if
draft-mattsson-srtp-store-and-forward uncovered a new
solution that doesn't bump into the problems SPEECHSC found
(but I wasn't curious enough to ask at the microphone today).
-d
--
Rolf Blom, Ph.D. Expert, Mobile Communications Security, Ericsson Research
Postal address: Ericsson AB, SE-164 80 STOCKHOLM, Sweden
Tel: +46 8 585 317 07, GSM: +46 70 572 99 16, Fax: +46 8 404 70 20
This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you
in error, please notify the sender by replying to this transmission
and delete the message without disclosing it. Thank you.
E-mail including attachments is susceptible to datacorruption,
interruption, unauthorized amendment, tampering and viruses, and
we only send and receive e-mails on the basis that we are not
liable for any such corruption, interception, amendment, tampering
or viruses or any consequences thereof.
|