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

Rene Hummen <Rene.Hummen@comsys.rwth-aachen.de> Mon, 21 July 2014 14:17 UTC

Return-Path: <Rene.Hummen@comsys.rwth-aachen.de>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167BA1A0025 for <hipsec@ietfa.amsl.com>; Mon, 21 Jul 2014 07:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH8cL9hKLIXY for <hipsec@ietfa.amsl.com>; Mon, 21 Jul 2014 07:17:05 -0700 (PDT)
Received: from mx-out-1.rwth-aachen.de (mx-out-1.rwth-aachen.de [134.130.5.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF081A001D for <hipsec@ietf.org>; Mon, 21 Jul 2014 07:17:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.01,701,1400018400"; d="p7s'?scan'208";a="340855516"
Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-1.rz.rwth-aachen.de with ESMTP; 21 Jul 2014 16:17:03 +0200
Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.nets.rwth-aachen.de (Postfix) with ESMTP id 30C5913DAB9; Mon, 21 Jul 2014 16:17:03 +0200 (CEST)
Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee]) by MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee%12]) with mapi id 14.01.0218.012; Mon, 21 Jul 2014 16:17:02 +0200
From: Rene Hummen <Rene.Hummen@comsys.rwth-aachen.de>
To: HIP <hipsec@ietf.org>
Thread-Topic: [Hipsec] processing review comments on RFC 5201-bis
Thread-Index: AQHPkvnhfwLtqf32AUCGb60aDjBTvJuJzwYAgALs3ICAABJWAIAdxywA
Date: Mon, 21 Jul 2014 14:17:01 +0000
Message-ID: <4FAC761D-1596-46B4-9F00-808E5C1B0E82@comsys.rwth-aachen.de>
References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> <53B416B3.1030307@cs.hut.fi> <53B42614.1070108@cs.hut.fi>
In-Reply-To: <53B42614.1070108@cs.hut.fi>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [137.226.12.29]
Content-Type: multipart/signed; boundary="Apple-Mail=_3789F9BE-A8F9-46E8-8990-3CBB0101BB3B"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/IrR7aeo_BID7vy9sL2MKoze4RkM
Subject: Re: [Hipsec] processing review comments on RFC 5201-bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 14:17:08 -0000

On 02 Jul 2014, at 17:32, Miika Komu <mkomu@cs.hut.fi> wrote:

> Hi,
> 
> On 07/02/2014 05:26 PM, Miika Komu wrote:
>> 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)
> 
> 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

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/