[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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>".
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