[VOIPSEC] Key Negotiation for SRTP

[Christian Stredicke]

I see we are on the same line.

INFO sems like a dirty hack to me. I guess some implementors have to
clean up this area.

BTW if you want to protect the ICE STUN passwords, you must transport
them also in a secure manner. Is that covered by MIKEY? The same applies
for the IP address and the port number, I mentioned that already in the
previous email.

The picture is getting clearer and clearer to me!

CS

> -----Original Message-----
> From: Zmolek, Andrew (Andy) [mailto:zmolek at avaya.com] 
> Sent: Monday, August 29, 2005 6:16 PM
> To: Dan Wing; Christian Stredicke; Ignjatic, Dragan; Lucas
> Cc: Voipsec at voipsa.org; Stegh, Christian S (Chris)
> Subject: RE: [VOIPSEC] Key Negotiation for SRTP
> 
> From an implementability and reliable interoperability 
> perspective, sdescriptions and INFO are the only real 
> candidates in my book (speaking from the perspective of an 
> enterprise voice vendor). So far, the INFO method is a 
> proprietary approach that doesn't have much of a shot at 
> getting anything but an Informational RFC in the IETF but 
> does actually have a couple of interoperating vendors in the field. 
> 
> Yes, sdescriptions means that one has to rely on TLS or 
> something else to secure the signaling channel. Some sanity 
> checking has to be done to make sure that the signaling 
> channel isn't exposed. But mainstream vendors aren't going to 
> implement a solution that has the potential of making the 
> surrounding PKI so complex for their customers that it 
> discourages them from going to encrypted voice in the first place. 
> 
> In any case, there's a huge security+interoperability problem 
> with VoIP today for the enterprise. One can purchase secure 
> VoIP products and services or interoperable VoIP products and 
> services but not both. We've just wrapped up writing a brief 
> article summarizing the protocols and interoperability gaps 
> for VoIP Magazine (www.voip-magazine.com - not sure how 
> quickly the article will be available online) but the bottom 
> line is that neither H.323 nor SIP have a strong story there 
> right now.
> 
> For SIP in particular, there are actually two problems 
> getting SRTP to work reliably between vendors. The first is 
> the key management problem described in this thread. The 
> other might be called "offer management" - in other words, 
> how can I offer SRTP in a way that's likely to be accepted by 
> a compatible implementation without causing problems or 
> delays in call processing for non-SRTP endpoints. So far, the 
> most promising long-term solutions involve the use of 
> multipart MIME to make multiple offers but unfortunately 
> there are a lot of endpoints that choke on multipart. 
> 
> In fact, it's this "offer management" problem that makes the 
> proprietary INFO method so attractive, since the SRTP 
> negotiation doesn't start until the call is already underway. 
> However, anyone with links to the IETF process will tell you 
> that the INFO method is an abuse of the intent of that method. 
> 
> /\\//\Y/\   Andy Zmolek  |  zmolek at avaya.com  |  303-538-6040
>              GCS Security Technology Development  |  Avaya, Inc.
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Dan Wing
> Sent: Friday, August 26, 2005 8:05 PM
> To: 'Christian Stredicke'; 'Ignjatic, Dragan'; 'Lucas'
> Cc: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> 
> ...
> > So my bottom line of this discussion so far is (for someone 
> who wants 
> > to implement this in a few MB):
> > 
> > 1. Implement SRTP
> > 
> > 2. Put the keys for SRTP in the SDP, probably with the a=crypto 
> > line(s)
> > 
> > 3. Use either TLS or S/MIME to make the key exchange secure/private.
> > 
> > Even if someone uses an insecure transport protocol for sending the 
> > keys, that's a start. At least it does not reduce the 
> security level.
> > Hey lets think a little bit strategically here. Lure the 
> implementors 
> > with SRTP and the crypto line, cuz that can be done 
> relatively easily.
> > Then step number three will come automatically later. 
> Jumping over the 
> > mikey wall right from the beginning seems to be pretty hard 
> to me. And 
> > in the end everybody has to implement TLS anyway.
> 
> I don't believe any standards organization would approve a 
> recommendation for implementors to do (2) -- send encryption 
> keys over an unencrypted channel.
> 
> > Having several conflicting proposals is not a good situation. 
> > It will help those people who want to see SIP dead.
> 
> I honestly don't know how to reduce this set of conflicting proposals:
> 
>   1. Security Descriptions (draft-ietf-mmusic-sdescriptions)
>   2. MIKEY with null encryptor (RFC3830)
>   3. MIKEY with pre-shared keys (RFC3830)
>   4. MIKEY with RSA (public key) (RFC3830)
>   5. MIKEY with DH (RFC3830)
>   6. MIKEY with DHHMAC (draft-ietf-msec-mikey-dhhmac)
>   7. MIKEY with ECIES (draft-ietf-msec-mikey-ecc)
>   8. MIKEY with ECMQV (draft-ietf-msec-mikey-ecc)
>   9. MIKEY with RSA-R (draft-ietf-msec-mikey-rsa-r)
> 
> -d
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
> 
> 
>