11 Oct
2005
11 Oct
'05
8:55 a.m.
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
11 Oct
11 Oct
9:30 a.m.
New subject: [Users] Re: [Serusers] trusting peers
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:
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.
You can also use trusted table and permission module.
Jan.
9:46 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Jan Janak wrote:
On 11-10-2005 14:55, Klaus Darilion wrote:
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
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.
You can also use trusted table and permission module.
9:58 a.m.
New subject: [Users] Re: [Serusers] trusting peers
On 11-10-2005 15:46, 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).
Jan.
On 11-10-2005 14:55, Klaus Darilion wrote:
Right! I think this should be documented somewhere :-)
Maybe we can adopt the this function to verify the doman of the client
certificate? 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.
You can also use trusted table and permission module.
10:32 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Jan Janak wrote:
On 11-10-2005 15:46, Klaus Darilion wrote:
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
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). On 11-10-2005 14:55, Klaus Darilion wrote:
Right! I think this should be documented somewhere :-)
Maybe we can adopt the this function to verify the doman of the client
certificate? 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.
You can also use trusted table and permission module. 
5:04 p.m.
New subject: [Serusers] trusting peers
On Tuesday 11 October 2005 16:32, Klaus Darilion wrote:
Jan Janak 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.
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
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.
12 Oct
12 Oct
2:28 a.m.
New subject: [Serusers] trusting peers
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:
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 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.
3:15 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Nils Ohlmeier wrote:
On Tuesday 11 October 2005 16:32, Klaus Darilion
wrote:
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
Jan Janak 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. 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. 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
5:13 a.m.
New subject: [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<http://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(a)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.
5:23 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Excellent summary! :-)
Have you looked at http://www.cacert.org/ ?
g-)
----- Original Message -----
From: Cesc
To: Klaus Darilion
Cc: serusers(a)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(a)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(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serusers
5:31 a.m.
New subject: [Users] Re: [Serusers] trusting peers
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(a)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-)
7:09 a.m.
New subject: [Users] Re: [Serusers] trusting peers
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(a)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.
7:53 a.m.
New subject: [Users] Re: [Serusers] trusting peers
On 12-10-2005 13:09, Klaus Darilion wrote:
Cesc wrote:
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.
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
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.
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()) ..
Jan.
11:16 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Jan Janak wrote:
On 12-10-2005 13:09, Klaus Darilion wrote:
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
Cesc wrote:
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. 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
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.
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()) ..
Jan.
11:40 a.m.
New subject: [Users] Re: [Serusers] trusting peers
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
13 Oct
13 Oct
4:29 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Juha Heinanen wrote:
Klaus Darilion writes:
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
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.
12 Oct
12 Oct
12:21 p.m.
New subject: [Users] Re: [Serusers] trusting peers
On 12-10-2005 17:16, Klaus Darilion wrote:
Jan Janak wrote:
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.
On 12-10-2005 13:09, Klaus Darilion wrote:
Yes, you are right. Validation should be against the next hop (whatever
it is, request URI or Route URI. Cesc wrote:
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. 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() 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.
13 Oct
13 Oct
4:34 a.m.
New subject: [Users] Re: [Serusers] trusting peers
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
14 Oct
14 Oct
6:07 a.m.
New subject: [Users] Re: [Serusers] trusting peers
On 13-10-2005 10:34, Klaus Darilion wrote:
Jan Janak wrote:
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.
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.
12 Oct
12 Oct
9:24 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Klaus Darilion wrote:
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()) ..
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
10:07 a.m.
New subject: [Users] Re: [Serusers] trusting peers
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:
1. 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
11:40 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Juha Heinanen wrote:
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:
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(a)iptel.org the proxy should not accept a certificate for
foo.bar.com, but for iptel.org or sip.iptel.org
* 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:
1. 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.
11:45 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Klaus Darilion writes:
2. The certificate should reflect the proxy I'm
tryin to reach. When
contacting klaus(a)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
13 Oct
13 Oct
4:31 a.m.
New subject: [Users] Re: [Serusers] trusting peers
Juha Heinanen wrote:
Klaus Darilion writes:
Yes. IMO a cetificate for iptel.org would also be fine.
klaus
2. The certificate should reflect the proxy
I'm tryin to reach. When
contacting klaus(a)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.
6842
days inactive
6845
days old
25 comments
7 participants
participants (7)
-
Arek Bekiersz -
Cesc -
Greger V. Teigre -
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Nils Ohlmeier