[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optional SRTP with SDES?
A nit below...
On Apr 13, 2006, at 2:25 PM, David McGrew wrote:
On Apr 12, 2006, at 7:00 AM, Rick Porter wrote:
This discussion started on the mmusic list
and was moved to this list this list at the request of the mmusic
The original question was: How do you make a call and optionally do
The responses highlighted that with SDES there is no way to do this
without additional INVITEs or mulitpart alternate SDP (which most
clients do not yet support). There are other requirements in the SDES
draft that also have negative impact on users (e.g. if a voicemail
system is configured for SRTP, only SRTP enabled phones could get
I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS,
EKT, SDP-DH). I'm aware that each solution has its good and bad
but I want to focus on the SDES draft since my un-scientific findings
are that it is the most widely used.
I've been testing with five other SDES/SRTP vendors who all handle
things a bit differently. Some are following the SDES draft to the
letter, but others have taken a more "user-friendly" approach. I
with a few tweaks, the SDES draft could reflect the behavior with
everyone is moderately happy (and seems to be converging on).
Here are my suggestions to the SDES draft:
1) Use the same media stream. No special transport. Crypto is just
another "optional" attribute of the media description.
When a callee who does not support SDES receives an INVITE with
he can accept the call and does not provide a crypto attribute in the
200/OK/SDP. Then, the caller can choose to CANCEL the call or
the non-secure call if he does not like the 200/OK/SDP without the
If I understand correctly, this would be equivalent to the current
methods security-wise in that the offerer could specify both
"secure" and "insecure" options, and the answerer would get to
choose. But there are deployability advantages to doing it this
way, which we definitely want, so it deserves serious consideration
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?
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).
Any sdescriptions crypto suite can signal "unencrypted_srtp", which
is effectively SRTP null encryption.
Maybe "a=secure" would be better.
If the encryption attribute is present, the callee knows whether
accept the call even if he does not share a common set of crypto
algorithms/options with the caller. It could give the callee the
to reject the call early (e.g. 480) instead of sending the 200/OK
(without crypto) and letting the caller reject the call upon
the 200/OK. I do not have a strong preference whether lack of the
encryption attribute means that encryption is optional or mandatory.
3) Add notification requirement (suggested by Paul/Alan).
It is important to let end-users know if their call is secure (at
on the first hop). Wording may be tricky since network devices (e.g.
b2bua, media-gateway) that may terminate SRTP do not have per
In the mmusic discussion, there was concern expressed about a bid-
attack. When using SDES, I would not be concerned with a bid-down
since anyone with access to the signaling stream has all the key
material necessary to decrypt each and every RTP packet. No need
it down crypto if you can decrypt the RTP packets anyway. This is a
design limitation of SDES.
Slightly OT: SDP-DH would remove that limitation, so I guess that
we should consider bid-down attacks w.r.t. that protocol.