[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optional SRTP with SDES?


Hi Rick,

On Apr 14, 2006, at 6:13 AM, Rick Porter wrote:


Hi David,

Thanks for the comments.


1) Use the same media stream. No special transport. Crypto is just
another "optional" attribute of the media description.


A minor question: with your proposal, if the answerer selected "no
encryption",  would the media stream use the AVP profile or the SAVP
profile with NULL encryption and NULL authentication?


I am suggesting one media stream with AVP as the transport, regardless
of whether sdescriptions (or potentially other cryptographic/secure
methods) are identified in the SDP. I know this disagrees with RFC-3711 
Section 12 (IANA Considerations), but IMO it is the most
expeditious/practical way forward.


I'm no SDP expert, so I can't comment on the best way to do the SDP.
But it strikes me that if we want to allow for RTP flows for which SRTP suddenly gets "turned on", then the best way to do this would be to define an SRTP cryptosuite that consists of NULL encryption and NULL authentication with anti-replay checking turned off. This very lame cryptosuite is very slightly different from regular RTP in that the ROC would be tracked by the sender and receiver and a cryptoalgorithm change could take place at some point in the future. Using SAVP with this "null cryptosuite" provides some advantages - the ROC can be used for synchronized rekeying, and the RTP profile is now consistent across the whole media flow. Are there some disadvantages to using this approach w.r.t. the SDP?
My thinking has been partly motivated by the thought of what would happen if your proposal got used in a scenario in which an (S)RTP implementation was expected to process packets that it receives before the SIP "answer" gets processed. In this scenario, I'd expect that it's definitely best to use the SAVP profile across the whole session. 

David
p.s. - the "null cryptosuite" would also violate rfc3711 if it was applied to RTCP, since authentication is required for the control protocol. I would expect that, if the "null cryptosuite" was deemed useful by the WG, then we'd deal with that by writing a new standards- track RFC that contained the appropriate disclaimers. 





2) Add an encryption attribute (e.g.
"a=encryption=<optional|mandatory>").


I agree that adding something explicit like this would be good.  But
I have a nit here: we probably want to choose a term other than
"encryption", since SRTP can provide authentication and not
encryption (in principle anyway - the sdesc spec doesn't include any
cryptosuites that do authentication but not encryption, IIRC).  Maybe
"a=secure" would be better.
I'm open to name suggestions, but Snom, Asterisk, and others already use 
the "encryption" attribute in essentially this manner.



Slightly OT: SDP-DH would remove that limitation, so I guess that we
should consider bid-down attacks w.r.t. that protocol.



Agree. Each key exchange method has its own strengths and weaknesses,
and I don't think you're going to find a one-size-fits-all solution. The 
slides presented at the last IETF meeting had a good quick comparison.

Cheers,
Rick