Hi, the documentation of TLS module says:
--------------------------------------- 1.7. Known Limitations
The TLS certificate verifications ignores the certificate name, subject altname and ip extensions, it just checks if the certificate is signed by a recognized CA. One can use the select framework to try to overcome this limitation (check in the script for the contents of various certificate fields), but this is not only slow, but also not exactly standard conforming (the verification should happen during TLS connection establishment and not after). -----------------------------------------
The last pharse "the verification should happen during TLS connection establishment and not after" is incorrect. It's true that the SIP node receiving a TLS certificate should first verify that the certificate is signed by a recognized CA and it's not expired. This is the first step and must occur when establishing the TLS session. IF not, drop the connection.
But in case a proxy/server receives a TLS connection and wants to authenticate SIP requests based on the certificate, it must extract the SIP domain identities in the certificate by inspecting each value in the subjectAltName field with type "domain". And for each SIP request coming within this TLS connection, the proxy/server could check whether the From domain matches a SIP domain present in the certificate, so the request gets automatically authenticated (no need of requiring SIP authenticationn neither checking the source IP against a list of trusted IPs).
In order to implement it, I suggest the following behaviour in sip-router:
- A client establishes a TLS session with sip-router. - The client presents a TLS certificate. - sip-router extracts the SIP identities of the certificate and stores them, somehow, in attributes belonging to this TLS session (maybe pseudovariables). - In the logic script, it would be possible then to match the From domain of the request (or whatever) against the list of SIP identities in the certificate (so authentication is done).
This is important in order to allow real SIP federation (as already occurs in XMPP world). We all know that SIP federation is not used yet, but it should in a future.
Regards.
Iñaki Baz Castillo writes:
In order to implement it, I suggest the following behaviour in sip-router:
- A client establishes a TLS session with sip-router.
- The client presents a TLS certificate.
- sip-router extracts the SIP identities of the certificate and stores
them, somehow, in attributes belonging to this TLS session (maybe pseudovariables).
- In the logic script, it would be possible then to match the From
domain of the request (or whatever) against the list of SIP identities in the certificate (so authentication is done).
inaki,
i do it simply by fetching client's (which may be another proxy too) attributes from htable based on @tls.peer.subject.cn. one of the attributes can be domain name and if so further attributes can be fetched from domain_attrs table. very easy and has been worked fine so far.
-- juha
2011/5/25 Juha Heinanen jh@tutpro.com:
i do it simply by fetching client's (which may be another proxy too) attributes from htable based on @tls.peer.subject.cn. one of the attributes can be domain name and if so further attributes can be fetched from domain_attrs table. very easy and has been worked fine so far.
Hi Juha, how do you get such @tls.peer.subject.cn to be populated?
2011/5/25 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
Hi Juha, how do you get such @tls.peer.subject.cn to be populated?
it is set automatically by sip router as result of tls handshake.
Interesting, I didn't know that. Could you please point me to the documentation in which those attributes are defined? (I couldn't find it in TLS module).
On Wed, May 25, 2011 at 09:50, Iñaki Baz Castillo ibc@aliax.net wrote:
2011/5/25 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
Hi Juha, how do you get such @tls.peer.subject.cn to be populated?
it is set automatically by sip router as result of tls handshake.
Interesting, I didn't know that. Could you please point me to the documentation in which those attributes are defined? (I couldn't find it in TLS module).
One list is here: http://sip-router.org/wiki/cookbooks/selects/devel
-Jan
2011/5/25 Jan Janak jan@ryngle.com:
One list is here: http://sip-router.org/wiki/cookbooks/selects/devel
Thanks Jan. Let me one question more:
RFC 5280 states that when receiving a TLS certificate, each value of subjectAltName must be inspected and just taken in case its Type is "URI" or "DNS":
http://tools.ietf.org/html/rfc5922#section-7.1
I'm not sure whether I can retrieve *all* (various) subjectAltName in the certificate (given the list of selects in your provided link). Is it possible? If so, how could I check its Type?
Thanks a lot.
On Wed, May 25, 2011 at 16:34, Iñaki Baz Castillo ibc@aliax.net wrote:
2011/5/25 Jan Janak jan@ryngle.com:
One list is here: http://sip-router.org/wiki/cookbooks/selects/devel
Thanks Jan. Let me one question more:
RFC 5280 states that when receiving a TLS certificate, each value of subjectAltName must be inspected and just taken in case its Type is "URI" or "DNS":
http://tools.ietf.org/html/rfc5922#section-7.1
I'm not sure whether I can retrieve *all* (various) subjectAltName in the certificate (given the list of selects in your provided link). Is it possible? If so, how could I check its Type?
I don't remember implementing that, so it's probably not possible with existing code. Nevertheless, it should be fairly easy to add.
-Jan
2011/5/26 Jan Janak jan@ryngle.com:
I don't remember implementing that, so it's probably not possible with existing code. Nevertheless, it should be fairly easy to add.
I would appreciate it as I would like to test real SIP TLS source authentication :)
Regards,
On Thu, May 26, 2011 at 13:22, Iñaki Baz Castillo ibc@aliax.net wrote:
2011/5/26 Jan Janak jan@ryngle.com:
I don't remember implementing that, so it's probably not possible with existing code. Nevertheless, it should be fairly easy to add.
I would appreciate it as I would like to test real SIP TLS source authentication :)
You don't really need this feature for that, but we would be glad to accept patches if you implement it.
-Jan
2011/5/26 Jan Janak jan@ryngle.com:
I would appreciate it as I would like to test real SIP TLS source authentication :)
You don't really need this feature for that, but we would be glad to accept patches if you implement it.
Hi Jan, why do you state that? As RFC 5954 defines (my own text):
- A client establishes a TLS session with sip-router. - The client presents a TLS certificate. - sip-router extracts the SIP domain identities in the certificate by inspecting each value in the subjectAltName field with type "domain". - sip-router stores them in attributes belonging to this TLS session. - In the logic script, it would be possible then to match the From domain of the request (or whatever) against the list of SIP identities in the certificate (so authentication is done).
So if I'm not wrong, I need all the subjectAltName values of the certificate.
Note that I'm not talking just about veryfing the validity of the certificate (it's correctly signed, it's not expired and so) but also checking that each new request coming within this TLS connection has a
From domain matching domain identities present in the certificate.
Regards.
On 26.05.2011 19:45, Jan Janak wrote:
On Thu, May 26, 2011 at 13:22, Iñaki Baz Castilloibc@aliax.net wrote:
2011/5/26 Jan Janakjan@ryngle.com:
I don't remember implementing that, so it's probably not possible with existing code. Nevertheless, it should be fairly easy to add.
I would appreciate it as I would like to test real SIP TLS source authentication :)
You don't really need this feature for that, but we would be glad to accept patches if you implement it.
AFAIK currently there are no "selects" to retrieve SubjectAlt - only Subject. For RFC conform certificate validation, the SubjectAlt fields (all of them) would also be needed as "selects". I think this should be sufficient as checking if the parameter starts with "domain" can be done in script.
regards klaus
2011/5/27 Klaus Darilion klaus.mailinglists@pernau.at:
AFAIK currently there are no "selects" to retrieve SubjectAlt - only Subject. For RFC conform certificate validation, the SubjectAlt fields (all of them) would also be needed as "selects". I think this should be sufficient as checking if the parameter starts with "domain" can be done in script.
And that is exactly what I was asking for :)
Iñaki Baz Castillo writes:
Interesting, I didn't know that. Could you please point me to the documentation in which those attributes are defined? (I couldn't find it in TLS module).
i found it on sr wiki page:
http://sip-router.org/wiki/cookbooks/selects/devel
-- juha
-
Iñaki Baz Castillo -
Jan Janak -
Juha Heinanen -
Klaus Darilion