Subject: RE: [Sip] draft-ietf-sip-rfc2543bis-07.9 now available

From: "Christian Huitema" <[email-masked]>
Date: Thu, 21 Feb 2002 17:18:14 -0800

Use reverse DNS lookup as a protection against DNS poisoning? You must
be kidding!

-- Christian Huitema 

> From: Ofir Arkin [mailto:[email-masked]]
>
> What about adding a Reverse DNS lookup so we can, not only, check the
> certificate domain against the domain we contacted but also the IP
> Source Address of the reply if it is corresponding with the domain
name
> as well...
> 
> Ofir
> 
> Christian Huitema wrote:
> 
> > In the Security section, the draft identifies the threat of
> > "Impersonating a Server" (26.1.2). I would suggest that we document
a
> > variant of this threat, DNS poisoning, and add text such as:
> >
> >    A possible way to impersonate a server is to use attacks against
the
> >    Domain Name System, such as "DNS poisoning." As explained in the
> > section
> >    4, Overview of Operation, we expect that a particular type of DNS
> > queries
> >    can be used to find the SIP server that serves a specific domain;
> >    attacking the DNS can induce a proxy or a UA to route the message
> > towards
> >    an impersonating server.
> >
> > The threat to the UA is addressed in section 26.3.2.1 by stating
that
> > the certificate must "correspond with the domain in which the UA
intends
> > to register", which is explained next as "must identify a host
within
> > the atlanta.com domain (such as sip.atlanta.com)." This is
reasonable,
> > but weak. With this rule, any host in the atlanta.com domain could
fake
> > a registration server; there is no way for the domain manager to
hand
> > out certificates that specifically designate the recipient as "an
> > authorized SIP server for the domain." An easily implemented
protection
> > would be a host name convention, such as having a certificate that
> > actually identifies the host as "sip.<domain>".
> >
> > A similar text is used in section 26.3.2.2, Interdomain Requests:
"The
> > atlanta.com proxy server, for example, SHOULD verify at this stage
that
> > the certificate received from the remote side corresponds with the
> > biloxi.com domain." This is again a bit underspecified, since it
would
> > potentially allow any compromised host in the "biloxi.com" domain to
> > impersonate a server. Again, a formal host name convention would be
more
> > effective.
> >
> > -- 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
> >
> 
> 
> --
> 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.
> 
> 
> _______________________________________________
> 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

_______________________________________________
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: Ofir Arkin <[email-masked]>
Date: Fri, 22 Feb 2002 09:25:25 +0000

Christian,

Did my 3 sentence post had the words "if the DNS server is poisoned" in 
it?... and by the way there are some who only compromise the name-to-IP 
venue and forget the IP-to-name, but this is another thing (and I bet it 
does not interest you).

Next time you jump and scream FIRE FIRE just read it slowly.

What I was referring to is another check that one can do, and it is 
extremely helpful if there is a host in the same domain which pertains 
to be a SIP entity (with the current certificate and all) or any other 
entity that you relay upon its certificate.

It is clear that if the DNS is poisoned this is game-over.

Ofir

-----------------------------
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.