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.
is not enough to
identify the server
- In that perspective I would interpret the exerpt so that subject should be
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(a)pernau.at>
To: "ser users" <serusers(a)iptel.org>rg>; "users openser.org"
<users(a)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(a)pernau.at>
To: SIP Implementors <sip-implementors(a)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?
1. 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
2. Should I leave the Subject empty and put all domains into the Subject
Alternative Name?
3. Why is it not sufficient to use only the domain "example.com" in the
certificate (putting it into the subject field)?
4. 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(a)cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serusers