[VOIPSEC] Using SRTP for University project

[Hadriel Kaplan]

Hi Alan,
Comments inline...

> -----Original Message-----
> From: Alan Johnston [mailto:alan at sipstation.com]
> Sent: Monday, March 27, 2006 4:54 PM
> To: Hadriel Kaplan
> Cc: 'Mark Baugher'; Voipsec at voipsa.org; Christian.Stredicke at snom.de;
> Philip Zimmermann
> Subject: Re: [VOIPSEC] Using SRTP for University project
> 
> In IETF specs, implementers may choose to not obey SHOULDs only if there
> is a very strong reason not to.  Ignoring SHOULDs that relate to
> security is especially hazardous and not good practice.

Totally agree.  And the implementer can make s/mime the only choice, or the
default with a strong warning of the user changes it.  I was only referring
to his word "required".

> In my personal opinion, the use of sdes without S/MIME is very flawed
> security.

Is sdes w/sips better than not providing SRTP at all?  For some no, since it
may give a false sense of better security.  For them I don't know why they
use TLS to begin with (for even signaling).  For others who trust a 3rd
party for everything else, and want to communicate to the pstn, or other
mediums which require transcoding and other media services for a particular
call, sdes w/sips is better than not.  Implementers can always warn the user
if they wish (e.g., create an icon to distinguish).

> I think Mark's point is that by trusting the confidentiality of your
> keying material to hopwise TLS means trusting any proxy that may be
> inserted in the signaling path - this effectively means trusting every
> intermediary in every domain you traverse.  For example, even though
> your domain may be sensible about this, my domain might route the SIP
> request through 15 proxies, all of which would have access to the keying
> material...

Of course, and they have access to everything else too.  They can simply
reject your call, or flood you with messages, or route it to the pstn, or
end the call when they wish, or replay your call, or snoop your IM traffic,
etc.  My only point was that signaling is as "sensitive" as media (more so
for some, less so for others).  

If you don't want your sip request to cross 15 proxies, don't route it
through one that isn't your's (personally your's).  Build a network of
proxies that support s/mime for people to use.  I'm only stating that s/mime
won't work through most service-providers today (nor enterprises I think),
nor do most phones support it.  I don't control market forces. (wish I did
:)  A large sector of the market has chosen, and it did not choose s/mime.
Maybe that will change, but my guess is not.

> ZRTP does provide authentication if a secret from the signaling (such as
> the dialog identifier which has been protected using hopwise TLS) is
> available.  

Interesting.  So if the middle-man swaps them too, will authentication fail?
(any B2BUA could swap them without too much difficulty I think, not that
they would...)

> Also, ZRTP uses key continuity which forces an attacker to
> perform an active DH MitM attack on every call or be detected.
 
That's not hard.  That could just be the local TLS proxy.  

> Last week at the IETF, Phil made an excellent argument in his
> presentation that the encryption of media is none of the business of a
> the signaling.  From an architectural point of view, tying the
> encryption of media to the signaling is a bad idea.

That depends on whose architecture.  In theory the codecs and their
attributes should not either.  Nor should two unrelated message formats (SIP
utf-8 and STUN binary) appear on the same socket used by a protocol that did
not support the new format previously.  Architecture must give way to
pragmatism.  If the best security mechanism impacts the needs of the
service, it seems to me the service wins out almost every time; by finding a
different security mechanism.  

-hadriel