Subject: RE: [Sip] Asserted-Identity - new hint proposal

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 11 Jun 2002 19:35:19 -0500

Sorry for my delay in responding to this one.

Agreed that identity-based assertions are ultimately better than role-based
assertions - no question. We made a simple scope decision that
identity-based assertion would be a matter for the long-term work, not the
short-term work. 

One of the reasons why we went in this direction was because we didn't feel
that we needed to have multiple P-Asserted-Identity headers in a message (or
more precisely, that we didn't feel we needed to have more than two, one for
a SIP[S] URI and one for a tel URL in support of certain PSTN gatewaying
applications) in order to satisfy the existing requirements. Agreed that
were a need for this to arise, multiple P-Asserted-Identity headers
(especially with different asserted identities) would be somewhat ambiguous.

Another reason why an identity-based approach didn't seem like a good match
for the short-term work is that without cryptographic authentication of the
P-Asserted-Identity header, it is a bit too easy for someone to forge
something like an 'asserted-by' parameter or add falsified
P-Asserted-Identity headers that could mislead downstream entities. You
still need to keep track of trust-based identity (i.e. who sent me this, and
whether I am configured to trust them) in order to learn how much you should
trust the P-Asserted-Identity header(s) in a message. Adding any
cryptographic properties to the header is also outside the scope of the
short-term identity work.

Finally, the short-term work is completely dependent on the concept of trust
domains discussed in Mark Watson's NAI requirements document. It therefore
has some slightly different assumptions about why proxies transitively trust
one another. An assertion from one intermediary in a trust domain is known
to be as good as an assertion from any other, as a trust domain is defined,
so knowing the identity of the particular intermediary that added the header
isn't immediately material. While the applicability of this might seem
limited, there are a number of parties that are apparently interested in
this sort of network.

But that much said, it sounds like your remarks have some applicability to
the long-term identity work, which today has no explicit concept of
transitivity - your suggestions could prove valuable there. I put together a
separate proposal on long-term identity (draft-peterson-sip-identity-00),
and I'd appreciate any comments.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, June 05, 2002 7:36 AM
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: [Sip] Asserted-Identity - new hint proposal
> 
> 
> 
> So, I still haven't heard why the role based
> assertions is better than the alternative of
> identity based assertions. The way it's structured
> now, you seemingly either lose information along
> the way, or have an ambiguous situtation with
> multiple P-Asserted-Identity's. Suppose for
> example that my real name is thomasm, but I
> want to use my alias mat. What I'd do is:
> 
> Asserted-Identity: <sip:[email-masked]>; asserted-by: 
> <[email-masked]>;etc
> 
> At my first hop proxy, it would check to see if
> [email-masked] was an acceptible alias, and if it
> is, it would add a new AI to vouch for me:
> 
> Asserted-Identity: <sip:[email-masked]>; asserted-by: 
> <[email-masked]>
> 
> When it's forwarded to the UAS proxy, it would
> know that it trusts proxy-15's assertions (but not
> thomasm's) and therefore add a new header for the
> UAS:
> 
> Asserted-Identity: <sip:[email-masked]>; asserted-by: 
> <[email-masked]>
> 
> So clear back at luser.mtcc.com we finally get the 
> INVITE and see these asserted-identities:
> 
> Asserted-Identity: <sip:[email-masked]>; asserted-by: 
> <[email-masked]>;etc
> Asserted-Identity: <sip:[email-masked]>; asserted-by: 
> <[email-masked]>
> Asserted-Identity: <sip:[email-masked]>; asserted-by: 
> <[email-masked]>
> 
> The UAS cdr's through the list and discovers --
> aha! -- an asserted identity by [email-masked]
> which it trusts since it's the inbound proxy.
> Therefore, luser.mtcc.com knows that the identity
> it will use for the callerid is the one supplied by
> proxy-22. If proxy-22 didn't insert an
> asserted-identity, it probably means that it
> didn't trust the previous hop, and that the UAS
> should mark the callerid as suspect, if it
> displays anything at all.
> 
> Notice that we don't need "roles" here of UA and
> proxy, but instead uses their actual identities.
> Note also that this could be generally applicable
> for more cases where you need to assert identity
> such as the firewall-proxy traversal case
> especially if it were combined with cryptographic
> proof by the party asserting the identity. It
> would also allow flexibility of _who_ enables
> traversal as well, ie that one of my proxies could
> insert the necessary credentials to get me through
> a foreign proxy instead of the UAC directly which
> would enable aggregation, and separation.
> 
> 	     Mike
> 
> 
> Cullen Jennings writes:
>  > 
>  > I am getting the feeling that people want to put the hint 
> in a separate
>  > header. How would everyone feel about something along the lines of:
>  > 
>  > P-Suggested-Identity: "Cullen Jennings" 
> <sip:[email-masked]>;mandatory
>  > 
>  > The UAC would insert this header to indicate the 
> Asserted-Identity that it
>  > wished the Trust Domain to choose. The "mandatory" 
> indicates that the Trust
>  > Domain MUST return some 4xx response if it is not going to 
> assert this
>  > identity. If the "mandatory" was not present, it would not 
> return an 4xx if
>  > it choose a different identity to assert for the user.
>  > 
>  > Should we go with two headers (PSI and PAI)?
>  > 
>  > Does PSI need some flag (like mandatory) to say how it is 
> handled in the
>  > case the suggested identity is not going to be provided?
>  > 
>  > Alternatively, should we go with one header and the 
> argument that Dean so
>  > nicely summed up as
>  > > I think existence of a P-A-I header in a message means 
> "a previous hop
>  > > (sender or proxy) has asserted this identity. Deal with it."
>  > >
>  > > Options for dealing with it are:
>  > >
>  > > 1) Believe it
>  > > 2) Delete it (in conjunction with "privacy" modifier)
>  > > 3) Delete it and assert a different identity
>  > > 4) Reject the message
>  > 
>  > Thanks, Cullen
>  > 
>  > 
>  > 
>  > 
>  > _______________________________________________
>  > 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
> 

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Wed, 12 Jun 2002 10:04:01 -0700 (PDT)

The problem I see is that for all intents and
purposes longterm > /dev/null. I'm not alone in
this concern, nor is my concern about this without
precedent. The entire structure of this wg seems
to have become how we can best rationalize range
of the moment hacks.

What happened to the mindset of doing the
necessary engineering to generalize what the PSTN
did badly instead of slavishly reproducing its
misfeatures, bug for bug?

	      Mike

PS: you are incorrect about the added vulnerablity;
    without cryptographic proof, both have
    equivalent transitive trust problems.

---

From: [email-masked]
Date: Wed, 12 Jun 2002 21:04:17 +0300

> misfeatures, bug for bug?

this is exactly what 3gpp is doing.  they are trying to re-implement
their existing walled garden with new set of protocols (ip, sip, radius,
etc).  ietf should have no part in such a madness.

-- juha

---

From: Chris Martin <[email-masked]>
Date: Wed, 12 Jun 2002 22:08:46 -0500

> etc).  ietf should have no part in such a madness.

I cant speak for 3GPP (I dont know enough about it) but walled gardens
exist and will continue to exist, out of necessity, for reasons of
security or lack of resources...yada..yada, within many  carrier,
corporate, and SOHO networks. The concepts that I have seen discussed
regarding asserted identity, hints, etc....are valid for any or all of
these infrastructures as well as those that join with one or more
infrastructures to offer enhancements or share resources. Sure maybe the
names could be worked on but the concepts are valid.

From what I have seen 3GPP is adopting SIP and, just as the enterprise
and carriers are trying to fit SIP into their infrastructures while
maintaining the policies that they must enforce in order to meet legal
and protective requirements, and I have seen some very good thoughts and
opinions pour out into this list that will become a necessity for SIP as
well. I am grateful that the topics have been brought out into the open
for discussion now than later.

It is one thing to not desire the re-invention of the PSTN, but
legalities and business policies must be met in the real world by the
entities that will provide the services, whether for profit or not.
These issues exist in the PSTN world but that does not make them
products of the PSTN world. It makes them products of the communications
world that must be met by all communications solutions that are
developed with the goal of attempting to provide the types of solutions
that SIP will be capable of providing now and in the future to everyone. 

To continue to perform nothing more than name calling because "they"
dont conform to your way of thinking is ludicrous. All of these
discussions and attempts to integrate existing architecture (at least
those based on IP for our requirements) furthers the development of SIP
and aids in the devlopment of new ideas.

I want to hear and read more about this and offer what I can when I can,
and hope you will too.

Chris