[VOIPSEC] Key Negotiation for SRTP

[Randell Jesup]

"Christian Stredicke" <Christian.Stredicke at snom.de> writes:
>a) This is a policy question. 
> 
>a.1) Sending an offer:
> 
>a.1.1) If you send an SDP offer and you insist on SRTP, use RTP/SAVP. If
>the other party does not support it, it will reject it and send a
>appropriate message (in case it is buggy and just ignores the SAVP, send
>a BYE like on the receipt of a multiple 2xx response). 

        They could reject the call (4xx) or they could accept it but reject
the stream (port 0 the m= line, in which case you can BYE the call if
you insist on SRTP).

>a.1.2) If your policy is optional security, use RTP/AVP and the a=crypto
>line and see what happens.

        Is that valid?  I don't think it is.  Or rather, a compliant
RFC3711 SRTP phone should ignore your a=crypto I believe, or reject.
Though that is effectively what I was suggesting as more workable
than the current "encode optional info in the profile", given the lack
of working alternative media.

>a.2) Sending an answer:
> 
>a.2.1) If you insist on SRTP and there is no a=crypto header, reject the
>call with an appropriate response.
> 
>a.2.2) If security is optional, and there is a a=crypto header, answer
>also with a a=crypto header.

        Somewhat problematic since you don't know if incoming data is
encrypted until you receive the 200 OK, which can be very delayed.  That's
probably part of the reason for the AVP/SAVP and using different ports or
at least payload types.  I.e. the caller has to be ready to receive data
without having seen an OK, and has to know how to decode it.  If it's
encrypted and the caller knows it's encrypted, they can wait for the OK
to get the key.  If they don't know, they can try to play it (but it will
be white noise), try to infer it (possible for audio often, not easily
for video), or hold off until 200 OK.  

        SRTP and key exchanges in general are a little bit problematic
for SIP at call startup since SIP was designed with a "lazy" acceptance.
See option d)

>b) Naahhhhh. That would be ugly.
> 
>c) I dont think that is necessary. 

        This really is the _right_ way to do it (or the equivalent,
grouping).  The only issue is compatibility with existing
endpoints/gateways/border-controllers/etc.

>d) No, there will be an overlap where you will hear terrible noise. I
>got a call where the SRTP negotiation did not work last day. It hits you
>like a hammer. Overlapping negotiations are not an option for me.

        Not if it's done right.  Both side know it's unencrypted to start
(good audio).  On re-invite, you use _different_ ports for the new
(different) media streams.  Once data starts from those, you switch over
(fairly) seamlessly.  With effort, it could be virtually seamless.

>From: Zmolek, Andrew (Andy) [mailto:zmolek at avaya.com] 

>We are focused on sdescriptions at this point as the key management
>standard most likely to interoperate widely - but even with
>sdescriptions, the "offer management" problem remains, namely how do you
>offer SRTP in a way that is likely to ensure success with another
>SRTP-capable endpoint:
>
>a) always try once with SRTP then fallback immediately if it doesn't
>work?
>b) try multiple combinations before fallback?
>c) use multipart MIME to send multiple offers and let the other endpoint
>pick one?
>d) just start with RTP and then use re-INVITE (since INFO isn't really
>appropriate) to try to establish SRTP?
>
>I've got it on my to-do list to start this dialog again within the IETF,
>but in many respects this is more of an implementation issue (except for
>(c) which would require a bit of work around a standard for selecting a
>single SDP part in a multipart MIME body). So it would be nice for a few
>vendors to agree on a starting position so that the issue can get enough
>traction to get a reaction. I don't think (a) moves anything forward and
>(b) just increases call completion latency for all calls even if SRTP
>isn't established. That leaves (d) as an option that needs a bit more
>definition (wouldn't it be nice if a "hints" that SRTP could be offered
>were part of the initial INVITE sequence?). 
> 
>With this in mind, I'd love to hear from other like-minded vendors
>regarding their preferences for SRTP "offer management" (and any
>specific objections regarding sdescriptions for key management) so that
>a de-facto multi-vendor SRTP interoperability story could become a
>reality. I've spoken to a few of you in the past mainly to ping you on
>what you're doing today, but based on what I've found so far I think
>there would be a lot of value in getting more SRTP interoperability
>alignment across at least the enterprise space and perhaps even the
>enterprise/carrier space. It would be a start, anyway.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com