Subject: [Sip] identity-coexistence: the value of signatures

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 22:03:11 -0400

I have on my long list of drafts to revise before the deadline, the 
identity-coexistence draft:

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexistence-00.txt

There was a good thread back in August on this topic, driven off on some 
comments by Cullen. Here is the thread URL if you are interested:

http://www1.ietf.org/mail-archive/web/sip/current/msg14996.html

There were a few issues in this thread, but the biggest byfar is the 
issue of what to do in transit domains that have b2bua which modify the 
Contact or SDP, invalidating the signature. Consider, for example, a 
chain of domains A->B->C->D. The caller is in A.com and the called party 
in B.com. The From header field of sip:[email-masked] is signed by a proxy 
in A.com. It goes through two transit providers B and C prior to 
reaching D. If a b2bua in B or C are B2bUA the signature is invalidated.

One proposal, that I think Cullen was arguing for unless I am mistaken, 
was that if B modifies the message it resigns using its own cert. C 
receives this, and if it trusts B it would resign with its cert too. 
Then it arrives at D, who of course trusts A and so resigns it with its 
own cert. THen, the idea is that teh UAS is configured to accept a 
signature even if the domain in the cert doesn't match the From domain, 
if the cert is from a configured list of good domains, which typically 
is just one domain - its own, D.com.

Hadriel posted in reply that if you do this, why bother with SIP 
identity? May as well use P-Asserted-ID since you are back to transitive 
trust. And indeed I have to agree with this. The reason I felt that SIP 
identity is superior to P-Asserted-ID is that I, in the terminating 
domina, know exactly who the originating domain was, and I could use 
that information to plug it into black/white lists, authorization rules, 
and so on, to decide whether to accept the call.

The canonical use case I have for this is a call from spammers.com, who 
gets service from their provider littlecountry.com, who gets service 
from biginterconnectprovider.com, which connects to my own provider, 
myprovider.com. Though there IS in fact transitive trust at each hop, 
the net value of P-Asserted-ID is nil here. The reason is that the value 
of P-Asserted-ID is equal to the trustworthiness of the LEAST 
trustworthy provider in the chain. In a transit situation, this 
exponentially approaches zero. However with SIP identity, I can directly 
determine that this is coming from spammers.com and look them up in 
sipspamhaus.org and reject their calls as a matter of local policy.

So if you emloy resigning at each transit hop, you will basically 
eliminate all of the benefit that SIP identity brings to the table, and 
I think thats bad.

Consequently, unless the transit is something like an anonymizing 
provider (and there are legitimate use cases for it), which purposefully 
masks identity and resigns, then *SIP IDENTITY DOES NOT AND CANNOT WORK 
THROUGH TRANSIT B2BUA*. That is the cost of the increased security we get.

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: "Henry Sinnreich" <[email-masked]>
Date: Tue, 17 Oct 2006 06:32:02 -0700

This is an excellent protocol centric argument about not trusting
intermediaries for identity and security. Not to mention what evil
intermediaries or compromised intermediaries can do. 

Thanks, Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 9:03 PM
To: IETF SIP List
Subject: [Sip] identity-coexistence: the value of signatures

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexist
ence-00.txt

masks identity and resigns, then *SIP IDENTITY DOES NOT AND CANNOT WORK 
THROUGH TRANSIT B2BUA*. That is the cost of the increased security we
get.

Thanks,
Jonathan R.

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 18 Oct 2006 10:01:14 +0200

Dear all,
With regard to the following section I have some concerns regarding the
thought use of the P-Asserted-Identity.

4.3.  Ingress Proxy

....  If the identity
   is verified, the ingress proxy SHOULD insert a P-Asserted-ID header
   field containing the identity contained in the From header field of
   the request.  The proxy SHOULD NOT remove the Identity and Identity-
   Info header fields.  This allows for SIP networks where there are
   more than two administrative domains in a request path, and also
   allows for a UA to verify the signature on its own if it should
   desire....

This will violate the use of the From and P-Asserted-Identity header
within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping
with the PSTN.

The P-Asserted-Identity is used as a public ID that is trusted. The From
header is set by the user itself and is untrusted. So that there is the
possibility to have two different identities within one INVITE.
To equalise such identities within a B2BUA at the ingress even if the
>From is also a now secure and trusted ID.

Within the NGN this two identities are used for PBX services to present
the main PBX number and a individual extension of the PBX.

Also the deletion and re-inclusion is against the rules of the RFC3325.
The destination domain is not allowed to change the identity of the
originating domain.

If such procedures will be done also charging and billing mechanisms
used between domains will be violated. because the P-Asserted-Identity
is the base identity of the origin domain on Billing and charging.

Best Regards

Roland

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 09:30:21 -0400

Roland's comments below are a reflection of a general issue about the 
semantics of identity that seems to be brewing.

On one hand we have a set of people who are trying to restore the lost 
usefulness of the From header, by providing a way to prove its validity 
as an identity.

On the other hand we have a different set of people who *like* the fact 
that From is an unauthenticated assertion of identity, and want to keep 
it that way.

Or do I have the latter wrong? Maybe its ok if From gets authenticated 
as long as there is still a way to have another asserted identity as well.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Oct 2006 10:28:12 -0400

Well, this harkens back to my rant during the last IETF meeting. My 
point was that this usage of both P-A-ID and From you are describing is 
not the semantics implied by RFC 3325 or RFC 3261, but rather a 
"decision" by 3gpp, ITU and others to use PAID as a billing identity.

Indeed I quote RFC 3325:

9.1 The P-Asserted-Identity Header

    The P-Asserted-Identity header field is used among trusted SIP
    entities (typically intermediaries) to carry the identity of the user
    sending a SIP message as it was verified by authentication.

To me, the "identity of the user sending a SIP message" is NOT the 
"identity of the entity that will be billed for this request". It means 
as it says - it is the identity of the *user* that *sent* the request.

Quoting from RFC 3261:

8.1.1.3 From

    The From header field indicates the logical identity of the initiator
    of the request, possibly the user's address-of-record.

These are identical definitions, the only difference being the term 
'logical', which is implied I think in any system that assigns 
identities to users.

I would like to understand how one can interpret these texts to mean 
that P-A-ID is a billing identity while From is the user's identity.

-Jonathan R.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Oct 2006 10:58:39 -0400

I've wondered about this myself.

Further, I don't want to foster interdomain use of P-A-I without the kinds
of "Trust Domain" specifications 3325 discusses.  I think we have the
problem now where most people ignore most of these issues in using P-A-I.

I'm particularly distressed by the use of P-A-I to assert the Main Number.
If we need such a facility, we should create one, and allow SIP Identity to
validate it.

I'd really like us to be thinking that we phase out P-A-I when Sip Identity
is deployed.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 9:30 AM
> To: Jesske, R
> Cc: [email-masked]; [email-masked]; Seibel,Matthias
> Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt
> furthercomments
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 11:01:51 -0400

OK, I'm sorry. This draft *does* talk about removing the P-A-ID. I was 
thinking of the discussion about connected identity which has been 
loosely associated with this.

What this draft doesn't do is relate its use of P-A-ID with the Privacy 
header, and specifically Privacy:id.

The action it specifies for an egress proxy can cause the P-A-ID to be 
removed in cases where a proxy conforming to 3325 would leave it in.

I am inclined to agree with Jonathan about how things ought to work. But 
I do think it can be arranged so that the two approaches can be made to 
coexist. Its all a matter of defining a suitable policy around the 
interaction of these two mechanisms.

If an egress proxy (P-CSCF) discovers that P-A-ID doesn't match From, 
and if there is no Privacy:id header, it can simply leave P-A-ID in the 
requeest. If an ingress proxy finds a P-A-ID and the message is received 
from a source it trusts, it could leave that in the message and not 
attempt to verify any Identity header.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 11:05:36 -0400

> I'd really like us to be thinking that we phase out P-A-I when Sip Identity

While this sounds nice in theory, I'm concerned that the computational 
cost of using this will be prohibitive for some time to come. If it can 
be restricted to inter-domain calls then the cost is reduced, on 
average. But I don't have any hard performance numbers on this, so I am 
willing to be convinced otherwise.

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Oct 2006 08:30:46 -0700

Paul Kyzivat wrote:

> cost of using this will be prohibitive for some time to come. If it 
> can be restricted to inter-domain calls then the cost is reduced, on 
> average. But I don't have any hard performance numbers on this, so I 
> am willing to be convinced otherwise.

I can't speak for the actual complexity of sip-identity, but I have a 
lot of experience with
DKIM which is similar computationally. Moore's Law has basically made this a
non-issue. At Cisco, we've deployed DKIM internally to sign all of our 
mail and
the cost/mail is minimal cpu-wise. We likely could have deployed on our 
existing
hardware as Y! did for their deployment of DK, but it was easier/safer 
to isolate
it into its own boxen that drove that decision, not the cpu cost.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Oct 2006 12:56:29 -0500

On Oct 18, 2006, at 8:30 AM, Paul Kyzivat wrote:

> Roland's comments below are a reflection of a general issue about  
> the semantics of identity that seems to be brewing.
>
> On one hand we have a set of people who are trying to restore the  
> lost usefulness of the From header, by providing a way to prove its  
> validity as an identity.
>
> On the other hand we have a different set of people who *like* the  
> fact that From is an unauthenticated assertion of identity, and  
> want to keep it that way.
>
> Or do I have the latter wrong? Maybe its ok if From gets  
> authenticated as long as there is still a way to have another  
> asserted identity as well.
>
> 	Paul
>

I'd like to assert that a third camp exists -- those who feel that  
From: and To: have gotten so confabulated that it is best to populate  
them with random haiku.

I believe this relates back to the usage of From and To tags and  
transaction matching rules. Once we moved transport-state into these  
application-layer features, we greatly reduced their utility from an  
application perspective. Something on my wish list for sip 3.0 . . .

--
Dean

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 18 Oct 2006 20:03:18 +0200

> that P-A-ID is a billing identity while From is the user's identity.

The P-A-ID is per definition within 3GPP the public user identity. So also user identity.
Why public Identity, because it was verified by an public (operator) entity.
So the user can be reached by this P-A-ID. So it is the identity of the user sending the message, but it was included by the network.
For what should we use such an asserted identity? 
Of course presenting the identity to an destination user is one use.
And since the Identity is trusted of course it is ideal to write Call Data Records. For Billing and accounting purposes. If I not use the P-A-ID what should I use for that? And as far as I know that was also discussed when the P-A-ID was defined.

As far as I know IETF is defining protocol tools that are used in a generic manner and that are not bind to specific uses. So P-A-ID is used in such an generic manner for:
Originating Identification Presentation, Billing, Call Barring services, as criteria for allowing services ect.

Also in RFC4474 is mentioned:
 RFC 3325 [12] defines the "id" priv-value token, which is specific to
   the P-Asserted-Identity header.  The sort of assertion provided by
   the P-Asserted-Identity header is very different from the Identity
   header presented in this document.  It contains additional
   information about the sender of a message that may go beyond what
   appears in the From header field; P-Asserted-Identity holds a
   definitive identity for the sender that is somehow known to a closed
   network of intermediaries that presumably the network will use this
   identity for billing or security purposes.
   ...

So it is here also mentioned for what purposes the P-A-ID is used for. And many people looked over this wording as far as I know. How came this people to this assumption?

>From header in the past was a user provided header and therefore not useful for billing at least. But back to the issue.

The From header is a user provided identity (because put in by the sending UA) that is also reflecting the identity where the request is coming from.
The user could set every identity in where he is reachable with his device. So if he has 10 devices at home so he had a couple of addresses possible. Of course such identities could be also used as public identities if configures by the asserting entity. But within some domains(like the IMS) this could lead to more complexity than needed. So this other identities will be handled as private identities that can be set by the user and in addition the P-A-ID will be set as a public one. With all the advantages as mentioned above.

Such a behaviour is also used within the PSTN/ISDN for entities called PBX.  With equal principles one asserted identity where you can reach at least the device sending the initial request. And a private identity reaching a special extension.

This principles were discussed also several times on different IETF lists. Based on this assumptions the interworking with the PSTN/ISDN was defined and also services within the IMS.

Based on this I was pointing to these facts that should be taken into consideration within your draft. So at least coping information from a FROM header into the P-A-ID without looking into the P-A-ID and the existing trust relationship of the sending domain. Ideally or at least in many cases the content of the From header would be equal to the content of the P-A-ID. And of course the P-A-ID can be deleted if received from a untrusted domain.

What I'm assuming that your document should show is a possibility to generate a P-A-ID in case the calls enter a trusted domain where a the P-A-ID is needed and not included within the Request and the From is authenticated due to the rules of RFC4474. And vice versa if possible. 

Best Regards

Roland 

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Mittwoch, 18. Oktober 2006 16:28
> An: Jesske, Roland
> Cc: [email-masked]; Jacobsohn, Dieter; Seibel, Matthias
> Betreff: Re: 
> [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments
> 
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Oct 2006 13:49:30 -0500

On Oct 18, 2006, at 1:03 PM, Jesske, R wrote:

> And since the Identity is trusted of course it is ideal to write  
> Call Data Records. For Billing and accounting purposes. If I not  
> use the P-A-ID what should I use for that? And as far as I know  
> that was also discussed when the P-A-ID was defined.

I think it is reasonable to base accounting on P-A-ID or other  
expression of sender identity if that's your business agreement.  
OTOH, you might also consider "collect calls" and things like that  
which might effect other business arrangements. All of this is  
outside the IETF's scope.

On the other hand, redefining the usage such that P-A-ID indicates  
the billing identity instead of sender identity would be a Bad Thing,  
and it would certainly be within IETF's scope to say so.

--
dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 19 Oct 2006 14:34:41 -0500

You don't trust Proxies for the identity etc, but for cipher-suites,
encryption etc group argued that we need to trust the proxies without
any verification.

Thx
Samir

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2006 6:32 AM
> To: Jonathan Rosenberg; IETF SIP List
> Subject: RE: [Sip] identity-coexistence: the value of signatures
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 19 Oct 2006 17:09:55 -0700

> You don't trust Proxies for the identity etc,

That's right; you don't trust them for anything, especially when your
fortune or life is at stake.

Thanks, Henry

-----Original Message-----
From: Samir Srivastava [mailto:[email-masked]] 
Sent: Thursday, October 19, 2006 2:35 PM
To: Henry Sinnreich; Jonathan Rosenberg; IETF SIP List
Subject: RE: [Sip] identity-coexistence: the value of signatures

Thx
Samir

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 20 Oct 2006 12:36:13 -0500

That was my thought too. In encryption etc, with less/no encryption my
life is in danger too. 

Imagine  CEO of Company A is talking to CEO of Company X, with call
pattern tracking etc, CEO of Company B (which is Competitor of A) comes
to know about the talk between A and X and then CEO of B comes to X and
clinches the deal. Size of damage varies as per the size of
Companies...... This is the potential damage from the Call Pattern
Tracking.. I am in danger too for my customers..

This is apart from URI learning etc for the SPAMMERS, which I kept
arguing endlessly on the list...

Thx
Samir 

> Sent: Thursday, October 19, 2006 5:10 PM
> To: Srivastava, Samir (SC100:8826); Jonathan Rosenberg; IETF SIP List