Olle E. Johansson | 1 Oct 22:36 2011
Picon

SIP identity and SIP domain certs

The SIP identity RFC 4474 talks about "SIP Domain certificates" but doesn't really specify the syntax.
There's a lot of text about them and parts are a bit confusing, mixing "host name" with "domain". It
mentions "subject alt names" in one part, but not in the important parts that only talks about the
"Subject" of the certificate.

The SIP domain certificates RFC approaches this (RFC 5922) but says clearly:

The discussion in this document is pertinent to an X.509 PKIX-
   compliant certificate used for a TLS connection; this document does
   not define use of such certificates for any other purpose (such as
   Secure/Multipurpose Internet Mail Extensions (S/MIME)).

So this document does not update RFC 4474 because it only talks about TLS connections, not certificates for
domains for signing. It seems like the idea is to have multiple certificates, which sounds impractical.
One for HTTPS, one for SIP/TLS and another one for SIP Identity.

Shouldn't RFC 5922 really have updated RFC 4474 so we got a  better specification of the actual X.509v3/PKIX
certificate used for Identity headers?

/O
Iñaki Baz Castillo | 1 Oct 23:02 2011
Picon

Re: SIP identity and SIP domain certs

2011/10/1 Olle E. Johansson <oej <at> edvina.net>:
> The SIP identity RFC 4474 talks about "SIP Domain certificates" but doesn't really specify the syntax.
There's a lot of text about them and parts are a bit confusing, mixing "host name" with "domain". It
mentions "subject alt names" in one part, but not in the important parts that only talks about the
"Subject" of the certificate.
>
> The SIP domain certificates RFC approaches this (RFC 5922) but says clearly:
>
> The discussion in this document is pertinent to an X.509 PKIX-
>   compliant certificate used for a TLS connection; this document does
>   not define use of such certificates for any other purpose (such as
>   Secure/Multipurpose Internet Mail Extensions (S/MIME)).
>
>
> So this document does not update RFC 4474 because it only talks about TLS connections, not certificates
for domains for signing. It seems like the idea is to have multiple certificates, which sounds
impractical. One for HTTPS, one for SIP/TLS and another one for SIP Identity.
>
> Shouldn't RFC 5922 really have updated RFC 4474 so we got a  better specification of the actual
X.509v3/PKIX certificate used for Identity headers?

Sure. Anyhow I've never seen a SIP "element" checking the
SubjectAltName entries in a certificate, most of them just inspect the
Subject (which requires having a separate certificate for each served
domain... ever worse... a SIP TLS server listening in a single IP:port
can only present a single certificate).

But well... the TLS usage in SIP is... poor, as any other security
mechanism (SRTP, ICE...). And much better if we don't talk about the
dissaster of SIPS schema!
(Continue reading)

Vineet Menon | 3 Oct 12:34 2011
Picon

Re: Implement a SIP server using SIPServlet

Dear Jean,

Thanks for the info Jean. But is it suitable for development by a beginner??
I want to use an IDE, and as mobicents says Eclipse. Have you tired doing
any work on mobicents with Eclipse and Tomcat?

Regards,

Vineet Menon

On Mon, Sep 26, 2011 at 1:45 PM, Jean Deruelle <jean.deruelle <at> gmail.com>wrote:

> Java is suitable for implementing a SIP Server. You can take a look at
> Mobicents Sip Servlets (
> http://www.mobicents.org/products_sip_servlets.html), it is open source
> and LGPL v2.1. It implements the Sip Servlets 1.1 specification and is using
> JAIN SIP and the NIST SIP Stack under the covers.
>
> Jean
>
> On Mon, Sep 26, 2011 at 9:34 AM, Vineet Menon <mvineetmenon <at> gmail.com>wrote:
>
>> Hi All,
>>
>> I am new to SIP and as per my project i am to implement a SIP Server.
>>
>> I want to know the possible technology and platforms to work on..I have
>> learnt about SIPServlets and JAIN Libraries, both on Java!
>>
>> Is Java suitable for  server implementation? or some other language
(Continue reading)

Kevin P. Fleming | 3 Oct 14:26 2011

Re: SIP identity and SIP domain certs

On 10/01/2011 04:02 PM, Iñaki Baz Castillo wrote:
> 2011/10/1 Olle E. Johansson<oej <at> edvina.net>:
>> The SIP identity RFC 4474 talks about "SIP Domain certificates" but doesn't really specify the syntax.
There's a lot of text about them and parts are a bit confusing, mixing "host name" with "domain". It
mentions "subject alt names" in one part, but not in the important parts that only talks about the
"Subject" of the certificate.
>>
>> The SIP domain certificates RFC approaches this (RFC 5922) but says clearly:
>>
>> The discussion in this document is pertinent to an X.509 PKIX-
>>    compliant certificate used for a TLS connection; this document does
>>    not define use of such certificates for any other purpose (such as
>>    Secure/Multipurpose Internet Mail Extensions (S/MIME)).
>>
>>
>> So this document does not update RFC 4474 because it only talks about TLS connections, not certificates
for domains for signing. It seems like the idea is to have multiple certificates, which sounds
impractical. One for HTTPS, one for SIP/TLS and another one for SIP Identity.
>>
>> Shouldn't RFC 5922 really have updated RFC 4474 so we got a  better specification of the actual
X.509v3/PKIX certificate used for Identity headers?
>
>
> Sure. Anyhow I've never seen a SIP "element" checking the
> SubjectAltName entries in a certificate, most of them just inspect the
> Subject (which requires having a separate certificate for each served
> domain... ever worse... a SIP TLS server listening in a single IP:port
> can only present a single certificate).

Doesn't SNI resolve this problem? Of course, that would require SIP/TLS 
(Continue reading)

Iñaki Baz Castillo | 3 Oct 14:32 2011
Picon

Re: SIP identity and SIP domain certs

2011/10/3 Kevin P. Fleming <kpfleming <at> digium.com>:
>> Sure. Anyhow I've never seen a SIP "element" checking the
>> SubjectAltName entries in a certificate, most of them just inspect the
>> Subject (which requires having a separate certificate for each served
>> domain... ever worse... a SIP TLS server listening in a single IP:port
>> can only present a single certificate).
>
> Doesn't SNI resolve this problem? Of course, that would require SIP/TLS
> clients to actually implement SNI, which I suspect none of them do, but
> still...

Yes, but SNI is not specified for SIP. Instead the usage of
SubjectAltName holding different domains in the TLS certificate is
stated.

Since most of the SIP clients don't yet examine such SubjectAltName in
a received certificate, and none of them implements SNI, I strongly
think that it's much better for them to implement SubjectAltName
inspection (which is already defined for SIP) rather than implementing
SNI.

Regards.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
(Continue reading)

Evgeniy Khramtsov | 3 Oct 14:44 2011
Picon

Re: SIP identity and SIP domain certs

On 03.10.2011 22:32, Iñaki Baz Castillo wrote:
> 2011/10/3 Kevin P. Fleming<kpfleming <at> digium.com>:
>>> Sure. Anyhow I've never seen a SIP "element" checking the
>>> SubjectAltName entries in a certificate, most of them just inspect the
>>> Subject (which requires having a separate certificate for each served
>>> domain... ever worse... a SIP TLS server listening in a single IP:port
>>> can only present a single certificate).
>> Doesn't SNI resolve this problem? Of course, that would require SIP/TLS
>> clients to actually implement SNI, which I suspect none of them do, but
>> still...
> Yes, but SNI is not specified for SIP. Instead the usage of
> SubjectAltName holding different domains in the TLS certificate is
> stated.
>
> Since most of the SIP clients don't yet examine such SubjectAltName in
> a received certificate, and none of them implements SNI, I strongly
> think that it's much better for them to implement SubjectAltName
> inspection (which is already defined for SIP) rather than implementing
> SNI.
>
> Regards.
>
>

As I understand, SubjectAltName won't work for virtual servers holding 
lots of separate certificates and listening on the same port.

--

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
(Continue reading)

Iñaki Baz Castillo | 3 Oct 14:51 2011
Picon

Re: SIP identity and SIP domain certs

2011/10/3 Evgeniy Khramtsov <xramtsov <at> gmail.com>:
>> Since most of the SIP clients don't yet examine such SubjectAltName in
>> a received certificate, and none of them implements SNI, I strongly
>> think that it's much better for them to implement SubjectAltName
>> inspection (which is already defined for SIP) rather than implementing
>> SNI.
>>
>> Regards.
>
> As I understand, SubjectAltName won't work for virtual servers holding
> lots of separate certificates and listening on the same port.

Why not? the client wants to establish a TLS connection with domain
"example1.org", so after DNS procedures it establishes a TLS
connection with the server and the server sends its TLS certificate.
Such certificate contains varios SubjectAltName fields with values:

- sip:example1.org
- sip:example2.org
- sip:example3.org

The client checks that "sip:example1.org" is present so *that's all*.
And this is clearly explained in RFC 5922 (which updates RFC 3261):

  http://tools.ietf.org/html/rfc5922#section-7.1

Regards.

--

-- 
Iñaki Baz Castillo
(Continue reading)

Kevin P. Fleming | 3 Oct 14:59 2011

Re: SIP identity and SIP domain certs

On 10/03/2011 07:51 AM, Iñaki Baz Castillo wrote:
> 2011/10/3 Evgeniy Khramtsov<xramtsov <at> gmail.com>:
>>> Since most of the SIP clients don't yet examine such SubjectAltName in
>>> a received certificate, and none of them implements SNI, I strongly
>>> think that it's much better for them to implement SubjectAltName
>>> inspection (which is already defined for SIP) rather than implementing
>>> SNI.
>>>
>>> Regards.
>>
>> As I understand, SubjectAltName won't work for virtual servers holding
>> lots of separate certificates and listening on the same port.
>
> Why not? the client wants to establish a TLS connection with domain
> "example1.org", so after DNS procedures it establishes a TLS
> connection with the server and the server sends its TLS certificate.
> Such certificate contains varios SubjectAltName fields with values:
>
> - sip:example1.org
> - sip:example2.org
> - sip:example3.org
>
> The client checks that "sip:example1.org" is present so *that's all*.
> And this is clearly explained in RFC 5922 (which updates RFC 3261):
>
>    http://tools.ietf.org/html/rfc5922#section-7.1

That's true, it's technically possible for SubjectAltName to be used 
this way. However, doing so requires that the cert be re-issued every 
time a virtual service is added or removed from the physical server, 
(Continue reading)

Evgeniy Khramtsov | 3 Oct 15:04 2011
Picon

Re: SIP identity and SIP domain certs

On 03.10.2011 22:51, Iñaki Baz Castillo wrote:
> 2011/10/3 Evgeniy Khramtsov<xramtsov <at> gmail.com>:
>>> Since most of the SIP clients don't yet examine such SubjectAltName in
>>> a received certificate, and none of them implements SNI, I strongly
>>> think that it's much better for them to implement SubjectAltName
>>> inspection (which is already defined for SIP) rather than implementing
>>> SNI.
>>>
>>> Regards.
>> As I understand, SubjectAltName won't work for virtual servers holding
>> lots of separate certificates and listening on the same port.
> Why not? the client wants to establish a TLS connection with domain
> "example1.org", so after DNS procedures it establishes a TLS
> connection with the server and the server sends its TLS certificate.
> Such certificate contains varios SubjectAltName fields with values.

What if you don't have an ability to generate such a certificate from 
multiple certfiles? For instance, when certfiles are private: uploaded 
by different persons/organizations to the shared virtual server.

--

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram <at> jabber.ru.

Iñaki Baz Castillo | 3 Oct 15:23 2011
Picon

Re: SIP identity and SIP domain certs

2011/10/3 Kevin P. Fleming <kpfleming <at> digium.com>:
>> The client checks that "sip:example1.org" is present so *that's all*.
>> And this is clearly explained in RFC 5922 (which updates RFC 3261):
>>
>>    http://tools.ietf.org/html/rfc5922#section-7.1
>
> That's true, it's technically possible for SubjectAltName to be used
> this way. However, doing so requires that the cert be re-issued every
> time a virtual service is added or removed from the physical server,
> which is a burden for the administrator.

Ok, right, I just said that this usage is specified for SIP protocol.
And honestly, I don't think there are real-in-production SIP servers
offering TLS with multiple virtual domains (are there?). Typically a
SIP provider just uses a single domain.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Gmane