Subject: [Sip] Comments on draft-ietf-sip-domain-certs-00

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Mar 2008 10:16:08 -0700

Greetings. Robert Sparks mentioned to me that this document is in WG 
Last Call. I am familiar with PKIX and make these comments based on 
my knowledge of PKIX, not based on my small knowledge of SIP.

In general, this document seems fine. However, there are some points 
worth noting.

- Steve Kent's comment about domain names in the CN is right: there 
is no reason for this group to standardize on allowing domain names 
in CNs. We have found almost no CA software that in practice today 
will only put a domain name in the CN; those that even allow doing so 
(which thankfully is few) have an option for putting it in the 
subjectAltName. Because of this, I suggest taking out this option 
everywhere in the document; you'll get much better interoperability 
if you do.

- The logic in item 1 of section 7.1 is confusing. If there is no 
sip: URI, but there is a DNS name, why is accepting it a MAY? 
Shouldn't this be a MUST for interoperability? If it is only a MAY, 
where else would the relying party get a useful SIP host identity?

- The document incorrectly talks about Digest authentication as the 
only way that a SIP server running TLS can authenticate a client. 
Basic authentication is just as good in such a case, and has many 
properties that make it better than Digest when used under TLS. The 
document should only talk about HTTP authentication, not Digest or 
Basic.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Sip mailing list  https://www.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: Eric Rescorla <[email-masked]>
Date: Wed, 26 Mar 2008 11:48:40 -0700

At Wed, 26 Mar 2008 10:16:08 -0700,
> everywhere in the document; you'll get much better interoperability 

So, I have no brief for one design or the other, but I think
we can agree that it's imperative that this work with certs
from commodity CAs. Has someone published a survey of which
CAs will give you SAN?

> document should only talk about HTTP authentication, not Digest or 

SIP is not HTTP, and does not support Basic authentication. See S 28.1
of RFC 3261:

   o  Basic authentication has been removed entirely and its usage
      forbidden.

-Ekr

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 26 Mar 2008 14:40:22 -0500

> my knowledge of PKIX, not based on my small knowledge of SIP.

Paul: Thanks for your time on reading the drafts (my co-author and
I owe you a response on the sip-eku as well.)  But for this one,
please see inline.

> everywhere in the document; you'll get much better interoperability 

Right; so when we first started this work, there was a tacit need
to support existing certificates -- not designed for the use of
SIP, per se -- that would not have the domain name in SAN, and
instead would have it in the CN (existing web certificates re-used
for SIP, for instance.)  These certificates would need to be
supported as well.  Hence the imperative to implementors to check
the CN if SAN is empty; the imperative to service providers to
use SAN; and in sip-eku, the imperative to a CA to insert the
identity in the SAN.

> where else would the relying party get a useful SIP host identity?

Our thinking was that whether to accept a DNS type in the SAN
is up to the individual policies of the service provider.  Ought
this be made more explicit?  Or other avenues explored?

> document should only talk about HTTP authentication, not Digest or 

RFC3261 deprecated Basic authentication.  Only Digest is
supported in rfc3261.

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
_______________________________________________
Sip mailing list  https://www.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: Wed, 26 Mar 2008 14:52:04 -0500

> from commodity CAs. Has someone published a survey of which

Ekr: I don't know of a survey, but anecdotally speaking, at least
Thawte does.  I have a freebie certificate from Thawte for
email signing.  It has a couple of my identities in SAN:

[osiris:/u/vkg]$ x509 -noout -in vkg-Thawte-SAN.pem -text
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             15:8d:ec:ff:b9:06:bf:76:49:7b:29:d6:e5:df:61:b8
         Signature Algorithm: sha1WithRSAEncryption
         Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte 
Personal Freemail Issuing CA
...
        X509v3 extensions:
             X509v3 Subject Alternative Name:
                 email:[email-masked], email:[email-masked]
             X509v3 Basic Constraints: critical
                 CA:FALSE

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Wed, 26 Mar 2008 15:08:34 -0500

> document should only talk about HTTP authentication, not Digest or

The argument here is that basic was explicitly deprecated in RFC 3261.  
Many people feel that this was a mistake, but that's what we have to  
work with. RFC 3261 even explicitly says (in Section 22):

> Note that due to its weak security, the usage of "Basic"  
> authentication has been deprecated. Servers MUST NOT accept  
> credentials using the "Basic" authorization scheme, and servers also  
> MUST NOT challenge with "Basic". This is a change from RFC 2543.

--
Dean

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Mar 2008 13:33:15 -0700

At 11:48 AM -0700 3/26/08, Eric Rescorla wrote:
>...snip...

 From what I have heard, all of them will, and all of them that don't 
ask "CN or SAN" give them in SAN. I could be wrong, of course. I'll 
ask on the PKIX list, and will report back.

>SIP is not HTTP, and does not support Basic authentication.

Got it. Sorry for missing that one.

>use SAN; and in sip-eku, the imperative to a CA to insert the

Given that there is now lots of interop experience with SIP-over-TLS, 
has anyone checked the certs floating around for whether there are 
any using domain names in CN? If not, you shouldn't have to drag 
around that baggage.

>this be made more explicit?  Or other avenues explored?

With the current wording, two systems will only be assured of having 
interoperability if they both have sip: URL in the certs. That goes 
directly against what you say above about the "tacit need" to support 
existing certificates. The "MAY" gives you an increased chance of 
interop, but far from a guarantee.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Mar 2008 09:15:20 -0500

> ask on the PKIX list, and will report back.

Paul: OK, good.  That would be invaluable data.

> any using domain names in CN? If not, you shouldn't have to drag 

I believe -- and someone on the WG will correct me if I am wrong --
that most of our interop experience with SIP/TLS comes from the
SIPits (SIP Interoperability Events).  At the SIPits, the certs
are generated and handed off to individual implementations.  These
certs have the identity in the SAN.   So this is not that much of
an issue when we have control of how certs are created.

Here is the breakdown of TLS support in the last few SIPits:

SIPit Number       Support for TLS (Total implementations)
-----------------------------------------------------------
     16                43.8%      (57)
     18                41.0%      (73)
     19                45.0% [1]  (90)
                       36.0% [2]
     20                46.0% [1]  (90)
                       24.0% [2]
     21                49.0% [1]  (70)
                        6.0% [2]
[1] Server auth only
[2] Server or mutual auth

I do not have a good feel for the deployment of SIP/TLS out in
the wild.  If anyone in the WG is using a X.509 cert for TLS,
it would be great to have some data as to where the identities
are encoded, and how many there are, etc.

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Thu, 27 Mar 2008 11:54:17 -0500

> ask on the PKIX list, and will report back.

OpenSSL can generate SAN. None of my certs have it .

Oddly enough, the SAN settings appear to go into the master config  
file and affect every CSR generated. So you have to reconfigure the  
software for each CSR generated. Yuck.

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Mar 2008 12:17:54 -0500

> software for each CSR generated. Yuck.

Could you not use the -extfile parameter to the "openssl x509 -req"
command?  In other words:

$ openssl x509 -req -in <...>.pem -extfile foo.cfg -extensions v3 ...

and in foo.cfg

[ v3 ]
subjectKeyIdentifier   = hash
basicConstraints       = CA:false
subjectAltName         = DNS:foo.example.com, URI:sip:foo.com

This works for me, of course, at least for the limited use that
I put openssl x509 command to.  I cannot speak for the CAs that
do this for a living on how they put SANs in the CSR they get.

- vijay

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Mar 2008 10:39:31 -0700

>OpenSSL can generate SAN. None of my certs have it .

Off-listk, Dean told me that his certs are CA certs, which indeed 
should not have the domain name in the subjectAltName.

But the bigger question is: how important is being able to handle 
legacy certificates for this protocol? In specific, section 7.1 of 
the document says:

    I-D.sip-eku [9] describes the method to validate any Extended Key
    Usage values found in the certificate for a SIP domain.
    Implementations MUST perform the checks prescribed by that
    specification.

    Given an X.509 certificate that the above checks have found to be
    acceptable, the following describes how to determine what SIP
    identity or identities it contains.  . . .

Because you are mandating that the certificates have to have the new 
EKU (or, if you adopt my earlier suggestion, a new PKIX extension 
that is better suited to your needs), then you can also mandate that 
the new certs need to follow RFC 3280 and put the domain name in the 
subjectAltName. This is simpler, and will certainly lead to better 
interoperability.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Mar 2008 12:53:45 -0500

Paul Hoffman wrote:
> Off-list, Dean told me that his certs are CA certs, which indeed 
> legacy certificates for this protocol? 

The WG consensus so far has been that handling legacy certificates
is very important.  If we (i.e., the author team) get guidance
from the ADs and SecDir that this can be relaxed, then we can do
as you suggest.

> EKU [...]

Our thought was to have *new* certificates be issued with the SIP EKU
and identity in SAN.  However, legacy certificates will most certainly
not have the SIP EKU, but could possibly have the identity in SAN.
Thus the rules you see in the drafts to allow legacy certificates to
be used while supporting newly issued certificates.

Thanks,

- vijay

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Mar 2008 11:01:26 -0700

At Thu, 27 Mar 2008 10:39:31 -0700,
> legacy certificates for this protocol?

Uh, absolutely critical? If people have to jump through major 
hoops to get certs for SIP, they won't.

> In specific, section 7.1 of 
> the document says:
> 

1. This isn't a requirement that the certificates HAVE this EKU,
   just that you validate it.
2. It's not clear to me there is consensus for this now levy.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Mar 2008 11:51:04 -0700

>from the ADs and SecDir that this can be relaxed, then we can do

If the WG wants to handle legacy certs, you certainly need to say how 
and hope for the best. Assume that interoperability will be less than 
full. For example, you haven't covered certificates that use the 
DomainComponent method of expressing domain names; not that you want 
to go there if you don't have to...

--Paul Hoffman, Director
--VPN Consortium

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Mar 2008 19:37:04 -0700

There was one site I work with a bit that I remembered used Thawte  
certificates so I connected to see what it does. Does not look like it  
uses SAN.

FluffyMac30-2.local:tmp 69% openssl s_client -connect mail.google.com: 
443 -showcerts > & foo.pem
^C
FluffyMac30-2.local:tmp 70% openssl x509 -in foo.pem -text -noout
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             78:62:5d:1b:e6:6e:2e:b0:19:80:fc:0f:e3:da:98:51
         Signature Algorithm: sha1WithRSAEncryption
         Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA
         Validity
             Not Before: May  3 15:34:58 2007 GMT
             Not After : May 15 17:24:01 2008 GMT
         Subject: C=US, ST=California, L=Mountain View, O=Google Inc,  
CN=mail.google.com
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
             RSA Public Key: (1024 bit)
                 Modulus (1024 bit):
                     00:c9:d4:b9:d2:d4:84:7b:f7:72:9c:b4:03:8e:ca:
                     df:ca:0e:60:af:42:78:7f:77:50:cc:c7:d5:00:3f:
                     15:8c:30:85:1a:dc:12:44:23:c1:2a:dd:74:da:85:
                     44:b0:49:32:ff:8a:58:a1:5b:31:b4:f3:31:24:7a:
                     f5:54:02:24:9d:ba:70:a4:8e:83:de:61:86:e2:2c:
                     45:fe:98:f0:c4:5f:ca:75:8a:e2:77:ee:9f:cb:9b:
                     17:c2:1f:2d:f2:12:7e:bc:d3:5f:cf:e7:c3:c8:e6:
                     b4:bd:33:68:d3:52:09:95:ac:e9:43:73:a6:d9:0a:
                     d3:ce:6d:44:ed:8a:a1:e6:79
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Extended Key Usage:
                 TLS Web Server Authentication, TLS Web Client  
Authentication, Netscape Server Gated Crypto
             X509v3 CRL Distribution Points:
                 URI:http://crl.thawte.com/ThawteSGCCA.crl

             Authority Information Access:
                 OCSP - URI:http://ocsp.thawte.com
                 CA Issuers - URI:http://www.thawte.com/repository/Thawte_SGC_CA.crt

             X509v3 Basic Constraints: critical
                 CA:FALSE
     Signature Algorithm: sha1WithRSAEncryption
         d4:9a:d2:a2:50:81:09:d7:5e:99:52:05:fc:5c:e1:1a:c3:75:
         79:31:40:d0:9c:20:cc:bf:83:e2:ee:b9:51:af:8f:7a:ac:cc:
         9e:b1:b4:f3:ea:d0:3b:0c:e0:35:93:c8:ea:57:7a:23:15:42:
         43:61:a4:0d:4f:15:51:19:37:d2:f5:36:e9:6b:9c:07:e2:26:
         4b:ea:42:dc:43:52:4a:69:62:07:a5:35:09:27:2e:d9:02:f8:
         03:5a:75:b0:67:73:f9:b3:9e:a2:f7:70:d9:70:0e:ad:06:0c:
         30:25:d3:d2:12:59:fb:e6:d3:52:1a:e2:8f:1a:a4:69:27:51:
         78:f5
FluffyMac30-2.local:tmp 71%

I poked a few other sites to see what they do
verisign.com
www.thawte.com
www.entrust.com
www.geotrust.com
www.comodo.com/
cisco.com
microsoft.com
nist.gov
nsa.gov

They all had one thing in common - no SAN. I realize this has nothing  
to do with if one could get a certificate with SAN or not - only a  
sample (not random) of what people who hopefully know about  
certificates are doing.

The funniest thing I found was that https://www.whitehouse.gov/ and https://www.gov.cn/ 
  were both signed with the *same* certificate. Seriously, I could not  
make this up if I tried. (for me, both were severed by  
a248.e.akamai.net). Again no SAN.

So this is a pretty adhoc selection but my point is simple - if these  
people are not using certificates with SAN, how long do we expect  
before most the certificates people are using for their web servers  
use SAN? Our goals with SIP has for a long time been that  it is  
possible to use the same certificate you already have for your web  
server and just use it to secure SIP.

One site I know of that does have SAN is cacert.org but I suspect that  
is only because I worked with them to get that working.   It also  
seems that digicert.com can provide certificate with at least a SAN  
name of DNS type but less clear if I they can add a URI. The only  
other site I found in my limited poking that had a SAN was godaddy.com  
- once again proving they are the CA with the best names.

Exchange Server 2007 can take advantage of SAN and I expect to see  
more people using them because of this. Perviously some CAs had  
offered SAN in certificates call  Microsoft Small Business Server  
certificates but last time I tried these (long ago) I could not get  
one that worked with a SIP URI.

Some old market share data is at http://news.netcraft.com/archives/2003/04/09/netcraft_ssl_survey.html

A few years back, I got the market share data of major CAs, went down  
the top four and tried to get them to sign a CSR with SIP URI in the  
SAN. I failed to get anything that worked. One of the CAs worked with  
me to try and resolve this and we got a test cert signed but they were  
unwilling to offer it as a service due to the small size of the  
market. Ideally someone (not me) would try this again and see if the  
stuff Microsoft has been doing has made it easier to get certs with  
SAN now than it was then.

Another nice test would be to randomly choose some domain names and  
look at their https certificate and see if it using SAN to get an idea  
of what the current deployment is like.

Cullen <with my individual contributor hat on>

---

From: Dean Willis <[email-masked]>
Date: Thu, 27 Mar 2008 23:00:29 -0500

> certificates so I connected to see what it does. Does not look like it

So the model is this: Use a CERT with SAN and EKU if you can. If you  
receive a cert with one or both, validate them and evaluate them  
appropriately. If you get a cert that has neither, proceed as usual.

SHOULD use in cert, MUST validate if present.

--
Dean