Re: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-07
Vincent Roca <vincent.roca@inrialpes.fr> Wed, 09 September 2009 13:44 UTC
Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362FF28C14F; Wed, 9 Sep 2009 06:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6j0hPYtP-6Q; Wed, 9 Sep 2009 06:44:12 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id BE87E3A69CF; Wed, 9 Sep 2009 06:44:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,358,1249250400"; d="scan'208";a="32463740"
Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Sep 2009 15:44:31 +0200
Message-ID: <4AA7B13F.1090007@inrialpes.fr>
Date: Wed, 09 Sep 2009 15:44:31 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Yaron Sheffer <yaronf@checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8012953655E08@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8012953655E08@il-ex01.ad.checkpoint.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Thu, 10 Sep 2009 00:20:49 -0700
Cc: "msec-chairs@tools.ietf.org" <msec-chairs@tools.ietf.org>, "draft-ietf-msec-tesla-for-alc-norm@tools.ietf.org" <draft-ietf-msec-tesla-for-alc-norm@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 13:44:14 -0000
Dear Yaron, Thanks a lot for your detailed review and comments. Please, find below our answers and explanations on how we addressed them. > General > > Overall this is a good document, but I suspect that it has too many options > and leaves too many things open as to be truly interoperable. So > Experimental is the right designation. From a security point of view, things > seem to be well covered, but see my two comments below. We agree there are too many options. This is one of our concerns and beyond interoperability, complexity is also a source of security concerns. To address this, at least partially, we have removed the four compact authentication tags, i.e. the compact formats where the 32-bit "i" interval index is not provided and is "replaced" by 1 or 3 of the least significant bytes with the i_LSB/i_NSB fields (section 3.4.7. "Format of the Compact Authentication Tags"). Doing so significantly simplifies the proposal: - there are only 4 different authentication tags instead of 8, - the "i" computation logic through the i_LSB/i_NSB fields in section 4.3 is removed, - the whole section 4.3.1. "Wrong Guess of the i Parameter" is removed too. It does not fundamentally change the protocol, and the main drawback is a mandatory 32-bit overhead (the "i" field) in each authentication tag. That's an acceptable price to pay IOHO. The second drawback is a renumbering of the "Type" field (section 5.1) but we believe it's still acceptable given the "work in progress" status of the document. Historically, when we proposed the compact versions, HMAC-SHA1 was the default and we felt it was interesting to replace the 3 reserved/ padding bytes by 3 bytes of "i". Now that HMAC-SHA255 is the default (and HMAC-SHA1 non recommended), i_NSB can no longer be used, only i_LSB (1 byte). So it's in any case less attractive. > Security Issues > > 4.2.2.2: it is far from clear that if I trust you to send me packets (a > movie, say), I also trust you to configure my NTP client (list of servers > and trust anchors for them). So I wonder if using one of the offered NTP > servers should really be MUST. Or are we really expecting a separate > application level NTP layer, on top of that maintained by the OS? You're right, the wording is not appropriate. We clarified this section by adding the following paragraph, at the end of 4.2.2.2: --- Note that this scenario assumes that each client trusts the sender and accepts to align its NTP configuration to that of the sender, using one of the NTP server(s) suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect time synchronization method (Section 2.3.2.). --- Section 2.3.2 specifies that some of the indirect synchronization methods require that the clients trust the sender sufficiently: --- It should be noted that the NTP/SNTP schemes assume that each client trusts the sender and accepts to align its NTP/SNTP configuration to that of the sender. If this assumption does not hold, the sender SHOULD offer an alternative solution. --- However, we think that "using one of the offered NTP server" is a MUST for TESLA to remain secure. If the two NTP hierarchies are totally disjoint, I don't see how secure time synchronization could be achieved. > 6. The Security Considerations have no discussion at all of the security of > the back channel. I understand that such a channel does exist, at least for > NORM. This channel remains unprotected (or its protection remains > unspecified, see Sec. 1.1). Can it be used to DOS the sender? Other > receivers? Are additional attacks possible? You're right. We added a new section to discuss the security of the back channel (section 6.3). We also added an informative reference to a companion document, draft-ietf-rmt-simple-auth-for-alc-norm-01, that expicits the use of such simple schemes as RSA/ECC digital signature and/or group MAC in the context of ALC/NORM, using the same EXT_AUTH header extension mechanisms. http://tools.ietf.org/html/draft-ietf-rmt-simple-auth-for-alc-norm-01 (this document will soon enter RMT WGLC). Section 1.1. "Scope of this Document" has also been improved in order to better introduce these possibilities. > Other Comments > > 2.2: leaving the bootstrapping step implementation-dependent means that the > protocol is non-interoperable. This is right. We added a sentence to say that it is RECOMMENDED that TESLA implementations support bootstrap messages. However, we don't want to make its support mandatory since there are use-cases where out-of-band is prefered (see RFC4442). > 3.1.2.2: this section implies (last paragraph) that the use of periodic > bootstrap information is only applicable for the case where direct time > synchronization is used. Is this required by the TESLA protocol? Good catch, thanks. This is indeed an error and anyway it contradicts section 3.2.1. New text is as follows: The only solution for this receiver to catch up consists in receiving an additional bootstrap information message. This can happen by waiting for the next periodic transmission (if sent in-band) or through an external mechanism (Section 3.2.1). > 3.4.3: the description of the “Disclosed Key” field says it must be 0 in the > first d intervals, which contradicts the last paragraph of the section, > where it is forbidden to use this tag in those intervals. We read the whole document several times, and this error slipped through. Of course, the "set to 0" requirement comes from the time there was no auth tag without key disclosure. Thanks. > 3.4.7 (and elsewhere): I wonder about the design choice of making the length > of the NSB (and hence, the explicit part of the interval index) depend on > the size of the truncated MAC. The considerations for selecting one are > primarily security-related, while for the other they are primarily about > bandwidth and reliability. Why make them dependent? We removed i_LSB/i_NSB altogether in the new version, for the sake of simplicity (see our answer to the "General comment"). This comment does not apply now. > 4.1: the text “verify the Group MAC if present” is misleading (an attacker > might remove it from the packet). It should be “if the G bit is set in the > Bootstrap message”. This is right, the wording is misleading. Corrected. New text is as follows: --- o first of all, if the Group MAC is present and if the session uses this feature (e.g., if the G bit is set in the bootstrap information message), then verify the Group MAC. A packet that does not contain a Group MAC tag whereas the session uses this feature MUST be immediately dropped. On the opposite, if a packet contains a Group MAC tag whereas the session does not use this feature, this tag MUST be ignored; --- Similarly we updated step 3 of section 4.3. > 4.3, step 5: when doing congestion control, isn’t there value in keeping > key-disclosure packets, even when other packets are dropped? The effect of > key-disclosure packets being dropped may be dozens of other packets that are > lost. There is a misunderstanding here. By "the receiver performs congestion control", one must understand that the sequence number information contained in this packet is used by the congestion control building block to detect possible packet losses. This happen even if the packet is not authenticated at this step. If the packet discloses a key, this key will be eventually used once the packet is authenticated. The text is clarified to better reflect this (and the DoS attack example corrected). --- 5. When applicable, the receiver performs any congestion control related action (i.e., the ALC or NORM headers are used by the associated congestion control building block, if any), even if the packet has not yet been authenticated [RMT-BB-LCT]. If this feature leads to a potential DoS attack (the attacker can send a faked packet with a wrong sequence number to simulate packet losses), it does not compromise the security features offered by TESLA and enables a rapid reaction in front of actual congestion problems. --- > 4.3: I find this text self-contradictory: “In this specification, a receiver > using TESLA MUST immediately drop unsafe packets. But the receiver MAY also > decide, at any time, to continue an ALC or NORM session in unsafe mode, > ignoring TESLA extensions.” I would have felt somewhat better about it if > the text said something like “there SHOULD be explicit user action to move > to unsafe (insecure) mode”. Corrected as suggested, especially as it was the idea. Thanks a lot for your valuable comments, and sorry for this late answer. Vincent and Aurelien. nb: I'll submit the new I-D later today.
- [secdir] SecDir review of draft-ietf-msec-tesla-f… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-msec-tes… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-msec-tes… Vincent Roca