Subject: [Sip] Comments on draft-gurbani-sip-domain-certs-03-

From: EKR <[email-masked]>
Date: Sun, 29 Oct 2006 11:16:27 -0800

Id: draft-gurbani-sip-domain-certs-03-rev.txt,v 1.1 2006/10/29 19:14:00 ekr Exp $

The subject of this draft is what identities should appear in the
TLS certificates presented by SIP clients and servers. To refresh
people's memories, here's some background from my review of the
-01 version of this draft:

    Let's take a step back and examine first principles: The basic
    assumption behind RFC 2818 (and most other uses of TLS) is that
    you start with some URI X that you want to dereference. Through
    some series of (untrusted) manipulations you end up with a
    connection to some endpoint which presents you a certificate
    C. You then need to determine whether X matches C. In order for
    this process to work properly, X needs to either contain C or
    there needs to be some trusted transformation between C and X.

    In the Web context, what this means is that if you have a server
    farm with A.example.com, B.example.com, C.example.com, etc.  then
    they all have certificates containing "www.example.com".  This can
    either be done via key-sharing or can be done by issuing them
    separate certificates that all contain the same domain name
    ("www.example.com").

This is basically the practice that people have assumed for RFC 3261.
The authors of this draft argue that this is a problem because 
proxy farms want to use record routes to force routing back through
a particular member of the proxy farm:

   While this is not a concern when
   choosing any proxy from a server farm, it is a problem when the
   choice of a proxy needs to be deterministic.  One way to combat this
   is to arrange for the proxy to possess two certificates -- one
   corresponding to "sips:example.com" and the other corresponding to
   "sips:downtown.example.com" -- and have it present the right one when
   contacted.  While technically this is feasible through the use of TLS
   extensions [7], administratively it requires the proxy vendor to
   acquire two distinct certificates.  In this document, we propose the
   use of one certificate with two identities as a possible way to
   counter this particular problem.

I'm skeptical that this is really going to be an important scenario.
If you want to have high availability (and presumably if you run a
proxy farm you do) you need to have proxy operations either be
stateless or arrange for state clustering, in which case getting
something back to the wrong proxy just looks like a cache
niss. Moreover, once outbound and draft-ietf-sip-connect-reuse-05 are
deployed, I would expect to see quite a bit of stickiness. That said,
it does seem relatively easily solved just by saying "if you ever
serve multiple names, you need some way to deal with it."

S 5.
I don't understand why you're separating out RFC 3263 versus non-3263
identities here. If you think you should have a cert with multiple
names, let's just have them be undifferentiated.

S 9.

   Is it conceivable that each domain have a distinct certificate that
   is provided to the hosting service?  Certainly, this means that the
   domain must share the domain's private key with the hosting service.
   TLS extensions [7] like the extended client hello allow TLS clients
   to provide to the TLS server the name of the server they are
   contacting.  Thus, the server can present the correct certificate to
   establish the TLS connection.

The appropriate thing here seems to be to follow HTTPS practice. Each
domain has its own key pair and cert. The hosting service has the
private key. You use name-based virtual hosting if you can trust
clients to provide the dns_name. Otherwise you use IP-based.

The following rules seem appropriate:
1. Nothing prohibits SIP servers certs from having multiple names.
2. Clients should accept certificates with multiple names.
3. Clients should deterministically check for the presence of 
   one name (the one in whatever they're dereferencing) and ignore
   others.
4. Servers which wish to act for multiple identities should either
   (a) have a certificate with multiple names
   (b) use some form of virtual hosting.
5. Clients should generate the dns_name extension.

Have I missed something? 

-Ekr

_______________________________________________
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: Scott Lawrence <[email-masked]>
Date: Sun, 29 Oct 2006 17:36:58 -0500

> 5. Clients should generate the dns_name extension.

The essential thing about puting both the SIP domain name as a URI and
the host name as a DNS name is to clarify the scope of the authority to
use that name.  I may deploy many services at 'example.com': SIP, DNS,
HTTP, some illegal music sharing service, whatever....  at some point, I
will want or need those services to be on different systems.  I may want
or need to even use different certificate hierarchies for different
services.  I want my SIP certificate to be able to express the statement
"I am authoritative for the SIP domain 'example.com'", without making
any statement about that server being authoritative for email to
'example.com'.  Further, I may want to make that statement about servers
that are the originators of connections but do not accept connections: I
may have two proxies for outbound connections and two for inbound
connections.  Resolving 'example.com' using NAPTR/SRV will find only the
inbound servers, but I still want to be able to assert that the outbound
servers are authoritative for the domain (it's fine to bill me for the
calls they originate, you can trust the identity headers they sign,
etc).  I do not want the fact that someone was able to create a host
certificate for 'randomhost.example.com', even from the same certificate
authority, to be accepted as an assertion of authority for my SIP
services.  That asymmetry doesn't occur in HTTP, so certificate usage in
HTTP doesn't cover it.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Oct 2006 15:23:50 -0800

Scott Lawrence <[email-masked]> writes:

> 'example.com'. 

That's a reasonable theory, but it's not clear to me why you think
this ought to be done with naming. ISTM that the right way to
do this is with extendedkeyusage.

> Further, I may want to make that statement about servers
> etc). 

Right. Give them all a certificate for the name "example.com" with
whatever "This is a SIP certificate" indicator we eventually
choose.

-Ekr

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 29 Oct 2006 21:28:30 -0500

> whatever "This is a SIP certificate" indicator we eventually

Well, the idea in the draft is to use the fact that the URL has a 'sip'
scheme to do just that.  Is there some reason you can think of why
something else is required?  As far as I can tell, all that is needed is
an unambiguous way to express what purpose the certificate is issued for
that's easy for implementors to do and certification issuers can
enforce.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Oct 2006 18:41:22 -0800

Scott Lawrence <[email-masked]> writes:
> scheme to do just that.  

Except that you've defined certificates that have two SANs, one SIP and
one not.

> Is there some reason you can think of why something else is
> required? As far as I can tell, all that is needed is an unambiguous
> way to express what purpose the certificate is issued for that's
> easy for implementors to do and certification issuers can enforce.

Right, but you realize that certificates already have a way to
express uses using the extendedKeyUsage extension. So, I'm
not at all sure that naming is what's appropriate here. That
said, I'm not an expert on this. I would recommend asking PKIX
what they like for denoting purpose.

-Ekr

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 29 Oct 2006 22:18:36 -0500

> what they like for denoting purpose.

Yes, that would seem to be a good idea.

For anyone interested, the relevant specs would appear to be RFC 3280
"Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile" sections 
4.2.1.7  Subject Alternative Name
4.2.1.13  Extended Key Usage

The extended key usage is an OID that we define to mean whatever we
decide it needs to mean, apparently.  Does the SIP working group already
have an OID root to hang this on?