25 May
2011
25 May
'11
12:05 p.m.
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
<ibc(a)aliax.net>
25 May
25 May
12:31 p.m.
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
12:46 p.m.
2011/5/25 Juha Heinanen <jh(a)tutpro.com>om>:
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?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:50 p.m.
2011/5/25 Juha Heinanen <jh(a)tutpro.com>om>:
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ñaki Baz Castillo
<ibc(a)aliax.net>
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. 
1:57 p.m.
On Wed, May 25, 2011 at 09:50, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2011/5/25 Juha Heinanen <jh(a)tutpro.com>om>:
One list is here:
http://sip-router.org/wiki/cookbooks/selects/devel
-Jan
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). 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.
2:34 p.m.
2011/5/25 Jan Janak <jan(a)ryngle.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
26 May
26 May
3:03 a.m.
On Wed, May 25, 2011 at 16:34, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2011/5/25 Jan Janak <jan(a)ryngle.com>om>:
I don't remember implementing that, so it's probably not possible with
existing code. Nevertheless, it should be fairly easy to add.
-Jan
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?
11:22 a.m.
2011/5/26 Jan Janak <jan(a)ryngle.com>om>:
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,
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:45 p.m.
On Thu, May 26, 2011 at 13:22, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2011/5/26 Jan Janak <jan(a)ryngle.com>om>:
You don't really need this feature for that, but we would be glad to
accept patches if you implement it.
-Jan
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 :)
7:20 p.m.
2011/5/26 Jan Janak <jan(a)ryngle.com>om>:
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
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. From domain matching domain identities present in the
certificate.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:58 p.m.
On 26.05.2011 19:45, Jan Janak wrote:
On Thu, May 26, 2011 at 13:22, Iñaki Baz
Castillo<ibc(a)aliax.net> wrote:
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/26 Jan Janak<jan(a)ryngle.com>om>:
You don't really need this feature for that, but we would be glad to
accept patches if you implement it. 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 :)
11:51 p.m.
2011/5/27 Klaus Darilion <klaus.mailinglists(a)pernau.at>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
<ibc(a)aliax.net>
25 May
25 May
2:34 p.m.
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
4736
days inactive
4737
days old
13 comments
4 participants
participants (4)
-
Iñaki Baz Castillo -
Jan Janak -
Juha Heinanen -
Klaus Darilion