Re: [secdir] SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06
Alexey Melnikov <alexey.melnikov@isode.com> Fri, 12 October 2012 14:53 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637CC21F844E; Fri, 12 Oct 2012 07:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.097
X-Spam-Level:
X-Spam-Status: No, score=-103.097 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr8ubiTZPp9e; Fri, 12 Oct 2012 07:53:26 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7312A21F8445; Fri, 12 Oct 2012 07:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1350053605; d=isode.com; s=selector; i=@isode.com; bh=YkXTL8MRNwasbWdKt5ViJuDvYGC+AnpxMvLVnUa/Bl4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dHLAw0fygKuIqisbcE2+5cdD6cNEOMaFnyQToHKEcERbwnV/USg8NHEI+D/DJ8XZ3cC5tW K0vqnMiY0iQkf7mUlBGIGz59tD3Mk3ldCd3dF0rlpUvX9omjHtQNh7hYc+gBBy2IcJuQzb M1orLLEdL+3PWwdnOtx6gr9Nj9B+ad0=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id <UHgu4QAoYH58@waldorf.isode.com>; Fri, 12 Oct 2012 15:53:24 +0100
Message-ID: <50782EE9.9050404@isode.com>
Date: Fri, 12 Oct 2012 15:53:29 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: "Black, David" <david.black@emc.com>
References: <4FBFAE5F.8010305@gmail.com> <506C43AA.9010206@isode.com> <E160851FCED17643AE5F53B5D4D0783A4C410C95@BL2PRD0610MB361.namprd06.prod.outlook.com> <507406C3.1070909@isode.com> <8D3D17ACE214DC429325B2B98F3AE7120DFAEA1F@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120DFAEA1F@MX15A.corp.emc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Mallikarjun Chadalapaka <cbm@chadalapaka.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-storm-iscsi-cons.all@tools.ietf.org" <draft-ietf-storm-iscsi-cons.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 12 Oct 2012 14:53:27 -0000
On 11/10/2012 16:58, Black, David wrote: > I'm picking up three items from your review that still appear to need some > discussion. We'll plan to add something for most of your requests for > explanations, forward references, and the like that aren't part of these > three. In addition, the stringprep/Unicode items have been resolved in > a separate email thread. Hi David, > [1] >>>> Security considerations for CHAP and SRP authentication mechanisms are >>>> discussed in details and seem to be adequate. I've not seen any >>>> discussion of KRB5 (mentioned in 12.1) related issues though. > Ok, we'll do something about KRB5 security considerations, although only > CHAP is implemented and used in practice - I'll respond separately to Sean's > comment about needing to indicate that CHAP will be replaced. The summary > there that an SRP-like secure password mechanism is probably what's wanted, > but I watched the ipsecme WG completely fail to select a single such > mechanism in the recent past - that's an experience that I don't care to > repeat in the storm WG, especially as storm is not a Security WG ;-). Understood. I just pointed out that you said nothing about KRB5, while you said something about CHAP & SRP. > [2] >>> [Mallikarjun:] LU Reset is a SCSI operation that iSCSI simply acts as >>> a transport for. So as such, iSCSI does not define an access control >>> mechanism for the SCSI-level operation. SCSI specs ([SPC4]) define >>> ACCESS CONTROL OUT and ACCESS CONTROL IN commands to set such access controls. >> This sounds like a security consideration to me. At least it seems worth >> pointing this out. > Yes - I'll work w/Mallikarjun to add Security Considerations text. > The two ACCESS CONTROL commands that he mentioned are rarely > implemented in practice, so the text will probably be more general > about SCSI-level access control mechanisms and indicate that they need to > cover task management operations such as Logical Unit Reset. Ok. > [3] >>>> base64-constant: base64 constant encoded as a string that >>>> starts with "0b" or "0B" followed by 1 or more digits or >>>> letters or plus or slash or equal. >>>> >>>> I think you need to include ASCII codes for the above, just to be clear. >> [Mallikarjun:] IMHO, the correct reference to RFC 2045 (which already exists) >> should address this comment. None of the preceding sections cite the respective >> ASCII codes either, e.g. hex-constant, decimal-constant.... While I suppose we >> could reference ASCII codes everywhere, I do not honestly see the necessity in >> this case - as readability will be impacted with lots of such ASCII code >> references on these pages (FYI, no changes have been made from RFC 3720 here). >> >> Well, when I read this I need to know if you are talking about ASCII or >> Unicode. The text is written as if it is talking about ASCII and I don't >> think it was updated properly. > It doesn't matter; all the characters involved here are ASCII, hence have the > same Unicode codepoints as ASCII. I really don't see the need to expand strings > like this by listing the codepoints. We could say that the entire constant > is ASCII if that helps. I was speaking more generally about this section of the document. >>> Also, this is not quite correct, as leading "=" is not valid in base64 >>> encoding, etc. > I believe this comment is off the mark, but I don't see a problem here. > > What's going on here is that when a base64-constant occurs as the right hand > side of a key=value construct, one can wind up with multiple instances of > '='in that construct: > > - one to separate the key and the value; and > - one or two at the end of the base64 constant. > > The parsers get this right because the "0b" or "0B" after the first '=' > indicates that everything that follows is base64, e.g., in > "example=0bZm9vYmE=", the first '=' introduces the value, "0b" flags > the value as base64-encoded, and the second '=' is part of the base64 > encoding of the value. This is unambiguous and works in practice. "example=0bZm9vYmE=" is valid, but something like "example=0bZm9vYmE=AAAA" is not (because the base64 value is not syntactically valid). Anyway, my point was that you should point to the RFC defining base64 and don't repeat information from it here.
- [secdir] SecDir review of draft-camarillo-rai-med… Yaron Sheffer
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- [secdir] SecDir review of draft-yegin-pana-encr-a… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-krb-wg-kerbe… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sean Turner
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sam Hartman
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Tom Yu
- [secdir] SecDir and AppsDir review of draft-ietf-… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] Use of StringPrep/Unicode (was Re: SecDi… Alexey Melnikov
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] SecDir review of draft-ietf-6renum-enter… Yaron Sheffer
- [secdir] SecDir repeat review of draft-ietf-6renu… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-rtgwg-ipfrr-… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-clue-telepre… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-v6ops-64shar… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš