[AVT] SRTP store-and-forward

[Rolf Blom <rolf.j.blom at ericsson.com>]

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