[Users] Re: [Serusers] trusting peers

[Klaus Darilion]

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

   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 at pernau.at 
> <mailto:klaus.mailinglists at 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.
>      >
>