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

[Tobias Heer <[e-mail]>]

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

Hello,

Am 16.02.2011 um 09:23 schrieb Andrei Gurtov:

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

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

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."

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk1bkBgACgkQf4eSaa7spb8DegCfWV6bCoDfVyj9bPauPBEaXpWV
dj0AoKAFLezZHvHxmcbiC/444GV8oBeV
=1mX5
-----END PGP SIGNATURE-----