Subject: RE: [Sip] Asserted-Identity: How to 'hint'?

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 3 Jun 2002 11:25:01 -0500

Well, I for one would be more than happy to deliver the hint with some other
header. The problem is that we're a little short on time. We know from Keith
that 3G and others require this hint on the same time frame as the
short-term identity assertion mechanism. Given that:

- Should the hint mechanism be specified in the same draft as the short-term
identity assertion mechanism? (I for one would like to believe that you
don't need the hint in order to have a trust-based network that manages
identity, so I don't think identity needs to block on defining the hint.
Still, building a new draft might take more time than we have.)

- What do we call the new header? (I think it should be a P- header; I don't
think we should change the name of the existing P-Asserted-Identity header
if we can help it - maybe P-Suggested-Identity for the hint?)

- Does the syntax of P-Asserted-Identity differ from that of
P-Suggested-Identity in any interesting way?

I think we need answers to these questions (and any others that may come up)
by tomorrow - to satisfy the IESG, we need to have the short-term
identity/privacy bundle resubmitted as complete drafts by this Thursday
(6/6/02).

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 9:02 AM
> To: Jonathan Rosenberg; Peterson, Jon
> Cc: 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy'; [email-masked]
> Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> I find Jonathan's point quite persuasive. It might help with 
> clarity on 
> Juha's application of the header as well. In fact, if we have 
> a separate 
> header for the UA to insert, it might also encode user's desire about 
> whether he wants the service provider to reject the call if 
> it is unwilling 
> to use the UA-asserted identity.
> 
> If we go the renaming route, could conveivably have:
> p-ua-asserted-identity, and
> p-proxy-asserted-identity.
> 
> Dave.
> 
> --On Friday, May 31, 2002 5:38 PM -0400 Jonathan Rosenberg 
> <[email-masked]> wrote:
> 
> > I hate to throw a wrench in here, but since we do have an oppty for
> > another rev of the doc during ietf LC, I would like to 
> voice an opinion.
> >
> > I don't believe that the hint should use the same header.
> >
> > My reasoning is simple. A header has a particular meaning. 
> That meaning
> > should be invariant to where that header appears, request 
> or response,
> > or any other conditions. We have been burned HARD by this 
> one with the
> > Contact header, which really has two different meanings depending on
> > context. It was only much later on we realized that we 
> needed both in
> > the same request, but of course, its too late...
> >
> > P-Asserted-Identity should mean "this is the identity 
> asserted by the
> > trust domain for the originator of this message". Period. 
> That is not at
> > all the same thing as "this is the identity the end user 
> would like you
> > to use, assuming its one of the allowed identities for this 
> user". In
> > fact, there are vastly different trust implications for the two
> > semantics. I can see right now a case where some misconfigured proxy
> > forgets to strip the "hint" and all of a sudden it becomes 
> a fraudulent
> > call, since the hint was the identity of a different user.
> >
> > It wouldn't shock me either if one day down the road we 
> find we do need
> > both of these things in the same request.
> >
> > I don't care what you call it. But, its not P-Asserted-Identity.
> >
> > -Jonathan R.
> >
> >
> > "Peterson, Jon" wrote:
> >>
> >> Since I've never been one to fly in the face of public 
> opinion (cough),
> >> I'll agree (at least in this case) that we should go with 
> majority rule
> >> and use the Asserted-Identity header for the 'hint'.
> >>
> >> Jon Peterson
> >> NeuStar, Inc.
> >>
> >> -----Original Message-----
> >> From: Mark Watson [mailto:[email-masked]]
> >> Sent: Thursday, May 23, 2002 9:18 AM
> >> To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy';
> >> [email-masked]
> >> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >>
> >> In the absence of further comment, can I make a *proposal* 
> that we stick
> >> with Asserted-Identity for the hint and for the NAI 
> itself, and that
> >> both are described in Cullen's draft ?
> >>
> >> Can we take this as AGREED if there are no comments by cob 
> tomorrow ?
> >> (Guidance sought from chairs on this second question).
> >>
> >> Updated requirements draft to be submitted first thing tomorrow.
> >>
> >> Regards...Mark
> >>
> >> > -----Original Message-----
> >> > From: Andrew Allen [ mailto:[email-masked]
> >> <mailto:[email-masked]> ]
> >> > Sent: 22 May 2002 15:51
> >> > To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 
> 'Peterson, Jon';
> >> > 'Rohan Mahy'; [email-masked]
> >> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >> >
> >> >
> >> >
> >> > I agree with Dave. Lets put the hint in the
> >> > asserted-identity. Lets not have
> >> > two redundant headers that need to be transferred over the
> >> > Radio interface
> >> > unnecessarily.
> >> >
> >> > Andrew
> >> >
> >> > > -----Original Message-----
> >> > > From: David R. Oran [ mailto:[email-masked] 
> <mailto:[email-masked]>
> >> ]
> >> > > Sent: Wednesday, May 22, 2002 9:45 AM
> >> > > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; [email-masked]
> >> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >> > >
> >> > >
> >> > > I suggest we allow the hint to be placed in the
> >> > > asserted-identity rather
> >> > > than in another header. A boundary proxy has to deal with a
> >> > UA putting
> >> > > in the header no matter what, if only to reject the 
> request with an
> >> > > error.
> >> > >
> >> > > Once we have a full solution the issue of hints should go
> >> > > away as a side
> >> > > effect of having the "authorization server" 
> functionality that Jon
> >> > > proposes. Better IMHO to have one obsolescent header to deal
> >> > > with rather
> >> > > than two, as well as avoiding the concomitant verbiage
> >> > describing the
> >> > > combinatoric cases involving two headers.
> >> > >
> >> > > Dave.
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: [email-masked] [ mailto:[email-masked]
> >> <mailto:[email-masked]> ] On
> >> > > > Behalf Of Mark Watson
> >> > > > Sent: Wednesday, May 22, 2002 9:59 AM
> >> > > > To: 'Peterson, Jon'; 'Rohan Mahy'; [email-masked]
> >> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >> > > > Importance: High
> >> > > >
> >> > > >
> >> > > > All,
> >> > > >
> >> > > > Can we have a *decision* asap as to whether the 'hint' uses
> >> > > > Asserted-Identity, or another header in another draft.
> >> > > >
> >> > > > I do not mind which. If the latter I will publish an I-D
> >> > > > describing it as soon as we have a decision, assuming it is
> >> > > > this week, since I'm away next week.
> >> > > >
> >> > > > If we do nothing, then I guess 3GPP will make up its own mind
> >> > > > how to do this, without supervision or advice from IETF,
> >> > > > which I think would  be a bad thing.
> >> > > >
> >> > > > Regards...Mark
> >> > > >
> >> > > >
> >> > > > -----Original Message-----
> >> > > > From: Watson, Mark [MDN05:EP10:EXCH]
> >> > > > Sent: 20 May 2002 12:08
> >> > > > To: 'Peterson, Jon'; 'Rohan Mahy'
> >> > > > Cc: [email-masked]
> >> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >> > > >
> >> > > >
> >> > > > The 'hint' was one of the three requirements that 3GPP
> >> > > > communicated to us in April.
> >> > > > It is a separate requirement from the Network Asserted
> >> > > > Identity itself, and so is not addressed in the requirements
> >> > > > draft, although I have been careful to point this out, and to
> >> > > > point out that it is a requirement nontheless, on several
> >> > > > occasions. I believe we need the 'hint' in the same timeframe
> >> > > > as the rest of the short term work.
> >> > > > Whether it is the same header/draft or a different
> >> > > > header/draft is another question on which I will only say
> >> > > > that we'd better make up our minds pretty quick. ...Mark
> >> > > >
> >> > > >
> >> > > > > -----Original Message-----
> >> > > > > From: Peterson, Jon [ mailto:[email-masked]
> >> <mailto:[email-masked]> ]
> >> > > > > Sent: 19 May 2002 18:11
> >> > > > > To: 'Rohan Mahy'
> >> > > > > Cc: [email-masked]
> >> > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > My argument was not that the proposed hint won't 
> work - just
> >> > > > > that it isn't
> >> > > > > necessary to solve the problem at hand. It might not be the
> >> > > > > case that the
> >> > > > > problems with the hint stop at the philosophical point you
> >> > > > > mention below.
> >> > > > > What I asked in my last mail was not whether or 
> not we needed
> >> > > > > a hint, but
> >> > > > > rather whether or not we should table that 
> question until we
> >> > > > > resolve the
> >> > > > > other questions at hand. I just don't want to spend the
> >> > > > > cycles arguing about
> >> > > > > the hint given our very aggressive timetable - frankly, I
> >> > > > think that
> >> > > > > reaching consensus on this hint matter might push back our
> >> > > > > dates a bit.
> >> > > > > Let's investigate this hint stuff in June, but for now just
> >> > > > > figure out how a
> >> > > > > Trust Domain can manage an asserted identity in a message.
> >> > > > >
> >> > > > > Jon Peterson
> >> > > > > NeuStar, Inc.
> >> > > > >
> >> > > > > > -----Original Message-----
> >> > > > > > From: Rohan Mahy [ mailto:[email-masked]
> >> <mailto:[email-masked]> ]
> >> > > > > > Sent: Sunday, May 19, 2002 8:29 AM
> >> > > > > > To: Peterson, Jon
> >> > > > > > Cc: [email-masked]
> >> > > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
> >> > > > > >
> >> > > > > >
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > The requirement for a hint is well understood, limited in
> >> > > > > > scope, and well motivated in the draft.  Nobody has
> >> > identified
> >> > > > > > any technical reason why the hint won't work.   
> Your argument
> >> > > > > > that allowing a hint weakens the strength of the 
> language on
> >> > > > > > ignoring Asserted-Identity from untrusted 
> parties is purely
> >> > > > > > philosophical in nature.  I don't buy your argument.
> >> > > > > >
> >> > > > > > thanks,
> >> > > > > > -rohan
> >> > > > > >
> >> > > > > >
> >> > > > > > ---- Original message ----
> >> > > > > > > Date: Fri, 17 May 2002 16:02:11 -0500
> >> > > > > > > From: "Peterson, Jon" <[email-masked]>
> >> > > > > > > Subject: [Sip] Asserted-Identity: How to 'hint'?
> >> > > > > > > To: "[email-masked]'" <[email-masked]>
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > In the course of the discussion between Mark 
> Watson, Cullen
> >> > > > > > Jennings and
> >> > > > > > > myself about the short-term identity work, we 
> have returned a
> >>
> >> > > > > > few times to
> >> > > > > > > the question of the infamous hint. This hint 
> is, of course, a
> >>
> >> > > > > > way that a
> >> > > > > > > user agent (one that is not a member of the 
> Trust Domain in
> >> > > > > > the short-term
> >> > > > > > > network asserted identity space) can provide a 
> 'hint' to the
> >> > > > > > intermediary
> >> > > > > > > that will generate an Asserted-Identity 
> indicating which
> >> > > > > > identity among
> >> > > > > > > several possibilities should be asserted.
> >> > > > > > >
> >> > > > > > > The need for this arises particularly from the 
> 3G space, in
> >> > > > > > which the
> >> > > > > > > authentication process takes place 
> independently of SIP and
> >> > > > > > does not carry
> >> > > > > > > this sort of personal identity information. It 
> also assumes
> >> > > > > > that the
> >> > > > > > > operators of the intermediary in question are aware of
> >> > > > > > several legitimate
> >> > > > > > > identities which the user can elect to assert.
> >> > > > > > >
> >> > > > > > > It has been proposed on the mailing list and
> >> > elsewhere that the
> >> > > > > > > Asserted-Identity header should be re-used by 
> user agents
> >> > > > > > outside the Trust
> >> > > > > > > Domain to provide such a hint. I see a number 
> of reasons for
> >> > > > > > and against
> >> > > > > > > using the Asserted-Identity for this purpose. 
> For example,
> >> > > > > > today, there is a
> >> > > > > > > requirement that asserted-identities which are 
> transmitted
> >> > > > > > from untrusted
> >> > > > > > > sources should not be used in any way - this 
> would seem to
> >> > > > > > weaken that
> >> > > > > > > requirement. There is also possibly some 
> behavior that still
> >> > > > > > needs to be
> >> > > > > > > specified (like how an intermediary would 
> reject or otherwise
> >>
> >> > > > > > handle a
> >> > > > > > > request with an inappropriate hint) that might 
> be impactful
> >> > > > > > to our choice.
> >> > > > > > >
> >> > > > > > > For the time being, however, I would like to 
> suggest that
> >> > > > > > providing the hint
> >> > > > > > > is outside the scope of the current deliverables (the
> >> > > > > > asserted-identity
> >> > > > > > > requirements and mechanism drafts), which need to be
> >> > > > > > complete, as we
> >> > > > > > > discussed in the interim meeting, by the end 
> of this month. I
> >>
> >> > > > > > believe that a
> >> > > > > > > separate draft should propose the use of 
> Asserted-Identity or
> >>
> >> > > > > > any other
> >> > > > > > > header for this hint (in whatever timeframe is 
> appropriate
> >> > > > > > for 3G's
> >> > > > > > > requirements), but that we should not speak to 
> this matter in
> >>
> >> > > > > > the current
> >> > > > > > > asserted-identity deliverables. There is, as I 
> see it, no
> >> > > > > > dependency on
> >> > > > > > > defining this hint before we dictate how 
> intermediaries will
> >> > > > > > assert
> >> > > > > > > identities.
> >> > > > > > >
> >> > > > > > > Any comments on this plan?
> >> > > > > > >
> >> > > > > > > Jon Peterson
> >> > > > > > > NeuStar, Inc.
> >> > > > > > >
> >> > > > > > > _______________________________________________
> >> > > > > > > Sip mailing list  
> https://www1.ietf.org/mailman/listinfo/sip
> >> <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
> >> <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
> >> <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
> >> <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
> >> > >
> >> >
> >
> > --
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > [email-masked]                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH:  (973) 952-5000
> > http://www.dynamicsoft.com
> 
> 
> 
> -----------------------------------------------------------
> David R. Oran                   Phone/Fax: +1 978 264 2048
> Cisco Systems                   VoIP: +1 408 571 4576
> 7 Ladyslipper Lane              Email: [email-masked]
> Acton, MA 01720
> 

_______________________________________________
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: Mon, 03 Jun 2002 14:30:06 -0400

> Still, building a new draft might take more time than we have.)

I see no reason for a separate draft. Its just an optional feature of
the asserted identity mechanism.

> if we can help it - maybe P-Suggested-Identity for the hint?)

Fine.

> P-Suggested-Identity in any interesting way?

I like Dave's idea of adding a param which indicates whether to reject
or ignore if the suggested identity cannot be asserted. 

-Jonathan R.

---

From: [email-masked]
Date: Tue, 4 Jun 2002 00:44:35 +0300

> if we can help it - maybe P-Suggested-Identity for the hint?)

since the hint is needed for the general case where from is anonymous
and since there is no other standardized sip mechanism for that purpose,
i'm strongly against defining a p-header for it.  it must be a normal,
standards track header with possibly a new error code to tell the UA
that the proxy didn't like the identity the ua was claiming.

-- juha