[Users] Re: [Serusers] trusting peers

Jan Janak jan at iptel.org
Wed Oct 12 13:53:12 CEST 2005


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 at 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.




More information about the Users mailing list