[Free-RTC] kamaillio script for federated communications

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/24/13 2:33 AM, Olle E. Johansson wrote:
> 
> 24 jun 2013 kl. 10:18 skrev Daniel Pocock <daniel at pocock.com.au>:
> 
>> On 24/06/13 09:03, Olle E. Johansson wrote:
>>> 21 jun 2013 kl. 18:14 skrev Emil Ivov <emcho at jitsi.org>:
>>> 
>>>> 
>>>> On 21.06.13, 17:41, Olle E. Johansson wrote:
>>>>> 21 jun 2013 kl. 15:05 skrev Daniel Pocock
>>>>> <daniel at pocock.com.au <mailto:daniel at pocock.com.au>>:
>>>>> 
>>>>>>> * The config uses DNS to establish the transport
>>>>>>> available on the remote proxy. It doesn't use DNSSEC to
>>>>>>> do this.
>>>>>> I'm not sure if DNSSEC matters if the TLS certificate is
>>>>>> valid - some people may prefer to trust the TLS cert and
>>>>>> not place any trust in the DNSSEC trust model
>>>>> THat's quite a misguided statement. If DNS points to an
>>>>> incorrect destination that succeeds in providing a
>>>>> certificate that you accept - how can that be a good 
>>>>> solution?
>>>> That's a bit inaccurate. If I am trying to reach jit.si
>>>> through TLS and a malicious DNS record sends me toward
>>>> evil.example.com, it wouldn't be enough for evil.example.com
>>>> to just have a valid cert.
>>>> 
>>>> It would need to provide a valid certificate for jit.si
>>> Of course - that's the only one you should accept. (hopefully)
>> 
>> Just to clarify: in reSIProcate, when we look at a client or
>> server-side cert,
>> 
>> a) we check if it has subjectAltName (sometimes dubbed SAN) - if
>> there is one or more subjectAltName attributes, we take all of
>> their values as valid domains and put them in a list called
>> TlsConnection::mPeerNames
>> 
>> b) if there is no subjectAltName, we take the common name (CN)
>> which can have only one value and put that in mPeerNames (so it
>> is a vector with just 1 value)
>> 
>> c) higher-level authentication checks then look at each incoming
>> message and screen it against mPeerNames
>> 
>> The CN or subjectAltName can be in a domain name format or an
>> email address format.  E.g. a Jitsi client may send
>> CN=daniel at pocock.com but a server-server connection might send
>> CN=pocock.com.au
>> 
>> Does Kamailio have the ability to analyze the certs in the same
>> detail, e.g. extracting subjectAltName and using both DNSname and
>> email values? Are the values available from the configuration
>> script?  In other words, I would think (a) and (b) would be in
>> the TLS code and (c) would be part of the cfg file
> I was aware that Resiprocate did this correctly, since we've tested
> it many times at SIPit :-)
> 
> The important thing here for other implementations is that if there
> are SANs in the certificate you should NOT check the CN. Just
> ignore whatever is in there. Also, you can not reuse that
> connection in the other direction unless you got a client cert.

RFC 6125 covers this stuff in gory detail (although not specifically
for SIP, although the specs about SIP cert handling might be updated
someday to track RFC 6125).

http://datatracker.ietf.org/doc/rfc6125/

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRyJelAAoJEOoGpJErxa2pRHMP/jyF3iiFtlqv/UmweBPLjePt
JvQDeMklrjLMJQhKlthFBfUkX8TXU6EFuckqzfdvDvEefeiJnsinYDZCvdvVAZ+s
0dwrU5ZIQKQ3QSLn+9DwRWkLeuvwAHJ9XExVEM+lDLsmVoBusfwEmtafsXqXNNii
SU4mDXTL+kWFMC7T9FiP130i2sc7PwxpaRHJ4loI+2xIFDt+UwXDvsSt1yfoWFEE
2nUwfsS4YnVhxbDN/1zRscsK/xncvjOzr4t8J+1NimwVIJYdIlS92lSJwLTIo2nd
5BbDRmlQvlxxgHtQqz9awefhR/LUZ75dqPEdddmx2i/l8yROSFfIuvh2G5F3NhS1
7T2j6GSHUmTI+bxImijDQOQEj8iy/3nqAt7fX4PqOWaNgVXrddjym+j83THFtUmO
Uitpsmu0PuX4BmPG8OPXYEGFhzFYyF7RlNHp0rlMra4aMU9BHaXFBOhjMTfR4xF+
IsHCqlwmyBlolGLqn6Cy+7ESsuH1qGs/uiEks/06aHTj+ju2EgRtpck9gqkiMOI/
PL+6rMsNEA1pLpxgghpcrM9wtU2FHogBhh/dKa35K7iJi8R0taUn9ZixygmT1AYm
4dvGVHeSXD7HvfNWkd5Eqm7Qh6tsgEkDKZmEdcDZpLpa2WJoMcDTd4AlpCoYSkc4
3x5c3K6iGadWT3OfOnMB
=cZXi
-----END PGP SIGNATURE-----