Re: [AVT] SRTP store-and-forward

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Rolf Blom
> Sent: Monday, March 30, 2009 8:09 AM
> To: AVT
> Subject: [AVT] SRTP store-and-forward
> 
> 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.

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
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt