[VOIPSEC] Key Negotiation for SRTP

[Dan Wing]

> Actually,
> draft-ietf-msec-mikey-rsa-r-00.txt, can be used in all SIP call
> scenarios, unicast as well as multicast.

I admit to not having investigated that particular MIKEY encryption
mode closely.

> It is true that there is overhead compared to TLS-only approach but it
> also provides more than TLS-only so it is a question of requirements.
> The problem I see with TLS is that it is only 
> administratively mandated
> for sips URI's but there are no enforcement methods/controls.
> It is true that if SIP is not adequately protected you could have SDP
> content modified but depending on security policy that probably only
> constitutes a DoS attack. In other words if a MITM strips off key-mgmt
> lines the call will be rejected (given such a policy). Such an attack
> would not be much different than dropping the INVITE in the 
> first place.
> This has little to do with media key negotiation but is rather a SIP
> message integrity protection problem.

Agreed.  

But with such attacks in mind, wouldn't you want to TLS protect the
signaling to avoid those threats?

> Sdescriptions are very useful if you have a trusted network 
> and you want
> minimal impact to endpoints. The obvious drawback is that the key gets
> exposed to all the servers along the way 

If exposing the keys to your SIP proxies is a concern then S/MIME (and, if
necessary, sip-e2m-sec) can be used to protect the keys.

> and possibly other endpoints in case of forking.

MIKEY's PSK and RSA modes have the same problem with forking -- all of the
forked endpoints know the keys for the media stream.

As I mentioned I haven't studied RSA-R, but I believe only DH, DHHMAC, and
RSA-R resolve the problem of disclosing SRTP keys to all of the endpoints in
the forked target set.

With sdescriptions, because each endpoint chooses its own transmit key, the
other endpoints in the forked target set only learn the SRTP key for the
media in one direction (initiator -> forked target set).  If disclosure of
the key in that direction is a concern, the initiator could wait until one
of the forked endpoints answers and then re-invite with that endpoint with a
new key.  Security precondition (draft-ietf-mmusic-security-precondition)
can be useful to perform this sort of per-endpoint rekeying before the
target phone begins ringing (alerting).  It causes more signaling messages
to be this paranoid, though.

However, in typical cases the devices in the forked target set all belong to
"Bob", or are equally trusted to handle "Bob"'s calls (such as Bob's
voicemail server), or else they wouldn't have been in the forked target set.
And, again, if you don't trust the SIP proxy to behave appropriately S/MIME
(and e2m-sec) can be used to protect the SRTP keys.  And much like we trust
our mail submission server for email, and trust our POP/IMAP servers for
retrieval of email, expecting your own SIP proxy to behave correctly is
reasonable.

-d

> RSA-R should be used if you want e2e media key negotiation 
> with minimal CPU impact (DH method is more CPU intensive and 
> doesn't work all that well for multicast case).
>
> Dragan
> 
> 
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Dan Wing
> Sent: August 26, 2005 8:16 AM
> To: 'Christian Stredicke'; 'Lucas'
> Cc: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> 
> > The latest idea would look like this: Transfer the key in 
> > clear text via a secure protocol in the SDP.
> 
> If you meant 'build a secure protocol in SDP', that's what
> MIKEY does -- MIKEY is a framework to build a secure protocol in 
> the SDP.  MIKEY itself (RFC3830) defines 4 such protocols (or 3, 
> depending on how you count them): 
>  * Null (no encryption) [often not counted],
>  * pre-shared keys,
>  * Diffie Hellman, and 
>  * RSA.  
> 
> MIKEY's Null is sortof like sdescriptions (except MIKEY has an 
> additional state machine for MIKEY itself, and sdescriptions 
> does not).  MIKEY's pre-shared keys require that for MIKEY key
> establishment all endpoints share one common pre-shared key 
> to exchange their SRTP keys.  MIKEY's DH and RSA mechanisms 
> require a public key infrastructure (that is, some way to obtain 
> the remote party's public key before you send Offer).
> 
> draft-ietf-msec-mikey-dhhmac-11.txt defines another technique
> which combines DH and pre-shared keys; see its introduction
> for details.
> 
> draft-ietf-msec-mikey-rsa-r-00.txt describes another technique
> necessary for some SIP call forwarding scenarios.  
> 
> draft-ietf-msec-mikey-ecc-00.txt defines two more MIKEY modes.
> 
> Each of these allow you to protect your SRTP keys using the
> a=key-mgmt lines themselves.  You don't "need" to protect
> SIP using TLS, S/MIME, or -sip-identity.  However, if you 
> don't protect SIP, someone can see it and modify it -- they
> can't modify the a=key-mgmt lines, but they can examine and
> modify any other part of the SIP or SDP.
> 
> And for any of these MIKEY encryption algorithms, all of
> the endpoints involved with a particular call must support
> the same two algorithms.  For example, if "Alice" only 
> supports -mikey-ecc- but "Bob" only supports the pre-shared 
> keys algorithm of RFC3830, they can't exchange SRTP keys.
> 
> > [SDP m-line]
> > A=crypto:1 F8_128_HMAC_SHA1_32
> > inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm
> > 
> > I think that is in line with Dan's proposal... At least one 
> > of the ways to do it. I like it. Simple & solves the problems.
> 
> Yep, doing this just requires you protect the SDP in some way:
> 
>   * encrypt it using S/MIME if you can (which, like the DH 
> and RSA modes
> of
> MIKEY, requires a public key infrastructure), or 
> 
>   * encrypt the SIP message using TLS (which means you need to use
> "SIPS:"
> instead of "SIP", so that all other proxies along the path understand
> the
> message needs to be encrypted).
> 
> In my view, there are lots of good reasons (without SRTP and key
> exchange)
> that SIP-over-TCP is already needed (SIP-over-UDP is less attractive
> with
> today's longer and longer SIP messages that exceed the MTU causing
> fragmentation and subsequent problems with NATs, firewalls, and
> reassembly
> on lossy links, and once you're doing SIP-over-TCP it's a relatively
> small
> step to add TLS to get its authentication, integrity, and encryption.
> OpenSSL is free and unencumbered, and you if you need you can offload
> TLS
> processing using TLS accelerators that are available from 
> almost a dozen
> vendors (today TLS accelerators are used in front of webservers; the
> difference is that performance of such TLS accelerators will be
> different
> because SIP's transaction model is different from HTTP's transaction
> model).
> 
> And because TLS is steady state (that is, a new SIP-over-TLS session
> isn't
> brought up per-call), TLS doesn't incur the CPU hit of 
> MIKEY's DH or RSA
> encryption methods.
> 
> 
> I'm obviously a proponent of -sdescriptions-.  Anyone choosing to
> implement
> or deploy MIKEY needs to understand well that its encryption 
> algorithms
> (Null, pre-shared keys, RSA, DH, DHHMAC, RSA-R, ECC) do not 
> interoperate
> and
> many of them consume a lot of per-call CPU resources (adding to
> post-dial
> call setup delay).
> 
> Further, if you have a public key infrastructure, S/MIME can 
> be used to
> protect your SDP.  A discussion earlier this week on this mailing list
> talked about middleboxes which need to see your SDP.  The technique to
> disclose _parts_ of that SDP (for QoS, firewall traversal, etc.) is
> draft-ietf-sipping-e2m-sec-00.txt.  I wrote
> draft-wing-sipping-multipart-mixed-00, but will drop that 
> draft and have
> some of my ideas added to -e2m-sec-.  The advantage of 
> disclosing parts
> of
> your SDP is that you don't have to disclose your SRTP keys to those
> middleboxes.
> 
> -d
> 
> > CS 
> > 
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwing at cisco.com] 
> > > Sent: Friday, August 26, 2005 4:01 AM
> > > To: 'Lucas'; Christian Stredicke
> > > Cc: Voipsec at voipsa.org
> > > Subject: RE: [VOIPSEC] Key Negotiation for SRTP
> > > 
> > > > I don't think sdescriptions is like MIKEY.  I think 
> > > sdescriptions puts 
> > > > the plaintext crypto parameters in an SDP attribute and 
> > needs to be 
> > > > protected using S/MIME, TLS, or similar.
> > > 
> > > Right.  sdescriptions is also much simplier than MIKEY; MIKEY 
> > > has an additional state machine for MIKEY itself.
> > > 
> > > Also, for two endpoints to interoperate with MIKEY, both 
> > > endpoints must also use the same MIKEY mode:  RSA, DH, 
> > > pre-shared keys, or whichever other MIKEY modes are added.  I 
> > > suppose an offer could include all of the various modes, but 
> > > that adds even more CPU overhead to originating a call and 
> > > you're already noticing the overhead of a single DH operation 
> > > in a CPU- constrained device.
> > > 
> > > > Thus, it is more like No. 4 below.
> > > 
> > > Right.
> > > 
> > > (I'm one of the coauthors of -sdescriptions-.)
> > > 
> > > -d
> > > 
> > > > Have you (or anyone else) implemented S/MIME and does it 
> > > have the same 
> > > > answer-after=0 problem you describe?
> > > >
> > > > Lucas
> > > > 
> > > > Christian Stredicke wrote:
> > > > 
> > > > >Now SRTP is a RFC, this is great work and people would like
> > > > to use this
> > > > >in SIP dialog establishment.
> > > > >
> > > > >I think there is a great degree of uncertainty how the key 
> > > should be 
> > > > >exchanged. So far we have (correct me if there is 
> > > something missing):
> > > > >
> > > > >1. Statically provision the keys. Very simple, but practically 
> > > > >impossible and dangerous. "Goofy".
> > > > >
> > > > >2. Use the mikey mechanism. Practically only the DH part 
> > should be 
> > > > >realistic. Problems here: We implemented this and found that
> > > > is takes a
> > > > >lot of CPU juice to answer a call immediately (e.g. 
> > > > answer-after=0). To
> > > > >me that is a show-stopper.
> > > > >
> > > > >3. draft-ietf-mmusic-sdescriptions-11.txt is more or less
> > > > like mikey, I
> > > > >was told. Should also have the answer-after=0 problem.
> > > > >
> > > > >4. Use TLS and send the keys in clear text in the SDP. 
> > AN earlier 
> > > > >version of the Microsoft Messenger did this. Problems here:
> > > > AFAIK only
> > > > >snom supports TLS on hard phones so far. And the proxies 
> > > will also be 
> > > > >able to see the keys (no end-to-end security). Or is it
> > > > another reason
> > > > >to finally really do TLS and solve a lot of other problems 
> > > this way?
> > > > >Rhetorical question...
> > > > >
> > > > >5. Using some INFO in the early dialog to re-negotiate the 
> > > insecure 
> > > > >session into a secure one. No comment...
> > > > >
> > > > >I would definitely favor 4.
> > > > >
> > > > >Opinions? Pointers? Did I miss something here? Any
> > > > experience with the
> > > > >answer-after=0 problem?
> > > > >
> > > > >
> > > > >Christian
> > > > >
> > > > >_______________________________________________
> > > > >Voipsec mailing list
> > > > >Voipsec at voipsa.org
> > > > >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > > >
> > > > >.
> > > > >
> > > > >  
> > > > >
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Voipsec mailing list
> > > > Voipsec at voipsa.org
> > > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > 
> > > 
> > > 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org