[Users] Re: [Serusers] trusting peers

[Klaus Darilion]

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