Subject: sip-eku and sip-domain-certs drafts

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 08 Nov 2007 11:37:45 -0600

Hello:

For a good part of this year, Scott Lawrence and I have been working
on the usage of X.509 certificates in SIP TLS connections.  As part
of that work, we have solicited -- and received excellent -- advice
from the PKIX WG on related issues (many thanks!).

The PKIX-related parts of the work has been defining a key usage
extension that identifies the holder of the certificate as
authoritative for a SIP service in a domain, and the interpretation
and usage of identities stored in a X.509 certificate when used
for SIP.

The original draft that was reviewed by the PKIX WG was
draft-gurbani-sip-domain-certs.  When this work was adopted as
a SIP WG deliverable, we split the draft into two.  One of these
drafts -- draft-ietf-sip-eku -- discusses EKU extension.  A
companion draft -- draft-ietf-sip-domain-certs -- describes
how to use identities in X.509 certificates and perform mutual
authentication between two SIP domains.

Now that the ideas and the work has been fully fleshed out, we
would kindly like to solicit a final review from PKIX on these
documents.  The URLs are:

http://tools.ietf.org/html/draft-ietf-sip-eku-00
http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt

Thank you in advance for your time and attention to this.

Regards,

- 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

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 9 Nov 2007 14:49:56 -0800

Hi Vijay,

draft-ietf-sip-eku-00
Overall I think the objectives of this draft are good. However as this draft stands I don't see how products conforming to this draft could be deployed because it does not lay out guidance on how to deal with the body of  certificates and products deployed today. There are also a few places where this draft seems to be impinging on rfc3280 which need to be clarified what you actually mean. Also while under some circumstances it may be desirable to restive usage to SIP, it is equally desirable to coexist with other applications on the same server. For many deployments, users will have more than one application on a server and want to get a single certificate for that server which meets the needs of all the services on the server, not just sip. I don't see how that works with this draft.

Setting the EKU extension to be critical.
Setting this extension to be critical will not have the effect you describe and will likely case interoperability problems and should be removed as a requirement. RFC3280 requires conformant applications to recognize the EKU extension. It further requires to only reject critical extensions it does not recognize. It also exempts applications from recognizing all EKU purposes. There is a body of SIP applications who are conformant to 3280 and therefore recognize the EKU extension but do not recognize this new purpose, all of whom would still accept the certificate if there was another EKU in the certificate they did recognize. The behavior of the applications would be totally driven by the presence\absence of the purposes of interest in the extension and not by the criticality of the extension.

EKU usage
This draft does not define behavior with respect to the id-kp-serverAuth purpose which is the most widely deployed today. The presence of the "and" clause with the current text also effectively ignores the id-kp-anyExtendedKeyUsage and should be removed. The id-kp-anyExtendedKeyUsage purpose means any and should be respected. I would suggest the following text for 4.1

The Extended Key Usage extension does not exist, the certificate is valid for SIP usage. It is a matter of local policy to accept certificates with no EKU extension as valid for SIP usage. If the extension exists, it MUST be examined to determine whether or not the certificate is valid for SIP usage:

   o  If the certificate contains the id-kp-anyExtendedKeyUsage purpose the certificate MUST be accepted as valid for SIP usage.
   o  If the certificate contains the id-kp-sipDomain purpose the certificate MUST be accepted as valid for SIP usage.
   o  If the certificate contains the id-kp-serverAuth purpose the certificate SHOULD be accepted as valid for SIP usage It is a matter of local policy to accept the certificate.
   o  If the EKU extension exists but does not contain the above purposes then the certificate MUST be rejected as valid for SIP usage.

A summary of the logic flow for peer certificate validation follows:

1.  If there is no EKU extension and local policy allows accept the certificate.

2.  If the EKU extension is present and contains id-kp-anyExtendedKeyUsage accept the certificate.

3.  If the EKU extension is present and contains the id-kp-sipDomain purpose accept the certificate.

4.  If the EKU extension is present and contains the id-kp-serverAuth purpose and local policy allows accept the certificate.

draft-ietf-sip-domain-certs-00
URI to represent Domain Names
I can sympathize why you have taken this approach, but it does seem an error prone path. Scribing special significance due to the presence\absence of the @ character is going to be hard to understand to users. URI is a superset of the allowed characters for DNS so it would be big ask of service provider to ensure the name conforms to just the DNS rules in some instances of URI names in certificates. This would increase support costs due to some certificates having valid names using to URI rules but invalid under DNS rules.
Have you considered just defining a new SAN name to represent SIP domains. I know some folks will moan at that suggestion but having a new name type would allow stronger and simpler typing for content and would be less ambiguous for applications or service providers. Email domains have a similar problem and it would be nice to come up with a common model.

Hosting and service providers
This draft does not address the needs of hosting and service providers. If a hoster is responsible for 1000's of domains, it's totally impractical to consider having 1000's of names in a certificate or to have 1000's of certificates available on a server. You need some kind of delegation model and preferably without local configuration so it can be automated and therefore scale. Have you looked at some delegation models for SIP? Email again has the same problem without a good solution today so it would be good to come up with a common solution.

Trevor

* -----Original Message-----
* From: [email-masked] [mailto:owner-ietf-
* [email-masked]] On Behalf Of Vijay K. Gurbani
* Sent: Thursday, November 08, 2007 9:38 AM
* To: [email-masked]
* Cc: Scott Lawrence
* Subject: sip-eku and sip-domain-certs drafts
*
*
* Hello:
*
* For a good part of this year, Scott Lawrence and I have been working
* on the usage of X.509 certificates in SIP TLS connections.  As part
* of that work, we have solicited -- and received excellent -- advice
* from the PKIX WG on related issues (many thanks!).
*
* The PKIX-related parts of the work has been defining a key usage
* extension that identifies the holder of the certificate as
* authoritative for a SIP service in a domain, and the interpretation
* and usage of identities stored in a X.509 certificate when used
* for SIP.
*
* The original draft that was reviewed by the PKIX WG was
* draft-gurbani-sip-domain-certs.  When this work was adopted as
* a SIP WG deliverable, we split the draft into two.  One of these
* drafts -- draft-ietf-sip-eku -- discusses EKU extension.  A
* companion draft -- draft-ietf-sip-domain-certs -- describes
* how to use identities in X.509 certificates and perform mutual
* authentication between two SIP domains.
*
* Now that the ideas and the work has been fully fleshed out, we
* would kindly like to solicit a final review from PKIX on these
* documents.  The URLs are:
*
* http://tools.ietf.org/html/draft-ietf-sip-eku-00
* http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt
*
* Thank you in advance for your time and attention to this.
*
* Regards,
*
* - 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