Re: [secdir] secdir review of draft-ietf-storm-iser-12.txt

["Black, David" <[e-mail]>]

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.

> 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.

> 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".

> 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.

> The Security Considerations section concludes with a paragraph that is
> a bit mysterious.

What's Halloween time without a good mystery :-) :-) ?

> 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,
--David

From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, October 17, 2012 7:57 PM
To: [e-mail]; [e-mail]; [e-mail]; secdir; [e-mail]; [e-mail]; Black, David; [e-mail]
Subject: secdir review of draft-ietf-storm-iser-12.txt

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


This is a rather hefty document, running 97 pages, including 3 appendices. The document specifies extensions to iSCSI to support RDMA (remote direct memory access). Since this is an extension of iSCCI, it inherits the security features available in that context. The new, consolidated iSCSI document is even longer than this document (342 pages!), and it contains a substantial (12 page) security considerations section. So, referring to the iSCSI security considerations text is an appropriate indirection here.



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.)



The security considerations section of the iSER document is less than a page in length. It begins by noting that if iSER operates above an RCaP (RDMA capable protocol) layer the security considerations are the same as for the RCaP layer, and refers to RFC 5042. RFC 5042 analyzes security issuers 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 RCCs were cited. (OK, time to fess up, which SECDIR member reviewed 5042?)



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. (When iSER is not carried over IP nets, security mechanisms applicable to the RCaP layer are to be employed, as per RFC 5042.)



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.



The Security Considerations section concludes with a paragraph that is a bit mysterious. 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.