Hi all!
I want to differ between _incoming_ SIP requests from trusted peers and from untrused (for different call routing). I came to the following solutions. All of them has some disadvantages, and I would like to now which you would prefer:
1. src_ip: incoming request are authenticated using the src_ip (only in TCP mode useful) +: easy to implement +: easy to differ authenticated from unauthenticated incoming calls -: lots of configuration (IP addresses may change, ) This can be implemented using if src_ip==... blocks in openser.cfg, which would require the change the script everytime the IP addresses are changed. Also requires restart of the proxy.
Also from_gw() from lcr module can be used. But this would interfere with the already used lcr tasks and IP addresses. Maybe copy/paste the code into a new function called from_peer().
2. IPsec: makes it hard to differ trusted from untrusted incomig requests in the application. Again verification of the src_ip would be necessary. -: requires sharing secrets with each peer +: works also with TCP and TLS unaware proxies
3. TLS with certificates signed by me. Then, if my SIP proxy only uses my root CA, all authenticated TLS connection must be from my trusted peers. +: simple, as long as there is only 1 perring-club to authenticate +: works with current (open)ser -: can't use public CA roots -: requires signing of the public key of the peer
4. TLS with public signed certificates. (open)ser would validate the TLS certificate. But after that, I need some function like tls_is_from_trusted() which checks the Subject of the certificate against a list of trusted peers. +: can use public signed CA roots +: allows to use TLS for incoming trusted and incoming untrusted peers -: need some more tls specific functions in (open)ser -: certificate costs $$$
5. Digest Auth between proxies -: uac module is not standard conform (CSeq Problem) -: requires sharing secrets with each peer
If I have forgotten some possibilities or made some mistakes please correct me.
regards klaus
On 11-10-2005 14:55, Klaus Darilion wrote:
Hi all!
I want to differ between _incoming_ SIP requests from trusted peers and from untrused (for different call routing). I came to the following solutions. All of them has some disadvantages, and I would like to now which you would prefer:
- src_ip: incoming request are authenticated using the src_ip (only in
TCP mode useful) +: easy to implement +: easy to differ authenticated from unauthenticated incoming calls -: lots of configuration (IP addresses may change, ) This can be implemented using if src_ip==... blocks in openser.cfg, which would require the change the script everytime the IP addresses are changed. Also requires restart of the proxy.
You can also use trusted table and permission module.
Jan.
Jan Janak wrote:
On 11-10-2005 14:55, Klaus Darilion wrote:
Hi all!
I want to differ between _incoming_ SIP requests from trusted peers and from untrused (for different call routing). I came to the following solutions. All of them has some disadvantages, and I would like to now which you would prefer:
- src_ip: incoming request are authenticated using the src_ip (only in
TCP mode useful) +: easy to implement +: easy to differ authenticated from unauthenticated incoming calls -: lots of configuration (IP addresses may change, ) This can be implemented using if src_ip==... blocks in openser.cfg, which would require the change the script everytime the IP addresses are changed. Also requires restart of the proxy.
You can also use trusted table and permission module.
Right! I think this should be documented somewhere :-)
Maybe we can adopt the this function to verify the doman of the client certificate?
regards klaus
On 11-10-2005 15:46, Klaus Darilion wrote:
Jan Janak wrote:
On 11-10-2005 14:55, Klaus Darilion wrote:
Hi all!
I want to differ between _incoming_ SIP requests from trusted peers and from untrused (for different call routing). I came to the following solutions. All of them has some disadvantages, and I would like to now which you would prefer:
- src_ip: incoming request are authenticated using the src_ip (only in
TCP mode useful) +: easy to implement +: easy to differ authenticated from unauthenticated incoming calls -: lots of configuration (IP addresses may change, ) This can be implemented using if src_ip==... blocks in openser.cfg, which would require the change the script everytime the IP addresses are changed. Also requires restart of the proxy.
You can also use trusted table and permission module.
Right! I think this should be documented somewhere :-)
Maybe we can adopt the this function to verify the doman of the client certificate?
Client certificate ? Why ? Make sure that the client certificate is created by a trusted CA (which is known to SER) and once a request arrives over TLS then you know that the certificate was valid (provided that you enable client certificate verification).
Jan.
Jan Janak wrote:
On 11-10-2005 15:46, Klaus Darilion wrote:
Jan Janak wrote:
On 11-10-2005 14:55, Klaus Darilion wrote:
Hi all!
I want to differ between _incoming_ SIP requests from trusted peers and
from untrused (for different call routing). I came to the following
solutions. All of them has some disadvantages, and I would like to now which you would prefer:
- src_ip: incoming request are authenticated using the src_ip (only in
TCP mode useful) +: easy to implement +: easy to differ authenticated from unauthenticated incoming calls -: lots of configuration (IP addresses may change, ) This can be implemented using if src_ip==... blocks in openser.cfg, which would require the change the script everytime the IP addresses are changed. Also requires restart of the proxy.
You can also use trusted table and permission module.
Right! I think this should be documented somewhere :-)
Maybe we can adopt the this function to verify the doman of the client certificate?
Client certificate ? Why ? Make sure that the client certificate is created by a trusted CA (which is known to SER) and once a request arrives over TLS then you know that the certificate was valid (provided that you enable client certificate verification).
Knowing that the certificate is valid is not enough. Badguy can have a certificate for badguy.com which is perfectly valid, but this does not imply that I trust badguy.com. I have to compare the certificate domain with the domains of trusted peers somehow.
regards klaus
On Tuesday 11 October 2005 16:32, Klaus Darilion wrote:
Jan Janak wrote:
Client certificate ? Why ? Make sure that the client certificate is created by a trusted CA (which is known to SER) and once a request arrives over TLS then you know that the certificate was valid (provided that you enable client certificate verification).
Knowing that the certificate is valid is not enough. Badguy can have a certificate for badguy.com which is perfectly valid, but this does not imply that I trust badguy.com. I have to compare the certificate domain with the domains of trusted peers somehow.
Klaus, if you do not trust badguy.com although he has a valid singed certificate from a CA which you trust, then you can throw away TLS completely. The hole model only works because the trust in inherited from the CA when you get a singed certificate. If you do not trust any CA, except your own, then you created your own trust database which is hard to maintain. No matter what is the base of the trustworthyness (IP; certificate signed by you; shared secret or signed certificate for IPSec) maintaining the trust database (or however you call it) is a real pain, that is the reason why you should trust someone else to do this job.
BTW why do you need/want to trust someone and others not? You want to give privileges to the trustworthy. But what happens if they cheat you? You should be able to track them down. And then sue them (if the laws of both countries allows this)?
Sueing them is your only weapon in the end. If you cant sue them you are doomed anyway no matter what is your trust base.
Enough philosophy :-) Nils
My impression was that Klaus wanted to use TLS for authentication (that is badguy.com is really badguy.com if he had certificate signed by trusted CA) and then perform authorization based on some data obtained from TLS. In other words, TLS based authentication is transparent to the application, while for TLS based authorization more code in SER is needed.
Jan.
On 11-10-2005 23:04, Nils Ohlmeier wrote:
On Tuesday 11 October 2005 16:32, Klaus Darilion wrote:
Jan Janak wrote:
Client certificate ? Why ? Make sure that the client certificate is created by a trusted CA (which is known to SER) and once a request arrives over TLS then you know that the certificate was valid (provided that you enable client certificate verification).
Knowing that the certificate is valid is not enough. Badguy can have a certificate for badguy.com which is perfectly valid, but this does not imply that I trust badguy.com. I have to compare the certificate domain with the domains of trusted peers somehow.
Klaus, if you do not trust badguy.com although he has a valid singed certificate from a CA which you trust, then you can throw away TLS completely. The hole model only works because the trust in inherited from the CA when you get a singed certificate. If you do not trust any CA, except your own, then you created your own trust database which is hard to maintain. No matter what is the base of the trustworthyness (IP; certificate signed by you; shared secret or signed certificate for IPSec) maintaining the trust database (or however you call it) is a real pain, that is the reason why you should trust someone else to do this job.
BTW why do you need/want to trust someone and others not? You want to give privileges to the trustworthy. But what happens if they cheat you? You should be able to track them down. And then sue them (if the laws of both countries allows this)?
Sueing them is your only weapon in the end. If you cant sue them you are doomed anyway no matter what is your trust base.
Enough philosophy :-) Nils
Nils Ohlmeier wrote:
On Tuesday 11 October 2005 16:32, Klaus Darilion wrote:
Jan Janak wrote:
Client certificate ? Why ? Make sure that the client certificate is created by a trusted CA (which is known to SER) and once a request arrives over TLS then you know that the certificate was valid (provided that you enable client certificate verification).
Knowing that the certificate is valid is not enough. Badguy can have a certificate for badguy.com which is perfectly valid, but this does not imply that I trust badguy.com. I have to compare the certificate domain with the domains of trusted peers somehow.
Klaus, if you do not trust badguy.com although he has a valid singed certificate from a CA which you trust, then you can throw away TLS completely.
There is a big difference between authentication and authorization.
1. I have to authenticate the peer. Using TLS and certifiactes is fine.
2. I have to authorize the peer. Some peers will be e.g. routed different. You would this this like: if (message is from trusted peer) { ....
So I need to check the certificate in ser.cfg somehow, or associate the domain in the From header with the domain in the certificate.
Or do I miss the point?
regards klaus
The hole model only works because the trust in inherited from the CA when you get a singed certificate. If you do not trust any CA, except your own, then you created your own trust database which is hard to maintain. No matter what is the base of the trustworthyness (IP; certificate signed by you; shared secret or signed certificate for IPSec) maintaining the trust database (or however you call it) is a real pain, that is the reason why you should trust someone else to do this job.
BTW why do you need/want to trust someone and others not? You want to give privileges to the trustworthy. But what happens if they cheat you? You should be able to track them down. And then sue them (if the laws of both countries allows this)?
Sueing them is your only weapon in the end. If you cant sue them you are doomed anyway no matter what is your trust base.
Enough philosophy :-) Nils
Hi, Klaus, i think that you hit the fountain of truth :) As of now, ser-tls only provides transport layer authentication. Not more. Who is allowed to authenticate? all those you trust, that is, all those with the cert signed by the CAs you trust. If you picked a ruthless CA that would give away certs to hacking.incorporated.comhttp://hacking.incorporated.com... sorry :) Now, for sip message authentication and authorization you need to lift the authentication information from TLS up to the application (ser). It is not difficult, it just needs a few lines of code for that (all the certs exchanged are within reach for as long as the tls connection stays up). Here is where the tls_tools module's functions (to be written) come into play: - tls_check_from/to() - tls_check_cn_trusted() - ...
So, let's say we want to set up a tls test network (which we do). We don't want to pay for the certs, so we should generate a root cert (say, "openser.org http://openser.org"). It would be even better if some nice CA whose cert is signed by a recognized root would do sign that for us ... anyone with connections? :) This would ease transition and compatibility issues ... The root cert provides certs for each domain (providerX.com, providerY.net, ... ) Now, we all can authenticate each other. With the tools for sip authentication and authorization, you can decide who you allow to do what in your proxy ... Regards, Cesc On 10/12/05, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Nils Ohlmeier wrote:
Klaus, if you do not trust badguy.com http://badguy.com although he
has a valid singed
certificate from a CA which you trust, then you can throw away TLS completely.
There is a big difference between authentication and authorization.
I have to authenticate the peer. Using TLS and certifiactes is fine.
I have to authorize the peer. Some peers will be e.g. routed
different. You would this this like: if (message is from trusted peer) { ....
So I need to check the certificate in ser.cfg somehow, or associate the domain in the From header with the domain in the certificate.
Or do I miss the point?
regards klaus
The hole model only works because the trust in inherited from the CA
when you
get a singed certificate. If you do not trust any CA, except your own, then you created your own
trust
database which is hard to maintain. No matter what is the base of the trustworthyness (IP; certificate signed by you; shared secret or signed certificate for IPSec) maintaining the trust database (or however you
call
it) is a real pain, that is the reason why you should trust someone else
to
do this job.
Excellent summary! :-) Have you looked at http://www.cacert.org/ ? g-) ----- Original Message ----- From: Cesc To: Klaus Darilion Cc: serusers@iptel.org ; users openser.org Sent: Wednesday, October 12, 2005 11:13 AM Subject: Re: [Users] Re: [Serusers] trusting peers
Hi,
Klaus, i think that you hit the fountain of truth :) As of now, ser-tls only provides transport layer authentication. Not more. Who is allowed to authenticate? all those you trust, that is, all those with the cert signed by the CAs you trust. If you picked a ruthless CA that would give away certs to hacking.incorporated.com ... sorry :)
Now, for sip message authentication and authorization you need to lift the authentication information from TLS up to the application (ser). It is not difficult, it just needs a few lines of code for that (all the certs exchanged are within reach for as long as the tls connection stays up). Here is where the tls_tools module's functions (to be written) come into play: - tls_check_from/to() - tls_check_cn_trusted() - ...
So, let's say we want to set up a tls test network (which we do). We don't want to pay for the certs, so we should generate a root cert (say, "openser.org"). It would be even better if some nice CA whose cert is signed by a recognized root would do sign that for us ... anyone with connections? :) This would ease transition and compatibility issues ... The root cert provides certs for each domain (providerX.com, providerY.net, ... ) Now, we all can authenticate each other. With the tools for sip authentication and authorization, you can decide who you allow to do what in your proxy ...
Regards,
Cesc
On 10/12/05, Klaus Darilion klaus.mailinglists@pernau.at wrote: Nils Ohlmeier wrote: > Klaus, if you do not trust badguy.com although he has a valid singed > certificate from a CA which you trust, then you can throw away TLS > completely.
There is a big difference between authentication and authorization.
1. I have to authenticate the peer. Using TLS and certifiactes is fine.
2. I have to authorize the peer. Some peers will be e.g. routed different. You would this this like: if (message is from trusted peer) { ....
So I need to check the certificate in ser.cfg somehow, or associate the domain in the From header with the domain in the certificate.
Or do I miss the point?
regards klaus
> The hole model only works because the trust in inherited from the CA when you > get a singed certificate. > If you do not trust any CA, except your own, then you created your own trust > database which is hard to maintain. No matter what is the base of the > trustworthyness (IP; certificate signed by you; shared secret or signed > certificate for IPSec) maintaining the trust database (or however you call > it) is a real pain, that is the reason why you should trust someone else to > do this job. >
------------------------------------------------------------------------------
_______________________________________________ Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Try this one as well. Helpful-a-lot, with some-basic-but-useful-stuff: http://www.eclectica.ca/howto/ssl-cert-howto.php ;-)
-- Regards, Arek
----- Original Message ----- From: Greger V. Teigre To: Cesc ; Klaus Darilion Cc: serusers@iptel.org ; users openser.org Sent: Wednesday, October 12, 2005 11:23 AM Subject: Re: [Users] Re: [Serusers] trusting peers
Excellent summary! :-) Have you looked at http://www.cacert.org/ ? g-)
Cesc wrote:
Hi,
Klaus, i think that you hit the fountain of truth :) As of now, ser-tls only provides transport layer authentication. Not more. Who is allowed to authenticate? all those you trust, that is, all those with the cert signed by the CAs you trust. If you picked a ruthless CA that would give away certs to hacking.incorporated.com http://hacking.incorporated.com ... sorry :)
So, in current ser, there is no domain comparison between the requested domain (request URI) and the domain in the certificate (for outgoing TLS)? This should be done by TLS part automatically in t_relay()
NAPTR-->TLS SRV A/AAAA lookups TLS handshake validate signature in certifiacte * validate domains in certifiacte with requests domain (host domain or SIP domain?) send request
* If I understand correctly, this part is missing in current implementation
Now, for sip message authentication and authorization you need to lift the authentication information from TLS up to the application (ser). It is not difficult, it just needs a few lines of code for that (all the certs exchanged are within reach for as long as the tls connection stays up). Here is where the tls_tools module's functions (to be written) come into play:
- tls_check_from/to()
- tls_check_cn_trusted()
- ...
Let's focus on this - which tls_ functions do we need? I guess these are only required for incoming SIP/TLS requests. Outgoing should be handled as described above.
- a function to verify if the incoming SIP request was received via a TLS link with client certificate or not. if (tls_client_has_certificate()) ...
Then we need some funtions to authorize the user. I'm yet not sure how to do this best.
Version A: 1. Validate the From: domain in the SIP request against the domain name in the certificate. This is not easy, as the hostname is typically different then SIP domain (e.g. sip:alice@atlanta.com is hosted on sip.atlanta.com). Also, which domain to use if there are several in the certificate (Subject, Subject Alternative Name, ...)
2. If 1. succeded, verify that the domain in From is one of your trusted peers.
Version B: 1. Validate the domain in the certificate against a local whitelist of known trusted peers. E.g. I could have all the public certificates of the trusted peers stored locally, or just having a database table with the hostname (as in the certificate) of the trusted peers. if (tls_is_from_trusted()) ..
Comments welcome!
regards klaus
connection reuse?
So, let's say we want to set up a tls test network (which we do). We don't want to pay for the certs, so we should generate a root cert (say, "openser.org http://openser.org"). It would be even better if some nice CA whose cert is signed by a recognized root would do sign that for us ... anyone with connections? :) This would ease transition and compatibility issues ... The root cert provides certs for each domain (providerX.com, providerY.net, ... ) Now, we all can authenticate each other. With the tools for sip authentication and authorization, you can decide who you allow to do what in your proxy ...
Regards,
Cesc
On 10/12/05, *Klaus Darilion* <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Nils Ohlmeier wrote: > Klaus, if you do not trust badguy.com <http://badguy.com> although he has a valid singed > certificate from a CA which you trust, then you can throw away TLS > completely. There is a big difference between authentication and authorization. 1. I have to authenticate the peer. Using TLS and certifiactes is fine. 2. I have to authorize the peer. Some peers will be e.g. routed different. You would this this like: if (message is from trusted peer) { .... So I need to check the certificate in ser.cfg somehow, or associate the domain in the From header with the domain in the certificate. Or do I miss the point? regards klaus > The hole model only works because the trust in inherited from the CA when you > get a singed certificate. > If you do not trust any CA, except your own, then you created your own trust > database which is hard to maintain. No matter what is the base of the > trustworthyness (IP; certificate signed by you; shared secret or signed > certificate for IPSec) maintaining the trust database (or however you call > it) is a real pain, that is the reason why you should trust someone else to > do this job. >
On 12-10-2005 13:09, Klaus Darilion wrote:
Cesc wrote:
Hi,
Klaus, i think that you hit the fountain of truth :) As of now, ser-tls only provides transport layer authentication. Not more. Who is allowed to authenticate? all those you trust, that is, all those with the cert signed by the CAs you trust. If you picked a ruthless CA that would give away certs to hacking.incorporated.com http://hacking.incorporated.com ... sorry :)
So, in current ser, there is no domain comparison between the requested domain (request URI) and the domain in the certificate (for outgoing TLS)? This should be done by TLS part automatically in t_relay()
I disagree that it should be done automatically. First of all domain comparison is not plain string comparison (domains versus IP addresses). Secondly there is no guarantee that the domain of the proxy server will be in the Request-URI. Think about pre-loaded route sets and in-dialog requests. Such requests would typicaly contain the IP of the proxy server, not domain.
NAPTR-->TLS SRV A/AAAA lookups TLS handshake validate signature in certifiacte
validate domains in certifiacte with requests domain (host domain or SIP domain?) send requestIf I understand correctly, this part is missing in current implementation
Now, for sip message authentication and authorization you need to lift the authentication information from TLS up to the application (ser). It is not difficult, it just needs a few lines of code for that (all the certs exchanged are within reach for as long as the tls connection stays up). Here is where the tls_tools module's functions (to be written) come into play:
- tls_check_from/to()
- tls_check_cn_trusted()
- ...
Let's focus on this - which tls_ functions do we need? I guess these are only required for incoming SIP/TLS requests. Outgoing should be handled as described above.
- a function to verify if the incoming SIP request was received via a
TLS link with client certificate or not. if (tls_client_has_certificate()) ...
Then we need some funtions to authorize the user. I'm yet not sure how to do this best.
Version A:
- Validate the From: domain in the SIP request against the domain
name in the certificate. This is not easy, as the hostname is typically different then SIP domain (e.g. sip:alice@atlanta.com is hosted on sip.atlanta.com). Also, which domain to use if there are several in the certificate (Subject, Subject Alternative Name, ...)
In addition to that you would need to use To header field for REGISTER requests.
More generic approach would be a function that could pull various fields from the certificate and store them in AVPs. You can then do whatever you want with AVPs.
- If 1. succeded, verify that the domain in From is one of your
trusted peers.
Version B:
- Validate the domain in the certificate against a local whitelist
of known trusted peers. E.g. I could have all the public certificates of the trusted peers stored locally, or just having a database table with the hostname (as in the certificate) of the trusted peers. if (tls_is_from_trusted()) ..
Jan.
Jan Janak wrote:
On 12-10-2005 13:09, Klaus Darilion wrote:
Cesc wrote:
Hi,
Klaus, i think that you hit the fountain of truth :) As of now, ser-tls only provides transport layer authentication. Not more. Who is allowed to authenticate? all those you trust, that is, all those with the cert signed by the CAs you trust. If you picked a ruthless CA that would give away certs to hacking.incorporated.com http://hacking.incorporated.com ... sorry :)
So, in current ser, there is no domain comparison between the requested domain (request URI) and the domain in the certificate (for outgoing TLS)? This should be done by TLS part automatically in t_relay()
I disagree that it should be done automatically. First of all domain comparison is not plain string comparison (domains versus IP addresses). Secondly there is no guarantee that the domain of the proxy server will be in the Request-URI. Think about pre-loaded route sets and in-dialog requests. Such requests would typicaly contain the IP of the proxy server, not domain.
Yes, you are right. Validation should be against the next hop (whatever it is, request URI or Route URI.
But we need to handle the validation of the domain in the certifiacte somehow. Is it useful to differ between in-dialog and out-of-dialog requests?
I wonder why there are no best practises/guidelines how to handle the certificate's domain validation in SIP. Does someone know how they handle this at the sipit events?
regards klaus
NAPTR-->TLS SRV A/AAAA lookups TLS handshake validate signature in certifiacte
validate domains in certifiacte with requests domain (host domain or SIP domain?) send requestIf I understand correctly, this part is missing in current implementation
Now, for sip message authentication and authorization you need to lift the authentication information from TLS up to the application (ser). It is not difficult, it just needs a few lines of code for that (all the certs exchanged are within reach for as long as the tls connection stays up). Here is where the tls_tools module's functions (to be written) come into play:
- tls_check_from/to()
- tls_check_cn_trusted()
- ...
Let's focus on this - which tls_ functions do we need? I guess these are only required for incoming SIP/TLS requests. Outgoing should be handled as described above.
- a function to verify if the incoming SIP request was received via a
TLS link with client certificate or not. if (tls_client_has_certificate()) ...
Then we need some funtions to authorize the user. I'm yet not sure how to do this best.
Version A:
- Validate the From: domain in the SIP request against the domain
name in the certificate. This is not easy, as the hostname is typically different then SIP domain (e.g. sip:alice@atlanta.com is hosted on sip.atlanta.com). Also, which domain to use if there are several in the certificate (Subject, Subject Alternative Name, ...)
In addition to that you would need to use To header field for REGISTER requests.
More generic approach would be a function that could pull various fields from the certificate and store them in AVPs. You can then do whatever you want with AVPs.
- If 1. succeded, verify that the domain in From is one of your
trusted peers.
Version B:
- Validate the domain in the certificate against a local whitelist
of known trusted peers. E.g. I could have all the public certificates of the trusted peers stored locally, or just having a database table with the hostname (as in the certificate) of the trusted peers. if (tls_is_from_trusted()) ..
Jan.
Klaus Darilion writes:
But we need to handle the validation of the domain in the certifiacte somehow.
why? since certificate doesn't carry any useful domain information, you have to do it yourself with a table that lists for each certificate the domains you want to see in from headers from that proxy.
-- juha
Juha Heinanen wrote:
Klaus Darilion writes:
But we need to handle the validation of the domain in the certifiacte somehow.
why? since certificate doesn't carry any useful domain information, you have to do it yourself with a table that lists for each certificate the domains you want to see in from headers from that proxy.
Yes! Thus we need to get the domain part for the certificate to make the lookup in the table. Thus, we have to handle it. I did not said that the TLS part has to handle it, but somewere we have to validate it.
e.g. simmilar to allow_trusted, but using the domain form the certificate instead of using src_ip.
regards klaus
On 12-10-2005 17:16, Klaus Darilion wrote:
Jan Janak wrote:
On 12-10-2005 13:09, Klaus Darilion wrote:
Cesc wrote:
Hi,
Klaus, i think that you hit the fountain of truth :) As of now, ser-tls only provides transport layer authentication. Not more. Who is allowed to authenticate? all those you trust, that is, all those with the cert signed by the CAs you trust. If you picked a ruthless CA that would give away certs to hacking.incorporated.com http://hacking.incorporated.com ... sorry :)
So, in current ser, there is no domain comparison between the requested domain (request URI) and the domain in the certificate (for outgoing TLS)? This should be done by TLS part automatically in t_relay()
I disagree that it should be done automatically. First of all domain comparison is not plain string comparison (domains versus IP addresses). Secondly there is no guarantee that the domain of the proxy server will be in the Request-URI. Think about pre-loaded route sets and in-dialog requests. Such requests would typicaly contain the IP of the proxy server, not domain.
Yes, you are right. Validation should be against the next hop (whatever it is, request URI or Route URI.
And this would be an IP address, most likely. So you will need to find out the domain/hostname in order to compare it with the domain/hostname in the certificate.
But we need to handle the validation of the domain in the certifiacte somehow. Is it useful to differ between in-dialog and out-of-dialog requests?
I wonder why there are no best practises/guidelines how to handle the certificate's domain validation in SIP. Does someone know how they handle this at the sipit events?
I am beginning to think that it should be perhaps the caller who decides whether a request should be forwarded to the proxy server if the domain name in the certificate does not match the domain in the Request-URI. Web browsers do the same, they do not refuse a https connection if the server certificate domain does not match the hostname in the HTTP URI, they just warn the user that the authenticity of the server cannot be established.
Unfortunately such warnings are common. Real certificates (verified by trusted CAs) are quite expensive and sometimes hard to obtain. Real CAs also have very strict policies sometimes.
I do not recall anyone doing that sort of test at sipits (but I did not test with everyone). Even certificate validation was problem during TLS multiparty tests, not even speaking about the delay all the TLS hanshakes introduced in a ring of 6 proxies.
Jan.
Jan Janak wrote:
I am beginning to think that it should be perhaps the caller who decides whether a request should be forwarded to the proxy server if the domain name in the certificate does not match the domain in the Request-URI. Web browsers do the same, they do not refuse a https connection if the server certificate domain does not match the hostname in the HTTP URI, they just warn the user that the authenticity of the server cannot be established.
This can be done in a client2proxy scenario, but not in a proxy2proxy scenario where user interaction is not possible.
I do not recall anyone doing that sort of test at sipits (but I did not test with everyone). Even certificate validation was problem during TLS multiparty tests, not even speaking about the delay all the TLS hanshakes introduced in a ring of 6 proxies.
Any real life values for the introduced delay? I think (open)ser should be able to reuse TLS connections and thus the handshake happens only once in a while.
klaus
On 13-10-2005 10:34, Klaus Darilion wrote:
Jan Janak wrote:
I am beginning to think that it should be perhaps the caller who decides whether a request should be forwarded to the proxy server if the domain name in the certificate does not match the domain in the Request-URI. Web browsers do the same, they do not refuse a https connection if the server certificate domain does not match the hostname in the HTTP URI, they just warn the user that the authenticity of the server cannot be established.
This can be done in a client2proxy scenario, but not in a proxy2proxy scenario where user interaction is not possible.
I do not recall anyone doing that sort of test at sipits (but I did not test with everyone). Even certificate validation was problem during TLS multiparty tests, not even speaking about the delay all the TLS hanshakes introduced in a ring of 6 proxies.
Any real life values for the introduced delay? I think (open)ser should be able to reuse TLS connections and thus the handshake happens only once in a while.
It took several seconds to close the ring, I do not recall exact value. Most of the proxies had to establish TLS connection and perform TLS handshake.
Jan.
Klaus Darilion wrote:
Version B:
- Validate the domain in the certificate against a local whitelist of
known trusted peers. E.g. I could have all the public certificates of the trusted peers stored locally, or just having a database table with the hostname (as in the certificate) of the trusted peers. if (tls_is_from_trusted()) ..
Maybe this can bone outside the routing logic. If the client certificate is received, ser should verifiy if the domain in the certificate is on the whitelist. If yes, this TLS connection gets the "trusted flag" and can be easily queried in the routing logic without checking against the whitelist for each request.
regards klaus
Klaus Darilion writes:
validate domains in certifiacte with requests domain
- If I understand correctly, this part is missing in current
- implementation
what would that check mean? proxy selects next hop proxy my manual configuration or by srv lookup on host part of request uri. then proxy can verify server certificate of the next hop proxy. i don't understand what domains have to do with this.
Version A:
- Validate the From: domain in the SIP request against the domain
name in the certificate.
you cannot do this, because domain of certificate has nothing to do with from domain.
-- juha
Juha Heinanen wrote:
Klaus Darilion writes:
validate domains in certifiacte with requests domain
- If I understand correctly, this part is missing in current
- implementation
what would that check mean? proxy selects next hop proxy my manual configuration or by srv lookup on host part of request uri. then proxy can verify server certificate of the next hop proxy. i don't understand what domains have to do with this.
server verification: 1. the certificate must be valid (signed by a trusted CA) 2. The certificate should reflect the proxy I'm tryin to reach. When contacting klaus@iptel.org the proxy should not accept a certificate for foo.bar.com, but for iptel.org or sip.iptel.org
Version A:
- Validate the From: domain in the SIP request against the domain
name in the certificate.
you cannot do this, because domain of certificate has nothing to do with from domain.
Depends on the certificate. IMO the complete TLS part is crude.
regard klaus
RFC 3261; 26.3.2.2 Interdomain Requests [...atlanta calls biloxy...] The proxy server at biloxi.com SHOULD inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the "domainname" portion of the From header field in the INVITE request. The biloxi proxy MAY have a strict security policy that requires it to reject requests that do not match the administrative domain from which they have been proxied.
Klaus Darilion writes:
- The certificate should reflect the proxy I'm tryin to reach. When
contacting klaus@iptel.org the proxy should not accept a certificate for foo.bar.com, but for iptel.org or sip.iptel.org
no, the proxy should accept certificate of whatever hosts that are according to srv records serving iptel.org.
-- juha
Juha Heinanen wrote:
Klaus Darilion writes:
- The certificate should reflect the proxy I'm tryin to reach. When
contacting klaus@iptel.org the proxy should not accept a certificate for foo.bar.com, but for iptel.org or sip.iptel.org
no, the proxy should accept certificate of whatever hosts that are according to srv records serving iptel.org.
Yes. IMO a cetificate for iptel.org would also be fine.
klaus
-
Arek Bekiersz -
Cesc -
Greger V. Teigre -
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Nils Ohlmeier