Subject: Re: [Hipsec] processing review comments on RFC 5201-bis

From: Miika Komu <[email-masked]>
Date: Wed, 02 Jul 2014 17:26:59 +0300

Hi,

On 06/30/2014 08:46 PM, Tom Taylor wrote:
>> 3) Section 5.2.18: given the strict ordering of HIP parameters, the
>> initial
>> plaintext for the Encrypted content (type and length of initial
>> parameter) may be fairly easily guessed. This opens up the minor
>> possibility of a known plaintext attack. [Comment to be reviewed after
>> further examination.] [Upon review: I1 packets have fixed type but
>> variable length due to varying lengths of DH-GROUP-LISTS. The set of
>> such lengths is limited, however, so it is worth considering whether
>> known plain-text attacks offer any real threat.]
>>
>> Discussion:  I don't know how/whether to handle this, or whether other
>> similar vulnerabilities in other security protocols are addressed.
>> Changes to address this would likely complicate things or increase the
>> packet sizes.
>
> [PTT] I have to leave it to people more knowledgeable in security to
> judge whether this is a realistic attack. One point of approach is to
> find out what sample size is needed for known plain-text attacks for
> specific algorithms, compare that with the rate at which an attacker
> could collect encrypted messages in specific scenarios, and decide
> whether there is a real threat. Mitigation presumably might be through
> adjustment of the rate of key rollover.

do we actually need the encrypted parameter for something really 
critical (i.e. some extensions rely on it)? If not, we could just remove 
it. Usually the encrypted parameter just contains the HOST_ID of the 
Initiator which does not really offer any real privacy since the HIT is 
in plaintext and actually can interfere with middleboxes (as already 
mentioned in the draft).

If the encrypted parameter is critical, here's a straw-man proposal that 
avoids increasing packet size: XOR the contents of the encrypted 
parameter by iterating through it block-by-block using the encryption 
key. Then, encrypt it with the same key.

If packet size is not a problem, we could include an extra, fixed size 
key for XORing within the encrypted parameter. Or perhaps just encrypt 
the plaintext twice with the encryption key.

(My solutions are presented in chronologically in the order of my 
personal preference)

---

From: Miika Komu <[email-masked]>
Date: Wed, 02 Jul 2014 18:32:36 +0300

Hi,

> (My solutions are presented in chronologically in the order of my

on second thought, do we actually have a real problem here? Let us consider:

* The encryption key is different for each base exchange, so the roll 
over is actually occurring every time, so that observing multiple base 
exchanges does not benefit the attacker
* To derive the encryption key, you need a very expensive brute for 
search, and the award is (usually) just the public key of the initiator
* If the parameter contains something else in addition to the public 
key, the brute force search is still very expensive (exponential)
* The default algo (AES) is resistant against linear and differential 
cryptanalysis

So, I am not convinced that the current mechanism should be changed.

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 06 Jul 2014 06:28:51 -0400

On 07/02/2014 10:26 AM, Miika Komu wrote:
> critical (i.e. some extensions rely on it)? If not, we could just
> remove it. Usually the encrypted parameter just contains the HOST_ID
> of the Initiator which does not really offer any real privacy since
> the HIT is in plaintext and actually can interfere with middleboxes
> (as already mentioned in the draft).

There are other uses for the encrypted parameter.  It should not be removed.

>
> If the encrypted parameter is critical, here's a straw-man proposal
> that avoids increasing packet size: XOR the contents of the encrypted

Sounds interesting.

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 06 Jul 2014 06:33:16 -0400

> So, I am not convinced that the current mechanism should be changed.

Also there is an assumption of what the first type value is?  Other uses 
of it may not contain the Host_ID, but something else.  And thus the 
length would be different according to that something else type.

I might point out that HIP DEX uses ENCRYPT parameter.  I am sure there 
are others.

---

From: Rene Hummen <[email-masked]>
Date: Mon, 21 Jul 2014 14:17:01 +0000

On 02 Jul 2014, at 17:32, Miika Komu <[email-masked]> wrote:

> * The encryption key is different for each base exchange, so the roll over is actually occurring every time, so that observing multiple base exchanges does not benefit the attacker

Just for the sake of completeness: The ENCRYPTED parameter can also be used in other messages such as UPDATE (currently not the case). Still, this is a low volume control channel. 

> * To derive the encryption key, you need a very expensive brute for search, and the award is (usually) just the public key of the initiator
> * If the parameter contains something else in addition to the public key, the brute force search is still very expensive (exponential)

The award of a known plaintext attack would be the encryption key not just the the content of the ENCRYPTED parameter. HIP_MAC would not be compromised though as it uses its own key. Nevertheless ...

> * The default algo (AES) is resistant against linear and differential cryptanalysis

This would also be my conclusion.

> So, I am not convinced that the current mechanism should be changed.

+1

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/