6 Oct
2005
6 Oct
'05
10:01 a.m.
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
8 Oct
8 Oct
3:09 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
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(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
3:57 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
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
10 Oct
10 Oct
4:03 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
Juha Heinanen wrote:
Greger V. Teigre 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)?
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
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.
4:38 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
Juha Heinanen wrote:
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.
Greger V. Teigre 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)?
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 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. 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-)
5:14 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
Hi all,
Interesting discussion :)
On 10/10/05, Greger V. Teigre <greger(a)teigre.com> wrote:
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
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.
1:54 p.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
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
5:26 p.m.
New subject: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
On Monday 10 October 2005 19:54, Klaus Darilion wrote:
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
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?) ... 
11 Oct
11 Oct
4:44 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
Nils Ohlmeier wrote:
On Monday 10 October 2005 19:54, Klaus Darilion wrote:
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
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?) ...
4:59 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
Bogdan-Andrei Iancu wrote:
Nils Ohlmeier wrote:
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
On Monday 10 October 2005 19:54, Klaus Darilion
wrote:
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 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?) ...
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
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
10 Oct
10 Oct
5 a.m.
New subject: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
On Monday 10 October 2005 10:03, Klaus Darilion wrote:
Juha Heinanen wrote:
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
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.
9:44 a.m.
New subject: [Users] Re: [Serusers] [Fwd: [Sip-implementors] TLS certificate question]
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
6840
days inactive
6845
days old
11 comments
6 participants
participants (6)
-
Bogdan-Andrei Iancu -
Cesc -
Greger V. Teigre -
Juha Heinanen -
Klaus Darilion -
Nils Ohlmeier