[VOIPSEC] Key Negotiation for SRTP

Christian Stredicke Christian.Stredicke at snom.de
Fri Aug 26 14:17:27 PDT 2005


Sorry guys, just a few stupid comments from someone who has to get this
stuff working in a few MB of RAM and no harddisk...

Can we learn from email? In Email we have two problems:

1. Safely transport the message to the email server. I would compare
that with talking to the proxy. The mechanism to do this would be TLS.

2. Safely transport the message to the recipient. Use PGP or S/MIME for
that, so that even the email server will not be able to see this. In
SIP, it can also be done using S/MIME, maybe also encrypting parts of
the attachment.

In both cases, my opinion is that the SRTP key (which was the stone that
I trew into the water) should be put into the SDP in "clear text" and
then be subject to 1. or 2. I must say I still dont get the point why
mikey defines a mechanism to implement another mechanism to transport
the key. That sounds like reinventing the wheel to me.

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.

Having several conflicting proposals is not a good situation. It will
help those people who want to see SIP dead.

CS

> -----Original Message-----
> From: Dan Wing [mailto:dwing at cisco.com] 
> Sent: Friday, August 26, 2005 9:46 PM
> To: 'Ignjatic, Dragan'; Christian Stredicke; 'Lucas'
> Cc: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Key Negotiation for SRTP
> 
> 
> > > But with such attacks in mind, wouldn't you want to TLS 
> protect the 
> > > signaling to avoid those threats?
> > 
> > [Ignjatic, Dragan]
> > Yes I would, all I am saying is that there is need/room for 
> > incremental work.
> 
> Sure.  That's why we kicked off our separate sdescriptions 
> work, in fact -- ride along with the security SIP itself has 
> built and is building.
> 
> > Even with TLS I would still much rather have my RFC2833 
> implementation 
> > talk to the bank's IVR directly (in terms of media encryption keys) 
> > than through a series of proxies for instance. So having 
> TLS only in 
> > my mind does not adequately cover all use cases.
> 
> Alright.  
> 
> I guess with RSA-R you escalate the threat from a passive 
> man-in-the-middle proxy (as with sdescriptions) to an active 
> man-in-the-middle proxy (with RSA-R), is that right?  Because 
> with RSA-R it seems (from its introduction) that you're not 
> requiring a PKI.
> 
> > > > 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.
> > > 
> > 
> > [Ignjatic, Dragan]
> > Not necessarily, PSK and PK modes rely on the fact that the 
> other end 
> > has the shared secret or the corresponding private key 
> (likely not to 
> > be true for not initially targeted forking destinations).
> 
> I had understood MIKEY's public key mode (called "MIKEY-RSA" in
> -mikey-rsa-r) required a PKI to obtain the other party's 
> public (not private) key.  The other end would have its own 
> private key, but in the case of forking all devices would 
> need to share that same "private" key (unless something like
> -sipping-certs- were used amongst those targets, I suppose).
> 
> > This was actually
> > one of the motivators for RSA-R. In other words even if 
> someone hacks 
> > the proxy and forks or forwards the message the new recipients will 
> > not get media keys.
> 
> In reading RSA-R, it appears you're accomplishing that by 
> encrypting the key with your private key and sending your 
> certificate (public key) to the other endpoint, leaving the 
> other endpoint to somehow determine if that certificate is 
> legitimate (that is, if it's the party they intended to 
> call).  To prove identity, it seems you need -sip-identity-.
> 
> In SIP and sdescriptions we would accomplish this same result by using
> -sip-identity- (to prove identity) in conjunction with 
> draft-jennings-sipping-multipart (to encrypt the a=crypto 
> lines so only the intended recipient can decrypt it).
> 
> -d
> 
> > > 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
> 
> 
> 




More information about the Voipsec mailing list