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

Re: Optional SRTP with SDES?


David,
  A nit below...
On Apr 13, 2006, at 2:25 PM, David McGrew wrote:



Hi Rick,

On Apr 12, 2006, at 7:00 AM, Rick Porter wrote:



This discussion started on the mmusic list
(http://www1.ietf.org/mail-archive/web/mmusic/current/msg04091.html),
and was moved to this list this list at the request of the mmusic
moderator.

The original question was: How do you make a call and optionally do
SRTP?

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 their 
voicemail).
I know there are other SRTP keying options (e.g. ZRTP, RTP/DTLS, MIKEY, EKT, SDP-DH). I'm aware that each solution has its good and bad points, 
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 think with a few tweaks, the SDES draft could reflect the behavior with which 
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 crypto, 
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 continue 
the non-secure call if he does not like the 200/OK/SDP without the
crypto attribute.
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 IMO.
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.
"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

Maybe "a=secure" would be better.
If the encryption attribute is present, the callee knows whether he can 
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 chance 
to reject the call early (e.g. 480) instead of sending the 200/OK
(without crypto) and letting the caller reject the call upon receipt of 
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 least 
on the first hop). Wording may be tricky since network devices (e.g.
b2bua, media-gateway) that may terminate SRTP do not have per
user/session UI's.
In the mmusic discussion, there was concern expressed about a bid- down attack. When using SDES, I would not be concerned with a bid-down attack 
since anyone with access to the signaling stream has all the key
material necessary to decrypt each and every RTP packet. No need to bid 
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. 

David



Cheers,
Rick