[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optional SRTP with SDES?
We've been thinking along the same lines. One thing we've considered is
the inclusion of a=crypto: lines in SDP/AVP to permit optional SRTP/SRTCP
or "plain old" RTP/RTCP. You'd get the latter from any endpoint that
didn't recognize the crypto line(s), so this should be backward compatible.
If one wants to force SRTP, then one could place the crypto lines in an
SDP/SAVP record - any endpoint capable of SRTP should recognize it.
The various options for SRTP would be controlled by cryptosuites and
parameters, as defined in sdescriptions. Looked at this way, we might
want to turn the a=crypto: line into an a=srtp: line.
Does this make sense?
Bob Gilman rrg@xxxxxxxxx +1 303 538 3868
Wayne Mills (wmills) wrote:
See below for the reasoning on why encryption is too specific.
Within the context of establishing an SRTP session, sdescriptions
already provides syntax to negotiate confidentiality and authenticity
characteristics, no additional attributes needed for that. What we are
trying to nail down is how to do profile "downgrade", i.e., SRTP-->RTP.
Heck, if it helps, the attribute can be brazenly specific:
From: David McGrew (mcgrew)
Sent: Monday, April 17, 2006 5:17 PM
To: Wayne Mills (wmills); Mark Baugher (mbaugher)
Cc: Rick Porter; ietf-rtpsec@xxxxxxx
Subject: Re: Optional SRTP with SDES?
thanks for the clarifications!
On Apr 17, 2006, at 2:07 PM, Wayne Mills ((wmills)) wrote:
I think Mark's comments were more aimed at your parenthetical ("in
principle anyway"). Sdescriptions has syntax (e.g.
to alter a crypto suite so that authentication is still
encryption is disabled, so it accomodates establishment of
SRTP ( oxymoronic as that sounds :) ).
Back to syntax, I think "a=security: <optional|mandatory>"
than "a=encryption: <optional|mandatory>", due to the ability to
negotiate unencrypted SRTP.
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
"encryption", since SRTP can provide authentication and not
encryption (in principle anyway - the sdesc spec doesn't
cryptosuites that do authentication but not encryption, IIRC).
Any sdescriptions crypto suite can signal
"unencrypted_srtp", which is
effectively SRTP null encryption.
Sure, but SRTP with NULL encryption is not equivalent to RTP
- turning off encryption is not the same as not doing SRTP.
If I understand Rick correctly, this is why he's suggesting the
additional "a=encryption" attribute.
Maybe "a=secure" would be better.