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

From: Tina TSOU <[email-masked]>
Date: Thu, 07 Sep 2006 21:21:13 +0800

Hi All,
 
I had some doubts about draft-gurbani-sip-domain-certs as following. It will be appreciated if someone would like to reply it.

1. In section 3 

<Quote>
   One way to combat this
   is to arrange for the proxy to possess two certificates -- one
   corresponding to "sips:example.com" and the other corresponding to
   "sips:downtown.example.com" -- and have it present the right one when 
   contacted.
</Quote>

But as per my understanding, the proposal in this draft doesn't resolve 
this problem thereinbefore. As there is only one SIPURI identity in certificate,
it cannot handle the proxy which had a domain name and a site name. 
Do I miss something?

2. As my understanding of section 4, Does it mean that certificate will contain two 
identities, one identity for transport layer, one for application protocol layer?
Is it possible to have multiple application protocol identity? e.g, one is sips:example.com,
another is sips:donwtown.example.com.

How about multiple kind of application layer protocols implemented by one site? it will
have each identity for every protocols?

3. In Section 5, 

<Quote>
If the UAC performed RFC3263 resolution on the
   URI to reach the server, the SIPS identity stored in the certificate
   MUST be matched.  Otherwise, if RFC3263 resolution on the URI failed, 
   the UAC MUST match the DNS label in the certificate with the name of
   the server that it opened a TLS connection to.
</Quote>
  "the SIPS ... MUST be matched", which URI will be used to match this SIPS identity?
Is it the NextHop URI UAC used to reach the server? If it's the NextHop URI and 3263 
resolution failed, how the UAC can find the server and then get the ceritificate from 
the server?

Thanks ahead.

B. R.
Tina
Messengers: 
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]
_______________________________________________
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: Tina TSOU <[email-masked]>
Date: Fri, 08 Sep 2006 11:47:22 +0800

Hi all,
I'm afraid this email has not been noticed as there is another thread which has similar subject title "[Sip] doubts about draft-audet-sip-sips-guidelines-03.txt"-_-|||

B. R.
Tina
  ----- Original Message ----- 
  From: Tina TSOU 
  To: [email-masked] 
  Sent: Thursday, September 07, 2006 9:21 PM
  Subject: [Sip] some doubts about draft-gurbani-sip-domain-certs

  Hi All,

  1. In section 3 

  <Quote>
     One way to combat this

  3. In Section 5, 

  <Quote>

  Thanks ahead.

  B. R.
  Tina
  Messengers: 

------------------------------------------------------------------------------

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 08 Sep 2006 08:10:12 -0500

Tina TSOU wrote:
> Hi All,
> 
> I had some doubts about draft-gurbani-sip-domain-certs as following.
>  It will be appreciated if someone would like to reply it.

Tina: Thanks for a reading of the draft.  More inline.

> 1. In section 3
> 
> <Quote> One way to combat this is to arrange for the proxy to possess
>  two certificates -- one corresponding to "sips:example.com" and the
>  other corresponding to "sips:downtown.example.com" -- and have it 
> present the right one when contacted. </Quote>
> 
> But as per my understanding, the proposal in this draft doesn't 
> resolve this problem thereinbefore. As there is only one SIPURI 
> identity in certificate, it cannot handle the proxy which had a 
> domain name and a site name. Do I miss something?

Ummm...I am not sure I follow your question.  The text you
quote further explains why having two certificates is not
desirable...

> 2. As my understanding of section 4, Does it mean that certificate 
> will contain two identities, one identity for transport layer, one 
> for application protocol layer?

Yes.

> Is it possible to have multiple application protocol identity? e.g, 
> one is sips:example.com, another is sips:donwtown.example.com.

You could conceivably have multiple application level
identities bound to the certificate, e.g., mailto:[email-masked],
sips:[email-masked], pres:[email-masked] and so on.  These
will be present in the certificate as a set of URIs.

However, if you note the draft has different labels on
"downtown.example.com" and "example.com"; the former is preceeded
by a "DNS" label, and the latter by a "URI" label.  So they are
two different identities.

> How about multiple kind of application layer protocols implemented by
>  one site? it will have each identity for every protocols?

Example ... I think I know what you mean, but in case my understanding
is flawed, I do not want to go off on a tangent...

> 3. In Section 5,
> 
> <Quote> If the UAC performed RFC3263 resolution on the URI to reach 
> the server, the SIPS identity stored in the certificate MUST be 
> matched.  Otherwise, if RFC3263 resolution on the URI failed, the UAC
>  MUST match the DNS label in the certificate with the name of the 
> server that it opened a TLS connection to. </Quote>

> "the SIPS ... MUST be matched", which URI will be used to match this
> SIPS identity? Is it the NextHop URI UAC used to reach the server? 

If by "NextHop URI" you mean the R-URI or the topmost Route URI, yes.

> If it's the NextHop URI and 3263 resolution failed, how the UAC can find
> the server and then get the ceritificate from the server?

Let's say you had a request destined to "sip:[email-masked]".
Doing an rfc3263-resolution on example.com domain will yield
a set IP address, port, transport tuples.  If when contacted over
TLS, the server presents a certificate with the SAN label
"sips:example.com", then you can be sure that your connection
reached the right destination.

Now, let's say that as a result of a Route list, you had a request
destined to "sips:[email-masked]", where downtown is a
specific host in the example.com domain.  NAPTR and SRV of
"downtown.example.com" may not yield any RRs, so you would do a
A/AAAA lookup.  If when contacted over TLS, the server presents a
certificate with the SAN label "DNS:downtown.example.com", then
you can be sure that your connection has reached the right
destination.

Note that in the last case above, it may be the same server that
was contacted during the first case.  But two different URIs were
used to reach it; however, by having the right set of identities
in the certificate, the server is accessible to either URI.

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)