[Sip] IETF solution for pairing cellular hosts

"Pars Mutaf" <pars.mutaf@gmail.com> Thu, 27 September 2007 13:49 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatkV-0000vD-Uy; Thu, 27 Sep 2007 09:49:51 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IatkT-0000rS-8k for sip-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:49:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatkS-0000r8-Kd for sip@ietf.org; Thu, 27 Sep 2007 09:49:48 -0400
Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IatkM-0006ir-8k for sip@ietf.org; Thu, 27 Sep 2007 09:49:48 -0400
Received: by nf-out-0910.google.com with SMTP id d21so1853722nfb for <sip@ietf.org>; Thu, 27 Sep 2007 06:49:13 -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:mime-version:content-type; bh=0lBQxFvmGvK/jfuTDD/ZiBFcEHhtvxEmwBsLS60P+H0=; b=tHzYlrz9fdinr2Oy0RRW9AiS2NHWfS9UNunI6PSZxoaxI7a93SAwWr+44tBXMdWgTT968n3hijfJToctYgvu6hRDIUn16dZarvHhmkN0qiglw1hUJtKsY7tNJUZthVAeVORSM7hPNu7NE5kvSie9HfwV2aYRLfDuDmfdqM+0JRg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=OUA/kQkbG/metpnholMx0u9xJ/t9Ko0lHGEXjeZ+TQAy7yesORXvoqVvVw5M8YhDo1Qrged1TT5CaIKXx29HDausm+J1w23L8dcisr7S3nJmtfqleoPewYm9PCHnNnSubQ/fu4MGrqIZ/hfVR8Y9Fwh6NDMu6Hywco2MV/gY2FA=
Received: by 10.78.177.3 with SMTP id z3mr1791437hue.1190900953104; Thu, 27 Sep 2007 06:49:13 -0700 (PDT)
Received: by 10.70.22.4 with HTTP; Thu, 27 Sep 2007 06:49:13 -0700 (PDT)
Message-ID: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com>
Date: Thu, 27 Sep 2007 15:49:13 +0200
From: Pars Mutaf <pars.mutaf@gmail.com>
To: sip@ietf.org, p2psip@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc:
Subject: [Sip] IETF solution for pairing cellular hosts
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1739867692=="
Errors-To: sip-bounces@ietf.org

[sorry for cross posting. this is an invitation]


Pairing Cellular Hosts

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

Currently there are two approaches for obtaining 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.


=======================

Interested folks could you please subscribe to the mailing list created
for this discussion:

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



We already had some discussions on the IETF list recently.
You may want to take a look at the archives for an introduction:

http://www1.ietf.org/mail-archive/web/ietf/current/msg48129.html

There is also a side discussion on CAPTCHAs:

http://www1.ietf.org/mail-archive/web/ietf/current/msg48172.html


Regards,
pars mutaf
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip