Subject: [Sip] Review of draft-gurbani-sip-domain-certs-04

From: EKR <[email-masked]>
Date: Sun, 11 Mar 2007 11:24:02 -0700

$Id: draft-gurbani-sip-domain-certs-04-rev.txt,v 1.1 2007/03/11 18:35:35 ekr Exp $

S 3.

   The two concerns enumerated above correspond to two specific problem
   areas that are currently visible in SIP's use of X.509 certificates.
   First, the contents of certificates must be such that it allows for
   mutual inter-domain authentication; and second, there must be means
   available to allow an upstream SIP host to deterministically "pin" a
   route through one proxy from a farm of downstream proxies.

Once again, I'll note that I'm very skeptical that the pinning
requirement described here is a real one. As I wrote in my review
of -03:

   I'm skeptical that this is really going to be an important scenario.
   If you want to have high availability (and presumably if you run a
   proxy farm you do) you need to have proxy operations either be
   stateless or arrange for state clustering, in which case getting
   something back to the wrong proxy just looks like a cache
   niss. Moreover, once outbound and draft-ietf-sip-connect-reuse-05 are
   deployed, I would expect to see quite a bit of stickiness.

S 4.1.
      Note that a domain name in an X.509 certificates should be
      interpreted only as a sequence of octets that should match the URI
      used to reach the host.  No inference should be made based on the
      DNS name hierarchy.

Why is this text indented? Is it a quote.

S 4.2.
   Suppose, now, that example.com is a large organization that maintains
   several SIP proxies, and normal resolution rules cause her INVITE to

s/her/Alice's/

   The authentication problem for proxyA is straightforward - if we
   assume secure DNS, then proxyA already knows that proxyB is a valid
   proxy for the SIP domain example.net, so it only needs a valid
   certificate from proxyB that contains the fully qualified host name
   proxyB.example.net, or a SIP URI that asserts proxy B's authority
   over example.net domain, i.e., a certificate that asserts the
   identity "sip:example.net".

I don't understand this. The basic premise here (and a good one) is that
you can't trust the DNS. The certificate that B presents MUST
contain example.net

   The problem for proxyB is different, however; it is presented with a
   connection from a specific host, but what it needs to determine is
   whether or not that connection can be treated as coming from a
   particular SIP domain.  If it receives a certificate that contains
   only the name proxyA.example.com, then it cannot determine that
   proxyA is authorized to act as a SIP outbound proxy for example.com,
   because example.com may use different systems for inbound messages so
   SIP DNS resolution of example.com may not lead to proxyA.example.com
   (if this is the case, proxyB should not reuse this connection if it
   needs to send a request to example.com).  The certificate usage in
   SIP should not require that every outbound proxy for a domain must
   also be an inbound proxy for that domain, but should provide for
   certificate based binding of the SIP domain name to a particular
   connection.

I don't understand this claim. For the same reason as I indicated above,
the certificate presented by A must contain example.com. The only
case in which you can plausibly switch from the original URI name to an FQDN
is if you're told to in a trusted fashion, e.g., in some connection
secured with TLS and bound to the original name (and even then
care is required).

S 5.
   As an example, consider that the autonomous domain example.com is
   applying for a certificate from an authority.  As part of the
   certificate request, it will ask the following two identities be
   bound to the generated certificate:  "URI:sips:example.com", and
   "DNS:downtown.example.com".  The latter DNS label provides assurance
   at the transport layer that the the certificate corresponds to a host
   that was the target of the TLS connection, while the former SIPS URI
   binds the holder of the certificate with a domain URI for which it is
   authoritatively responsible.  This information may be subsequently
   used by the application to make authorization decisions of the form
   outlined in Section 26.3.2.2 of RFC3261.

As noted in my previous review, I see no reason for these to have different
prefixes. Have 'em both be SIP or both DNS. SIP, I assume. I'd note
at this point that you presumably need to say what goes in the DN
field...

S 6.
This extension should be a work item in PKIX, IMO.

S 11.

   Is it conceivable that each domain have a distinct certificate that
   is provided to the hosting service?  Certainly, this means that the
   domain must share the domain's private key with the hosting service.
   TLS extensions [10] like the extended client hello allow TLS clients
   to provide to the TLS server the name of the server they are
   contacting.  Thus, the server can present the correct certificate to
   establish the TLS connection.

Exactly the same situation obtains in HTTPS and you should use the
same practices. Again, as noted in my -03 review.

   The appropriate thing here seems to be to follow HTTPS practice. Each
   domain has its own key pair and cert. The hosting service has the
   private key. You use name-based virtual hosting if you can trust
   clients to provide the dns_name. Otherwise you use IP-based.

-Ekr

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Sun, 11 Mar 2007 15:47:39 -0500

> Why is this text indented? Is it a quote.

Supposedly the convention is that "Note" statements in SIP documents are 
  to be indented.

I wasn't aware of this convention, but the last document I submitted 
post-WGLC was returned with a request from the reviewing chair to indent 
(or delete) all of the the "Note" paragraphs.

--
Dean

---

From: EKR <[email-masked]>
Date: Sun, 11 Mar 2007 14:35:05 -0700

Dean Willis <[email-masked]> writes:

> te:
> Supposedly the convention is that "Note" statements in SIP documents
> are to be indented.
>
> post-WGLC was returned with a request from the reviewing chair to
> indent (or delete) all of the the "Note" paragraphs.

Hmm.... So, I think there's a difference between a "Note:" which is
basically our version of a footnote and a graf that just happens
to begin with "Note that...". I'm not sure which this one is, but
IMHO the indenting convention doesn't help with that as much as
you would like....

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Sun, 11 Mar 2007 16:55:28 -0500

> IMHO the indenting convention doesn't help with that as much as

I don't disagree.

I ended up changing most of the "Note that x is . . ." paragraphs to "X 
is", in the draft I recently revised but I don't think it made things 
any clearer.

--
Dean

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 12 Mar 2007 16:12:33 +0100

This was started before my time in RFC 3261, and (at least to me) it seems like a useful thing to follow.

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Sunday, March 11, 2007 8:48 PM
> To: EKR
> Cc: [email-masked]
> Subject: Re: [Sip] Review of draft-gurbani-sip-domain-certs-04
> 
> EKR wrote:
> 
> > S 4.1.
> I wasn't aware of this convention, but the last document I 
> submitted post-WGLC was returned with a request from the 
> reviewing chair to indent (or delete) all of the the "Note" 
> paragraphs.
> 
> --
> Dean
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 12 Mar 2007 16:20:28 +0100

To expand, many SDOs use the SIP documents, and they follow ISO rules
(or a derivitive of same) in handling text. This makes a distinct
difference between normative and informative text.

Text beginning "Note:" is informative text (except under special
conditions which we will not go into here), and cannot contain
requirements, definitions, etc, and do not form part of the main text.

Footnotes are another way of expressing informative text, but in many of
the SDOs these are not preferred.

Based on this, if an author intends the text to be part of the main
document, it is very bad practice to start a sentence with "Note" or
"Note that". RFC 3261 and other SIP documents merely use the indentation
to emphasise that this really is supporting text (informative) rather
than the main text of the document.

Keith

> From: EKR [mailto:[email-masked]] 
> Sent: Sunday, March 11, 2007 9:35 PM
> To: Dean Willis
> Cc: [email-masked]
> submitted 
> Hmm.... So, I think there's a difference between a "Note:" 
> which is basically our version of a footnote and a graf that 
> just happens to begin with "Note that...". I'm not sure which 
> this one is, but IMHO the indenting convention doesn't help 
> with that as much as you would like....
> 
> -Ekr
>