Re: [AVT] SRTP store-and-forward

[Randell Jesup <rjesup at wgate.com>]

"John Mattsson" <john.mattsson at ericsson.com> writes:

>>Rolf Blom <rolf.j.blom at ericsson.com> 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 <rjesup at wgate.com> 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.

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.

>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.

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
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)