Re: [Sip] doubts about draft-gurbani-sip-domain-certs

[Tina TSOU <tena at huawei.com>]

Vijay: Thanks for your detailed explanation. Please see [Tina3: ...].

B. R.
Tina
Messengers: 
MSN: tinatsou6 at hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina at jabber.org

----- Original Message ----- 
From: "Vijay K. Gurbani" <vkg at lucent.com>
To: "Tina TSOU" <tena at huawei.com>
Cc: "IETF SIP List" <sip at ietf.org>
Sent: Friday, September 22, 2006 7:07 AM
Subject: Re: [Sip] doubts about draft-gurbani-sip-domain-certs


> Tina: Thanks for your comments; please see inline.
> 
> Tina TSOU wrote:
> > [Tina2: Is it possible that we can use another DNS label other than
> > URI label to do the same thing? E.g. instead of using DNS:
> > example.com and sips: downtown.example.com, we can define DNS:
> > example.com and DNS: downtown.example.com label. 
> 
> It is not the intent of the draft to make the certificate a
> repository of all DNS aliases.  Instead, we are trying to
> determine if a judicious set of identities can help in
> increasing the confidence with respect to the authenticity
> of the server when it is contacted.
> 
> To that extent, the URI label helps when a request is routed
> to the server as a result of running RFC3263 on a URI like
> "sips:user at example.com", and the DNS label helps when a request
> is routed to the server as a result of running RFC3263 on a
> URI that may appear in, say, the Route header; i.e.,
> "Route: <sips:downtown.example.com;lr>".
[Tina3: 
A.  This solution is not backward compatible with many implementation which only compare the DNS label, either the URI for 3263 resolution like "<sips:downtown.example.com;lr>" or "sips:user at example.com". 

B. What's the advantage in concept-wise or implementing by introducing this URI label? Even a host may have many DNS aliases, but it will not be changed frequently. ]

[Tina3: 
Is a host like multi-user computer the concern of this draft? One kind of attack in multi-user computer is being discussed in connect-reuse draft. If all the users share the same certificate, the same attack can happen for TLS. 
]
> 
> > In section 6 UAS Considerations, "If the domain is one that is
> > allowed by such a policy, the TLS connection can be considered to be
> > authenticated."
> > 
> > This behavior is not consistent with section 5.2 in sip-tls-use which
> > defines a reverse lookup.
> > 
> > "Thus, to be certain, P2 should do a reverse DNS lookup of the source
> > address of the incoming TCP packet and match the result to the
> > contents of the certificate that contain P1's canonical hostname."
> > 
> > Which one should be followed?]
> 
> I have learned a few things since sip-tls-use-00 ;-)
> 
> Yes, you are right; the above two views are not completely
> consistent.  We had a good discussion in the Dallas IETF (I
> think) on the merits and de-merits of doing a reverse DNS lookup.
> At the time I had wrote sip-tls-use-00, I accorded more trust
> to DNS than I did to a compromised certificate.  As was
> pointed out in the meeting, this may not be entirely a good
> thing.
> 
> Assume a certificate C contains a DNS label P1 (i.e., C is bound
> to identity P1).  Assume that IPAddress(P1) = 10.1.1.1.
> 
> Let's consider DNS to be compromised if the attacker has inserted
> bogus RRs.
> 
> Let's consider C to be compromised if its passphrase is
> stolen (note that if this happens, the legitimate user can
> ask the CA to put C in the CRL, but I don't think CRLs are
> ubiquitous yet.)  If C is compromised and used from P1
> by the attacker, there is nothing that can be done to prevent
> this attack due to the lack of CRLs.
> 
> Of interest to us is if C is compromised and used on a
> different host, or if the legitimate user that owns C uses
> it for malicious purposes by possibly using it on a host
> other than P1.
> 
> Case 1: C is compromised, but DNS is not.  C is used on a
>   SIP host P2 (instead of P1, which would be normally where
>   C would be used.)  IPAddress(P2) = 10.1.1.2.
>   The cracker sends a SIP request with a topmost Via of:
> 
>   Via: SIP/2.0/TLS P1;branch=...;received=10.1.1.2
> 
>   (received parameter added by the server).  Server does a
>   ReverseIPAddress(10.1.1.2) = P2 != P1, and immediately closes
>   the connection.
> 
>   However, if the attacker changes the source address in the packet
>   to be 10.1.1.1, then the server will do a
>   ReverseIPAddress(10.1.1.1) = P1, and the attacker succeeds.
> 
> Case 2: C is compromised and DNS is also compromised so that
>   ReverseIPAddress(10.1.1.2) returns P1; the attacker succeeds.
> 
> Case 3: DNS is compromised, C is not.
>   The attacker can make DNS return anything to match the identity
>   in C.
> 
> Case 4: C is NOT compromised, and DNS is NOT compromised.
>   We count our lucky stars ;-)
> 
> So checking against DNS is not perfect.  Depending on how
> the attack is mounted, the server does not know whether or not
> DNS was compromised.
> 
> I believe that the WG generally leans in the direction that
> the server follows some policy when making a decision whether
> or not a client certificate should be accepted.  Making that
> decision based on the URI label seems appropriate.
> 
> When I revise sip-tls-use, I will ensure that it matches with
> domain-certs.
> 
> Thanks.
> 
> - vijay
> -- 
> Vijay K. Gurbani  vkg at {lucent.com,research.bell-labs.com,acm.org}
> Bell Laboratories, Lucent Technologies, Inc.
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip