Re: [Hipsec] NULL encryption mode in RFC 5202-bis

Tom Henderson <> Wed, 09 July 2014 20:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CCA1B1A0463 for <>; Wed, 9 Jul 2014 13:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FmNB54t5N1mB for <>; Wed, 9 Jul 2014 13:27:25 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id B02711A0421 for <>; Wed, 9 Jul 2014 13:27:25 -0700 (PDT)
Received: (qmail 5719 invoked by uid 0); 9 Jul 2014 20:27:20 -0000
Received: from unknown (HELO cmgw4) ( by with SMTP; 9 Jul 2014 20:27:20 -0000
Received: from ([]) by cmgw4 with id QST91o00s2molgS01STCoc; Wed, 09 Jul 2014 20:27:19 -0600
X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=gJ5Z7B3MS4cA:10 a=q7J0aIbBmN8A:10 a=IkcTkHD0fZMA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=JYugLowsNTKLHXIckQ0A:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=cugmGxYKbC2Z0oQ7WKO/+9EE/r+NzsjFPHWovV+HfE0=; b=Nxt4gpJBM2SuILh4VBzI5sys/vWJYAvTapT70upfgBsGg/tRNY/pMdO+GJGApvCf5r5pCMNKzrKceUfmzm9XxZAAe7MnjG4t3HRgD/8CIBh03nkPwpIzLsWAtFcMIAYg;
Received: from [] (port=47608 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1X4ySN-0006Oy-0J; Wed, 09 Jul 2014 14:27:11 -0600
Message-ID: <>
Date: Wed, 09 Jul 2014 13:27:08 -0700
From: Tom Henderson <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Robert Moskowitz <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
Cc:, Stephen Farrell <>
Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Jul 2014 20:27:27 -0000

On 07/09/2014 07:48 AM, Robert Moskowitz wrote:
> Sent to the HIPSEC list from my HIPSEC user:
> The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed
> payload, and in many use cases, the Initiator has pre-deteremined the
> Responder's HI and HIT so it can check the SIG before processing the ESP
> TRANSFORM parameters. In sensornets where the Initiator cannot
> pre-determine the Responder's (typically some sensor controller) HI and
> HIT, then it is a concern.
> Further eventhough I1 is unsigned, the Initiator 'knows' what suites it
> wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC
> back, it MUST NOT complete the exchange. If in the R1 it gets NULL,
> CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC.
> If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST
> NOT complete the exchange.
> The HIP design team spent a long time working out downgrade attacks. I
> have to thank Tobias Heer and Miika Komu for a couple day design when I
> was visiting HIIT in Helsinki.
> NULL, CMAC, or GMAC should only be configured as allowable suites when
> they are needed for debug, or the situation requires auth-only. And I
> should point out there are devices and situations where auth-only is the
> case, so those suites are needed. IMNSHO.
> In the worst case scenario, we could cover with text that clearifies the
> privacy versus auth-only suites with requirements that these suites not
> be mixed in an exchange and if one is expected, the other not accepted.
> Of course 'servers' (I say that parenthetically, as HIP is a peer
> exchange) MIGHT need to support both classes of customers and thus need
> to respond based on the unprotectable I1 packet. Even there, the
> Initiator still can bid back if its I1 was altered by a MiTM.

I would be fine with lessening this MUST to SHOULD.  We probably should 
do the same for RFC 5201 (the HIP CIPHER).

Below are some suggested edits along the lines of your suggestions 
above; any comments or concerns?

In Section 5.2.8 of RFC 5201-bis:


    Mandatory implementation: AES-128-CBC.  NULL-ENCRYPTION [RFC2410] is
    included for testing purposes.


    Mandatory implementation: AES-128-CBC.  Implementors SHOULD support 
NULL for testing/debugging purposes, but MUST NOT offer or accept this 
value unless explicitly configured for testing/debugging of the HIP 

In Section 3.3.5 of RFC 5202-bis:


    In addition to AES-128-CBC, all implementations MUST implement the
    ESP NULL encryption algorithm.  When the ESP NULL encryption is used,
    it MUST be used together with SHA-256 authentication as specified in
    Section 5.1.2


    In addition to AES-128-CBC, all implementations SHOULD implement the
    ESP NULL encryption algorithm.  When the ESP NULL encryption is used,
    it MUST be used together with SHA-256 authentication as specified in
    Section 5.1.2.

    When an authentication-only suite is used (NULL,
    AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT
    be accepted if offered by the peer unless the local policy
    configuration regarding the peer host is explicitly set to allow an
    authentication-only mode.  This is to prevent sessions from being
    downgraded to an authentication-only mode when one side's policy
    requests privacy for the session.

In Section 5.1.2 of RFC 5202-bis:


    Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL
    with HMAC-SHA-256.


    Mandatory implementation: AES-128-CBC with HMAC-SHA-256.  NULL with
    HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5).

- Tom