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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 01:29:09 -0400

Vijay,

A few comments on the draft.

Firstly, I think the draft mixes authentication and authorization. You 
spend a bunch of time talking about checks that a server makes when 
receiving a request from a client, comparing bits of the SIP message to 
the TLS certificate. To me, all of those checks are authorization, not 
authentication. TLS mutual auth has done what its name suggests - it has 
already authenticated the other side. Now you are trying to figure out 
whether they are authorized to send you a SIP request. I think these are 
quite separable.

For example, if my proxy has a policy about only connecting to specific 
other domains, then it can take the identities determined from TLS 
mutual auth and use those to decide whether to accept requests coming 
from that proxy. No need to every look at the via, record-route or whatever.

More importantly though, I'm not at all sure that the Via based check 
you are suggesting adds any value. The value in the Via header is almost 
never used for anything. Its certainly not used for sending requests in 
the reverse direction. Its only used if the server needs to open a 
connection to the client to send a response - an extremely rare case. 
Thus, it seems futile to verify the value of a field that is never used 
for anything.

Indeed, I'm not at all sure that this whole concept of verifying the 
client certificate against fields in the SIP request message makes any 
sense at all. Validaing the Via is almost completely pointless as I 
mention above. Record-route, which at first glance seems better, won't 
work either since the proxy might not have record-routed. From doesn't 
work due to retargeting and also in networks where there are multiple 
proxies in the terminating domain.

Thinking about this some more, I think connect-reue has got the 
validation model wrong. Its not about validating that the client is 
authorized to send this request. Rather, what you want to demonstrate is 
that connect-reuse has security that is equivalent to the 'normal' 
connection-in-each-direction model. The way you do that is as follows.
Consider proxies A and B. A opens a connection to B, and provides a 
certificate. B caches the certificate and associates it with that 
connection. B also adds the entries to the alias table as your draft 
suggests. However, it does not attempt to validate the incoming SIP 
request against the certificate at all.

Now, when B needs to send a request in the reverse direction, it looks 
up the r-uri/route in DNS, gets the IP/port, and checks the alias table 
as you have described. If it finds a match, it checks the cached 
certificate for that connection. The trick is - that certificate had 
better look exactly like what it would have looked like if B had opened 
a new TLS connection towards A to send that request. In particular, the 
r-uri/route domain had better be a match for the SAN in the cached 
certificate. If its a match, the request is sent over the connection. If 
not, a fresh connection is opened.

This validation model has the desired property; a request gets delivered 
in the reverse direction with connect-reuse only if it would have been 
delivered had connect-reuse not been used.

This has the benefit of making certificate validation in SIP always look 
like the existing web-model of client to server connections only. This 
simplifies the work that domain-certs has to do. It merely needs to give 
guidance on how the server certificate should look like, addressing the 
two main things EKR mentioned:

1. what field does the identity get coded into
2. what does that identity represent - the specific host or the domain

My two cents is, I think it should always just be the domain 
(example.com and not proxy2.example.com). Thus if you connect to 
proxy2.example.com, and the server provided a certificate for 
example.com, that would be OK. This handles the record-routing use case 
you mention in the draft and works for server farms and TLS offloaders.

I also think its highly unlikely that a cerificate authority would hand 
out certs that verify that a *host* is proxy2.example.com. How would a 
CA verify that this is true?

Hope this makes sense,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Sun, 09 Jul 2006 00:44:06 -0500

> A few comments on the draft.

Jonathan: Thanks for reviewing the draft.  More inline.

> Firstly, I think the draft mixes authentication and authorization. 
> You spend a bunch of time talking about checks that a server makes 
> when receiving a request from a client, comparing bits of the SIP 
> message to the TLS certificate. To me, all of those checks are 
> authorization, not authentication. TLS mutual auth has done what its
>  name suggests - it has already authenticated the other side.

To me, the term "mutual authentication" implies that the
client authenticates the server, and the server authenticates
the client.  As it exists today, TLS mutual authentication
in SIP does only the former, not the latter.

> Now you are trying to figure out whether they are authorized to send
> you a SIP request. I think these are quite separable.

They may be separable, but rfc3261 conflates these.  When
the server asks a certificate of a client, rfc3261 expects
the server to match the domain in the certificate to the
"domainname" portion of the From header.  I am trying to
tease this out and better specify it from an implementation
point of view.  Due to retargetting, using the From is
pointless.  R-R is optional, so that only leaves the Via
header.  However, the identity of the client in the Via header
is usually in the form of a FQDN, whereas the certificate
from the client will normally only contain a domain.

> For example, if my proxy has a policy about only connecting to 
> specific other domains, then it can take the identities determined 
> from TLS mutual auth and use those to decide whether to accept 
> requests coming from that proxy. No need to every look at the via, 
> record-route or whatever.

But what do you do absent such a policy?  A proxy put up on
the Internet by a service provider cannot be expected to know
all the domainsthat will send it a request.  Thus, in the worst
case, it will do minimal authentication on the client certificate:
probably the CA check and the expiry check.  If that iFrom [email-masked] Sun Jul 09 01:46:03 2006
Date: Sun, 09 Jul 2006 00:44:06 -0500
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: Jonathan Rosenberg <[email-masked]>
Subject: Re: [Sip] comments on draft-gurbani-sip-domain-certs-01
Cc: IETF SIP List <[email-masked]>

> A few comments on the draft.

Jonathan: Thanks for reviewing the draft.  More inline.

> Firstly, I think the draft mixes authentication and authorization. 
> You spend a bunch of time talking about checks that a server makes 
> when receiving a request from a client, comparing bits of the SIP 
> message to the TLS certificate. To me, all of those checks are 
> authorization, not authentication. TLS mutual auth has done what its
>  name suggests - it has already authenticated the other side.

To me, the term "mutual authentication" implies that the
client authenticates the server, and the server authenticates
the client.  As it exists today, TLS mutual authentication
in SIP does only the former, not the latter.

> Now you are trying to figure out whether they are authorized to send
> you a SIP request. I think these are quite separable.

They may be separable, but rfc3261 conflates these.  When
the server asks a certificate of a client, rfc3261 expects
the server to match the domain in the certificate to the
"domainname" portion of the From header.  I am trying to
tease this out and better specify it from an implementation
point of view.  Due to retargetting, using the From is
pointless.  R-R is optional, so that only leaves the Via
header.  However, the identity of the client in the Via header
is usually in the form of a FQDN, whereas the certificate
from the client will normally only contain a domain.

> For example, if my proxy has a policy about only connecting to 
> specific other domains, then it can take the identities determined 
> from TLS mutual auth and use those to decide whether to accept 
> requests coming from that proxy. No need to every look at the via, 
> record-route or whatever.

But what do you do absent such a policy?  A proxy put up on
the Internet by a service provider cannot be expected to know
all the domainsthat will send it a request.  Thus, in the worst
case, it will do minimal authentication on the client certificate:
probably the CA check and the expiry check.  If that is the expected
behavior, then we ought to proscribe it in a form that
implementors can understand and code to.  Today, no such text
or guideline exist.

> validation model wrong. [...] This validation model has the desired 
> property; a request gets delivered in the reverse direction with 
> connect-reuse only if it would have been delivered had connect-reuse 
> not been used.

Thanks; this'll be added to connect-reuse.

> This simplifies the work that domain-certs has to do. It merely
> needs to give guidance on how the server certificate should look 
> like, addressing the two main things EKR mentioned:
> 
> example.com, that would be OK. 

This works fine for majority of the cases where the client
authenticates the server, i.e., client has a R-URI of
"sips:[email-masked]" and the server certificate asserts
an SAN identity of "DNS:example.com".  The corner case where
there is a problem is the case where the client follows a R-URI of
"sips:[email-masked]" and gets a certificate
saying "DNS:example.com".  Is downtown a subdomain?  If so,
is example.com authorized to present a certificate for
downtown.example.com?  Or is downtown a host?  In which
case, it would be trivial for the certificate to have an
additional DNS name matching that host.

The same problem occurs when a client follows a Route
header (sips:proxy2.example.com) and gets a certificate
saying "DNS:example.com".  Is proxy2 a host in example.com?
Or is it a subordinate domain of example.com?

> I also think its highly unlikely that a cerificate authority would 
> hand out certs that verify that a *host* is proxy2.example.com. How 
> would a CA verify that this is true?

The CA will not verify this; I would think it would be upto
the holder of the example.com domain to ensure the integrity
of any additional identities stored in the certificate.

I am curious: my understanding is that a certificate for a
virtual servers may contain multiple domain names in it
(c.f. Identity, Section 13.4: "certificates have varying
ways of describing their subjects, and may indeed have
multiple subjects, especially in 'virtual hosting' cases
where multiple domains are managed by a single application.").
If so, how do CAs do validation of these individual domain
names?

> Hope this makes sense.

Yes, a lot of good comments driving some discussion above...

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)