Re: [secdir] SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06

Alexey Melnikov <> Fri, 12 October 2012 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 637CC21F844E; Fri, 12 Oct 2012 07:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.097
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sr8ubiTZPp9e; Fri, 12 Oct 2012 07:53:26 -0700 (PDT)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (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;; s=selector;; 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 [] ( []) by (submission channel) via TCP with ESMTPA id <>; Fri, 12 Oct 2012 15:53:24 +0100
Message-ID: <>
Date: Fri, 12 Oct 2012 15:53:29 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: "Black, David" <>
References: <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Mallikarjun Chadalapaka <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.
> [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.