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

[Tina TSOU <tena at huawei.com>]

See in line with [Tina2: ...]

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