Subject: [AVT] SRTP store-and-forward

From: Rolf Blom <[email-masked]>
Date: Mon, 30 Mar 2009 17:09:11 +0200

To continue the discussion following my presentation on SRTP Store and 
Forward on Thursday I would like to make the following comments:

Our first ideas were to use RFC 3711 and only add the possibility to 
have separate keys for confidentiality and integrity protection. This 
would allow e2e confidentiality and hbh integrity fulfilling the most 
basic requirements. However, not providing integrity protection e2e 
seems like opening up for different types of attacks. In 
draft-mattsson-srtp-store-and-forward-01 we proposed GCM with AEAD as 
the "confidentiality – e2e" transform which provides both integrity and 
confidentiality protection. But it really doesn't add much complexity to 
include key derivations of both an integrity and a confidentiality key 
so in draft-mattsson-srtp-store-and-forward-02 we aligned the 
functionality in SRTP store and forward with the mandatory functionality 
in RFC 3711 as much as possible and chose to have independent 
confidentiality and integrity protection transforms. For the hbh 
protection it then seemed natural to also allow both integrity and 
confidentiality protection and just reuse the protection mechanism in 
RFC 3711. The confidentiality protection in hbh may provide additional 
privacy protection as the SSS in the e2e part could make it possible to 
link incoming and outgoing streams from a SaF middlebox.

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.

Finally, as was indicated in the slides, keying for SRTP 
store-and-forward only requires that existing key management protocols 
are extended to allow also carrying information about CID, CCI and SSS. 
For the e2e keying in the answering machine use case, the sender must 
hold a shared key or certificate with the responder. This situation is 
thus exactly as when you send an encrypted email.

Rolf Blom

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Mar 2009 13:51:52 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rolf Blom
> Sent: Monday, March 30, 2009 8:09 AM
> To: AVT
> Subject: [AVT] SRTP store-and-forward
> 
> the "confidentiality - e2e" transform which provides both 
> integrity and 

But we lack a mechanism to acquire such a shared key or 
certificate on the Internet for SIP (or email, for that matter),
correct?  I am told that MIKEY-RSA has some mechanism to acquire
such information but I haven't seen it described anywhere -- it
certainly isn't in an IETF document that I am aware of.

-d

> Rolf Blom
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Mar 2009 11:39:31 -0400

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

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

-- 
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: Rolf Blom <[email-masked]>
Date: Wed, 01 Apr 2009 08:50:52 +0200

Dan Wing wrote:

snip

Finally, as was indicated in the slides, keying for SRTP
store-and-forward only requires that existing key management
protocols
are extended to allow also carrying information about CID,
CCI and SSS.
For the e2e keying in the answering machine use case, the sender must
hold a shared key or certificate with the responder. This
situation is
thus exactly as when you send an encrypted email.

-d

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  wouldn't work for SRTP  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!

/Rolf