Subject: Re: [secdir] SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06
From: Alexey Melnikov <[email-masked]>
To: "Black, David" <[email-masked]>
Cc: Mallikarjun Chadalapaka <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 12 Oct 2012 15:53:29 +0100
List-Id: Security Area Directorate <secdir.ietf.org>

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.