Subject: [Sip] Review of draft-ietf-sip-domain-certs-00

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Mar 2008 09:12:51 -0400

$Id: draft-ietf-sip-domain-certs-00-rev.txt,v 1.1 2008/03/13 12:53:39 ekr Exp $

S 5.
   The problem for proxyB is slightly more complex since it accepted the
   TLS request passively.  Thus, it does not possess an equivalent AUS
   that proxyA did; instead, it uses local policies to consider the
   client authenticated.  The normative behavior for servers is provided
   in Section 7.4.

I don't think this point is necessarily right. It's job is to primarily
to record the claimed identity from the SSL client. Why is this
problematic?

S 6.
   Service providers MAY continue the practice of using existing
   certificates for SIP usage with the identity conveyed in the Subject
   field; however, such usage is NOT RECOMMENDED for new certificates,
   which MUST contain the identity in the subjectAltName extension.

Will standard CAs give you certificates of with SAN set? If not,
this MUST seems to be too strong.

S 7.2.
What's the reason for forbidding wildcards?

S 7.4.
   When a server accepts a TLS connection, it presents its own X.509
   certificate to the client.  To authenticate the client, the server
   asks the client for a certificate.  If the client possesses a
   certificate, it is presented to the server.  If the client does not
   present a certificate, it MUST NOT be considered authenticated.

Is this really true? My understanding was that when proxy servers
thought clients were connecting they did not request client auth,
but rather used digest. Note that a number of clients react badly
when a cert is requested and they don't have one.

S 7.6.
   A SIP registrar, acting as a server, follows the normative behavior
   of Section 7.4.  When it accepts a TLS connection from the client, it
   present its certificate.  Depending on the registrar policies, it may
   challenge the client with HTTP Digest.

See above.

S 7.7.
   Smae comment.

S 7.8.
   The closest guidance in SIP today regarding certificates and virtual
   SIP servers occurs in SIP Identity ([8], Section 13.4).  The quoted
   section states that, "... certificates have varying ways of
   describing their subjects, and may indeed have multiple subjects,
   especially in the 'virtual hosting' cases where multiple domains are
   managed by a single application."

   The above quote is incorrect, in that it implies that one certificate
   can have multiple subjectAltName (or Subject) fields, each
   corresponding to a discrete virtual server that represents a single
   domain; actually, a PKIX-compliant certificate has exactly one
   Subject field and at most one subjectAltName (the subjectAltName MAY
   contain multiple identifiers for the Subject).

I'm not sure this is really contradictory, since it sort of puns on
the word "subject"...

S 7.8.
   The TLS extended client hello [7] allows a TLS client to provide to
   the TLS server the name of the server to which a connection is
   desired.  Thus, the server can present the correct certificate to
   establish the TLS connection.

This seems like it should be a SHOULD.

S 8.
   Authentication:  each principal is authenticated to the other as
      possessing a private key for which a certificate has been issued.
      Moreover, this certificate has not been revoked, and is verifiable
      by a certificate chain leading to a (locally configured) trust
      anchor.

So, TLS doesn't guarantee any properties at all about the cert
validity. It just implies "do something PKIXy"

S 8.1.
I actually agree with this stuff, but I don't think it belongs here.

-Ekr
_______________________________________________
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: Thu, 13 Mar 2008 09:55:18 -0500

Ekr: Will follow up on other things later, however, request
clarification on one thing:

> when a cert is requested and they don't have one.

Is this true; i.e., number of clients react badly when a cert
is requested and they don't have one?  I have used openssl 0.9.8a
with the SSL_CTX_set_verify(g_ctx, SSL_VERIFY_PEER, verify_cb)
API and that seems to work.  The client does not grok if it does
not have a certificate; it will send the server if it does have
one.

Admittedly, I have only used the openssl library and do not know
what other TLS libraries do when the same scenario occurs.

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