Re: [hiprg] clarification of identity privacy properties of HIP base exchange

Andrei Gurtov <gurtov@hiit.fi> Wed, 16 February 2011 08:23 UTC

Return-Path: <gurtov@hiit.fi>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99CE93A6C6A for <hiprg@core3.amsl.com>; Wed, 16 Feb 2011 00:23:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 TsfbkTI98JAH for <hiprg@core3.amsl.com>; Wed, 16 Feb 2011 00:23:04 -0800 (PST)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 2AFAF3A68A3 for <hiprg@irtf.org>; Wed, 16 Feb 2011 00:23:03 -0800 (PST)
Received: from [10.20.208.12] (gw1.panoulu.net [212.50.147.101]) by argo.otaverkko.fi (Postfix) with ESMTP id D9F7425ED06; Wed, 16 Feb 2011 10:23:29 +0200 (EET)
Message-ID: <4D5B8982.6040306@hiit.fi>
Date: Wed, 16 Feb 2011 10:23:30 +0200
From: Andrei Gurtov <gurtov@hiit.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
References: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.boeing.com>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CED25AE6E@XCH-NW-10V.nw.nos.boeing.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "hiprg@irtf.org" <hiprg@irtf.org>
Subject: Re: [hiprg] clarification of identity privacy properties of HIP base exchange
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Feb 2011 08:23:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henderson, Thomas R wrote:
> There is a paragraph in the HIP experiment report, Section 8:
> http://tools.ietf.org/html/draft-irtf-hip-experiment-10
> for which I am wondering whether it is completely correct.
> 
> 
>    All two-round-trip variations of the Diffie Hellman key exchange
>    using public keys for authentication are vulnerable to identity
>    theft.  The Responder must not generate the shared session key before
>    receiving two messages from the Initiator, to avoid DoS attacks.  If
>    the Responder sends its public key in the first reply message (R1) to
>    the Initiator, the Responder's identity will be revealed to third
>    parties.  The Initiator cannot determine the identity of the
>    Responder until after receiving the last message (R2) of the key
>    exchange.  As a result, an active attacker can find out the public
>    key and identity of the Initiator by pretending to be a trusted
>    correspondent host.  The Initiator's public key is sent encrypted in
>    the third message of the Diffie Hellman key exchange and can be
>    decrypted by an attacker based on the established session key.
> 
> Some questions:
> 1) (fourth sentence) The R1 sends HOST_ID and is signed, so can't the Initiator learn the identity in the first reply message?  Or is this referring to possible R1 replay by an adversary?

- From the content of R1 packet it indeed looks like Initiator can
identify the Responder based on the public key. Replays are a
possibility, but still the attacker wouldn't be able to alter the packet
or misuse the responder's identity, just resend the same packet.

A related question is how R1s can be pre-generated (I think RFC5201
refers to this possibility). R1 includes at least the destination HIT so
how the signature can be constructed in advance? Also the puzzle can
have expiration lifetime.

> 2) (fifth and sixth sentence) In what situations can an active attacker learn the key and identity of the Initiator (if the Initiator chooses to encrypt HOST_ID)?   Opportunistic mode may be one, but are there others?

I guess in any case when the public key of the recipient is not
authenticated (e.g. by DNSSEC) and when the initiator attempts
connecting without taking the ID of Responder from a trusted source.
(e.g. someone storing own public key in DHT under domain name google.com)

Andrei
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1biYIACgkQP7jp0uceFkTznwCg1dshsXsepBvi3skKwzOfcxm+
Pv4AoL0hb12mgvYcZQ5hu8w6wcYPOfD4
=djBX
-----END PGP SIGNATURE-----