[VOIPSEC] Voipsec Digest, Vol 8, Issue 26

[Randell Jesup]

"Dustin D. Trammell" <dtrammell at sipera.com> writes:

>On Thu, 2005-09-08 at 04:14 -0400, Randell Jesup wrote:
>>         Another may be to bite the bullet and specify some form of
>> PKI.  But we have to verify not on that the UA cert is a valid cert, but
>> that it's the valid cert for that UA - i.e. that it matches who we think
>> we're calling or we think called us; that it matches the caller info or
>> the number we dialed.  And matching against the number we dialed will
>> be...  fun (not).  (Forking, forwarding, dialing rules/enum handled by
>> the proxy/ server, etc).

>If the purpose of the key you need to exchange is for session integrity
>and not authentication (it matters that the key is valid for the device
>you're talking to, not necessarily that it's valid for the party you're
>trying to reach), then since the lower layer protocol (SIP, in this
>case) routes the message to the proper device for the Request-address
>you're attempting to reach, why could you not forgo the PKI and have the
>device itself give out it's public key in response to an OPTIONS request
>with the Accept line set to some crypto algorithm identifier it's
>expecting a key for?  If the device does not have a public key for that
>crypto scheme it could respond with a crypto capability that it does
>have a key for, or an error.  Otherwise, it would respond with it's
>public key for that algorithm.  Then, when the calling device sends it's
>initial INVITE it could encrypt signaling with the called device's
>public key, and at that point securely negotiate a symmetric algorithm
>session key for further signaling encryption and media channel
>encryption.

        Two issues with that:
1) Extra round-trips to initiate the call; more delay before ringing.
   Not as bad as delay on answer though.
2) No end-to-end authentication (which was why people weren't happy
   with TLS).  This allows for MITM attacks (either along the path or
   via the SIP proxy). 

That said - encryption without end-2-end auth is useful.  We could
use SIPS (TLS) with unencrypted a=crypto unless end-2-end authentication
is wanted.  Or use it and then re-invite with end-2-end auth (which can
be slower).  From a UI aspect for consumer devices (as opposed to geek
toys) these are significantly sub-optimal - it requires users to understand
the issues around auth, mitm, etc.

>In this way all of the preliminary key negotiation can be done prior to
>ringing the called device (via the OPTIONS request), which alleviates
>the delay due to crypto-channel setup during call answer, as well as
>secures the signaling channel from the beginning of the initial INVITE.

        Encrypting the signalling with the public key (i.e. S/MIME)
causes problems for proxies that need to add information for things like
NAT traversal.  Multipart has been proposed to allow overlaying data on top
of S/MIME, but has issues with legacy support.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)