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

From: [email-masked]
Date: Sat, 1 Jun 2002 08:44:58 +0300

i support jonathan's proposal to have some other header that the nai to
tell its identity to the proxy.  in the absence of this other header,
the from header should serve the purpose (unless it is anonymous).  a
long time ago i remember someone proposing a "Really-From" for this
purpose.

-- juha

_______________________________________________
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: [email-masked]
Date: Sun, 2 Jun 2002 14:05:49 +0300

Ben Campbell writes:

 > The fact that the From field _can_ be anonymous makes the From header a 
 > not-very-good choice. It is entirely possible you would want to use such 
 > a hint _and_ request anonymity.

in which case as i proposed to use Really-From header in the very same
message to which you replied.

-- juha

---

From: [email-masked]
Date: Sun, 2 Jun 2002 23:18:14 +0300

Ben Campbell writes:

 > This means any device that cares has to check From, and then under some 
 > conditions check somewhere else. It would be much better to have only 
 > one header to check for this purpose.

in theory yes, but for backwards compatibility we MUST support current
UAs that do not insert Really-From.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 2 Jun 2002 22:55:09 -0500

> 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.

I think I disagree.

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

There are some interesting transitivity properties if one considers that
ANY delivered P-A-I is potentially a "hint".

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Sun, 02 Jun 2002 11:32:48 -0500

---

From: Ben Campbell <[email-masked]>
Date: Sat, 01 Jun 2002 19:02:30 -0500

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 03 Jun 2002 12:01:48 -0400

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
> 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.
>> > > > > > >
>> <https://www1.ietf.org/mailman/listinfo/sip>
>> <https://www1.ietf.org/mailman/listinfo/sip>
>> <https://www1.ietf.org/mailman/listinfo/sip>
>> <https://www1.ietf.org/mailman/listinfo/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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 4 Jun 2002 17:17:54 -0700 (PDT)

> p-proxy-asserted-identity.

   What this essentially says is that the _role_
   (eg, ua, proxy) is somehow important rather
   than or along with the identity itself. That
   is, I might take a different action just
   because a proxy asserts an identity rather
   than a UA. This seems rather squirrelly to me.
   It also means that roles need to be bound to
   (currently non-existant) credentials as well.
   Normally I'd think you just want to have
   identities which bound to some authorization
   information determine what your course of 
   action. Adding roles adds another dimension.

   Or is this in *lieu* of who's asserting the 
   identity?

   Hmm.

		Mike