Subject: [Sip] draft-gurbani-sip-domain-certs

From: Cullen Jennings <[email-masked]>
Date: Sun, 11 Mar 2007 10:42:13 -0700

I think many of my previously mentioned issues with this draft still  
exist.

Lets consider the case where you have proxy farm with 3 members known  
as a,b, and c in the domain example.com. This draft is premised on  
the idea that it is actually desirable to pin mid dialog requests to  
one particular member of the farm. I don't actually find this a  
compelling use case because it breaks any sense of high reliability  
but I'm will to suppress my disbelief and take this as the problem we  
need to solve.

Clearly having a single certificate that has 4 name in the SAN list  
solves this - the name would be for example.com, a.example.com,  
b.example.com, and c.example.com. You don't need 4 certificates - you  
need one with all the names you will use.

The advantage of 1 certificate with 4 names over extendedClientHellos  
is that there is not yet widespread support for the extended hellos  
stuff.

One of the other use caes you bring up is where example.com has a  
single server which runs several virtual domains - say example.net  
and example.org. The way that the web server world manages to solve  
this problem (and how many existing SIP proxies do it today) is by  
running each domain on a different port for each virtual domain and a  
separate certificate for each domain. Now the extendedClientHello  
would allow for  multiple virtual domains to use one port (still with  
one cert per domain) and I hope that happens in the future.

I don't understand how the certificate names relate to you inbound  
outbound proxy problem. Lets say a domain uses only a.example.com for  
inbound and only b.example.com for outbound. Clearly the DNS SRV  
resolution for example.com would only point at a.example.com and not  
b. However, both could use a certificate with example.com,  
a.example.com, and b.example.com in it. Of you could have two certs  
one with example.com and a.example.com and the other with example.com  
and b.example.com. If some other domain receives a TLS connection  
from example.com with the cert and mutual auth etc, the issues of if  
it can use this connection for new requests it wants to send to the  
example.com domain is not one that is deal with using the TLS certs -  
it is solved by other things like 1) don't do or 2) use draft-ietf- 
sip-connect-reuse (which oddly has a author in common with this draft)

The examples seem to use DNS types in the SAN for some things and URI  
types for other things. We have had many emails about this and I see  
no reason to make them different - please clearly explain in the  
draft why you use DNS fro some and URI for others. You know my  
opinion on this which is these constrain what the cert can be used  
for and nothing more or less.

The suggestions about costs and number of certificates required in  
the draft seem to be mostly wrong.

I seem to recall people pointing out problems with the maddr approach  
that had to do with URI which needed to be different would end up  
matching.

Defining an Extended Key Usage that restricts a certificate for SIP  
seems like a perfectly fine thing to do but I will need to be in a  
separate draft that is off in the SEC area somewhere. I do note that,  
uh, lots of things ignore theses - so marking it as critical often  
reduces deployability, luckily lots of things just ignore the  
critical which makes the certificate usable but the constraint  
useless - but I degree, in theory they are clearly the right way to  
constrain certificates. I certainly agree that this gives a much more  
refined way of controlling usage than the course granularity that the  
DNS vs URI type in the SAN list provides.

One of the primary things that causes confusing for implementers is  
what a UAC needs to actually match when it opens a connection and  
sends a request over TLS. This tries to clarify it with

    When a UAC receives a certificate from a server, it MUST ensure that
    the certificate asserts one of the two identities that the UAC used
    to reach the server:  If the UAC performed RFC3263 resolution on the
    URI to reach the server, the SIP or SIPS identity stored in the
    certificate MUST be matched.  Otherwise, if RFC3263 resolution on  
the
    URI failed, the UAC MUST match the DNS label in the certificate with
    the name of the server that it opened a TLS connection to.

I've got to admit - I can't make heads or tails out of any of that.  
What you need to explain is that there is a URI that UAC is trying to  
send the message to, after doing some resolution on this URI it opens  
a TLS connection which will present a certificate. The UAC need to  
check that one of the possibly many names in the SAN matches the  
destination specified in the URI. If you want to allow use of CN then  
you need to explain that too but usage of SAN is clearly preferred to  
CN.

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 12 Mar 2007 11:19:43 -0600

> I think many of my previously mentioned issues with this draft still

Cullen: Thanks for a read.  More inline.

> but I'm will to suppress my disbelief and take this as the problem we

The formulation of the pinning problem was predicated not so
much on providing high availability (HA) services but rather
on simple experiment of noticing that the many proxies in use
today insert a URI with a FQDN name in a R-R going downstream.
If that URI happens to be a sips URI, then a subsequent
connection opened to that proxy will result in a certificate
coming back that does not match the said URI.

This is the basic problem at hand.  Saying that proxies must
not insert FQDN in the R-R header is something that we have
advocated so far in the WG.  But I believe we can do better
than that (see below).  There may be legitimate reasons why
pinning is desirable.

As you note, HA can be provided by inserting a domain URI
(example.com) and not a FQDN URI (proxy1.example.com).  However,
if an implementation insists on using FQDN URIs in R-R, then HA
can also be provided by maintaining the FQDN as an identity in
the certificate and using an active-passive redundancy scheme.

Regardless of whether or not an implementation puts a domain URI
or a FQDN URI, the certificate presented to it should provide
identity assurance that the UAC is looking for.  Today, this
is not the case.  There are ways to do this, of course.  The
tricky part is agreeing to which one is the right way.

> the URI failed, the UAC MUST match the DNS label in the certificate
> with the name of the server that it opened a TLS connection to.
> 

Let's take two cases.

Case 1: UAC looks up on domain URI:

   NAPTR("example.com") = "_sips._tcp.example.com"
     SRV("_sips._tcp.example.com") = "proxy1.example.com"
      A("proxy1.example.com") = "192.0.2.3"
        TLS_connect("192.0.2.3", 5061) = Cert received contains
                                         "example.com"
         Server authenticated (since "example.com" matches what we
         started off with)

Case 2: UAC looks up on FQDN URI:

   NAPTR("proxy1.example.com") = NULL;
    SRV("_sips._tcp.proxy1.example.com") = NULL
     A("proxy1.example.com") = "192.0.2.3"
      TLS_connect("192.0.2.3", 5061) = Cert received contains
                                         "example.com"
         Server NOT authenticated (since "example.com" does not match
         what we started off with, namely "proxy1.example.com")

Here is where having two identities in the certificate helps.
The client in case 2 could have matched "proxy1.example.com" if
it was stored in the certificate.

> for and nothing more or less.

These need to be URI types; didn't get down to scrubbing everything,
unfortunately.

> the draft seem to be mostly wrong.

Hmmm ... in the design team meetings, it has been expressed that
the reason why multiple names in a certificate (domain URI, FQDN) is
undesirable is because of cost.  A service provider will have to get
multiple certificates, each corresponding to a host.  OTOH, if a
certificate contains only a domain URI, the same certificate can
be used on all hosts.  Cost was pointed out as a prohibitive factor
in using multiple names (domain URI, FQDN) in the certificate.

> that had to do with URI which needed to be different would end up 

I am trying to think of a specific example, but drawing a blank.
Can you recall one?

> separate draft that is off in the SEC area somewhere. I do note
> that, uh, lots of things ignore theses - so marking it as critical
> often reduces deployability, luckily lots of things just ignore the

OK.

> If some other domain receives a TLS connection  from example.com with
> the cert and mutual auth etc, the issues of if  it can use this
> connection for new requests it wants to send to the  example.com
> domain is not one that is deal with using the TLS certs -  it is
> solved by other things like 1) don't do or 2) use draft-ietf-

Yeah, odd ;-)  I think the harder part has been figuring out
where connection reuse begins and where mutual authentication
ends.  The *result* of a mutual authentication, in may cases,
is the reuse of connections.  We have been conflating both of
these together so far.  Maybe if we separate them out, and deal
with them individually, that'll help.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs