Hi Klaus, I don't have any experience with SIP TLS, but just a couple of reflections/comments: - Normally a server certificate should have the fully qualified domain name as subject, i.e. server1.example.com, as example.com is not enough to identify the server - In that perspective I would interpret the exerpt so that subject should be server1.example.com and the _*._*.example.com should be added as alternative name - I haven't read the RFC you are referring to, but in a proxy-proxy scenario, do you really validate against an uri? Shouldn't you validate the server and not the actual requests? (If the proxy is relaying on behalf of others) Also, whether you want to accept a request to another domain is not really on TLS level is it?
Just my 2 cents worth. If I'm off target, just ignore ;-) g-)
----- Original Message ----- From: "Klaus Darilion" klaus.mailinglists@pernau.at To: "ser users" serusers@iptel.org; "users openser.org" users@openser.org Sent: Thursday, October 06, 2005 04:01 PM Subject: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
Hi!
I asked a question on the sip-implementors list. As nobody answered I post it here again, as it is also related to ser/openser.
thanks klaus
-------- Original Message -------- Subject: [Sip-implementors] TLS certificate question Date: Wed, 05 Oct 2005 09:10:05 +0200 From: Klaus Darilion klaus.mailinglists@pernau.at To: SIP Implementors sip-implementors@cs.columbia.edu
Hi!
I'm trying to figure out how to make a certificate for a SIP proxy. RFC3262, section 4.1 states:
For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack.
I'm not sure what the phrase "...MUST both be valid based on the site certificate" means. Does it mean that all possible domains must be present in the certificate?
now imagine the follwing DNS lookups: sip:user@example.com ; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.
_sips._tcp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5061 server1.example.com IN SRV 0 2 5061 server2.example.com _sip._tcp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com _sip._udp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com
Finally, a TLS connection is made with server1.example.com.
IF I understand RFC3263 correct, all of the above domains must be present in the certificate, but how to do this?
- Should I put CN=example.com into the Subject and all other domains
into the Subject Alternative Name? DNS=_sips._tcp.example.com. DNS=_sip._tcp.example.com DNS=_sip._udp.example.com. DNS=server1.example.com DNS=server2.example.com
- Should I leave the Subject empty and put all domains into the Subject
Alternative Name?
- Why is it not sufficient to use only the domain "example.com" in the
certificate (putting it into the subject field)?
- Which SIP URIs should be used to check against the domains in the
certificate (mutual proxy-proxy scenario)? Is it correct to check the domain in the request URI against the certificate of the receiving proxy, and check the domain in the From: URI against the certificate of the originating proxy?
Thanks for any clarifications Klaus _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers