Subject: RE: [Sip] Certificate authentication in SIP

From: "Steve Dotson" <[email-masked]>
Date: Tue, 3 Jul 2007 14:35:10 -0600

Hi Jonathan, 

The use case we are looking at is where the registrar is separate from
the edge proxy. While the edge proxy could validate the UA has access to
a cert issued by a trusted root, it doesn't necessarily mean the UA has
a valid subscription to network services. The edge proxy may/would not
have access to this type of registration data, thus the need to
authenticate from UA to registrar. The only use case I am aware of is
UAs authenticating directly to registrar's, for these same reasons. 

Steve.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 2:43 PM
To: Dean Willis
Cc: IETF SIP List; DRAGE,Keith (Keith)
Subject: Re: [Sip] Certificate authentication in SIP

Dean Willis wrote:

> Jonathan Rosenberg wrote:
> 
>>Well, I'm going to be contrarian here. I'm not convinced that this is 
>>needed.
>>
>>I think certificate based authentication is a great idea. However, I 
>>am not sure I understand why TLS is not an appropriate solution.
>>
> 
> 
> I think it is very simple why TLS is not appropriate. TLS doesn't work

> across proxies, and would therefore require the edge proxy to do 
> authentication.

So what? I think thats what ought to happen. I'd like to see some
specific use cases where this can't work with the edge proxy performing
the authentication. Keep in mind, we are talking about *certificate*
authentication; that doesn't (by definition) required any kind of
pre-arranged secret - only a common root CA.

-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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 22:38:10 -0400

inline.

Dean Willis wrote:

>> specific use cases where this can't work with the edge proxy 
>> performing the authentication. Keep in mind, we are talking about 
>> *certificate* authentication; that doesn't (by definition) required 
>> any kind of pre-arranged secret - only a common root CA.
> 
> My edge proxy might be provided by MCI, but I might be using a chat 
> service from another provider overseas. This other provider might be 
> willing to trust the certificate for authentication (given that I have a 
> signed cert from MCI, who in turn has a signed CA cert from a recognized 
> op-level CA). However, the chat provider might not be willing to just 
> accept P-Asserted-Identity from MCI as an authentication mechanism, 
> since said provider does not have a trusted peering arrangement with MCI 
> and therefore ANYBODY could spoof my P-Asserted-Identity.

In a case where your chat provider has no relationship whatsoever with 
this edge proxy, for what purpose would you be connecting to it in the 
first place? You should connect directly to your chat provider offering 
the service. Then, if you have a cert - great - authenticate to it using 
mutual TLS.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 22:40:09 -0400

Steve Dotson wrote:
> the edge proxy. 

Sure. I think that is a valid case.

> While the edge proxy could validate the UA has access to
> a valid subscription to network services.

No. But, such a proxy could assert the identity it verified.

> The edge proxy may/would not
> authenticate from UA to registrar. 

You lost me here. With mutual TLS, the client can authenticate itself to 
the edge proxy. The edge proxy can assert the authenticated identity 
towards the registrar, ala P-A-ID or even better, SIP Identity. THe 
registrar then authorizes access, and rejects the request if the user is 
not authorized.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Wed, 4 Jul 2007 01:37:48 -0500

On Jul 3, 2007, at 9:38 PM, Jonathan Rosenberg wrote:

>>> *certificate* authentication; that doesn't (by definition)  
>>> required any kind of pre-arranged secret - only a common root CA.
>> My edge proxy might be provided by MCI, but I might be using a  
>> chat service from another provider overseas. This other provider  
>> might be willing to trust the certificate for authentication  
>> (given that I have a signed cert from MCI, who in turn has a  
>> signed CA cert from a recognized op-level CA). However, the chat  
>> provider might not be willing to just accept P-Asserted-Identity  
>> from MCI as an authentication mechanism, since said provider does  
>> not have a trusted peering arrangement with MCI and therefore  
>> ANYBODY could spoof my P-Asserted-Identity.
>
> In a case where your chat provider has no relationship whatsoever  
> with this edge proxy, for what purpose would you be connecting to  
> it in the first place? You should connect directly to your chat  
> provider offering the service. Then, if you have a cert - great -  
> authenticate to it using mutual TLS.
>

Well, I might be doing "outbound" with my edge proxy in order to get  
some help from it for relaying messaging back through my NAT. Or it  
might be a QoS-controlling proxy ala PacketCable. Or a firewall- 
control-proxy . . .

The chat provider might not just be on the other side of my edge  
proxy, but on the other side of my home serving proxy too. And the  
certificate auth stuff would appear to be able to traverse that proxy  
as well.

--
Dea

---

From: "Steve Dotson" <[email-masked]>
Date: Thu, 5 Jul 2007 15:45:14 -0600

Maybe this is naïve, but doesn't this alter the operator trust model? 

I always envisioned P-A-ID (as an example) as a way for a home network to tell a 3rd party service "trust this one, they are authenticated", as long as the home network and the service had a relationship. Having an edge proxy in a visited domain telling the home network "trust this one" seems to turn things around.

Steve.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 8:40 PM
To: Steve Dotson
Cc: Dean Willis; IETF SIP List; DRAGE,Keith (Keith)
Subject: Re: [Sip] Certificate authentication in SIP

> While the edge proxy could validate the UA has access to a cert issued 
> by a trusted root, it doesn't necessarily mean the UA has a valid 
> subscription to network services.

> authenticate from UA to registrar.

You lost me here. With mutual TLS, the client can authenticate itself to the edge proxy. The edge proxy can assert the authenticated identity towards the registrar, ala P-A-ID or even better, SIP Identity. THe registrar then authorizes access, and rejects the request if the user is not authorized.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 17:57:55 -0400

inline.

Dean Willis wrote:
>>> willing to trust the certificate for authentication (given that I 
>>> have a signed cert from MCI, who in turn has a signed CA cert from a 
>>> recognized op-level CA). However, the chat provider might not be 
>>> willing to just accept P-Asserted-Identity from MCI as an 
>>> authentication mechanism, since said provider does not have a trusted 
>>> peering arrangement with MCI and therefore ANYBODY could spoof my 
>>> P-Asserted-Identity.
>>
>> first place? You should connect directly to your chat provider 
>> offering the service. Then, if you have a cert - great - authenticate 
>> to it using mutual TLS.
>>
> 
> some help from it for relaying messaging back through my NAT.

Why can't you do that with the edge proxy in your home providers network?

> Or it 
> might be a QoS-controlling proxy ala PacketCable. Or a 
> firewall-control-proxy . . .

Ah, well QoS control is much better handled through policy server 
peering than SIP connectivity. And it works for non-SIP things. Why is 
it that SIP is the vehicle for getting QoS in a visited network? Is this 
problem not more generic?

> 
> The chat provider might not just be on the other side of my edge proxy, 
> but on the other side of my home serving proxy too. And the certificate 
> auth stuff would appear to be able to traverse that proxy as well.

I don't follow the picture you have in mind.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 18:03:50 -0400

Steve Dotson wrote:
> I always envisioned P-A-ID (as an example) as a way for a home
> network to tell a 3rd party service "trust this one, they are
> authenticated", as long as the home network and the service had a
> relationship. Having an edge proxy in a visited domain telling the
> home network "trust this one" seems to turn things around.

P-A-ID asserts identity between providers with trust, yes that is true. 
SIP Identity works with lesser degrees of trust, but if you don't trust 
the signing domain, of course it doesn't work.

However, my point is, one of the two following scenarios always apply:

1. the edge proxy is trusted by the home proxy, in which case you can 
use mutual TLS to authenticate the client to the edge proxy, and then 
P-A-ID or SIP Identity from edge proxy to home proxy, *OR*

2. there is no trust at all between visited and home networks. In this 
case, you shouldn't be connectign to a visited proxy in the first place. 
COnnect to the home proxy in your home network. Then, case 1 applies again.

In other words, the entire motivation behind this draft is based on an 
assumption that a client needs to connect to its actual proxy through an 
intermediate proxy that no one trusts. SO many things get broken in that 
model. So, don't do it! This idea of a visited proxy with whom I have no 
relationship, is totally broken. ALl of the reasons people list for 
wanting them, we have far better solutions for (NAT traversal, firewall 
traversal, QoS). I'll note further that QoS can never work in a model 
without trust.

-Jonathan R.

---

From: "Rai, Anupam (Anupam)" <[email-masked]>
Date: Thu, 5 Jul 2007 18:36:17 -0600

(1) Will the the P-A-ID syntax require modification to carry UA's certificate related information (Obtained during mutual TLS) from edge proxy to home proxy or registrar ?
(2) Edge proxy utilizing TLS offloaders.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 3:04 PM
To: Steve Dotson
Cc: IETF SIP List; DRAGE,Keith (Keith); Dean Willis
Subject: Re: [Sip] Certificate authentication in SIP

Steve Dotson wrote:
> I always envisioned P-A-ID (as an example) as a way for a home network 
> to tell a 3rd party service "trust this one, they are authenticated", 
> as long as the home network and the service had a relationship. Having 
> an edge proxy in a visited domain telling the home network "trust this 
> one" seems to turn things around.

P-A-ID asserts identity between providers with trust, yes that is true. 
SIP Identity works with lesser degrees of trust, but if you don't trust the signing domain, of course it doesn't work.

1. the edge proxy is trusted by the home proxy, in which case you can use mutual TLS to authenticate the client to the edge proxy, and then P-A-ID or SIP Identity from edge proxy to home proxy, *OR*

2. there is no trust at all between visited and home networks. In this case, you shouldn't be connectign to a visited proxy in the first place. 
COnnect to the home proxy in your home network. Then, case 1 applies again.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 21:32:43 -0400

Rai, Anupam (Anupam) wrote:
> 
> (1) Will the the P-A-ID syntax require modification to carry UA's
> certificate related information (Obtained during mutual TLS) from
> edge proxy to home proxy or registrar ? 

Yes. You'd get nothing but the identity. Do you need more?

> (2) Edge proxy utilizing TLS

The offloader would need to pass the identity to the server. If it acted 
as a simple SIP proxy in addition to doing TLS offload, it would work 
fine. There are other non-standard ways of passing this identity also.

-Jonathan R.

---

From: "Rai, Anupam (Anupam)" <[email-masked]>
Date: Thu, 5 Jul 2007 20:27:21 -0600

inline

> Sent: Thursday, July 05, 2007 6:33 PM
> To: Rai, Anupam (Anupam)
> Cc: Steve Dotson; IETF SIP List; DRAGE,Keith (Keith); Dean Willis
> > certificate related information (Obtained during mutual 
> TLS) from edge 
> > proxy to home proxy or registrar ?
> 
[Anupam Rai]
Identity as asserted by certificate presented by UA during mutual TLS or
identity as established by edge proxy after consulting some
authentication service/database ?
> The offloader would need to pass the identity to the server. 
> If it acted as a simple SIP proxy in addition to doing TLS 
> offload, it would work fine. There are other non-standard 
> ways of passing this identity also.
> 
> -Jonathan R.
> 
> 
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 22:37:54 -0400

inline:

> authentication service/database ?

As asserted by the certificate. In other words, the edge proxy would 
validate the client cert, extract the subjectAltName which presumably 
has something like [email-masked] somewhere and then shoves that into a 
P-Asserted-ID. Or if it matches the From it would use RFC 4474 and sign 
the request.

-Jonathan R.

---

From: "Rai, Anupam (Anupam)" <[email-masked]>
Date: Thu, 5 Jul 2007 21:02:48 -0600

inline 

> Sent: Thursday, July 05, 2007 7:38 PM
> To: Rai, Anupam (Anupam)
> > Identity as asserted by certificate presented by UA during 
> mutual TLS 
> > or identity as established by edge proxy after consulting some 
> As asserted by the certificate. In other words, the edge 
> proxy would validate the client cert, extract the 
> subjectAltName which presumably has something like 
> [email-masked] somewhere and then shoves that into a 
> P-Asserted-ID. Or if it matches the From it would use RFC 
> 4474 and sign the request.

[Anupam Rai]
It would be nice to include some more information related to certificate
presented by UA. At a minimum identity of the UA's certificate issuer is
required.

---

From: Dean Willis <[email-masked]>
Date: Mon, 09 Jul 2007 01:35:06 -0500

Jonathan Rosenberg wrote:

>>> with this edge proxy, for what purpose would you be connecting to it 
>>> in the first place? You should connect directly to your chat provider 

You might do that with the edge proxy in your home provider's network. 
But that doesn't mean thet your 3rd-party service provider trusts the 
authentication service provided by your home provider's network.

>> Or it might be a QoS-controlling proxy ala PacketCable. Or a 

Probably. But as I recall, PacketCable does it with SIP.

> I don't follow the picture you have in mind.

Clearly.

Imagine a "home network" consisting of an edge proxy and a home service 
proxy. Imagine a 3rd party service that is NOT in a trust relationship 
with the "home network". How does that 3rd party service validate the 
identity of a user?

Options include:

1) Do a conventional SIP authentication using digest or basic, both of 
which have issues we understand.
2) Trust the P-A-ID (which we've exluded by definition, since we don't 
trust it).
3) Use AIB (which doesn't exist, and we might have just excluded by 
definition as well).
4) Use certificate authentication as proposed.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 09 Jul 2007 01:37:56 -0500

> COnnect to the home proxy in your home network. Then, case 1 applies again.

Wrongo.

3) There is no trust between the edge proxy and the 
point-of-service-delivery (which MIGHT be a proxy, or might not, and we 
don't know and don't care). But you have to use the edge proxy, because 
it's the only one that can get you out of your little 
nat/firewall/whatever administrative island.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 09 Jul 2007 01:39:23 -0500

> (2) Edge proxy utilizing TLS offloaders.

Also an excellent example, and one I've seen come up in real-world 
planning discussions.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 09 Jul 2007 01:44:49 -0500

> fine. There are other non-standard ways of passing this identity also.

Let's just say that we're aware of commercial TLS concentrators from a 
certain vendor (who might ostensibly be said to fund your participation 
in this forum) that are both very popular and that DO NOT HAVE this 
functionalility and aren't very likely to get it (after all, why would 
you wish to reduce their performance by a factor of 50 or so to start 
parsing SIP messages?). Finding a way other than basic or digest to 
authenticate across them would be very nice, and would be very likely to 
ramp up the deployment of SIP/TLS.

--
Dean