Re: [humanresolv] Tentative problem statement

"Pars Mutaf" <pars.mutaf@gmail.com> Tue, 30 October 2007 19:26 UTC

Return-path: <humanresolvers-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imwjp-00062T-3D; Tue, 30 Oct 2007 15:26:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwjH-0005QY-5T for humanresolvers@ietf.org; Tue, 30 Oct 2007 15:26:23 -0400
Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImwjA-0000xE-M5 for humanresolvers@ietf.org; Tue, 30 Oct 2007 15:26:23 -0400
Received: by wx-out-0506.google.com with SMTP id s8so1866744wxc for <humanresolvers@ietf.org>; Tue, 30 Oct 2007 12:26:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=tiloV2aQd6cMHNXCgwXU/tL0pXBcuKy1FIKtV2qmvmo=; b=C09OKzxZH5cfLvUDcrsBrfO/kS1+yfJatiCqsBf/qY/gXLR+8UtZf35EHafpWmC2M13Cn8lyNW8u7JKXS0e0yI8dOlqSZOzCBKVgq1FLCzgBcVRnb9Q8ZxlW3LvImzchyzWoa+7oPGZJv7kxRFZLIjdsdcwaT1LACN0MZp1fF3U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mFP/cEBFp2HIw371E5OxqbCQniL0BvhxMdkouZQcxy/xIWcrwWNhEcOxw8aegvssttIa8IcHpRiSRCrgX+uqVu6pj0nvAZBgJkRWuvFOJzaxVFZhAE5XWSBADiiuKX1OKiRdMVqTxn7mlbXkh6B12zubQsOvuGB8XMujtvhHOvA=
Received: by 10.70.48.11 with SMTP id v11mr13120614wxv.1193772361249; Tue, 30 Oct 2007 12:26:01 -0700 (PDT)
Received: by 10.70.117.20 with HTTP; Tue, 30 Oct 2007 12:26:01 -0700 (PDT)
Message-ID: <18a603a60710301226r42c3c89bs6d406eaec4d9ad39@mail.gmail.com>
Date: Tue, 30 Oct 2007 20:26:01 +0100
From: "Pars Mutaf" <pars.mutaf@gmail.com>
To: "Vanderveen, Michaela" <mvanderv@qualcomm.com>
Subject: Re: [humanresolv] Tentative problem statement
In-Reply-To: <4B3FE0E0367A2F4EB75EE82BC0B21EFCE23A41@NAEX15.na.qualcomm.com>
MIME-Version: 1.0
References: <18a603a60710260508h281a126bjda7179c2b896448b@mail.gmail.com> <47220ECD.9020204@gmail.com> <18a603a60710290322n151e0650hd9f405957f67c169@mail.gmail.com> <18a603a60710301109w17a1de6k3d5984cb08a6cc0b@mail.gmail.com> <4B3FE0E0367A2F4EB75EE82BC0B21EFCE23A41@NAEX15.na.qualcomm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: humanresolvers@ietf.org
X-BeenThere: humanresolvers@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pairing cellular hosts <humanresolvers.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/humanresolvers>
List-Post: <mailto:humanresolvers@ietf.org>
List-Help: <mailto:humanresolvers-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=subscribe>
Errors-To: humanresolvers-bounces@ietf.org

Hi Michaela,

On 10/30/07, Vanderveen, Michaela <mvanderv@qualcomm.com>; wrote:
>
> 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.


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


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

Regards,
pars


Best regards,
>
> Michaela
>
> "My own opinions only."
>
>
> > 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.
> >
>
>
>
>
> > -----Original Message-----
> > From: Pars Mutaf [mailto:pars.mutaf@gmail.com]
> > Sent: Tuesday, October 30, 2007 11:10 AM
> > To: Alexandru Petrescu
> > Cc: humanresolvers@ietf.org
> > Subject: Re: [humanresolv] Tentative problem statement
> >
> > A simplified alternate take based on Alex's comments.
> > Thanks,
> > pars
> >
> > --------------
> >
> >                   IP host pairing problem statement
> >
> > 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 <pars.mutaf@gmail.com>; wrote:
> > >
> > > Hi Alex,
> > >
> > > On 10/26/07, Alexandru Petrescu <alexandru.petrescu@gmail.com>;
> wrote:
> > > >
> > > > Pars Mutaf wrote:
> > > > > 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.
> > > >
> > > > IKE already does this (establish IPsec SA).
> > > >
> > > > > IPsec will be required not only for protecting their SIP URIs
> from
> > > > > eavesdroppers, but also for protecting data.
> > > >
> > > > 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.
> > >
> > >
> > > > "IP host pairing" is defined as a pairing protocol that can
> operate
> > > > > 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.
> > >
> > >
> > > 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<http://sparrow.ece.cmu.edu/
> %7
> > Eadrian/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.
> > >
> > >
> > > > 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?
> > >
> > >
> > > Good point.
> > >
> > > (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.
> > > > >
> > > > > 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.
> > > >
> > > > 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?
> > >
> > >
> > > Please see above. We need more than that.
> > >
> > > Thanks,
> > > pars
> > >
> > >
> > > Alex
> > > >
> > > >
> > > >
> ______________________________________________________________________
> > > > This email has been scanned by the MessageLabs Email Security
> System.
> > > > For more information please visit http://www.messagelabs.com/email
> > > >
> ______________________________________________________________________
> > > >
> > >
> > >
> > _______________________________________________
> > humanresolvers mailing list
> > humanresolvers@ietf.org
> > https://www1.ietf.org/mailman/listinfo/humanresolvers
>
_______________________________________________
humanresolvers mailing list
humanresolvers@ietf.org
https://www1.ietf.org/mailman/listinfo/humanresolvers