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.