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

Alexey Melnikov <> Tue, 16 October 2012 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34A1F21F873A; Tue, 16 Oct 2012 11:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.421
X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pLXsUJIkLPr2; Tue, 16 Oct 2012 11:06:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D667E21F8A7B; Tue, 16 Oct 2012 11:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1350410772;; s=selector;; bh=/dRSbEVO08rYpEQPq/mFH+Z6P8OuffFbR63/omKh8w4=; 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=ZBKaEZ09ev/+ykwkM1BxakFzK4gg48CKW8FsobKIPKz9mXNPW2hoIJKn3XFM23uDiDexBw 18r/EJaht1I8Gv7Mpsqu8+718Kql6L3jcyhErEfRKG4TIZoPk56+1I0cxYu429HEfavDmu axwk96uz31b6g8obZgHw6GD8qGFJcRA=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Tue, 16 Oct 2012 19:06:11 +0100
Message-ID: <>
Date: Tue, 16 Oct 2012 19:06:11 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Mallikarjun Chadalapaka <>
References: <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, "" <>
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: Tue, 16 Oct 2012 18:06:36 -0000

Pretty much agreeing with all you proposed.

On 15/10/2012 00:12, Mallikarjun Chadalapaka wrote:
> Let me catch up on a few items that David didn't already respond to:
>>>> How can the initiator know whether the target only complies with RFC
>>>> 3720 or not?
>>> [Mallikarjun:] See section 13.23. TaskReporting was negotiated to
>> "RFC3720" or "NotUnderstood"
>> I think a forward reference here would be good.
> Done.
>>>> [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.
> Tend to agree with David.  Here's some new text that might work.
> 9.5. SCSI Access Control Considerations
> iSCSI is a SCSI transport protocol and as such does not apply any access controls on SCSI-level operations such as SCSI task management functions (e.g. LU Reset, see Section 11.5.1). SCSI-level access controls (e.g. ACCESS CONTROL OUT, see [SPC3]) have to be appropriately deployed in practice to address SCSI-level security considerations, in addition to security at iSCSI connection and packet protection mechanisms that were already discussed in preceding Sections.
>>>> Why is this a SHOULD (and not a MUST)? What are possible alternatives?
>>> [Mallikarjun:] Because some steps may not be backwards-compatible with
>> RFC 3720-compliant implementations. That's the reason or the immediately
>> following "MUST" statement - to make the distinction between the two
>> clear.
>> Personally I am a big fan of explaining SHOULDs. If you can add your
>> explanation, that would be great.
> Protocol behavior defined in this Section SHOULD be implemented by all iSCSI implementations complying with this document, noting that some steps below may not be compatible with [RFC3720] semantics. However, protocol behavior defined in this Section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 13.23) key to "FastAbort" on that session.
Looks good.
>> registered domain name. This domain name does not have to be active,
>> IMHO, the meaning of "active" is not clear here.
>>    [...]
>>>    [Mallikarjun:] "active" as in "not expired registration"
>> If it is expired, it is no longer owned, which conflicts with the previous
>> sentence ;-).
> Fair enough. I removed this phrase now, so the sentence reads:
> This domain name does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name.
Yes, this is good. Thanks.
>>>> Every time the document is referring to "hexadecimal" - is the case
>>>> important or not?
>>>    [Mallikarjun:] Not important, it's normalized to lower-case via stringprep
>> for key names, and for key values, we explicitly allow upper and lower case.
>> I don't mind either way, I am just missing where this is explicitly said.
> Hexadecimal values can occur in "iSCSI names" - e.g. "naa" names. (section
> Section - iSCSI name encoding section covers this.
> When hexadecimal values show up in key values, the text format discussion (section 6.1) makes it clear that either upper case or lower case is fine - see the definition for hex-constant.
>>>    [Mallikarjun:] Nope, it is not an empty list. When both sides agree to it, it
>> means that no key-specific semantics are operational for the functionality
>> represented by the key. Look at 12.1 (AuthMethod), and 13.1 (Digests) for
>> examples.
>> Ok. It would be helpful to explain this earlier.
> Sure, here's text I have added now to complete that paragraph:
> The constant "None" MUST always be used to indicate a missing function. However, "None" is only a valid selection if it is explicitly proposed. When "None" is proposed as a selection item in a negotiation for a key, it indicates to the responder that not supporting any functionality related to that key is legal, and if "None" is the negotiation result for such a key, it means that key-specific semantics are not operational for the negotiation scope (connection or session) of that key.
Perfect, thanks :-).
>>>>      Security MUST be completely negotiated within the Login Phase. The
>>>> What is the meaning of the word "Security" in this case?
>> FYI, unqualified word "security" is a red flag during SecDir review ;-).
> Fair enough, I have re-crafted that sentence to the following:
> Authentication-related security keys (Section 12 ) MUST be completely negotiated within the Login Phase.
Much better, thanks!