[Free-RTC] kamaillio script for federated communications

[Daniel Pocock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 24/06/13 21:01, Peter Saint-Andre wrote:
> 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/

This extends it for SIP (it is based on RFC 5741 which is the ancestor
of RFC 6125):

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRyJhDAAoJEOm1uwJp1aqDbvUP/jnA7SvBmPQV6OXrEyANYiHl
+MPCO/Dx+170MBSD5a+1IkpxpQeSZUW2KsauIUb/bv0fEXU+brIuTpc/P9f0xm7V
D4B4RR5NMo961Y9b8AaM5T0pI/wiUHlJI+xs4dC5imZPu7yqGCmxmCeZDExMLK8C
AHJ/XMfRB3lCuL58o7k2J8Wf5eRQSEvrLuWkIKF3WG462KzCgp0/0OVakCJ/A9hE
/THJokmbOg1oEWpG8AcGQJAVyHPYEVvWQ57NJ8G+R/DIV3QWDR0x5W8ZdWupjnJB
svEenBvgUXpfuOL1QawWYv4gCQuFzbeOPW4i+DXiZ5CUaS0++Yc3AXoel6xQcUUE
fPhAKrRQPKUYkAiJ9Zcdl0fWeyrWGWeaTydebKUSVQnAqZLOH/GdEwDQg95doxOX
r2+0SvR2f1LDZXaFWTVv0PKzjmtU0uqRJRoaQMlXt5lj9W8aXDv3SOX8eGac9AAN
+t/2W4bldHInd6vbi3jMUVruYsDhdPciiQgQEYWXkslpPViF2YBsyydpHQbTxYlF
DU5RG1GTl0etkd3qhBNvE4S9x6e/aTh1tF4sNT6Z1BNZG+Cy0q7yIOmyTppc0PV/
XF/DikfZfncMnX/Lw5yB5406yfP1fbopfhl2fVTxLvRvfVrtFQcGfwF/lum7IJ9d
fpDlEpqJ0qz60tPG8tca
=Qe+Q
-----END PGP SIGNATURE-----