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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Jun 2002 03:01:01 -0500

So, I take it from the silence on this list today about this matter that
there is consensus to create a P-Suggested-Identity header in the existing
short-term identity draft that admits of a criticality parameter as Jonathan
descibes it below?

This would be a good time to speak up if you feel otherwise.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 11:30 AM
> To: Peterson, Jon
> Cc: 'David R. Oran'; 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy';
> [email-masked]
> Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> 
> 
> "Peterson, Jon" wrote:
> > 
> > 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.)
> 
> I see no reason for a separate draft. Its just an optional feature of
> the asserted identity mechanism.
> 
> > 
> > - 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?)
> 
> Fine.
> 
> > 
> > - Does the syntax of P-Asserted-Identity differ from that of
> > 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.
> 
> -- 
> 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
> 

_______________________________________________
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: Tue, 4 Jun 2002 11:29:35 +0300

> short-term identity draft that admits of a criticality parameter as Jonathan
 
haven't you been listening?  i'm STRONGLY opposed a P-header for this
purpose. there are many reasons for it:

1) there is a general need to include such capability in sip.  

2) we may need a new error code to indicate that the request was
   rejected due to "wrong" requested identity and p-headers are
   informational only.

3) i would have hard time to convince non-3gpp UA, proxy, and SIP/ISUP
   gw vendors to implement anything starting with P.

this rush seems again be caused solely by 3gpp reasons, which in totally
unacceptable for the "rest of us" (if any besides me are still left).

i would like to hear a comment from the ADs on this.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Jun 2002 11:57:35 -0400

inline.

>    gw vendors to implement anything starting with P.

I haven't really made up my mind yet on whether this suggested identity
is a P-header or not; so please don't construe the following as an
argument in favor - I am just trying to tease the problem apart a bit.

I think the decision point about the hint is based on whether the hint
is ever useful without the P-Asserted-Identity. If it is useful without
that extension, then it probably does qualify as a regular header. If it
is not useful without that extension, then it is probably a P-header.

Personally, I don't see how one would use the hint without a network
asserted identity. In the application you are interested in, you are
delivering one of several phone numbers to a PSTN gateway, even when the
user is anonymous. The gateway needs to only pass an authenticated
identity, in which case it can't pass the user's hint, it has to pass
the P-Asserted-Identity. Thus, your application would seem to require
the P-Asserted-Identity header. 

However, I can imagine that the hint might be useful for the long term
identity work too. When a request is sent to an authentication service,
the authentication service needs to know what identity to assert, in the
same way the proxy needs to know what identity to assert in the short
term case. So, here is a case where the suggested identity is useful for
an application outside of the P-header. 

I must admit, though, in the general SIP usage that I am unconvinced
that one really needs to have such a large number of identities that it
is not reasonable to have a different set of credentials for each of
them. In many cases the credentials are configured in some reasonable
way, so that the user won't necessarily need to manually enter them (for
example, burn in at a store for a wireless phone) I am curious whether
you are really handing out 15 phone numbers to a single user...

-Jonathan R.

---

From: [email-masked]
Date: Tue, 4 Jun 2002 20:41:28 +0300

> is not useful without that extension, then it is probably a P-header.

my reply to that is that also the asserted-identity should be a regular,
rather than a p header.  i haven't yet figured out why asserted-identity
is a p header except because of the rush by 3gpp, which has taken over
ietf sip working group.  

it would be nice if each person sending email to the list about this
topic could tell up front if she/he or his/her company has vested
interest in 3gpp in order to be able to determine how "objective"
his/her opinion is.

 > The gateway needs to only pass an authenticated

i have always disliked the word "hint" and asked to replace it in the
drafts.  as i have said too many times already, to me requested-identity
is what the user asks for and it i don't like it, i refuse the request.
therefore within my own domain, the sip/pstn gw may very well look at
the requested-identity and thus requested-identity is useful without
asserted-identity.

 > In many cases the credentials are configured in some reasonable

yes, since it would allow the user to have local identity in each of the
15 calling areas and people can return to the call to the user via a
cheaper local call.  having a separate username/password for each number
is a nightmare not only to the user, but also for the service provider.

-- juha

---

From: [email-masked]
Date: Tue, 4 Jun 2002 21:50:17 +0300

henry,

i also do want requested and asserted identity features, but i want them
as real sip headers, not private p headers in order to meet some 3gpp
deadline.  so you don't care if all new useful extensions are all p
headers?

-- juha

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 04 Jun 2002 13:43:08 -0500

> it would be nice if each person sending email to the list 
> about this topic could tell up front if she/he or his/her 
> company has vested interest in 3gpp in order to be able to 
> determine how "objective" his/her opinion is.

I do not work for 3GPP but am very happy to see SIP embraced by such an
important constituency. SIP has only to gain by the additional
requirements from such commercial user communities. Plus mobility...

Whatever we may think of some "walled garden" or not e2e transparent
approaches, there is an analogy to IP that is used not only over the
Internet, but also in private IP networks that are "very closed". I
propose a cheer for the 3GPP folks for adopting SIP so seriously.

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, June 04, 2002 12:41 PM
> To: Jonathan Rosenberg
> Cc: Peterson, Jon; 'David R. Oran'; 'Mark Watson'; 'Andrew 
> Allen'; 'Rohan Mahy'; [email-masked]
>  > I think the decision point about the hint is based on 
> whether the hint  > is ever useful without the 
> P-Asserted-Identity. If it is useful without  > that 
> extension, then it probably does qualify as a regular header. 
> If it  > is not useful without that extension, then it is 
> probably a P-header.
> 
> my reply to that is that also the asserted-identity should be 
> a regular, rather than a p header.  i haven't yet figured out 
> why asserted-identity is a p header except because of the 
> rush by 3gpp, which has taken over ietf sip working group.  
> 
> it would be nice if each person sending email to the list 
> about this topic could tell up front if she/he or his/her 
> company has vested interest in 3gpp in order to be able to 
> determine how "objective" his/her opinion is.
> 
>  > identity, in which case it can't pass the user's hint, it 
> has to pass  > the P-Asserted-Identity. Thus, your 
> application would seem to require  > the P-Asserted-Identity header. 
> 
> i have always disliked the word "hint" and asked to replace 
> it in the drafts.  as i have said too many times already, to 
> me requested-identity is what the user asks for and it i 
> don't like it, i refuse the request. therefore within my own 
> domain, the sip/pstn gw may very well look at the 
> requested-identity and thus requested-identity is useful 
> without asserted-identity.
> 
>  > In many cases the credentials are configured in some 
> reasonable  > way, so that the user won't necessarily need to 
> manually enter them (for  > example, burn in at a store for a 
> wireless phone) I am curious whether  > you are really 
> handing out 15 phone numbers to a single user...
> 
> yes, since it would allow the user to have local identity in 
> each of the 15 calling areas and people can return to the 
> call to the user via a cheaper local call.  having a separate 
> username/password for each number is a nightmare not only to 
> the user, but also for the service provider.
> 
> -- juha
> 
> 
> 
> 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, 04 Jun 2002 14:16:08 -0500

Juha,

>so you don't care if all 
> new useful extensions are all p headers?

You are right we should care and a doable approach may be to let the
3GPP folks meet their deadline first, and after that adopt from their
work whatever makes sense in the open Internet as non p- headers. 

What do you think?

Henry

> Sent: Tuesday, June 04, 2002 1:50 PM
> To: Henry Sinnreich
> Cc: 'Jonathan Rosenberg'; 'Peterson, Jon'; 'David R. Oran'; 
> 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy'; [email-masked]
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> henry,
> 
> i also do want requested and asserted identity features, but 
> i want them as real sip headers, not private p headers in 
> order to meet some 3gpp deadline.  so you don't care if all 
> new useful extensions are all p headers?
> 
> -- juha
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Jun 2002 15:19:47 -0400

> deadline.  so you don't care if all new useful extensions are all p

The asserted identity draft is a P-header because it has some big
assumptions that make it inapplicable to the Internet at large, and
dangerous if not part of a well architected network. The assumptions are
true for 3gpp, but it is not the case that the draft is a P-header just
because of 3gpp.

-Jonathan R.

---

From: [email-masked]
Date: Tue, 4 Jun 2002 22:29:25 +0300

> work whatever makes sense in the open Internet as non p- headers. 

once ietf defines a p header for some purpose, there is far less
motivation to produce the corresponding standards track sip header.
the result is weaker sip and non-interoperable products.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 4 Jun 2002 14:58:20 -0500

> once ietf defines a p header for some purpose, there is far 
> less motivation to produce the corresponding standards track 
> sip header. the result is weaker sip and non-interoperable products.

That is a legitimate position to take regarding the proposed SIP Change
Process, something that we ARE working to refine.

I've found my own P-header draft has been as rigorously developed and
discussed as my standards-track work, and the more we talk about it, the
more I've begun to wonder:

1) What REALLY differentiates P-headers from standards track, if they're
held to the same level of accountability? The difference here, I
suspect, is contained in the applicability statement -- P-headers seem
to need a "Danger! Don't use this UNLESS you have the following really
odd network AND have taken special steps, listed here, to compensate for
the problems induced by that oddness". It actually appears to be harder
to write a P-header draft and get it accepted than a "standard" draft,
because it's so hard to craft this applicability statement.

2) For things that turn out to be broadly useful, how will we evolve
from a P-header to a standard? Can we? Should we discard the
"preliminary" definition of P and only use P-headers for things that
seem really obviously proprietary, like unique billing tokens and stuff?
What happens when they turn out to be widely used?

3) Should I have just made P-Service-Route standards track instead of a
P-header? It does have applicability outside of 3GPP, and doesn't need
the "Danger, Will Robinson!" applicability statetement that seems to
characterize the "really 3GPP drafts".

--
Dean

---

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

> the P-Asserted-Identity header. 

Jonathan,

I'm probably foolish wandering back into this
debate, but I find this entire subject rather
perplexing. I guess I see all of this as various
elements wanting to assert an identity -- perhaps
bound to some cryptographic proof -- along with
who is signing it. Yes, there may well be the need
for different identities, just like I need
different keys to unlock locks; same goes for the
doors along the proxy routed path. Nor do I think
we should expect that there is any global name
space which would allow a single unified identity;
to my first hop proxy, I'm [email-masked], but I'm
pretty sure that I'll need an [email-masked]
identity to get past Cisco's edge proxy. Telling
either one that they must adopt the other's
indentifiers is... hopeless IMO (and undesirable).

So, I guess from the UA standpoint I see that we
have a general requirement that the UA be able to
assert multiple identities. Essentially, what it
seems to me that we need is one or more AKA's to
be used anywhere along the proxy routed path by
anyone who is willing to believe that identity, or
more specifically the identity which was asserted
(and signed) by some (possibly third party)
entity.

For network asserted, it seems to me that all
we're doing is expanding the set of things that
can insert an AKA, along eventually with some
cryptographic proof as well. Again, its consumer
would be anybody along the proxy routed path who
is willing to believe it. The UAS is an obvious
consumer, but this may well be a useful way for
organizations to "vouch" their users to the next
hop proxy without having to expose the underlying,
internal authentication mechanisms to the outside
for verification.

So, I guess I don't understand all of the
thrashing around on this issue. If we had a 
header sort of like:

Also-known-as: identity [; asserted-by=identity [; signature=signature]]

Which could be inserted along the proxy routed
path, does that give each device farther
downstream the necessary information to unlock the
sucessive door? (yes, I realize there is more to
this given privacy, etc, but that doesn't seem to
be what's at issue in this current go-round)

So to answer your question, yes I think that the
Asserted-Identity, or AKA, or "hint" (bletch) is
useful all on its own.

	  Mike

---

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

> the result is weaker sip and non-interoperable products.

   Indeed, this entire process seems like it leads
   to national-variants-of-ISUP hell. Add me to
   the list of people worried about whether 3GPP 
   short term hacks are harming the long term
   health of SIP.

   If you ask me, the main problem here is an
   inability to just declare consensus for these
   and just *live* with it. Frankly I'm astonished
   that this is all still on the table after the
   endless series of meetings, correspondence etc
   on this subject. I can't say as that I've seen
   anything new here. This P-hack route seems to
   be nothing more than an explicit admission
   of the WG's dysfunction.

   Sorry for adding to the noise level.

	     Mike

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 04 Jun 2002 20:03:01 -0500

Michael Thomas writes:

> This P-hack route seems to

This stems actually from a business decision not to have the 3GPP
networks be part of the open Internet and I am afraid the WG engineeers
can do very little about it.

Henry

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Tuesday, June 04, 2002 7:45 PM
> To: [email-masked]
> Cc: Henry Sinnreich; 'Jonathan Rosenberg'; 'Peterson, Jon'; 
> 'David R. Oran'; 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy'; 
> [email-masked]
>  >  > You are right we should care and a doable approach may 
> be to let the  >  > 3GPP folks meet their deadline first, and 
> after that adopt from their  >  > work whatever makes sense 
> in the open Internet as non p- headers. 
>  > 
>  > once ietf defines a p header for some purpose, there is 
> far less  > motivation to produce the corresponding standards 
> track sip header.  > the result is weaker sip and 
> non-interoperable products.
>