Sip Implementors

Olle E. Johansson | 1 Oct 2011 22:36

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 2011 23:02

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 2011 12:34

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 2011 14:26

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 2011 14:32

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 2011 14:44

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 2011 14:51

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 2011 14:59

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 2011 15:04

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 2011 15:23

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

Group

gmane.ietf.sip-implementors.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12

Articles in period: 115

October 2011

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

commercial SIP stack/library. (24 May 2013)
Query for "received" parameter in top Via header (21 May 2013)
Query for "received" parameter in top Via header (21 May 2013)
sip over TCP (20 May 2013)
Query regarding session timer behaviour in SIP Stack (20 May 2013)
Query for method name in Request URI (20 May 2013)
FMT are mandatory in the Media Descriptions ("m=") line (20 May 2013)
Survey on SIP overload control algorithms (17 May 2013)
Clarification/recommendation needed on sip protocol (15 May 2013)
Require header in ACK request (14 May 2013)
Query for Out of dialod Notify (14 May 2013)
Query related register (14 May 2013)
What is the best SIP stack ? (10 May 2013)
Question about RFC4028 session timer (9 May 2013)
REGISTER message without Contact Header and Expires 0 (8 May 2013)
cpu usage g711/g729 (7 May 2013)
Question about RFC4028 session timer (7 May 2013)
A question about Section 8.1.1.2 of RFC3261 (To header filed) (4 May 2013)
about call frauds and client auth/registration (3 May 2013)
Auto-Attendant / IVR (30 Apr 2013)
Auto-Attendant / IVR (30 Apr 2013)

Archives

55	May 2013
69	April 2013
49	March 2013
74	February 2013
68	January 2013
39	December 2012
34	November 2012
29	October 2012
30	September 2012
49	August 2012
76	July 2012
95	June 2012
64	May 2012
101	April 2012
182	March 2012
82	February 2012
32	January 2012
57	December 2011
129	November 2011
115	October 2011
115	September 2011
61	August 2011
193	July 2011
191	June 2011
148	May 2011
196	April 2011
275	March 2011
176	February 2011
186	January 2011
97	December 2010
188	November 2010
160	October 2010
133	September 2010
121	August 2010
185	July 2010
143	June 2010
236	May 2010
156	April 2010
268	March 2010
284	February 2010
109	January 2010
119	December 2009
151	November 2009
130	October 2009
124	September 2009
231	August 2009
272	July 2009
217	June 2009
271	May 2009
362	April 2009
280	March 2009
368	February 2009
252	January 2009
279	December 2008
212	November 2008
228	October 2008
353	September 2008
301	August 2008
274	July 2008
252	June 2008
207	May 2008
294	April 2008
303	March 2008
201	February 2008
244	January 2008
175	December 2007
228	November 2007
203	October 2007
119	September 2007
183	August 2007
166	July 2007
262	June 2007
347	May 2007
415	April 2007
366	March 2007
317	February 2007
214	January 2007
241	December 2006
372	November 2006
268	October 2006
266	September 2006
274	August 2006
230	July 2006
378	June 2006
316	May 2006
300	April 2006
290	March 2006
274	February 2006
304	January 2006
299	December 2005
442	November 2005
378	October 2005
298	September 2005
314	August 2005
263	July 2005
275	June 2005
334	May 2005
296	April 2005
276	March 2005
261	February 2005
137	January 2005
231	December 2004
221	November 2004
152	October 2004
268	September 2004
231	August 2004
71	July 2004
1	September 2003
2	July 2003

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template