Re: Optional SRTP with SDES?

["Robert R. Gilman" <rrg@xxxxxxxxx>]

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
----------------------------------------------------
Bob Gilman       rrg@xxxxxxxxx      +1 303 538 3868

Wayne Mills (wmills) wrote:
> Scott,
>
> 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:
>
> a=savp_usage: <optional|mandatory>
>
> Regards,
> Wayne
>
>
> > -----Original Message-----
> > 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?
> >
> > Wayne, Mark,
> >
> > thanks for the clarifications!
> >
> > David
> >
> > 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.
> > > "unencrypted_srtp")
> > > to alter a crypto suite so that authentication is still 
> >
> > enabled while 
> >
> > > encryption is disabled, so it accomodates establishment of 
> >
> > unencrypted 
> >
> > > SRTP ( oxymoronic as that sounds :) ).
> > >
> > > Back to syntax, I think "a=security: <optional|mandatory>" 
> >
> > is better 
> >
> > > than "a=encryption: <optional|mandatory>", due to the ability to 
> > > negotiate unencrypted SRTP.
> > >
> > > Regards,
> > > Wayne
> > >
> > >
> > > > > > > 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).
> > > > >
> > > > > Any sdescriptions crypto suite can signal
> > > >
> > > > "unencrypted_srtp", which is
> > > >
> > > > > effectively SRTP null encryption.
> > > > >
> > > > > Mark
> > > >
> > > > 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.
> > > >
> > > > David
> > > >
> > > >
> > > >
> > > > > > Maybe "a=secure" would be better.