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" <[EMAIL PROTECTED]>
To: "ser users" <[EMAIL PROTECTED]>; "users openser.org"
<[email protected]>
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 <[EMAIL PROTECTED]>
To: SIP Implementors <[email protected]>
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:[EMAIL PROTECTED]
; 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
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Serusers mailing list
[EMAIL PROTECTED]
http://mail.iptel.org/mailman/listinfo/serusers
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
