Subject: [Sip] Certificates handling in SIP/TLS

From: Johan Bilien <[email-masked]>
Date: Thu, 6 Nov 2003 17:01:01 +0100

Hi,

I have a few questions regarding the certificates handling when using
SIP over TLS:

  . When the mutual authentication isn't used, should the TLS connection
  between the proxy and the UA be kept alive after the first
  registration ? Otherwise, how can the proxy contact the client, for
  example to forward an incoming INVITE: if the initial connection was
  closed, the UA will need a TLS listening connection, thus act as a TLS
  server and need a certificate.

  . When using mutual authentication, to which identity should the UA
  certificate's CN refer ? To the FQDN of the UA, or to the SIP URI ? In
  the last case, it would allow to use the same certificate as in MIKEY
  for instance.

Thanks,
-- 
Johan Bilien

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 09 Nov 2003 22:32:18 -0800

On 11/6/03 8:01 AM, "Johan Bilien" <[email-masked]> wrote:

> registration ? 

Yes - and it it goes down, the UA should re-register. If you are behind many
types of firewalls or gasp worse yet a NAT, you will have to do this even if
you are not using TLS.

> Otherwise, how can the proxy contact the client, for
> certificate's CN refer ? To the FQDN of the UA, or to the SIP URI ?

It's really the SubjectAltname not the CN that should be used in SIP. This
should refer to the same FQDN as the proxy would be trying to connect to -
this basically means it needs to assert the hostname portion of of whatever
it put in it's contact. This is not really possible if you got your
hostname/IP via DHCP like nearly every device that registers does. I view
mutual TLS as very useful between proxies and to things like gateways or
voice mail servers but not really very practical to most devices where user
register. 

Cullen

---

From: Johan Bilien <[email-masked]>
Date: Mon, 10 Nov 2003 17:20:32 +0100

> types of firewalls or gasp worse yet a NAT, you will have to do this even if

So the client should check continuously that the connection is up ? And
if the connection goes down, and the client does not see it for some
reason, the server will not be able to forward the next INVITE messages.
In some cases, it is not very convenient to have to maintain a
connection alive, for example in case of mobile IP.

On the other hand, having the UA being able to handle TLS-server
connections would allow to re-establish a closed connection in any case.
Using TLS session resumption, re-establishing the connection is very
fast. The need for a UA certificate has other motivations (see below).

> voice mail servers but not really very practical to most devices where user

In the case of a UA, having the certificate point to the FQDM doesn't
make much sense to me. On the other hand, having a certificate pointing
to the SIP URI of the user would allow several interesting things:

  . Replace the HTTP Digest client-to-proxy authentication with a TLS
  mutual authentication.

  . Allow a user to switch from one device to another without having to
  use different certificates.

  . Use the same certificate for the signature of a Diffie-Hellman key
  exchange, in a scheme such a MIKEY [1], and maybe for instant
  messaging encryption and signature ...

In this case, the association user-hostname would still be provided in a
secured way through the contact header, in the TLS-encrypted REGISTER. 

[1] http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-07.txt

Best regards,
-- 
Johan Bilien

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Nov 2003 15:11:12 -0800

> connection alive, for example in case of mobile IP.

Yes I agree. 

> fast. The need for a UA certificate has other motivations (see below).

This is good as long as you have stable address that is used to reach the
device that can be bound into the credentials of the device. This is
typically true in wireless systems. However, with IP phones or soft phones
often get their address via DHCP and do not have a stable IP address or DNS
domain name and this is unfortunately what is used to address them. I agree
that session resumption can greatly speed the set up.

> to the SIP URI of the user would allow several interesting things:

I assume you mean the SIP AOR like sip:[email-masked] so you can do end
to end or middle to end security. I agree this is a good idea but I think
this what was being address by S/MIME stuff.

> . Replace the HTTP Digest client-to-proxy authentication with a TLS

Sure - see e2m stuff.

> use different certificates.

This does introduce the tricky problem of making sure both devices have the
same private key but yes.