Subject: IETF solution for pairing cellular hosts

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 25 Sep 2007 18:03:35 +0200

Hello,

Currently there are two approaches for obtaning contact information for a
target cell phone: (i) consulting a phonebook, (ii) manually exchanging
phone numbers upon face-to-face user contact. Both approaches have
their own limitations.

The following is a new abstract solution, a third alternative, a protocol
for "pairing" two cellular hosts:

Model of operation

1. The querier user types the target user's "human name" (as if he were
   consulting a phonebook), or a pseudoynm.
2. The pairing request is forwarded to the target phone.
3. The query, along with the querier user's name, are displayed on the
   target phone's screen.
4. The target user approves the request in real-time by pushing on the YES
   button of the phone.
5. The two phones exchange their Mobile IPv6 home addresses, SIP URIs, and
   establish an IPsec security association (using IKEv2).

The target user does not need to publish his/her private SIP URI and home
address (as recommended in [1] in SIP context). Cell phone users do not
publish their phone numbers today.

The users do not need to manually exchange their SIP URIs and home
addresses which are too long (an IPv6 address is 16 bytes long and random
looking, a SIP URI can be very long e.g. up to 30 characters and even more
with a random part for privacy).

The protocol also works in the absence of user contact, for example when
the target user's SIP URI is lost (loss of state, new phone), or this is
the user's first phone, and hence his/her contact list is initially empty.
Thousands of cell phones are sold everyday..

[1] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol",
    RFC3323, November 2002.

------------

Please note that this is an abstract to solution, I personally don't know
how to design it (or, which design might be the best one). I hope this would
be
of interest to the IETF. Comments appreciated either here or please
subscribe to the following mailing list:

https://www1.ietf.org/mailman/listinfo/humanresolvers

Thanks
pars mutaf
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: 25 Sep 2007 16:33:32 -0000

>3. The query, along with the querier user's name, are displayed on the

I have a list of 250,000 people here (scraped off web sites) to whom
I'd just love to make recorded phone calls.  Can I use your protocol
to ask them all if it's OK?  If not, why not, and how are you going to
stop me?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 25 Sep 2007 18:48:36 +0200

Hello,

> to ask them all if it's OK?  If not, why not, and how are you going to

Using a Turing test (CAPTCHA) for example.

http://en.wikipedia.org/wiki/Captcha

When you make a request, the target phone returns a captcha. If you
don't provide the right solution, the target user won't even see your
request, it will be dropped. Captcha's difficulty can be adaptively
tuned by the target phone..

So another step should be added to the above description.

I hope this answers your question!

Regards,
pars

Regards,

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 25 Sep 2007 21:02:15 +0200

> So another step should be added to the above description.

A quick addition to my previous mail:

Captcha is proposed for protecting the target user against
disturbing bogus requests.

There is also the 4th step (below) in the original mail which suggests
that user approval is needed before the phone number
(or any info you like) is returned to the querier:

Regards,
pars

> > Information Superhighwayman wanna-be, http://www.johnlevine.com ,
> > ex-Mayor

---

From: Daniel Senie <[email-masked]>
Date: Tue, 25 Sep 2007 15:09:17 -0400

At 03:02 PM 9/25/2007, Pars Mutaf wrote:

>On 9/25/07, Pars Mutaf 
><<mailto:[email-masked]>[email-masked]> wrote:
>Hello,
>
>On 25 Sep 2007 16:33:32 -0000, John Levine <<mailto:[email-masked]> 
>[email-masked]> wrote:
><http://en.wikipedia.org/wiki/Captcha>http://en.wikipedia.org/wiki/Captcha
>

And hopefully this can all be FULLY disabled, or be disabled by 
default. Otherwise, everyone will be inundated with these messages 
popping up, asking you to hit the "yes" button. Count me as someone 
who'd never want this protocol implemented in my phone.

>John Levine, <mailto:[email-masked]>[email-masked], Primary 
>Perpetrator of "The Internet for Dummies",
>Information Superhighwayman wanna-be, 
><http://www.johnlevine.com>http://www.johnlevine.com , ex-Mayor

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 25 Sep 2007 21:25:38 +0200

On 9/25/07, Daniel Senie <[email-masked]> wrote:
> On 9/25/07, *Pars Mutaf* <[email-masked]> wrote:
>  Hello,
>
> On 25 Sep 2007 16:33:32 -0000, John Levine < [email-masked]> wrote:
> And hopefully this can all be FULLY disabled, or be disabled by default.
> Otherwise, everyone will be inundated with these messages popping up, asking
> you to hit the "yes" button. Count me as someone who'd never want this
> protocol implemented in my phone.
>

You have the other problems listed above in this case (manual exchange
difficult etc.
and the other problems listed in my original mail).

Why the CAPTCHA solution is not enough for you? In my personal view, the
person who
wants to disturb you is the one who is suffering (CAPTCHAs can be made very
hard
if you wish).

Maybe it wasn't clear. Here are the steps:

The querier user makes the request.
The target phone returns a CAPTCHA.
The querier user solves the CAPTHA.
The target user sees the query displayed on the screen and approves the
request (or not).
The phone number is returned (or not).

Thanks,
pars

Regards,
> Information Superhighwayman wanna-be, http://www.johnlevine.com , ex-Mayor

---

From: Daniel Senie <[email-masked]>
Date: Tue, 25 Sep 2007 15:33:19 -0400

At 03:25 PM 9/25/2007, Pars Mutaf wrote:

>On 9/25/07, Daniel Senie <<mailto:[email-masked]>[email-masked]> wrote:
>You have the other problems listed above in this case (manual 
>exchange difficult etc.
>Why the CAPTCHA solution is not enough for you? In my personal view, 
>the person who
>wants to disturb you is the one who is suffering (CAPTCHAs can be 
>made very hard
>if you wish).
>
>The target user sees the query displayed on the screen and approves 
>the request (or not).

The target phone gets pestered whether the owner of the target phone 
wishes to receive or not? Does the target phone need to be in a "I 
want to receive" mode, or will anyone be able to fire such a request 
at your phone?

What I'm imaginging is every retailer bombarding every cell phone 
with a request to get their contact information added to your phone.

The simple act of receiving the request for the Captcha is an 
annoyance. The question is, how are you going to limit the ability 
for someone to annoy someone else? Or to put it in a more blunt way, 
how do you avoid having people instigate a DDoS, in the form of tons 
of CAPTCHA handshake requests, or approval requests or whatever?

I must be missing something, because I can't imagine why you'd want 
to create such a wonderful pathway for rendering someone's phone unusable.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Sep 2007 15:42:38 -0400

Hi Pars,

> 2. The pairing request is forwarded to the target phone.

How? How do you locate the target phone? Isn't this the problem we are 
trying to solve?

Cheers
Suresh

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 25 Sep 2007 21:59:48 +0200

Hi Suresh,

> How? How do you locate the target phone? Isn't this the problem we are

For example (I'm not saying that this THE solution):

You can have a relay agent where the human names map
to MIPv6 home addresses of the target phones.

Using the proposed protocol, the target phone can return
another home address.

Infrastructureless solutions may also be possible, by
multicasting a query to the target human name..

cheers,
pars

Cheers

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 25 Sep 2007 22:26:21 +0200

On 9/25/07, Daniel Senie <[email-masked]> wrote:
> On 9/25/07, *Daniel Senie* <[email-masked]> wrote:
>  On 9/25/07, Pars Mutaf <[email-masked]> wrote: Hello,
> On 25 Sep 2007 16:33:32 -0000, John Levine < [email-masked]> wrote: >1.
> The querier user types the target user's "human name" (as if he were >
> consulting a phonebook), or a pseudoynm. >2. The pairing request is
> forwarded to the target phone. >3. The query, along with the querier
> user's name, are displayed on the >   target phone's screen.
> I have a list of 250,000 people here (scraped off web sites) to whom I'd
> just love to make recorded phone calls.  Can I use your protocol to ask
> them all if it's OK?  If not, why not, and how are you going to stop me?
>
>
> When you make a request, the target phone returns a captcha. If you don't
> provide the right solution, the target user won't even see your request,
> it will be dropped. Captcha's difficulty can be adaptively tuned by the
> target phone..
> wants to disturb you is the one who is suffering (CAPTCHAs can be made
> very hard
> if you wish).
>
> wishes to receive or not? Does the target phone need to be in a "I want to
> receive" mode, or will anyone be able to fire such a request at your phone?
>

"I want to receive mode" why not. This answers the other questions below?

In the worst case (where many attackers are "constantly" looking for
reachable phones):

You can enable this protocol when you need to pair your phone
with another user's phone. Because manual exchange is difficult.

Or, you can enter "I want to receive mode" when you have a new phone
or phone number, home address, etc.

pars

What I'm imaginging is every retailer bombarding every cell phone with a
> request to get their contact information added to your phone.
>
> The simple act of receiving the request for the Captcha is an annoyance.
> The question is, how are you going to limit the ability for someone to annoy
> someone else? Or to put it in a more blunt way, how do you avoid having
> people instigate a DDoS, in the form of tons of CAPTCHA handshake requests,
> or approval requests or whatever?
>
> I must be missing something, because I can't imagine why you'd want to
> create such a wonderful pathway for rendering someone's phone unusable.
>

---

From: John L <[email-masked]>
Date: Tue, 25 Sep 2007 18:18:02 -0400 (EDT)

> http://en.wikipedia.org/wiki/Captcha

There are many well known ways to defeat CAPTCHAs, unfortunately.

R's,
John

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 26 Sep 2007 00:23:06 +0200

> There are many well known ways to defeat CAPTCHAs, unfortunately.

It depends on the CAPTCHA you are using
and your application.
You may want to take a look at the following talk?

http://www.youtube.com/watch?v=dtFroEJN1nI

regards,
pars

R's,

---

From: John L <[email-masked]>
Date: Tue, 25 Sep 2007 19:14:28 -0400 (EDT)

> with another user's phone. Because manual exchange is difficult.

Now I don't understand what problem you are trying to solve.  If the two 
phones are physically close to each other, we have existing short-range 
data exchange systems such as infrared and Bluetooth that work fine.  If 
the two parties already know each other, there is presumably some existing 
communication path such as e-mail they can use to exchange credentials.

On the other hand, if you are trying to solve the introduction problem, 
how to establish a channel between two people who don't already know each 
other, that's a famous swamp, and taking a couple of phones into the 
swamp doesn't change the issues.

Regards,

---

From: John L <[email-masked]>
Date: Tue, 25 Sep 2007 21:05:33 -0400 (EDT)

> It depends on the CAPTCHA you are using and your application.

I've seen it.  Without getting into more details that the IETF list wants 
to see, let me just say that having been thinking about the introduction 
problem for the better part of a decade, I'm pretty sure I'm not the only 
one who thinks that approaches that depend on something like a CAPTCHA to 
work don't have much of a long term future.

Regards,

---

From: Bill McQuillan <[email-masked]>
Date: Wed, 26 Sep 2007 00:22:31 -0700

> to MIPv6 home addresses of the target phones.

This is the big problem. "Human names" are not unique enough!

In a normal wire-line directory the name is associated with a fixed
location, usually an address but at least a city. This can be used as a
discriminator among possible name duplications by the querier.

Cellphones do not provide the "relay agent" with such fixed, known
information to assist in discriminating among customers with the same name.
Since cellphones are so mobile there even might only be a country indication.

Or were you intending that ALL phones of people with the same name be
contacted. Wouldn't this just put the burden on all of the target users to
determine the identity of the querier based on....what?

And how would any one of the targets determine that she was the intended
victim?

-- 
Bill McQuillan <[email-masked]>

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 26 Sep 2007 11:31:42 +0200

Hello thanks for the question, I'm pasting a note that
I wrote in a previous I-D:

(I'm not entering here into solution discussions!)

Regards,
pars

4.  Name collisions

   With the traditional phone book, the querier can filter the returned
   results using some other information about the target user e.g. the
   street address, company, etc.  A similar solution may be adopted.
   Along with a Turing test, the target host may return some information
   helping the querier make the right choice.  If the target user is
   unlikely to be the right person, the querier can give up the query
   and avoid solving an unnecessary Turing test.

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 26 Sep 2007 11:22:56 +0200

> swamp doesn't change the issues.

Hi,
Please refer to my first mail. There are three basic problems that I see.

1. You don't want to publish your private information
2. Manual exchange is difficult
3. Face-to-face contact is not always available

The proposed solution is the only one that addresses these three problems.

I can also add that I don't want to use Bluetooth. This is an abstract
solution, i.e. technology independent.

As for your "using e-mail" proposal, I don't understand. In fact you can
use this protocol for distributing an e-mail address too.

Regards,

pars

Regards,

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 26 Sep 2007 12:05:06 +0200

> work don't have much of a long term future.

I respect your opinion but it says that one day we won't be able to tell
humans and computers apart.

In fact I'm not saying that the solution depends on CAPTCHA, I propose it
as an option.

Regards,

pars

Regards,

---

From: <[email-masked]>
Date: Wed, 26 Sep 2007 11:40:41 +0100

>2. Manual exchange is difficult 

Ridiculous! I give my phone to the other person and ask
them to dial my number and call me. Now we both have a
record of each others' phone numbers.

>3. Face-to-face contact is not always available

I can't believe that I'm reading this in an email message.
Some people put their phone number in the signature block.
Others type it in when requested. Most mobile devices have
a way to sync a phonebook with a PC. Job done.

>The proposed solution is the only one that addresses these three
problems. 

Seems to me that you have only one real problem and we
can adress that (number 1 above) by simply doing nothing.

--Michael Dillon

P.S. I did design a method vaguely similar to this for exchanging
contact information between mobile phone users that required the
support of the mobile network operator.

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 26 Sep 2007 13:09:07 +0200

> record of each others' phone numbers.

SIP URIs and home addresses are too long (an IPv6 address
is 16 bytes long and random looking, a SIP URI can be very
long e.g. up to 30 characters and even more with a random
part for privacy).

I would appreciate comments on this. Maybe we should move
to the mailing list if you are interested?

> a way to sync a phonebook with a PC. Job done.

I don't understand.

> can adress that (number 1 above) by simply doing nothing.

I really don't understand.

--Michael Dillon
> support of the mobile network operator.

I would be interested. Is there an I-D or something?

pars

---

From: "Virendra Gandhi" <[email-masked]>
Date: Wed, 26 Sep 2007 20:25:48 +0530

Hi Pars,
This is the classic John Smith problem, what you mention comes after
the target is identified, but first comes the John Smith problem,
there could be multiple John Smiths so it is necessary which John
Smith the querier  wants further as is also mentioned by others in
these discussions the location has to also come into play.

An interesting quote "Names are an important key to what a society
values. Anthropologists recognize naming as 'one of the chief methods
for imposing an order on perception'. David Slawson.

So first Naming has to be set right mentioned here an example of the
magnitude of this problem, Recently there was an article that mentions
quote " Shanghainese frustrated over name game" in which it states
that there are over 3937 people named Chen Jie and 3751 people named
Zhang Min and purely in terms of Surnames (last name) Zhang comes out
first with almost 90000 occurrences Unquote. Similarly practically
every third person in Korea is a Kim and if I talk about Indians I bet
you must have heard of at least one Patel not to mention John Smith in
any English speaking country. It is necessary not only to know which
Zhang or Patel or John Smith one is talking about but also to trace
/locate/ search the right one universally from Domain or related way.

I am working on Naming and it could not only solve the problem
mentioned by you but also others like say one of the ideas prevailing
during the dot com boom was that if one is driving around and passes
by a restaurant and wants to talk to people for reservation it would
be possible and other problems of Convergence for example titled 'The
beast of complexity' Apr 12th 2001 From The Economist print edition
Stuart Feldman the director of IBM's Institute for Advanced Commerce
states, Quote "Imagine, says the man from IBM, that you are running on
empty and want to know the cheapest open petrol station within a mile.
You speak into your cellphone, and seconds later you get the answer on
the display. This sounds simple, but it requires a combination of a
multitude of electronic services, including a voice-recognition and
natural-language service to figure out what you want, a location
service to find the open petrol stations near you and a
comparison-shopping service to pick the cheapest one. Unquote. Now
such services would require a platform where 'all users and service
providers' are registered, this (Won) would then be the platform for
all such net services and also help enabling compatibility and
convergence. Yet again this would only be possible if the Namespace
problem is solved.

 The cell phone will definitely enable wonders but first Naming has to
be in place

World On Net.
Virendra Gandhi

>
>
> On 9/26/07, Pars Mutaf <[email-masked]> wrote:
> >