[VOIPSEC] Key Negotiation for SRTP

[Randell Jesup]

"Dan Wing" <dwing at cisco.com> writes:
>> >IMHO the proxy/end-to-end concerns as not so serious. In 
>> >real life, you
>> >will talk to your operator or office directly and you must trust him
>> >anyway. It is just like with the emails. If some day 
>> >end-to-end becomes necessary, you still have S/MIME.
>> 
>> I am reading your example as signaling security is not an end-to-end 
>> concern.  Do you think that we don't need bearer path 
>> security for end2end voice communication?  Ever?
>
>Christian's last sentence seems to indicate he believes that end-to-end
>SDP encryption may become a necessity.  At which time S/MIME can be used
>to provide that end-to-end encryption of SDP.

        If you don't have end-to-end signalling security (at least of the
keys), then you don't really have end-to-end media security.  Media can be
no more secure than the signalling of keys used to set it up, by
definition.

        And S/MIME has issues that MIKEY doesn't, like ability for
SBC's and the like to map ports, etc - though some proposals address
this as well with yet another layer of complexity.  And then there's the
issue of a working PKI (not that MIKEY necessarily totally sidesteps that,
though it can to a degree).

        TLS has advantages, and there's no reason (as stated) you can't
do MIKEY-over-TLS to end-to-end protect the media streams while allowing
SBCs and other proxies to do their thing with the SIP and SDP data.

        All that said, I'm not sure of the "right" solution, but we
certainly need one - and more importantly, a solution that allows interop
with non-secure endpoints without excessive setup delay.

        BTW, on using INFO to negotiate security after call completion -
you'd do better to negotiate it via re-INVITE after initial completion,
if the application can allow for initially-unencrypted calls, and the
potential for MITM attacks to block reinvites leaving a call open but
unencrypted (which is always an issue without S/MIME or TLS or some
equivalent).  Using re-INVITE is much more standards-friendly, too.

>> There is DTLS now, so perhaps the reasoning should be based on 
>> transport features and not security protocol availability.
>
>To avoid fragmentation, large SIP messages are going to force us to TCP.
>DTLS doesn't handle large application-layer messages except by (a)
>fragmentation or by (b) pushing the problem to the application layer.  Of
>course, SIP doesn't have any application-level fragmentation, so DTLS will
>cause fragmentation of these large SIP messages.

        Except (unless DTLS relaxes this) RFC 3261 doesn't allow a UA (or
proxy I think) to send a UDP datagram larger than the MTU-200 or 1300 if
not known.  So either you bend that restriction, or you have to go TCP/TLS.
You _can_ bend that (since UAs/proxies are required to accept fragments).
But it doesn't solve the "fragmented IP packets may get hosed" problem when
there's congestion between source and dest.  And supposedly a number of
routers/etc cause problems for fragmented UDP packets.

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