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?
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@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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
Greger V. Teigre writes:
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?
i'm not a TLS expert either, but i have been wondering if a proxy serving multiple domains would need to have a client/server certificate for each. i hope not.
in klaus' example, srv query on
_sips._tcp.example.com.
could return a server name in a domain foo.com. in proxy-to-proxy scenario, it should suffice that both proxies have certificates for the proxy hosts themselves and they don't need to have anything to do with the domains in the uris of sip requests.
-- juha
Juha Heinanen wrote:
Greger V. Teigre writes:
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?
i'm not a TLS expert either, but i have been wondering if a proxy serving multiple domains would need to have a client/server certificate for each. i hope not.
in klaus' example, srv query on
_sips._tcp.example.com.
could return a server name in a domain foo.com. in proxy-to-proxy scenario, it should suffice that both proxies have certificates for the proxy hosts themselves and they don't need to have anything to do with the domains in the uris of sip requests.
But then, the whole authorization thing would be nonsens.
Just imagine a host named "sip.badguy.com". This host has a valid certificate for its hostname. Then, this SIP proxy sends a SIP request with the header: From: "Klaus Darilion" sip:klaus@darilion.com
Now, what is the receiving proxy interested in? Does it want to validate the host or the sender (From header)?
IMO, I want to authenticate the sender in the From header. Thus, the certificate would have to match the SIP domain, and not the host name.
Please read RFC3263 section 4.1. It gives much insight.
regards klaus
Juha Heinanen wrote:
Greger V. Teigre writes:
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?
i'm not a TLS expert either, but i have been wondering if a proxy serving multiple domains would need to have a client/server certificate for each. i hope not. in klaus' example, srv query on
_sips._tcp.example.com.
could return a server name in a domain foo.com. in proxy-to-proxy scenario, it should suffice that both proxies have certificates for the proxy hosts themselves and they don't need to have anything to do with the domains in the uris of sip requests.
But then, the whole authorization thing would be nonsens.
Just imagine a host named "sip.badguy.com". This host has a valid certificate for its hostname. Then, this SIP proxy sends a SIP request with the header: From: "Klaus Darilion" sip:klaus@darilion.com
Now, what is the receiving proxy interested in? Does it want to validate the host or the sender (From header)?
IMO, I want to authenticate the sender in the From header. Thus, the certificate would have to match the SIP domain, and not the host name.
Please read RFC3263 section 4.1. It gives much insight.
But then you are not talking just about a proxy-to-proxy scenario. You don't really want to check only the integrity and authenticity of the proxy, but also of the sender. Just like smtp, you can use TLS to exchange messages between mail servers and you trust the certificate of the other mail server, but how do you check the sender of the email? It's on a different level and mostly you do it on the MTA level. Of course, you could add checks verifying that emails from mail server A matches the domain found in server A's certificate.
From that perspective, you would probably only allow From domains that are
found in the CN and alternative names of the certificate of server A.
I don't think this is a general matter (finding what is "correct"), but more about the policies you implement (or level of integrity checks you want to enforce). Do you allow the certificate of the sender to deviate (domain-wise) from the domain of the proxy? If you have multiple proxies between you and the sender and you trust the proxy, you probably will allow it. If you are peering with a proxy and only want to allow that proxy's users, you probable disallow it.
BTW, "I want to authenticate the sender in the From header": You cannot possibly authenticate the sender in the From header using the proxy server certificate, you need to use the sender's certificate. You can verify that the proxy you trust (because the certificate is correct) does not try to forward calls from somebody outside its domain (maybe a hacker found a way to do that through that proxy). And if the bad guy really wants to send you from darillion.com, he can add that domain to his certificate as an alternative name (if I interpret the mentioned section correctly).
Out of interest: Is this related to SER TLS or are you working on some other implementation that you can share info on? g-)
Hi all, Interesting discussion :) On 10/10/05, Greger V. Teigre greger@teigre.com wrote:
From that perspective, you would probably only allow From domains that
are found in the CN and alternative names of the certificate of server A.
I don't think this is a general matter (finding what is "correct"), but more about the policies you implement (or level of integrity checks you want to enforce). Do you allow the certificate of the sender to deviate (domain-wise) from the domain of the proxy? If you have multiple proxies between you and the sender and you trust the proxy, you probably will allow it. If you are peering with a proxy and only want to allow that proxy's users, you probable disallow it.
I would agree with greger that the authentication you need depends on the local policy. For that, ser needs to provide flexible mechanism as i don't think there is a one-fits-all. As it is now, the current tls code does not really allow for flexibility, i would say. How about creating some kind of module that would allow in-depth access to tls functions, such as - tls_verify_peer_cert() - tls_check_from() - tls_check_to() ..... This way a barebones connection may be accepted on the tls level (say, just server authentication). Then, in the config file you may be able to stiffen the authentication requirements with a bunch of functionalities provided by a tls_tools module. Regards, Cesc
Hi!
Thanks for your comments!
I just wanted you to know that I'm still working on my answer (reading RFC, list archives ...). Thus, no answer yet ;-)
Cesc wrote:
Hi all,
Interesting discussion :)
...
As it is now, the current tls code does not really allow for flexibility, i would say. How about creating some kind of module that would allow in-depth access to tls functions, such as
- tls_verify_peer_cert()
- tls_check_from()
- tls_check_to()
I agree. We will need this functions. We should also document what the current implementation is validating (when authenticating a server certificate: which domain is checked against which part of the certificate?) ...
regards klaus
..... This way a barebones connection may be accepted on the tls level (say, just server authentication). Then, in the config file you may be able to stiffen the authentication requirements with a bunch of functionalities provided by a tls_tools module.
Regards,
Cesc
On Monday 10 October 2005 19:54, Klaus Darilion wrote:
As it is now, the current tls code does not really allow for flexibility, i would say. How about creating some kind of module that would allow in-depth access to tls functions, such as
- tls_verify_peer_cert()
- tls_check_from()
- tls_check_to()
I agree. We will need this functions. We should also document what the current implementation is validating (when authenticating a server certificate: which domain is checked against which part of the certificate?) ...
Just a note: your are thinking/discussing here about the connection layer. But when the script is processed the connection is already established. So the only thing which you can do in the script is verifying the client certificate. As the connection is already established you can only reject the request on the SIP layer. And client certificates usually work only in proxy-toproxy scenarios, but not for typical UA's. Server certificate verification can only be handled by a global policy.
Nils
Nils Ohlmeier wrote:
On Monday 10 October 2005 19:54, Klaus Darilion wrote:
As it is now, the current tls code does not really allow for flexibility, i would say. How about creating some kind of module that would allow in-depth access to tls functions, such as
- tls_verify_peer_cert()
- tls_check_from()
- tls_check_to()
I agree. We will need this functions. We should also document what the current implementation is validating (when authenticating a server certificate: which domain is checked against which part of the certificate?) ...
Just a note: your are thinking/discussing here about the connection layer. But when the script is processed the connection is already established. So the only thing which you can do in the script is verifying the client certificate. As the connection is already established you can only reject the request on the SIP layer. And client certificates usually work only in proxy-toproxy scenarios, but not for typical UA's. Server certificate verification can only be handled by a global policy.
basically, there are two cases: 1) incoming TLS connections - you can check the connection properties from script (based on the source IP, like if it's a proxy peer, check if a certificate was provided). You may reject the connection on SIP level 2) outgoing connections - you can set before relaying the desired parameters for the outgoing TLS connection (again, based on the destination IP, if it's peer or not). In this case the rejection will take place directly at connection layer.
based on this you can deal in a secure way with both UAC and proxy certificated.
regards, bogdan
Bogdan-Andrei Iancu wrote:
Nils Ohlmeier wrote:
On Monday 10 October 2005 19:54, Klaus Darilion wrote:
As it is now, the current tls code does not really allow for flexibility, i would say. How about creating some kind of module that would allow in-depth access to tls functions, such as
- tls_verify_peer_cert()
- tls_check_from()
- tls_check_to()
I agree. We will need this functions. We should also document what the current implementation is validating (when authenticating a server certificate: which domain is checked against which part of the certificate?) ...
Just a note: your are thinking/discussing here about the connection layer. But when the script is processed the connection is already established. So the only thing which you can do in the script is verifying the client certificate. As the connection is already established you can only reject the request on the SIP layer. And client certificates usually work only in proxy-toproxy scenarios, but not for typical UA's. Server certificate verification can only be handled by a global policy.
basically, there are two cases:
- incoming TLS connections - you can check the connection properties
from script (based on the source IP, like if it's a proxy peer, check if a certificate was provided). You may reject the connection on SIP level
How? I do not want to check IP addresses (static configuration). I want to use TLS to avoid checking IP addresses. We would need functions like Cesc suggested (tls_check_to ...)
regards klaus
- outgoing connections - you can set before relaying the desired
parameters for the outgoing TLS connection (again, based on the destination IP, if it's peer or not). In this case the rejection will take place directly at connection layer.
based on this you can deal in a secure way with both UAC and proxy certificated.
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Monday 10 October 2005 10:03, Klaus Darilion wrote:
Juha Heinanen wrote:
i'm not a TLS expert either, but i have been wondering if a proxy serving multiple domains would need to have a client/server certificate for each. i hope not.
in klaus' example, srv query on
_sips._tcp.example.com.
could return a server name in a domain foo.com. in proxy-to-proxy scenario, it should suffice that both proxies have certificates for the proxy hosts themselves and they don't need to have anything to do with the domains in the uris of sip requests.
But then, the whole authorization thing would be nonsens.
Just imagine a host named "sip.badguy.com". This host has a valid certificate for its hostname. Then, this SIP proxy sends a SIP request with the header: From: "Klaus Darilion" sip:klaus@darilion.com
Now, what is the receiving proxy interested in? Does it want to validate the host or the sender (From header)?
IMO, I want to authenticate the sender in the From header. Thus, the certificate would have to match the SIP domain, and not the host name.
Please read RFC3263 section 4.1. It gives much insight.
I think you are right for the scenarios where you are the client and you are serving the domain in the From header. In that case you should present a certificate which matches the From. But on the other site: what happens if you just forwarded the request and neither the From, To or (the new) request-uri belongs to you. In that case you can only present a generic certificate which matches one of your domains. But for me it is anyhow a question what a server is going to verify on a client certificate.
But for the server scenario I think Juha is right. Because when the TLS connections is being establish you do not know for what is the target domain of the request. Thus you can only present one generic certificate and that should be valid for all of your domains.
Nils
Klaus Darilion writes:
But then, the whole authorization thing would be nonsens.
Just imagine a host named "sip.badguy.com". This host has a valid certificate for its hostname. Then, this SIP proxy sends a SIP request with the header: From: "Klaus Darilion" sip:klaus@darilion.com
Now, what is the receiving proxy interested in? Does it want to validate the host or the sender (From header)?
there are other ietf means to validate the sender. usually they involve signing of from uri with the certificate of its domain. see for example
draft-rosenberg-sip-identity-privacy-00
for a good summary of the issues and problems involved. in proxy-to-proxy case, all that needs to be done is to validate the remote proxy.
IMO, I want to authenticate the sender in the From header. Thus, the certificate would have to match the SIP domain, and not the host name.
see above.
-- juha