Message-ID: <53BD5652.300@htt-consult.com>
Date: Wed, 09 Jul 2014 10:48:50 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, 
 Tom Henderson <tomh@tomh.org>, hipsec@ietf.org
References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie>
 <53BBE66D.2080807@htt-consult.com>
In-Reply-To: <53BBE66D.2080807@htt-consult.com>
Content-Type: multipart/alternative;
 boundary="------------080309080402040008010308"
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/HSXG3IfpO9rP5IuoutxWLp6mI-w
Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis
Precedence: list

This is a multi-part message in MIME format.
--------------080309080402040008010308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.



--------------080309080402040008010308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Sent to the HIPSEC list from my HIPSEC user:<br>
    <br>
    <div class="moz-text-flowed" style="font-family: -moz-fixed;
      font-size: 12px;" lang="x-western">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.
      <br>
      <br>
      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.
      <br>
      <br>
      If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it
      MUST NOT complete the exchange.
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      <br>
    </div>
  </body>
</html>

--------------080309080402040008010308--