Subject: [Sip] Comments on draft-gurbani-sip-domain-certs-01

From: EKR <[email-masked]>
Date: Tue, 04 Jul 2006 09:30:58 -0700

It seems to me that this document addresses two issues:

1. What name(s) should appear in certificates.
2. Where they should appear and how they should be encoded.

I'd like to separate these two, on the theory that (1)
is difficult and (2) is bit-mangling.

Let's take a step back and examine first principles: The basic
assumption behind RFC 2818 (and most other uses of TLS) is that you
start with some URI X that you want to dereference. Through some
series of (untrusted) manipulations you end up with a connection to
some endpoint which presents you a certificate C. You then need to
determine whether X matches C. In order for this process to work
properly, X needs to either contain C or there needs to be some
trusted transformation between C and X.

In the Web context, what this means is that if you have a server
farm with A.example.com, B.example.com, C.example.com, etc.
then they all have certificates containing "www.example.com".
This can either be done via key-sharing or can be done by 
issuing them separate certificates that all contain the 
same domain name ("www.example.com").

ISTM that the same situation needs to apply with SIP. If
you're dereferencing <sips:[email-masked]> then the
certificate presented to you needs to either be for a
known (and trusted!) proxy or contain "atlanta.com". Anything
else requires trusting the DNS resolution process, which
isn't generally considered acceptable.

So, this leaves us with the question of whether there should
be multiple names. As I understand S 10, the claimed disadvantages
of a single name are:

   1.  It does not correspond to common TLS usage, which is to use a
       certificate identifying the host.  If proxy.biloxi.com is allowed
       to require that the subject of the certificate contains a DNS
       entry corresponding to the IP address of proxy1.atlanta.com, then
       this in turn requires every authoritative proxy for atlanta.com
       to be registered with the DNS entry atlanta.com.  Hence it is
       impossible for a domain to use different SIP proxies as incoming
       and outgoing proxies.
   2.  It makes forensics in the case of compromise more complex.  If a
       malicious principal is discovered making use of a certificate for
       a private key issued to proxy1.atlanta.com, there is little to
       identify which of atlanta.com's SIP proxies has been compromised.
       If the certificate contains proxy1.atlanta.com's name as well as
       atlanta.com's name, then the forensics are simpler.

I'm not sure what "common TLS usage" is being referred to. As I 
noted above, in my experience HTTPS behaves exactly this way 
(putting the generic domain name and not host name in the
certificate). I agree that it does make forensics more difficult,
but this problem can be solved iwth a separate certificate 
(with a separate serial #) for each host, even if they contain
the same name. There's no need for a second name here.

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 05 Jul 2006 15:01:18 -0500

> 2. Where they should appear and how they should be encoded.

Eric: Thanks much for your analysis.  More inline.

> ISTM that the same situation needs to apply with SIP. If you're 
> dereferencing <sips:[email-masked]> then the certificate presented
> to you needs to either be for a known (and trusted!) proxy or
> contain "atlanta.com". Anything else requires trusting the DNS
> resolution process, which isn't generally considered acceptable.

Yes, the discussion on issue (1) on the mailing list converged
on the same outcome you mention above; i.e., it suffices
that when contacting "sips:[email-masked]", the certificate
presented contains "atlanta.com."

However, it is the specific places where SIP differs from HTTP
in its routing of subsequent requests that is of concern.  For
example: consider a dialog that has been established across a
set of proxies that Record-Routed.  The UAC is now ready to send a
new request:

    UPDATE sips:[email-masked] SIP/2.0
    Route: <sips:proxy.atlanta.com;lr>
    ...

The request will go to "sips:proxy.atlanta.com", the Route URI.
What typically appears in a Route URI is the fqdn of a
certain proxy, as opposed to a URI that we can run rfc3263-
resolution on to derive a candidate host.  In other words,
when sending a request to "sips:[email-masked]", it
suffices to see "atlanta.com" in the certificate.  But what
about the case where the UAC is sending a request to
"sips:proxy.atlanta.com"?

Is it sufficient that when the server presents a certificate
that contains "atlanta.com", this certificate is good for
"sips:proxy.atlanta.com" and "sips:proxy3.atlanta.com" and
for subordinate names like "sips:east.proxy.atlanta.com"?
It very well might be the case that this is sufficient (SIP
Identity alludes to the name subordination problem in Section
13.4).  However, if so, then we should state it as such so that
implementations can built the required logic into their code.

So, what are the guidelines to implementors here for comparison?
As an implementor, should I just do a substring comparison
of the contents of a certificate ("atlanta.com") against the
Route URI ("proxy.atlanta.com")?  Today, I am not sure how
implementors are dealing with such cases.  Any thoughts on
this from you or the WG at large will be much appreciated.

> So, this leaves us with the question of whether there should be 
> multiple names. As I understand S 10, the claimed disadvantages of a 
> single name are:
[...]
> I'm not sure what "common TLS usage" is being referred to. As I noted
> above, in my experience HTTPS behaves exactly this way (putting the 
> generic domain name and not host name in the certificate).

So what, then, does it mean to do "mutual authentication" in
SIP?  RFC3261 states that mutual authentication should occur
across inter-domain requests (Section 26.3.2.2).  It's relatively
easy to authenticate the server, but how should the client be
authenticated?  Consider:

     INVITE sips:[email-masked] SIP/2.0
     Via: SIP/2.0/TLS proxy.biloxi.com;branch=...
     To: <sips:[email-masked]>
     From: <sips:[email-masked]>;tag=98jukss-1
     ...

The client authenticates the server using the established norm
of checking for "atlanta.com" in the certificate.  But the
server has only one piece of authoritative information about
the client: the sent-by value in the topmost Via, which contains
the specific host that sent the request.  This could be any host
in the biloxi.com domain, including a host in a subordinate
domain.  Thus, this case now degenerates to the same scenario we
were discussing above.

RFC3261 exhorts the server to match the certificate presented
from the client to the domainname in the From header.  This
will not work if retargetting is used (please see Appendix A and
B in the draft for more information on retargetting).

Now, it could well be that a combination of deprecating
retargetting outside your domain and SIP Identity is the
preferred means to do mutual authentication in SIP.  And if so,
then we ought to deprecate the portions of rfc3261 that talks
about mutual authentication.

I realize that you will be busy with the impending IETF, but
if you have some time for thoughts on virtual server
certificates (section 8) and server farms (section 7), I'd
much appreciate them as well.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: David R Oran <[email-masked]>
Date: Thu, 6 Jul 2006 19:35:22 -0400

On Jul 5, 2006, at 4:01 PM, Vijay K. Gurbani wrote:

> presented contains "atlanta.com."
Do you mean "the name in the certificate contains the string" or  
"ends with the string" or something else. In other words, does a  
certificate for badboy.atlanta.com.chaoscomputerclub.org match a sip  
uri of sip:[email-masked].

One would think not...

Or do you mean "the name in the certificate is precisely the string  
'atlanta.com'", in which case does the certificate match sip uri's  
registered in a subdomain, e.g. [email-masked].

The "contains" terminology ought to be a bit tighter, no?

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 09 Jul 2006 00:44:03 -0500

David R Oran wrote:
> Do you mean "the name in the certificate contains the string" or  "ends 
> with the string" or something else. In other words, does a  certificate 
> for badboy.atlanta.com.chaoscomputerclub.org match a sip  uri of 
> sip:[email-masked].
> 
> One would think not...

I would hope so as well.

> registered in a subdomain, e.g. [email-masked].

Yes, exactly!  You hit the nail right on the head, Dave.

What should an implementor of a client expect when a
R-URI contains sips:[email-masked] and
the certificate that is received contains "atlanta.com"?
It could, of course, simply close the connection.  But then
again, "downtown" could have been a certain host in the
atlanta.com domain versus a subordinate domain, in which
case, the client may have torn the connection down prematurely.

Are the guidelines that implementors must match exactly
the domainname in the cerificate to the domainname in
the R-URI?  Anything else is considered suspect?

If so, then how do we handle this case of a mid-dialog
request:

     INVITE sips:[email-masked] SIP/2.0
     Route: <sips:proxy1.atlanta.com;lr>
     ...

The proxy (proxy1.atlanta.com) presents a certificate that
asserts "atlanta.com".  What should the UAC do now?
Close the connection?

I think any guidance we provide around these issues is
well worth it if we are to have a semblance of security
in the stacks.

Thanks,

- vijay

ol2)
	id k695i5H22153; Sun, 9 Jul 2006 00:44:06 -0500 (CDT)
Date: Sun, 09 Jul 2006 00:44:03 -0500
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: [email-masked]
Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-01
Cc: IETF SIP List <[email-masked]>

David R Oran wrote:
> Do you mean "the name in the certificate contains the string" or  "ends 
> with the string" or something else. In other words, does a  certificate 
> for badboy.atlanta.com.chaoscomputerclub.org match a sip  uri of 
> sip:[email-masked].
> 
> One would think not...

I would hope so as well.

> registered in a subdomain, e.g. [email-masked].

Yes, exactly!  You hit the nail right on the head, Dave.

What should an implementor of a client expect when a
R-URI contains sips:[email-masked] and
the certificate that is received contains "atlanta.com"?
It could, of course, simply close the connection.  But then
again, "downtown" could have been a certain host in the
atlanta.com domain versus a subordinate domain, in which
case, the client may have torn the connection down prematurely.

Are the guidelines that implementors must match exactly
the domainname in the cerificate to the domainname in
the R-URI?  Anything else is considered suspect?

If so, then how do we handle this case of a mid-dialog
request:

     INVITE sips:[email-masked] SIP/2.0
     Route: <sips:proxy1.atlanta.com;lr>
     ...

The proxy (proxy1.atlanta.com) presents a certificate that
asserts "atlanta.com".  What should the UAC do now?
Close the connection?

I think any guidance we provide around these issues is
well worth it if we are to have a semblance of security
in the stacks.

Thanks,

- vijay