Comments on draft-ietf-sip-domain-certs-00

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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Paul Hoffman wrote:
> 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.

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.

> 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.

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.

> - 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?

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?

> - 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.

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.al
catel-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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

At 11:48 AM -0700 3/26/08, Eric Rescorla wrote:
>At Wed, 26 Mar 2008 10:16:08 -0700,
>Paul Hoffman wrote:
>  >
>>  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
>...snip...
>  > subjectAltName. Because of this, I suggest taking
out this option
>>  everywhere in the document; you'll get much better
interoperability
>>  if you do.
>
>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?

 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.

At 2:40 PM -0500 3/26/08, Vijay K. Gurbani wrote:
>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.

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.

>>- 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?
>
>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?

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
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Eric Rescorla wrote:
> 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?

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:vkgacm.org, email:vkgalcatel-lucent.com
             X509v3 Basic Constraints: critical
                 CA:FALSE

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.al
catel-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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Mar 26, 2008, at 12:16 PM, Paul Hoffman wrote:
>
> - 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.

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

_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

At Wed, 26 Mar 2008 10:16:08 -0700,
Paul Hoffman wrote:
> 
> 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.

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?



> - 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.

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

_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Mar 26, 2008, at 3:33 PM, Paul Hoffman wrote:
> At 11:48 AM -0700 3/26/08, Eric Rescorla wrote:
>> At Wed, 26 Mar 2008 10:16:08 -0700,
>> Paul Hoffman wrote:
>>>
>>> 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
>> ...snip...
>>> subjectAltName. Because of this, I suggest
taking out this option
>>> everywhere in the document; you'll get much
better interoperability
>>> if you do.
>>
>> 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?
>
> 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.

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

_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

At 11:54 AM -0500 3/27/08, Dean Willis wrote:
>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
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

At Thu, 27 Mar 2008 10:39:31 -0700,
Paul Hoffman wrote:
> 
> At 11:54 AM -0500 3/27/08, Dean Willis wrote:
> >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?

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:
> 
>     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.

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

_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

At 12:53 PM -0500 3/27/08, Vijay K. Gurbani wrote:
>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.

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
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip