Re: [humanresolv] Trying to open discussion

"Pars Mutaf" <pars.mutaf@gmail.com> Fri, 21 March 2008 08:47 UTC

Return-Path: <humanresolvers-bounces@ietf.org>
X-Original-To: ietfarch-humanresolvers-archive@core3.amsl.com
Delivered-To: ietfarch-humanresolvers-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFFE3A6BAE; Fri, 21 Mar 2008 01:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.661
X-Spam-Level:
X-Spam-Status: No, score=-100.661 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOH-q1QAiK-v; Fri, 21 Mar 2008 01:47:10 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64C03A6949; Fri, 21 Mar 2008 01:47:10 -0700 (PDT)
X-Original-To: humanresolvers@core3.amsl.com
Delivered-To: humanresolvers@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DA33A68C1 for <humanresolvers@core3.amsl.com>; Fri, 21 Mar 2008 01:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rrEOqJBscpw for <humanresolvers@core3.amsl.com>; Fri, 21 Mar 2008 01:47:08 -0700 (PDT)
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by core3.amsl.com (Postfix) with ESMTP id 1863B3A6949 for <humanresolvers@ietf.org>; Fri, 21 Mar 2008 01:47:07 -0700 (PDT)
Received: by wx-out-0506.google.com with SMTP id i26so1516357wxd.31 for <humanresolvers@ietf.org>; Fri, 21 Mar 2008 01:44:47 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YF+crK1/aWJcuKIpZX1fqD+0EMFUGQxQiuD9CVnWtA8=; b=T34i37nMJJvj/DWh7m/VAyUEVKHeMkWJxUW3TQvmka9Hm/duafTqaMfqF48ZDfs5+uuDdEyGieg+iz9QeDWeUxyD/5OWESd80PP6Mo4iJxYSng4zOq6xHlz0icNYcVSUsc2YhNLE2ziCn81/JnqxrLmzU0/DCXNlyTpoi/dJveM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GCk6PeZdsLcrzfbKYeN/DnJzb3zb9Wnh9/SMSg5+QiKNa3rTITSaFdyXUsudL2k8iWFUcTgdZHTprVr/MGqxm30uHiHiT10kG7R2b0ui/vqWU0oKBWCvrWs6ErTfXhFXieaP9Do+d7NTXt6b6LqkydKWtNnRiDXVGFoiexd7jr8=
Received: by 10.70.77.17 with SMTP id z17mr3855344wxa.88.1206089087167; Fri, 21 Mar 2008 01:44:47 -0700 (PDT)
Received: by 10.70.110.8 with HTTP; Fri, 21 Mar 2008 01:44:47 -0700 (PDT)
Message-ID: <18a603a60803210144w62e84ecdtf0bbfa94e3298949@mail.gmail.com>
Date: Fri, 21 Mar 2008 10:44:47 +0200
From: Pars Mutaf <pars.mutaf@gmail.com>
To: humanresolvers@ietf.org
In-Reply-To: <18a603a60803201049g3885dd57uef46dc2d2466a053@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <18a603a60803201049g3885dd57uef46dc2d2466a053@mail.gmail.com>
Subject: Re: [humanresolv] Trying to open discussion
X-BeenThere: humanresolvers@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pairing cellular hosts <humanresolvers.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/humanresolvers>
List-Post: <mailto:humanresolvers@ietf.org>
List-Help: <mailto:humanresolvers-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: humanresolvers-bounces@ietf.org
Errors-To: humanresolvers-bounces@ietf.org

More detailed:


IP Pairing protocol

1. Face-to-face

Alice and Bob have face-to-face contact.
Bob tells his pseudo to Alice.
Alice enterw the pseudo.
They perform mutual authentication using a short authentication
string [SAS].
Alice and Bob sign each other's certificate, exchange SIP URIs and
mobile IPv6 home addresses. Note that Alice and Bob can communicate
without using SIP infrastructure since they know each other's home
address.

[SAS] Vaudenay, S., "Secure Communications over Insecure
      Channels Based on Short Authenticated Strings", Advances
      in Cryptology, CRYPTO 2005.

2. Remote

2.1 Web of trust

Bob finds Carol's home address or DNS name on the web. Bob makes a
query to Carol by clicking on the home address, and shows his
certificate signed by Alice. Carol knows Alice, hence she accepts
to return a SIP URI and possibly another home address to Bob.

2.2 Certification authority (CA)

Bob and Carol may also have cerfiticates signed by the same SA.
In this case, Carol can accept Bob's query.

3. Pairing update

The pairing protocol should take care of pairing state
changes e.g. SIP URIs, home addresses, requesting additional
information HTTP access to the target phone etc.




On Thu, Mar 20, 2008 at 7:49 PM, Pars Mutaf <pars.mutaf@gmail.com> wrote:
> Hello humanresolvers,
>
>  Hoping that this ML is not my personal IETF blog ;-)
>  I would like to ask your opinion on the following idea.
>
>  Pairing protocol (basic)
>  ========================
>
>  What it does?
>
>  1. Mutual authentication using [SAS].
>  2. Sign each other's certificate.
>  3. Exchange SIP URIs.
>  4. Exchange Mobile IPv6 home addresses and other information.
>
>  What is the outcome?
>
>  1. IPsec or TSL can be used.
>  2. No need to use SIP triangle nor trapezoid.
>         ->More reliable
>         ->Faster connection establishment.
>
>  [SAS] Vaudenay, S., "Secure Communications over Insecure
>       Channels Based on Short Authenticated Strings", Advances
>       in Cryptology, CRYPTO 2005.
>
>  Review of [SAS]:
>  One user tells (i.e. orally) to the other a short auth
>  string and their phone get mutually authenticated. The
>  contribution of [SAS] is that it shortens and simplifies very
>  much the authentication string. 15-20 bits are enough. The
>  general belief is that the pairing problem was solved
>  by this paper.
>
_______________________________________________
humanresolvers mailing list
humanresolvers@ietf.org
https://www.ietf.org/mailman/listinfo/humanresolvers