Re: [humanresolv] Tentative problem statement

"Pars Mutaf" <pars.mutaf@gmail.com> Mon, 29 October 2007 10:23 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 1ImRm2-0002Up-5Q; Mon, 29 Oct 2007 06:23:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImRm1-0002Uk-FA for humanresolvers@ietf.org; Mon, 29 Oct 2007 06:23:09 -0400
Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImRlv-00067i-5C for humanresolvers@ietf.org; Mon, 29 Oct 2007 06:23:09 -0400
Received: by wx-out-0506.google.com with SMTP id s8so1445442wxc for <humanresolvers@ietf.org>; Mon, 29 Oct 2007 03:22:30 -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=rqO+eFpdSnDwdeHovNBjKX+aIOXDPEcNM3xvTZ/IXHM=; b=qy+diSgoXoHMvaeRo9qlGx+gK09KZ9+Gyq/9LTc6qzoicwPpiW1Yt+gvr5aIr0cyRstCHDfAOCmowVs6hBE5AwlFTWA7TMzN76HffSemWIjxnFwDOAlkhw5Cjixzgxz+AmRlB7VE/mjnZZorPtZK0Rv8v9L1ZGlB4h9L2UGFh4Y=
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=kEdjRgrLvNBE9W8JrRXRrEqvfzCWYn1nKGXSrH81VWOXZxEfhsRUMQ56TqJInDuWD9BT2+sC45ac9A83lZrDe/TztZAvReB1FPX/ln89bCG/Aj/KUy36Jmx7plXxgf24DQjh4nqmJXnulxh8ofwytzI8i7ch7ZBFE31drcQxMDs=
Received: by 10.70.69.2 with SMTP id r2mr10362313wxa.1193653350608; Mon, 29 Oct 2007 03:22:30 -0700 (PDT)
Received: by 10.70.117.20 with HTTP; Mon, 29 Oct 2007 03:22:30 -0700 (PDT)
Message-ID: <18a603a60710290322n151e0650hd9f405957f67c169@mail.gmail.com>
Date: Mon, 29 Oct 2007 11:22:30 +0100
From: Pars Mutaf <pars.mutaf@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Subject: Re: [humanresolv] Tentative problem statement
In-Reply-To: <47220ECD.9020204@gmail.com>
MIME-Version: 1.0
References: <18a603a60710260508h281a126bjda7179c2b896448b@mail.gmail.com> <47220ECD.9020204@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
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 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


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