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

From: Tina TSOU <[email-masked]>
Date: Wed, 20 Sep 2006 14:02:31 +0800

See in line with [Tina2: ...]

B. R.
Tina
Messengers: 
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]

----- Original Message ----- 
From: "Vijay K. Gurbani" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Friday, September 15, 2006 5:46 AM
Subject: Re: [Sip] doubts about draft-gurbani-sip-domain-certs

> Tina TSOU wrote:
>> See in line with [Tina1: ...].
>
> Tina: Please see inline.
>
> (Tina's email is in its entirety at
> http://www1.ietf.org/mail-archive/web/sip/current/msg16278.html;
> here I quote her questions).
>
>> [Tina1: Let me re-phrase the question: In the proposed solution in this
>> draft, there is only one
>> URI label in the extension, but in the text quoted, there are 2 sips
>> URI. How to map 2 sips URI into only one URI label?
>> I am not sure if one sips URI will be matched by URI label, the other
>> URI will be matched by DNS label. But this is not a consistent behavior.]
>
> I think we are talking past one another ... it is not the intent
> to map two SIP URIs into one.  All the section you quote is
> trying to say is that if a proxy is known through multiple
> names (i.e., sips:example.com and sips:downtown.example.com), then
> it is expected that it has keying material corresponding to each
> identity, and that it presents the right certificate when
> contacted.  The draft is trying to argue that a proxy can possess
> one certificate with multiple identities to allow cases where
> it can present the same certificate when contacted through a
> generic URI like "sips:example.com" and a host-specific URI
> (that may appear in a Route) like "sips:downtown.example.com".
[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. As DNS label is a transport layer label, then the site certificate will not be bound to the application layer protocol. So after any new application layer protocol stack being added to the same host, it's not required to apply a new certificate. 
Perhaps it's already discussed, however I don't have the need to add the URI label to site certificate as it's a site, so DNS label could be enough. But URI label may be useful for user certificate as the example in sec-flows 4.3. ]

>
>> [Tina1: as in your example, one domain can have multiple applications
>> such as mail, pres, sips, is it mandatory to have multiple URI labels
>> (one for each application)?]
>
> Yes; see example certificate in sec-flows-01, Section 4.3.
>
>> [Tina1: I feel that the statement "This NATPR and SRV may not yield any
>> RRs" doesn't mean 3263 resolution failed, it only means NAPTR or SRV
>> fails, but A/AAAA lookup will succeed, so 3263 resolution still succeed.]
>
> Yes, you are right.  We should qualify the phrase "RFC3263 resolution
> on the URI failed"...
>
>> Also, for sips:downtown.example.com, it may also yield NAPTR RR, say the
>> server want to map this sips URI to TLS over SCTP. As per the rule in
>> draft, if the NAPTR/SRV/A query success, the URI used for query should
>> match the URI label which is sips:example.com in your case, obviously it
>> cannot match. Is anything missed?
>
> In the above case, "sips:downtown.example.com" is a delegated
> subdomain, and thus the URI label in its certificate should say
> "URI:sips:downtown.example.com" and not "URI:sips:example.com".
>
>> [Tina1: As in the certificate, there is already a DN label which
>> intimates the domain and the domain of URL label is same as DN label,
>> why is the URI label required?]
>
> Do you mean DNS label or DN (Distinguished Name)?  I presume you
> meant DNS; if so then this catches the case where you are
> sending request through a specific proxy (probably due to R-R).
> When you opened a TLS connection to that proxy, it will present
> to you a certificate that had the hostname corresponding to the
> one that you opened the TLS connection to.
[Tina2: Thanks, I got it now:-) ]
>
>> In section 9, para 3,
>> <Quote>Certainly, this means that the domain must share the domain's
>> private key with the hosting service.</Quote>
>>
>> Why does the hosting service have to share the same private key? Is it
>> not allowed to have one private key per virtual domain?]
>
> In case of a virtual SIP server, the certificate (and its keying
> material) is owned by me, but the server itself is running on a
> third party's host.  So I do have to make the keying material
> available to the operator...
[Tina2: If the site certificate is different to the user certificate which can be used for S/MIME, it's maybe not a big issue that the hosting service shares its private key to the site.

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?]
>
> Thanks,
>
> - vijay
> -- 
> Vijay K. Gurbani  vkg@{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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 21 Sep 2006 18:07:59 -0500

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:[email-masked]", 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."
> 
> "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."
> 

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

---

From: Tina TSOU <[email-masked]>
Date: Fri, 22 Sep 2006 16:43:57 +0800

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

B. R.
Tina
Messengers: 

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

> "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:[email-masked]". 

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 24 Sep 2006 10:14:41 -0500

Tina TSOU wrote:
> [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:[email-masked]".

Backwards compatibility to what?  At the current time, there
is a fair amount of work in the WG to provide better guidelines
for both the SIPS URI as well as certificate use in SIP.

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

A host may have many DNS aliases, yes.  But if it is inserting
its URI in a R-R header, it can pick the alias whose canonical
name appears in the certificate.

Thanks.

- vijay

---

From: Tina TSOU <[email-masked]>
Date: Mon, 25 Sep 2006 10:39:19 +0800

Hi Vijay,
See in line with [Tina 4: ...]
Thanks a lot(:

B. R.
Tina
----- Original Message ----- 
From: "Vijay K. Gurbani" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Sunday, September 24, 2006 11:14 PM
Subject: Re: [Sip] doubts about draft-gurbani-sip-domain-certs

> for both the SIPS URI as well as certificate use in SIP.
[Tina4: In sip-sec-flow-01 section 8 Additional test scenarios, there is only DNS label being compared. But in this draft, URI label must be compared. This behavior is not compatible.]
> name appears in the certificate.
[Tina4: Perhaps I had missed some discussions on this draft about why SIP URI label should be introduced to TLS certificate verification and DNS label checking is not the preferred choice. Would you give me a reference?

This is the question which missed in the text jungle in last mail.
Is a host like multi-user computer within the scope of this draft? One kind of attack in multi-user computer is being discussed in connect-reuse draft section 9.3. If all the users share the same site certificate, the same attack can happen for TLS. ]

<[email-masked]>
Subject: Re: [Sip] doubts about draft-gurbani-sip-domain-certs
To: "Vijay K. Gurbani" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

Hi Vijay,
See in line with [Tina 4: ...]
Thanks a lot(:

B. R.
Tina
----- Original Message ----- 
From: "Vijay K. Gurbani" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Sunday, September 24, 2006 11:14 PM
Subject: Re: [Sip] doubts about draft-gurbani-sip-domain-certs

> for both the SIPS URI as well as certificate use in SIP.
[Tina4: In sip-sec-flow-01 section 8 Additional test scenarios, there is only DNS label being compared. But in this draft, URI label must be compared. This behavior is not compatible.]
> name appears in the certificate.
[Tina4: Perhaps I had missed some discussions on this draft about why SIP URI label should be introduced to TLS certificate verification and DNS label checking is not the preferred choice. Would you give me a reference?

This is the question which missed in the text jungle in last mail.
Is a host like multi-user computer within the scope of this draft? One kind of attack in multi-user computer is being discussed in connect-reuse draft section 9.3. If all the users share the same site certificate, the same attack can happen for TLS. ]