Subject: [humanresolv] Tentative problem statement

From: "Pars Mutaf" <[email-masked]>
Date: Fri, 26 Oct 2007 14:08:04 +0200

Hello,
Please find below a tentative problem statement, comments are welcome.
pars

                  IP host pairing problem statement

Today, cell phone numbers are not published in a phonebook for avoiding
telemarketers, prank callers, Spam and SPIT (SPam over Internet
Telephony). Users today exchange their phone numbers upon user contact,
often through oral communication.

In IP telephony, users will need a user friendly "pairing" protocol
that identifies the two phones and let them exchange their SIP URIs and
Mobile IPv6 home addresses, and possibly other information. The phones
will establish an IPsec security association upon this first contact.
IPsec will be required not only for protecting their SIP URIs from
eavesdroppers, but also for protecting data.

"IP host pairing" is defined as a pairing protocol that can operate
over IP; upon user contact and also over the Internet i.e. long distances.
It will address three problems of pairing:

1. Pairing when there is user contact: In this case, users can exchange
   their names or pseudonyms helping identify the hosts to each other the
   first time they meet.

2. Re-pairing, or updating pairing state through the Internet: The users
   may change their SIP URIs and/or Mobile IPv6 home addresses or other
   information. The users will need to update these informations without
   waiting until their next meeting. Or, they may need additional
   information which was not previously exchanged when there was user
   contact.

3. Pairing without user contact (where possible): Users may know each
   other but user contact may not be possible. Or, two previously paired
   hosts may lose pairing state. Users cannot probably wait until their
   next meeting to recover from loss of state.

Engineering problems:

   - Identifying the two hosts to each other in (1) and (3).
   - Preventing unauthorized and annoying pairing attempts from unknown
     users.
   - The design of the pairing protocol used to exchange and update
     the SIP URIs, home addresses and possibly other information.
_______________________________________________
humanresolvers mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/humanresolvers

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Oct 2007 17:59:09 +0200

Pars Mutaf wrote:
> Hello, Please find below a tentative problem statement, comments are 
> welcome. pars
> 
> 
> Today, cell phone numbers are not published in a phonebook for 
> avoiding telemarketers, prank callers, Spam and SPIT (SPam over 
> Internet Telephony). Users today exchange their phone numbers upon 
> user contact, often through oral communication.
> 
> that identifies the two phones and let them exchange their SIP URIs 
> and Mobile IPv6 home addresses, and possibly other information. The 
> phones will establish an IPsec security association upon this first 
> contact.

IKE already does this (establish IPsec SA).

> eavesdroppers, but also for protecting data.

IPsec already protects data.

> over IP;

Is ND a host pairing protocol, if so can we say so.  Is Bluetooth a
pairing protocol, if so can we say so.  Is Bluetooth VCARD exchange a
means to achieve what IP host pairing tries to achieve.

> upon user contact and also over the Internet i.e. long distances. It
> will address three problems of pairing:
> 
> 1. Pairing when there is user contact: In this case, users can 
> exchange their names or pseudonyms helping identify the hosts to each
>  other the first time they meet.

Define better "user contact": visual contact?  Natural talk/hear
distance?  "Out-of-band" communication?  Letter-through-mail communication?

(When in a meeting and I want to talk to someone next to me, but talking 
disturbs the meeting, and hushing is too incomprehensible - then I write 
on paper and show the paper.)

> 2. Re-pairing, or updating pairing state through the Internet: The 
> users may change their SIP URIs and/or Mobile IPv6 home addresses or 
> other information. The users will need to update these informations 
> without waiting until their next meeting. Or, they may need 
> additional information which was not previously exchanged when there 
> was user contact.
> 
>  other but user contact may not be possible. Or, two previously 
> paired hosts may lose pairing state. Users cannot probably wait until
>  their next meeting to recover from loss of state.
> 
> Engineering problems:
> 
> - Identifying the two hosts to each other in (1) and (3). - 
> Preventing unauthorized and annoying pairing attempts from unknown 
> users. - The design of the pairing protocol used to exchange and 
> update the SIP URIs, home addresses and possibly other information.

I think ND with link-local addresses, followed by an IKE exchange and
then by some extensions to "IPv6 Node Information Queries" rfc4620
(extensions to deliver the URI, or the phone number, instead of just the 
FQDN) - can do the trick.  Could this work?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Pars Mutaf" <[email-masked]>
Date: Mon, 29 Oct 2007 11:22:30 +0100

Hi Alex,

> IPsec already protects data.

Our goal is to obtain a SIP URI and home address from the target device,
and to establish an IPsec SA using IKE with the target device, **if
accepted**
by the target user.  For example, the target user will see a message on the
screen "Pairing request from Michael Knight. Accept?" .  If accepted by
the target user, the devices will exchange SIP URIs, home addresses, etc.,
and create an IPsec SA using standard IKE(v2).

IKE, for example, does not ask user authorization.

We can also make IKE authentication easier.
We can use human name certificates, or something like the PGP web of
trust or self-signed certificates perhaps. Authentication is in general
considered a difficult problem, and requires global PKI hierarchy. This  is
not true in our case. I hope we can talk about that. My guess is that
we can use certificates.

> pairing protocol, if so can we say so.

ND is not a pairing protocol. Bluetooth has a pairing function.

Pairing, in general, is about introducing two devices to each other
(there is human intervention), creating a security association, and
making sure that your device is paired with the intended device and
not with an attacker's device.

You may want to look at the following paper to have some ideas:
sparrow.ece.cmu.edu/~adrian/projects/sib.pdf

Is Bluetooth VCARD exchange a
> means to achieve what IP host pairing tries to achieve.

Please see above. I'm not sure Bluetooth pairing can be used for
creating an IPsec SA. I also don't see why we would do this for
Bluetooth. See also below, the problems (2) and (3) can not be addressed
via Bluetooth.

> distance?  "Out-of-band" communication?  Letter-through-mail

Good point.

> FQDN) - can do the trick.  Could this work?

Please see above. We need more than that.

Thanks,
pars

Alex

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 30 Oct 2007 19:09:31 +0100

A simplified alternate take based on Alex's comments.
Thanks,
pars

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

In the current model of operation (phone number privacy obligates it),
cell phone users exchange their phone numbers upon user contact. This
model is likely to persist in IP telephony, yet under exploited and can be
extended using an IP protocol. Upon their meeting, an "IP host pairing"
protocol can allow two cell phone users to:

  1. Exchange their SIP URIs, mobile IPv6 home addresses, and possibly
     other information.
  2. Establish an IPsec security association using IKEv2.

under user control, i.e. _if accepted_ by the users. For example, one
user will initiate a pairing request, and the target user's phone display
the initiator user's human name and ask for approval.

Since there is user contact, IKEv2 authentication can be less challenging
than the general case. I.e., a global PKI hierarchy is probably not
needed. Solutions like password-based IKEv2 authentication can be applied.
Human name certificates can be applicable, certificate revocation may not
be needed, and human name collisions may not be harmful in this context.
Certificates may be signed by the cellular operators for example, or
PGP-like web of trust solutions may be applicable.

An IP-layer pairing solution can also allow for re-pairing or updating
the pairing state through the Internet. The users may change their
SIP URIs and/or Mobile IPv6 home addresses or other information. The users
will need to update these informations without waiting until their next
meeting. Or, they may need additional information which was not previously
exchanged when there was user contact.

On 10/29/07, Pars Mutaf <[email-masked]> wrote:
> sparrow.ece.cmu.edu/~adrian/projects/sib.pdf<http://sparrow.ece.cmu.edu/%7Eadrian/projects/sib.pdf>
>
>

---

From: "Vanderveen, Michaela" <[email-masked]>
Date: Tue, 30 Oct 2007 11:37:19 -0700

Hi Pars,

It seems that this problem is targeted at peer-to-peer scenarios rather
than client-server. Therefore password-based authentication (e.g. IKEv2
with EAP) does not fit well, unless users are sharing passwords? Would
you clarify what you mean by the statements below (snipped). I for one
don't see how users can possess some shared keys without also possessing
the other party's associated private info. In order words, a public key
infrastructure might be required.

Also, as you mention in your PQI draft, the problem of selective user
blocking should be kept in mind; it's not fully addressed in the
description below. Specifically, users should be able to turn
undiscoverable to a particular user with whom they already shared SIP
URIs, phone nrs, etc. Such as example is the selective user blocking and
unblocking feature of popular Instant Messaging apps. Changing phone
numbers is cumbersome, and made even more difficult if one wishes to
re-instate that user.

Best regards,

Michaela

"My own opinions only."

> -----Original Message-----
> From: Pars Mutaf [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2007 11:10 AM
> To: Alexandru Petrescu
> Cc: [email-masked]
> Subject: Re: [humanresolv] Tentative problem statement
> 
> > by the target user.  For example, the target user will see a message
on
> > the
> > considered a difficult problem, and requires global PKI hierarchy.
This
> > is
sparrow.ece.cmu.edu/~adrian/projects/sib.pdf<http://sparrow.ece.cmu.edu/
%7
> Eadrian/projects/sib.pdf>
> >
> >
> > > (extensions to deliver the URI, or the phone number, instead of
just
> the

---

From: "Pars Mutaf" <[email-masked]>
Date: Tue, 30 Oct 2007 20:26:01 +0100

Hi Michaela,

> infrastructure might be required.

Since there is user contact, one user can tell the other a password used
for IKE authentication (IKEv2 requires EAP for this to defeat off-line
dictionary attacks, unless I'm missing something). The idea comes from EKE
and is adopted by IKEv2 if I'm not wrong.

Note for example that in Bluetooth pairing the user types the same
PIN number to both devices to get them paired. Bluetooth chose
to specify a non-EKE protocol which was perhaps considered too
CPU expensive for devices like headsets etc (correct me if I'm wrong).
Result, it is severely broken:

http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/

Specifically, users should be able to turn
> numbers is cumbersome, and made even more difficult if one wishes to

I'm not sure to understand this sounds like a requirement to me?

Regards,
pars

Best regards,

---

From: "Vanderveen, Michaela" <[email-masked]>
Date: Tue, 30 Oct 2007 12:35:46 -0700

Hi Michaela,

MCV>> That is fine, EKE is understood, but I didn't know how wide-spread password sharing is.

<snip>

MCV>> This is "IP host de-pairing" if you wish. Not necessarily a requirement, but desirable IMO. And of course we don't mean just putting an expiration time on shared credentials. Ideally hosts should be able to disable the pairing with other hosts immediately upon user action. This translates in not being reachable by this one other agent at the old SIP URI, for example.

Regards,
pars 

Best regards,

Michaela

"My own opinions only."

> From: Pars Mutaf [mailto: [email-masked]]
> On 10/29/07, Pars Mutaf < [email-masked]> wrote:
> >
> > Hi Alex,
> >
on
This
just

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 31 Oct 2007 17:40:28 +0100

On 10/30/07, Vanderveen, Michaela <[email-masked] > wrote:
> MCV>> This is "IP host de-pairing" if you wish. Not necessarily a
> requirement, but desirable IMO. And of course we don't mean just putting an
> expiration time on shared credentials. Ideally hosts should be able to
> disable the pairing with other hosts immediately upon user action. This
> translates in not being reachable by this one other agent at the old SIP
> URI, for example.

OK I see. Maybe it is also noteworthy that SIP is probably not the only
protocol that will be used between paired hosts.
Some folks are interested in "mobile web servers". They also explain why
this is a good idea:

http://wiki.opensource.nokia.com/projects/Mobile_Web_Server

(note that in our case we don't need a special infrastructure, Mobile IPv6
takes care of routing)

Using IP pairing:
-Alice and Bob share their SIP URIs.
-Alice also offers an Web URL to allowing Bob access her photos stored in
her phone for example.

All exchanges are secured by IPsec.

Bob is authorized to call Alice. He can also look at photos taken by Alice
using a standard web
browser. Later Alice can cancel the HTML access to her phone. Bob can still
make a SIP call, but
no longer look at photos or other files.

What do you think?

pars

---

From: "Vanderveen, Michaela" <[email-masked]>
Date: Wed, 31 Oct 2007 11:24:54 -0700

Hi Pars

Please see inline.

Michaela

________________________________

From: Pars Mutaf [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2007 9:40 AM
To: Vanderveen, Michaela
Cc: [email-masked]
Subject: Re: [humanresolv] Tentative problem statement

MCV>> This is "IP host de-pairing" if you wish. Not necessarily a
requirement, but desirable IMO. And of course we don't mean just putting
an expiration time on shared credentials. Ideally hosts should be able
to disable the pairing with other hosts immediately upon user action.
This translates in not being reachable by this one other agent at the
old SIP URI, for example. 

OK I see. Maybe it is also noteworthy that SIP is probably not the only
protocol that will be used between paired hosts.
Some folks are interested in "mobile web servers". 

MCV>> Understood about SIP.

They also explain why this is a good idea: 

(note that in our case we don't need a special infrastructure, Mobile
IPv6 takes care of routing) 

MCV>> Not sure whether the MWS covers this case, as the "Access Control"
and "Security & Privacy" sections are "to be added"...

Using IP pairing:
-Alice and Bob share their SIP URIs. 
-Alice also offers an Web URL to allowing Bob access her photos stored
in her phone for example. 

Bob is authorized to call Alice. He can also look at photos taken by
Alice using a standard web 
browser. Later Alice can cancel the HTML access to her phone. Bob can
still make a SIP call, but 
no longer look at photos or other files. 

What do you think?

MCV>> Perhaps in this type of scenario this is as good as de-pairing
gets. I don't have any better ideas for now.

pars