Re: [Hipsec] NULL encryption mode in RFC 5202-bis
Robert Moskowitz <rgm@htt-consult.com> Wed, 09 July 2014 14:49 UTC
Return-Path: <rgm@htt-consult.com>
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 1E70C1A05C3 for <hipsec@ietfa.amsl.com>; Wed, 9 Jul 2014 07:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 qQC7jh1HSM2A for <hipsec@ietfa.amsl.com>; Wed, 9 Jul 2014 07:49:05 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2E1A0AE8 for <hipsec@ietf.org>; Wed, 9 Jul 2014 07:49:05 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D0A9862A71; Wed, 9 Jul 2014 14:49:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cyb3HshsHaLi; Wed, 9 Jul 2014 10:48:54 -0400 (EDT)
Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 0163063418; Wed, 9 Jul 2014 10:48:53 -0400 (EDT)
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
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: Wed, 09 Jul 2014 14:49:07 -0000
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.
- [Hipsec] NULL encryption mode in RFC 5202-bis Tom Henderson
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Miika Komu
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Stephen Farrell
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Stephen Farrell
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Tom Henderson
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Paul Lambert
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… James Cloos
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… James Cloos
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Paul Lambert
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Henry B Hotz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Edward Lopez
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon