Subject: [Cfrg] question about DH identity theft vulnerabilities

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 27 Feb 2011 21:21:51 -0800

I am trying to finalize a HIP research group document [1] and I am trying to validate the below claim that appears in Section 6 (User Privacy Issues) of the draft:

   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.

I would like to know more about the cited vulnerability to understand whether and how it applies to HIP.  The Initiator's public key and identity is revealed in the third message (I2) of the exchange, but the Initiator can choose to encrypt it with a key generated from the DH shared secret.  In such a case, I can't see how an active attacker could successfully find out the public key and identity of the Initiator, since it could not generate itself a valid R1 in response to the Initiator's I1.

Does anyone have an idea about what vulnerability (first sentence in the excerpt above) is being referred to?

Thanks,
Tom

[1] http://tools.ietf.org/html/draft-irtf-hip-experiment-10

---

From: Adam Back <[email-masked]>
Date: Mon, 28 Feb 2011 08:24:10 +0100

I think what they are saying is that with mutual authentication, the client
should not have to reveal its identity to a passive adversary, nor an active
attacker.  (The client's identity being represented by its public key).

(I designed the (2nd gen) forward anonymous key exchange protocol in ZKS
freedom network where identity privacy is a consideration, so I recognize
the design consideration.)

Adam

On Sun, Feb 27, 2011 at 09:21:51PM -0800, Henderson, Thomas R wrote:
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Feb 2011 06:56:25 -0800

I agree with Adam's interpretation of what the draft is trying to say. 
However, I think the draft calling it "identity theft" is a gross 
overstatement. In the common usage, "identity theft" means an attacker 
getting personally identifiable information that can be used to 
impersonate the attacked party.

That is absolutely not what is happening in HIP. An attacker can find 
out the public key being used by the attacked party, and if that key 
comes with a string for matching (such as a domain name or IP address), 
the attacker gets that as well.

Without the private key, the attacker has no way to use the identity 
information to impersonate the attacked party, period.

If there is a concern that the identifying string somehow reveals 
information that can identify the party, then use strings that don't 
reveal such information. Either the relying party needs some good 
identifier for the protocol, or they don't.

--Paul Hoffman