Subject: RE: [Sip] SMIME in SIP

From: "Christian Huitema" <[email-masked]>
Date: Mon, 18 Feb 2002 12:09:13 -0800

> > 4) TLS doesn't address UDP. IPsec WG is working on
> >    NAT traversal
> >
> 
> Also will break firewall implementations, that have/are being
developed by
> many well
> known vendors, to address SIP....would require that they also decrypt
to
> peform
> pinhole allocation. Would most likely also affect SIP infrastructures
> already built
> today based on UDP if we must suddenly implement TCP based SIP (Would
have
> actually
> been nice from the start).

In fact, we should seriously consider that we reverse the priorities
between transport: make TLS a MUST, at least for proxies; make TCP a
SHOULD and make UDP a MAY. In fact, I would argue for a "SHOULD NOT
support UDP, at least in the absence of IPSEC. There are just way too
many ways to attack a UDP based system -- spoof the source address of a
proxy and send whatever you wish to the UA, spoof the source address of
a third party and mount a denial of service attack against a proxy, etc.
Using S/MIME for end-to-end security is certainly a very good idea, but
using TLS is probably the only secure solution that we can deploy right
now. 

However, if we want to use TLS seriously, we need to resolve a security
issue that is caused by the use of SRV records as specified in
draft-ietf-sip-srv-04.txt. In short, DNS records can be spoofed. A
hacker can manage to spoof the SRV record for "_sip._tls.microsoft.com"
to point to "hackers-are-us.tv", thus intercepting all the SIP traffic
to Microsoft. The basic usage of TLS will only guarantee that the name
to address mapping is genuine, i.e. that the target is really the
authorized server for "hackers-are-us.tv", but that will not make us a
whole lot of good. So, when we say "check the certificate", we should
really check for a link to the initial domain, pre-SRV.

-- Christian Huitema

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 Feb 2002 12:30:08 -0800 (PST)

> a third party and mount a denial of service attack against a proxy, etc.

   Thus far, arguments about the insecurity of UDP 
   have been falling on deaf ears. I have proposed that
   either we deprecate UDP or we endorse IPsec. Instead,
   we've been told that digest authentication is adequate
   for UDP. I kid you not.

	    Mike

---

From: Ofir Arkin <[email-masked]>
Date: Mon, 18 Feb 2002 21:07:14 +0000

Christian,

Let's examine several things here:

TLS and DNS Reverse Lookup
What we need with TLS is a DNS Reverse Lookup so we will be able to 
determine that the IP address which generated the traffic (or the 
presumable target) is really sip.microsoft.com (in your case) and not 
some other domain.

This is futile when the malicious party poisoned the DNS you query for 
both for name to IP and for IP to name records.

But it is another check missing from our specs.
As well as a MUST for verifying certificates for a client.

No UDP Any More?
UDP is not secure, and nothing will make it secure with the current 
offered standard. What is wired for me is that UDP was the winning 
transport protocol and suddenly TCP made a remarkable comeback...
So decide what you want to do, just remember the TCP has it's own 
weirdness. Don't come running when implementing TCP in large scale 
networks will be problematic... Slow start, retransmit, more time to 
bill the user and any other nice things. Let the user's discover they 
pay too much (1-several seconds more) for each call, cause miracle 
happen. I am not saying there is something else to do with UDP here, but 
the way all try to justify TCP.

And I cannot finish without S/MIME rent:
Another little note for S/MIME. In my opinion it might be useless in 
what it tries to do. If I wish to determine some details about your 
target, I will just connect to that host and send a BYE after the ACK. I 
will have all I need (as well as the IP for the peer-to-peer, etc). So 
what are we trying to defend here?...

BTW - I might gain that info from the RTP channel (YES I know that there 
are efforts to secure that as well - ENJOY).

We need to encrypt everything not just parts...

We need also to forget about pre-shared keys (god help me here).

I will wait for the flames to come. I am getting use to it here :P

P.S. 1 - UDP does work
P.S. 2 - It is about time people will look at the bigger picture here.

and if you are tired do not answer for the email...

btw - sorry for the english.

Enjoy
Ofir

-- 
Ofir Arkin
Managing Security Architect
@stake, Limited.
http://www.atstake.com
email: 
[email-masked]
Tel: 
+44 (0) 207 495 7002
Fax: 
+44 (0) 207 495 7062
Mobile: +44 (0) 779 630 8632	

-----------------------------
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material.  Any review, re transmission, dissemination or other use of, 
or taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited.  If you 
received this in error, please contact the sender and delete the 
material from any computer.

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 18 Feb 2002 23:09:08 +0200

>    we've been told that digest authentication is adequate

i fully support deprecating udp even in the presence of ipsec due to the
message size problems.

-- juha