Subject: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jun 2006 09:26:50 -0400

As folks know, we have defined both P-Asserted-ID and SIP-identity. 
Though the intention is for SIP-identity to replace P-Asserted-ID, there 
are a number of practical challenges in doing this. SIP identity 
requires both sides of the call to support it, and it doesn't work at 
all with b2buas with media (whether THAT is a bug or a feature is a 
matter of perspective).

I've written an I-D that describes a pretty straightforward technique 
for allowing both mechanisms to simultaneously co-exist. Its backwards 
compatible with rfc3325 and works in the presence of b2bua's under many 
(but not all) conditions. The essential idea is to use SIP identity 
inter-domain and P-Asserted-ID intra-domain. Until it appears in the 
archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-coexistence-00.txt

Thanks,
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: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jun 2006 19:34:59 -0400

Jonathan,

I really agree we need something more or less like this to arrive at a 
practical and workable identity solution. I had been thinking (vaguely) 
of something like this, but never got around to clarifying my thoughts 
and writing them down.

I have a few comments from first reading:

- Why should the terminating UA check the identity header. It makes 
sense to do if it wants to distinguish if there was a B2BUA with media 
in the path on the terminating side. But it doesn't distinguish if there 
was one on the sending side. Is there much value in that? Or in 
detecting it at all? I suppose it might in some special cases, but 
knowing such nuances is only useful if they affect the subsequent 
action. Without some sophisticated and likely confusing user interface 
this info probably won't be much use.

- I don't know how much detail is needed here, but depending on topology 
it may not be the edge proxy that does the authentication. It isn't 
important that it be done there. All that is necessary is that the 
P-Asserted-Identity be inserted only after authentication has been done.

- While it is clear that you are trying to tighten up the security of 
identity from what it is in 3325, I'm not convinced that requiring the 
removal of P-Asserted-Identity when receiving a request from another 
domain actually achieves anything. Suppose it were left in? That means 
that if some server along the path was bad or inept the assertion might 
be a lie. But a bad or inept server in the originating network, before 
signing, can also result in an assertion that is a lie, and then result 
in a signature for that lie, and then to that being trusted in the 
terminating network.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jun 2006 22:13:09 -0400

inline.

> this info probably won't be much use.

I had in mind that the UA might like to make sophisticated policy 
decisions that would reqiure sip-identity; but thinking about this more, 
as long as the UAS is sure that the terminating network verified the 
identity, everything it needs for policy checks is in P-Asserted-ID - 
the domain and identity of the requestor. So perhaps you are right and 
there is no point.

> P-Asserted-Identity be inserted only after authentication has been done.

Right.

> in a signature for that lie, and then to that being trusted in the 

The main point is that I am trying to change the scope of P-Asserted-ID 
to intra-domain, and thus by definition any value received from outside 
the domain is meaningless.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jun 2006 09:04:28 -0400

Jonathan Rosenberg wrote:

>> that if some server along the path was bad or inept the assertion 
>> might be a lie. But a bad or inept server in the originating network, 
>> before signing, can also result in an assertion that is a lie, and 
>> then result in a signature for that lie, and then to that being 
>> trusted in the terminating network.
> 

I think this begs the question of what it means for a message flow 
between a sender and a receiver to be "in the domain" vs "outside the 
domain". When sip:edge1.atlanta.com sends a message to 
sip:home3.atlanta.com, how do they decide they are in the same domain, 
and that it is the atlanta.com domain?

Isn't that itself all a matter of trust? Or is there some formal 
definition of it? If it is all a matter of trust, then why is it ok for 
sip:home3.atlanta.com to trust sip:edge1.atlanta.com but not ok to trust 
sip:edge5.biloxi.com?

Are all the atlanta.com servers supposed to be using TLS with mutual 
authentication and certs that say they are in atlanta.com? But then how 
do they prove they are the specific server they claim?

Even in this case, why is it ok to trust the proxies in your own domain 
but not ok to trust those in another domain. Some providers are 
federations of semi-autonomous divisions, but want to appear to be a 
single domain. But that doesn't make them all equally competent. The 
trust of one division by another may not be as great as its trust in 
some other domain.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jun 2006 19:48:48 -0400

I view a domain, in the SIP context, as a set of proxies under single 
administrative control. This is also somewhat loosely defined, I admit. 
The main idea is that, since a single administrative entity manages the 
proxies (configuring them, operating them, etc.), it has complete 
confidence that it knows the precise and absolute conditions under which 
P-Asserted-ID was inserted into the request.

There is trust inter-domain, but knowledge about the configuration of 
the proxy that resulted in insertion of P-Asserted-ID isn't known 
directly - its known indirectly by trusting that the peer domain did its 
job. I think thats different.

-Jonathan R.

Paul Kyzivat wrote:

>>> identity from what it is in 3325, I'm not convinced that requiring 
>>> the removal of P-Asserted-Identity when receiving a request from 
>>> another domain actually achieves anything. Suppose it were left in? 
>>> That means that if some server along the path was bad or inept the 
>>> assertion might be a lie. But a bad or inept server in the 
>>> originating network, before signing, can also result in an assertion 
>>> that is a lie, and then result in a signature for that lie, and then 
>>> to that being trusted in the terminating network.
>>
>>
>> The main point is that I am trying to change the scope of 
>> P-Asserted-ID to intra-domain, and thus by definition any value 
>> received from outside the domain is meaningless.
> 
>

---

From: Shida Schubert <[email-masked]>
Date: Thu, 22 Jun 2006 12:14:48 -0700

Hi Jonathan;

Few comments.

Section 3.3
> If the ingress proxy strips the P-A-ID before it verifies the
SIP-Identity, there shouldn't be a case where you get a P-A-ID
with SIP-Identity that does not verify. If there is, the procedure
in section 4.3 for this is missing.

> I don't understand why P-A-ID + "support for coexist" is better than
P-A-ID alone.

Section 4.3 is missing the behavior of ingress proxy when only
P-A-ID is present.

Section 8.
> Third bullet reads " Makes P-A-ID applicable only in intra-domain.."
I think "only" does not belong here.

Regards
Shida

Jonathan Rosenberg wrote:
> Though the intention is for SIP-identity to replace P-Asserted-ID,
> there are a number of practical challenges in doing this. SIP identity
> compatible with rfc3325 and works in the presence of b2bua's under
> many (but not all) conditions. The essential idea is to use SIP
> identity inter-domain and P-Asserted-ID intra-domain. Until it appears
> in the archives, you can pick up a copy at:
>