Re: [secdir] draft-ietf-storm-iser and IPsec version requirements
Stephen Kent <kent@bbn.com> Tue, 18 June 2013 15:51 UTC
Return-Path: <kent@bbn.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 78E0121F9955 for <secdir@ietfa.amsl.com>; Tue, 18 Jun 2013 08:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m+CYkI5liIT for <secdir@ietfa.amsl.com>; Tue, 18 Jun 2013 08:50:46 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB8521F9815 for <secdir@ietf.org>; Tue, 18 Jun 2013 08:50:45 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49476) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1UoyB5-000Dvc-GO; Tue, 18 Jun 2013 11:50:39 -0400
Message-ID: <51C081CF.6060208@bbn.com>
Date: Tue, 18 Jun 2013 11:50:39 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Black, David" <david.black@emc.com>
References: <507F45BE.2040900@bbn.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B01F@MX15A.corp.emc.com> <50983EB5.2010501@bbn.com> <8D3D17ACE214DC429325B2B98F3AE712980CA080@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980CA080@MX15A.corp.emc.com>
Content-Type: multipart/alternative; boundary="------------080706070301050905020006"
Cc: "mkosjc@gmail.com" <mkosjc@gmail.com>, Mallikarjun Chadalapaka <cbm@chadalapaka.com>, "ttalpey@microsoft.com" <ttalpey@microsoft.com>, secdir <secdir@ietf.org>, "nezhinsky@gmail.com" <nezhinsky@gmail.com>, "alexandern@mellanox.com" <alexandern@mellanox.com>, "spencerdawkins.ietf@gmail.com" <spencerdawkins.ietf@gmail.com>, "martin.stiemerling@neclab.eu" <martin.stiemerling@neclab.eu>
Subject: Re: [secdir] draft-ietf-storm-iser and IPsec version requirements
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: Tue, 18 Jun 2013 15:51:00 -0000
David, Thanks for the followup note. I've been on vacation, so I just read your message. I assume everything is OK now. Steve ---- On 6/6/13 7:03 PM, Black, David wrote: > > Steve, > > This is a much delayed follow-up on the IPsec version concern noted > > in the secdir review of draft-ietf-storm-iser found. After further > > investigation, it turns out that the iSER draft implicitly used > > different sets of IPsec requirements for the iSCSI vs. RDMA layers > > of the iSER protocol stack. That was not a good approach, as the > > protocol stack is iSER/RDMA/TCP/IP, so a single common IPsec > > implementation is likely to be used for both iSER and RDMA, but > > doing the proverbial "right thing" has taken a while. > > Getting to a single common set of IPsec requirements required a new > > draft. That new storm WG draft has just been posted; it updates > > RFC 3723's IPsec requirements to encompass IPsec v3 (4301 series RFCs). > > That update covers iSCSI, iSER, the iWARP RDMA protocols, and all other > > protocols that use the IPsec requirements for IP Storage in RFC 3723: > > http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/ > > Yaron Sheffer's prompt review of that draft (thank you!) found a > > few minor problems, which will be addressed in a -01 version to be > > posted in the next few days. > > The just-posted -14 version of the iSER draft contains a normative > > reference to that ipsec-ips-update draft, with the result that the IPsec > > requirements are now consistent and include IPsec v3 (4301 series RFCs). > > Everything else noted in the secdir review has been addressed in that > > new -14 version. > > Thanks, > --David > > *From:*Stephen Kent [mailto:kent@bbn.com] > *Sent:* Monday, November 05, 2012 5:33 PM > *To:* Black, David > *Cc:* mkosjc@gmail.com; alexandern@mellanox.com; nezhinsky@gmail.com; > secdir; wes@mti-systems.com; martin.stiemerling@neclab.eu; > ttalpey@microsoft.com; Mallikarjun Chadalapaka; Steve Kent > *Subject:* Re: secdir review of draft-ietf-storm-iser-12.txt > > David, > > > Steve, > > Thank you for this review. > > > RFC 5042 analyzes security issues associated with RDMA, so it is an > > > appropriate reference here. As an aside, I'm surprised to see that RFC 5042 > > > refers to the old IPsec RFCs (2401 series), instead of the newer IPsec RFCs > > > (4301 series). RFC 5042 was published in October 2007, almost 2 years after > > > the later set of IPsec RFCs, so there was plenty of time to update the > > > references! I didn't see any rationale in 5042 for why the earlier IPsec > > > RFCs were cited. (OK, time to fess up, which SECDIR member reviewed 5042?) > > A conscious and deliberate decision was made at that time to continue > to use > > the IP Storage profile of the older IPsec RFCs (2401 series) as > specified in > > RFC 3723 for consistency. While that decision was apparently not recorded > > in RFC 5042, another RFC in that series, RFC 5040 does have this to say in > > its Security Considerations (Section 8): > > The IPsec requirements for RDDP are based on the version of IPsec > > specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC > > 3723 [RFC3723], despite the existence of a newer version of IPsec > > specified in RFC 4301 [RFC4301] and related RFCs [RFC4303], > > [RFC4306], [RFC4835]. One of the important early applications of the > > RDDP protocols is their use with iSCSI [iSER]; RDDP's IPsec > > requirements follow those of IPsec in order to facilitate that usage > > by allowing a common profile of IPsec to be used with iSCSI and the > > RDDP protocols. In the future, RFC 3723 may be updated to the newer > > version of IPsec, and the IPsec security requirements of any such > > update should apply uniformly to iSCSI and the RDDP protocols. > > So, I think the (anonymous) SECDIR reviewer is off the hook on this one, > > which is just as well as (IIRC), at least one of the SEC ADs at the time > > was also involved :-). > > The consolidated iSCSI draft updates RFC 3723 to extend that IPsec profile > > to the 4301 series RFCs (as well as to the current IKEv2 specification, > > RFC 5996), although the 2401 series RFCs are still the "MUST implement" > > requirements based on what has been widely implemented. I will check with > > the current security ADs (both of whom just happen to be holding Discuss > > positions on that iSCSI draft for good reasons) about whether to go ahead > > and use that iSCSI draft to update the 5040 series RFCs - I think that > > should probably be done. > > Thanks for the explanation. If the WG and ADs choose to stick with the > 3401 series, > I think it would be useful to readers to note the rationale for this > in the SC section. > > > The document states that "iSER requires no changes to iSCSI authentication, > > > security and text mode negotiation mechanisms." (The wording here is a bit > > > worrisome as suggests that the authors equate security with confidentiality, > > > since the more general, and accurate, use of the term "security" encompasses > > > authentication.) > > You could have just called that an editorial nit :-) - we'll fix it, > regardless. > > Too often I review docs where the authors don't know the difference, > which is why > I flag issues like this. but, in your case I'll chalk it up as a typo :-). > > > This section states plainly that iSER is "functionally iSCSI" and thus > > > all of the iSCSI security considerations apply. In particular, when iSER > > > is carried over IP networks, IPsec MUST be employed. > > Not exactly ;-). The IPsec requirements are consistently "MUST implement, > > MAY use". > > Right. sorry for my sloppy characterization. > > > There is an overly-long, single sentence paragraph discussing how to > > > minimize the potential for DoS attacks. The wording is a bit vague, but > > > the text refers to the discussion of initiator and target behaviors, > > > which provide the relevant details. This is a very narrow focus on DoS, > > > and I suggest that the paragraph in question be augmented to state that > > > the only DoS attacks addressed here are ones that could cause resource > > > exhaustion at a target. > > Will edit and clarify as suggested. > > Thanks. > > > The Security Considerations section concludes with a paragraph that is > > > a bit mysterious. > > What's Halloween time without a good mystery :-) :-) ? > > good timing! > > > It seems to warn implementers of a residual vulnerability associated > > > with the use of a buffer identifier. However, the section to which this > > > paragraph refers contains the following sentence: > > > > > > "That iSER layer MUST check that STag invalidation has occurred whenever > > > receipt of a Send with Invalidate message is the expected means of causing > > > an STag to be invalidated, and MUST perform the STag invalidation if the > > > STag has not already been invalidated (e.g., because a Send message was > > > used instead of Send with Invalidate)." > > > > > > This sort of writing does not explain complex issues to a reader. > > We'll provide a better explanation in the Security Considerations section. > > What happened here is that the original specification of iSER (RFC 5046) > > required (MUST) use of a Send with Invalidate RCaP primitive in some > cases. > > That primitive has the side effect of invalidating a buffer identifier, > > preventing future use (as the buffer identifier enables remote direct > access > > to memory), and that requirement allowed the implementation on the > receiving > > end to rely on use of that primitive to invalidate the buffer identifier. > > This draft allows use of a Send RCaP primitive that does not > invalidate the > > buffer identifier in all cases, and that exposes the buffer identifier to > > future use, thereby creating a potential security issue if the identifier > > was supposed to be invalidated. Hence when invalidation of the buffer > > identifier is intended or required (e.g., it's not being cached for future > > reuse), an iSER implementation can no longer rely on the underlying use of > > an RCaP Send with Invalidate primitive, but has to instead explicitly > check > > the state of the buffer identifier and/or perform a local invalidation > if the > > identifier is still valid. > > Thanks for the explanation. I;m confident that your revision will make > this OK. > > No need for me to re-review. > > Steve >
- [secdir] secdir review of draft-ietf-storm-iser-1… Stephen Kent
- Re: [secdir] secdir review of draft-ietf-storm-is… Black, David
- Re: [secdir] secdir review of draft-ietf-storm-is… Stephen Kent
- [secdir] draft-ietf-storm-iser and IPsec version … Black, David
- Re: [secdir] draft-ietf-storm-iser and IPsec vers… Stephen Kent