[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optional SRTP with SDES?
On Apr 14, 2006, at 6:13 AM, Rick Porter wrote:
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
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
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.
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
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
slides presented at the last IETF meeting had a good quick comparison.