Subject: Re: [AVT] SRTP store-and-forward

From: "John Mattsson" <[email-masked]>
Date: Thu, 2 Apr 2009 15:23:41 +0200

>Rolf Blom <[email-masked]> writes:
>>To be able to handle an audio and a video stream using one security 
>>context it is necessary to introduce a mechanism to give them separate

>>protection. We did that with the introduction of the SSS, the SRTP SaF

>>Source. It s also necessary to be able to indicate which e2e security 
>>context that the media is using and thus a CCI, Crypto Context 
>>Identifier is needed. So we believe that what we have presented is 
>>general enough but still is a very thin design providing not more than
what is really needed.
>>
>>Cullen gave an example in which it was essential that what is 
>>forwarded is the complete message that was received by the SaF 
>>middlebox (do not launch the missile!). Even if I believe that such a 
>>message wouldn't be left on an answering machine - it probably should 
>>be delivered directly to eliminate the risk for mistakes - it points
at a possible threat.
>>This threat might perhaps be countered by some RTCP signaling messages

>>e2e. However, in the current draft-naslund-saf-00 we do not provide 
>>e2e integrity protected RTCP. Is this a problem? Should it be added? 
>>Or are there other application layer mechanisms that should be 
>>applied? Note that with an e2e integrity transform and letting PUV be 
>>a counter, it is possible to detect replays and re-orderings at the 
>>application layer. However, it will not guarantee that all packets are
forwarded.
>>Note that the threat discussed is outside the trust model assumed for 
>>SRTP store-and-forward, which assumes a honest but curious SaF
middlebox.

Randell Jesup <[email-masked]> writes:
>You need to at least include RTCP as well, or synchronization between 
>streams (audio and video) cannot be done. Protecting it would be smart,

>though probably not strictly necessary. (If not protected, someone 
>could mess with the stream sync, possibly tickling bugs in the player 
>or causing one stream or the other to never play, to jump around, or to

>be unintelligible.)

Our intention have always been that the middlebox saves the relevant
parts of RTCP (e.g. SR, APP) and retransmits them to the final receiver.
As RTCP is protected hop-by-hop, the only one that could mess with the
synchronization is the middlebox, which according to our trust model is
trusted not to do so. Most of what can be achieved by messing with the
synchronization could be done by not forwarding chosen packets. We
thought about protecting RTCP e2e but felt that it creates more problems
than it solves. Parts of RTCP should be sent e2e and other parts only
hbh, for RTCP APP, this distinction is application dependant. If there
is a need to protect against a synchronization messing middlebox, the
audio and video should encoded in a format that can be sent in a single
stream.

/John

---

From: Randell Jesup <[email-masked]>
Date: Thu, 02 Apr 2009 15:39:41 -0400

"John Mattsson" <[email-masked]> writes:

>>>Cullen gave an example in which it was essential that what is forwarded
>>>is the complete message that was received by the SaF middlebox (do not
>>>launch the missile!). Even if I believe that such a message wouldn't be
>>>left on an answering machine - it probably should be delivered directly
>>>to eliminate the risk for mistakes - it points at a possible threat.
>>>e2e. However, in the current draft-naslund-saf-00 we do not provide e2e
>>>integrity protected RTCP. Is this a problem? Should it be added?  Or are
>>>there other application layer mechanisms that should be applied? Note
>>>that with an e2e integrity transform and letting PUV be a counter, it is
>>>possible to detect replays and re-orderings at the application
>>>layer. However, it will not guarantee that all packets are forwarded.

Ok, though I don't know how the midbox would know what RTCP packets are
relevant in all cases, especially if they're RTCP sub-packets that are
defined after the midbox is written/updated.

>trusted not to do so.

RTCP is protected end-to-end normally, not hop-to-hop (excluding B2BUAs -
perhaps you're assuming a B2BUA, but then RTP isn't end-to-end protected
either).  And I'm confused (probably by not reading the recent versions of
this): why are you assuming that the midbox is trusted?  And if it's
trusted, why are you not decrypting the message, then re-encrypting for
playback, avoiding the entirety (or most of it) of the need for this draft?

I'd assumed SRTP Store-and-forward was supposed to assume a lack of trust
in the box doing the storing, beyond that it would do the forwarding when
asked.  I.e. allow a message to be stored on an insecure server in a secure
manner; avoiding the possibility that the contents could be snooped or
modified.  (Obviously they could be deleted or truncated.)

>Most of what can be achieved by messing with the synchronization could be
>done by not forwarding chosen packets.

Simple refutation: set the current NTP time via RTCP for the one stream to
be 20 years in the future.  The user will probably hear the audio and see
no video (or a still image); or the other way around, depending on how the
client works.  (Some very dumb clients might ignore this.)  Alternate
refutation: cause the NTP time to jump around (forward and backwards); this
could cause all sorts of nasty effects depending on the client.

>We thought about protecting RTCP e2e but felt that it creates more
>problems than it solves. Parts of RTCP should be sent e2e and other parts
>only hbh, for RTCP APP, this distinction is application dependant. If
>there is a need to protect against a synchronization messing middlebox,
>the audio and video should encoded in a format that can be sent in a
>single stream.

You can do that, but then you lose the ability to leverage all the tools
that understand audio/video streams; it no longer is an extension to
existing abilities, but a new, separate tool for messages.

The question is: what is the reason(s) for SRTP usage, and how does that map
to the usecase you're trying to handle here (storing messages)?  Who are
you protecting against; what level of interference needs to be overcome?

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"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)

---

From: "John Mattsson" <[email-masked]>
Date: Fri, 3 Apr 2009 18:41:18 +0200

>>>streams (audio and video) cannot be done. Protecting it would be 
>>>smart, though probably not strictly necessary. (If not protected, 
>>>someone could mess with the stream sync, possibly tickling bugs in
the 
>>>player or causing one stream or the other to never play, to jump 
>>>around, or to be unintelligible.)

>defined after the midbox is written/updated.
 
This is a general problem for store-and-forward of RTP and not specific
to SRTP SaF. You are right in that the middlebox cannot know which RTCP
packets are relevant in all future cases and might need to be updated. I
think that a simple policy were the middlebox forwards the information
it knows should be forwarded e2e (e.g. synch info) and the information
it does not recognize (e.g. RTCP APP) goes a long way.

 
 
>asked.  I.e. allow a message to be stored on an insecure server in a
>secure manner; avoiding the possibility that the contents could be
>snooped or modified.  (Obviously they could be deleted or truncated.)
 
The middlebox is exactly as you say only trusted to do the forwarding
when asked (including unmodified synchronization info). We call this
semi-trusted in the draft. If the middlebox is totally untrusted it
would be meaningless to use for anything. We do not trust the middlebox
with cleartext data.
 
>>Most of what can be achieved by messing with the synchronization could

>>be done by not forwarding chosen packets.
 
>Simple refutation: set the current NTP time via RTCP for the one stream
>to be 20 years in the future.  The user will probably hear the audio
and
>see no video (or a still image); or the other way around, depending on
>how the client works.  (Some very dumb clients might ignore this.)  
>Alternate refutation: cause the NTP time to jump around (forward and
>backwards); this could cause all sorts of nasty effects depending on
>the client.
 
I agree, the middlebox could cause the the NTP time to jump around. The
semi-trusted middlebox is however trusted to forward the packets without
modifing them.
 
>>problems than it solves. Parts of RTCP should be sent e2e and other 
>>parts only hbh, for RTCP APP, this distinction is application 
>>dependant. If there is a need to protect against a synchronization 
>>messing middlebox, the audio and video should encoded in a format that

>>can be sent in a single stream.

>The question is: what is the reason(s) for SRTP usage, and how does
that
>map to the usecase you're trying to handle here (storing messages)?
Who
>are you protecting against; what level of interference needs to be
overcome?
 
The main thing that we are protecting is the confidentiality of the
data. If you look at the use cases described in the drafts, I think you
will agree that in these use cases it is reasonable to assume that the
middleboxes are what we call semi-trusted. If one absolutely needs to
use a middlebox which is not trusted to not modify the synchronization
info and if modification of the synchronization info is seen as an
unacceptable risk, one might be limited to a smaller set of formats and
tools.

/ John Mattsson

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 06 Apr 2009 16:49:56 -0700

> When you refer to MIKEY-RSA having some mechanism to acquire such
> information (shared key / certificate) I believe you refer to
> MIKEY-RSA-R. In MIKEY-RSA-R the initiator attaches his certificate in
> the first message and the responder uses it to return the key to be
> used. This works well when there is an on-line connection between the
> two but&nbsp; wouldn't work for SRTP&nbsp; Store-and-Forward applications. Here
> we must rely on either predistributed keys or certificates or that keys
> or certificates can be acquired from an online third party. As I said
> before this situation is exactly as for secure email. And secure email
> is used!

I would say extraordinarily rarely. Indeed, this is precisely one
of the challenges that led to RTPSEC.

-Ekr

---

From: Rolf Blom <[email-masked]>
Date: Tue, 07 Apr 2009 15:47:46 +0200

Hi Eric,

My experience is that secure email becomes of more and more interest
for enterprises and government authorities. Such organizations already
now invest in the needed infrastructure to enable handling of user
certificates and other types of user credentials for secure access and
communication. I also expect that in the future, secure email will be
used more and more by the general public for privacy reasons. Look e.g.
at the success for PGP.

/Rolf

Eric Rescorla wrote:

-Ekr

--
Rolf Blom, Ph.D. Expert, Mobile Communications Security, Ericsson Research
Postal address: Ericsson AB, SE-164 80 STOCKHOLM, Sweden
Tel: +46 10 713 17 07, GSM: +46 70 757 2092, Fax: +46 8 757 01 35

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 07 Apr 2009 08:48:38 -0700

At Tue, 07 Apr 2009 15:47:46 +0200,
Rolf Blom wrote:
> communication.

My experience is the contrary. Some organizations try and they're
almost universally miserable.

> I also expect that in the future, secure email will be
> at the success for PGP.<br>

If that's a success, I'd hate to see failure. Compare the deployment of
TLS to the deployment of PGP.

-Ekr