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

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 15 Feb 2011 20:47:08 -0800

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

Tom

---

From: Andrei Gurtov <[email-masked]>
Date: Wed, 16 Feb 2011 10:23:30 +0200

> 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, b…

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

---

From: Tobias Heer <[email-masked]>
Date: Wed, 16 Feb 2011 09:51:29 +0100

Hello,

Am 16.02.2011 um 09:23 schrieb Andrei Gurtov:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
For what I can say, the Responder cannot stay anonymous during the exchange. This is mentioned in RFC5201 and there is text on policies: some hosts may not act as responders because of this issue. RFC5201 says, that the BEX can be reversed. The Responder would become the Initiator then -- with a possible deadlock situation of both hosts would implement that policy.

> have expiration lifetime.

There is SIGNATURE_2 the HITs as well as Puzzle I and K are excluded from the signature. I quote:

"Within the R1 packet that contains the
HIP_SIGNATURE_2 parameter, the Initiator's HIT, the
checksum field, and the Opaque and Random #I fields
in the PUZZLE parameter MUST be set to zero while
computing the HIP_SIGNATURE_2 signature."

> (e.g. someone storing own public key in DHT under domain name google.com)
The anonymous bit and the concept of pseudonym HIs is useful here. If these are not used, the Initiator authenticates to the public key/ host identity of the host, and thus, knows the HI.
An interesting question is what the "identity" of the Initiator is.
Is it its real-word identity? You need more information to figure this out?
Is it the HOST identity? This one is revealed without pseudonyms.

BR,

Tobias

---

From: Tobias Heer <[email-masked]>
Date: Wed, 16 Feb 2011 10:00:20 +0100

There was a fatal flaw in my punctiation.... 

> Is it its real-word identity? You need more information to figure this out?
This questionmark should certainly be a fullstop.
The meanong of the sentence is: 

> Is it its real-word identity? You need more information to figure this out.
I meant that one needs some separate register or some knowledge from previous communication for mapping a HI to an identity.

Sorry for any confusion.

Tobias

- -- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 17 Feb 2011 18:20:18 -0800

Thanks for the attempted clarifications, but I am not sure that these types of attacks (binding between a host name and HI, as Andrei suggested, or different concepts of identity) are what is being referred to in this paragraph.  Does anyone have a reference to substantiate this statement?:
>    theft.  

If I understood more clearly the general attacks being referred to here, I could try to relate that to the existing base exchange and better describe the vulnerabilities.  

- Tom