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

From: "Mark Watson" <[email-masked]>
Date: Thu, 6 Jun 2002 13:14:36 +0100

Just got back from holiday. Where are we on this one ?

I can see both sides of this argument. The meaning of the 'hint' and of the
'asserted identity within a Trust Domain' are somewhat different, and if one
is confused for the other then this is bad. This would suggest different
headers.

On the other hand, both of these are only as good as your trust relationship
with the entity you received it from - you don't get any information about
the 'trustworthyness' from the name of the header, you get it from your
security relationships/configuration data, as described in the Trust Domain
definition.

The name 'Asserted-Identity' begs the question 'Asserted by whom' to which
the answer is just 'the entity you received it from'. You need more data
(configuration/secure connections) etc. to augment its status to 'asserted
by the Trust Domain'.

So, the semantics of the two headers *in themselves* are the same.

Does giving them different names lull you into a false sense of security
about the P-Asserted-Identity one ?

Finally, P-Suggested-Identity begs the discussion: "Why did you suggest this
identity ? Well, because that's the identity I'd prefer to use. Well, why
didn't you say than then ?"

So, if we must have a separate header, P-Prefered-Identity ??

...Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 05 June 2002 07:49
> To: Cullen Jennings; [email-masked]
> Subject: Re: [Sip] Asserted-Identity - new hint proposal
> 
> 
> 
> > 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:
> 
> I liked one header -- I thought the semantic was pretty good "SOMEBODY
> asserted this identity -- vouch for it or reject it". But at 
> this point
> I just don't care anymore. . .
> 
> --
> Dean
> 
> 
> 
> _______________________________________________
> 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: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2002 12:50:39 -0500

I agree that there is a danger that the short-term work will become the de
facto standard, and that the long-term work will never mature. On the former
point, we have taken some steps to minimize that possibility (it's a P-
header, it has very limited applicability, it is tied to the Trust Domain
model, etc). On the latter point, I've already spent some time trying to
work on the long-term story, and I've received quite a few comments,
suggesting that there is some reasonable interest in this work. Rather than
merely arguing that it will never amount to anything, I'd like to ask you to
help those of us that are interested make this happen.

We also hope to define a way of transitioning from the short-term to
long-term model when both are relatively complete.

Jon Peterson
NeuStar, Inc.

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 10:04 AM
> To: Peterson, Jon
> Cc: 'Michael Thomas'; Cullen Jennings; [email-masked]
> Subject: RE: [Sip] Asserted-Identity - new hint proposal
> 
> 
> 
> 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.
> 
> Peterson, Jon writes:
>  > 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.
>  > 
>  > > 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
>  > >  > 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
>  > >  > 
>  > >  > 
>  > >  > 
>  > >  >

---

From: [email-masked]
Date: Wed, 12 Jun 2002 14:43:55 EDT

>     equivalent transitive trust problems.

To all,

I agree that "long term" probably means "never implemented". Or it means that 
there is never any short-term attempt to achieve what is really needed. I 
have to suspect that one of the purposes of this focus on "long-term" is to 
avoid any useful identification service in the near future. What is needed is 
to realize that, unless the means are defined to provide the currently 
required identification services, SIP can not be used to provide a commercial 
service which might replace the current (inferior?) telephone system.

As a long time participant in the development of the US standards for 
identification/privacy, and watching the discussion here, it occurs to me 
that there is a fundamental difference between the two approaches:

PSTN (US standards) - the goal was to provide a useful identification 
service, while recognizing the need for privacy
IETF - the goal is to provide foolproof privacy, while maybe providing 
identification in some cases.

Just my thoughts.

Mike Pierce
Artel