Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Jun 2002 13:21:16 -0500

Your users can have multiple identities and a single password with the
existing SIP Digest authentication system. Groups of identities can simply
use the same password (users do it all the time today when they are known by
multiple names):

Auth: username=+358-8-XXX-1234, password=foo
or
Auth: username=+358-8-XXX-1235, password=foo
or
Auth: username=+358-8-XXX-1236, password=foo

Each username expressed with Digest is a different identity that is 'hinted'
to the network, while the From field remains anonymous. This is exactly the
same, from a protocol perspective, as having headers like this:

Auth: username=juha, password=foo
Hint: +358-8-XXX-1234

... except that my way uses one less header. The intermediate 'juha'
username adds no useful information to this (the service provider that
receives an Authorization can also know administratively that 'juha' owns
'+358-8-XXX 1234', if that's important). This technique is also applicable
to most other authentication schemes (generally, such systems allow one to
express a username).

The real point of this whole sidebar, though, is this: if your application
has some need to express some second identity in an anonymity case (like
'juha' distinct from '+358-8-XXX 1234'), then I suspect your requirements
actually diverge somewhat from those of the short-term identity application
anyway, and this would be a subject of further investigation. If it doesn't
need this second identity, then the Digest system described above should
work for you. The fact that you seem especially concerned with telephone
numbers also makes your case a little different from the 3G case.

Finally, I'd like to cite your description of your application from an
earlier mail:

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

... and I would like to ask you what, if anything, this has to do with
sending calls with an anonymous From header field. Your application is one
in which the owner of those 15 numbers uses them in order to receive calls,
not to originate calls. Why is it important that the user be able to choose
one of these 15 identities on the fly when they originate (anonymous) calls?
Do you really think users should individually select one of these 15
identities based on, perhaps, the telephone number of the person they are
calling? Remember, the recipient of the call will never even see the calling
party's number, because the From header field is anonymous - this hint will
be consumed only by the network. None of the foreseeable effects of this
seem powerful or beneficial to me. It sounds to me like the only case in
which a user needs to select one of these 15 identities is when they
register (a case where you would never have an anonymous From header).

As far as I can understand it from your description, your service has little
bearing on the anonymous identity assertion problem. In so far as it does,
I'm not sure exactly what requirements it introduces. I promise you that if
the relevance of your needs were more clear, the remainder of the mailing
list would be more responsive to your diatribes.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 13, 2002 7:48 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01
> 
> 
> Peterson, Jon writes:
> 
>  > For the nth time, if a user selects an anonymous From 
> header field, that
>  > does NOT mean that there is no other way in the base SIP 
> specification for
>  > them to specify an identity to an intermediary.
> 
> the only other way that i'm aware is having a different
> username/password for each identity, which is not acceptable to our
> customers.  they want to have a single username/password and multiple
> sip identities.  i would like to hear your base sip solution to this.
> 
> -- 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: Thu, 13 Jun 2002 21:37:37 +0300

> use the same password (users do it all the time today when they are known by

this is not acceptable to our users nor to us.  we have a user database
that includes one unique username and password per user.  that database
is not sip specific, but is used for all services that we may be
providing for the user.  it would thus be totally out question to start
introducing new users to the user database if one user wants to have
more than one sip identity.

 > one of these 15 identities on the fly when they originate (anonymous)

the user simply does want to remain anonymous when he places a certain
call, i.e., doesn't want to show any of its 15 sip identities.  the user
most likely still wants the calling party number to be one that belongs
to the same area code to which he is calling to in order to save long
distance charges.

 > calling? 

yes, see above.

-- juha

---

From: Chris Martin <[email-masked]>
Date: Thu, 13 Jun 2002 21:49:36 -0500

> more than one sip identity.

This answers one of my earlier questions posed (and incorrect
assumptions, at least for your application, within the response that I
made regarding same un/pw)and is of course an issue of policy(s) which
probably exist both for security and business reasons (Which is a good
example of my earlier message where I mention these reasons for walled
gardens).

Hey this makes your application of SIP a type of walled garden too!

:^)

> to the same area code to which he is calling to in order to save long

Then IMO that would be an issue of provisioning at the network of this
account based on the un/pw.

Good point, gives us some perspective to your complaints.

Chris