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 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, ...)
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.
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.