Subject: iSCSI: Text request/response spanning - security issue?

From: "John Hufferd" <[email-masked]>
Date: Fri, 29 Mar 2002 16:04:55 -0800

Before we run off to far in this direction, ....

Each Key of the Key=value pairs, supplies enough information to understand
the Max length of the value that follows.  The length permitted by each
keyword that is supported, should  be enough to define the approprate
length for any key=value pair.  I think that the implementation can
determine the Max amount of buffer it needs by computing the Max size based
on the keywords supported.

I think the item that got us into the Multi PDU  spanning of a key=value is
the Certificates associated with authentication.  So depending on the type
of Authentication supported, and the Max size of Certificates supported,
you can compute the Max size of the total key=value buffer needed.

I do not see anything broken here.  Hence, I do not think a fix is needed.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Paul Koning <[email-masked]>@ece.cmu.edu on 03/29/2002 12:27:22 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    Re: iSCSI: Text request/response spanning - security issue?

Excerpt of message (sent 29 March 2002) by Bill Studenmund:
> > Yes, you can renegotiate after login, but login is the primary
> > negotiation point.  I think a fixed minimum requirement is more
> > straightforward.
>
> While having a minimum required is good, if we don't have a way to
> negotiate a larger value, how can we really use a larger value? So if we
> can't negotiate the largest size we allow for key=value items and for the
> set, aren't you really suggesting we just pick a number and that's it?
>
> What's the alternative? Send something too large and either crash the
> other side or have some 'I'm confused' error come back? At least with
> negotiation, each side will know what it can and can't send.

If you crash, you have a bug.  I was assuming a reject that says "your
text is too long".

> So here's the suggestion again. We start negotiation with a default value
> for the largest key=value item that can be sent, and the largest set of
> items that can be sent. These defaults are the minimum required that you
> mention. If we want, either side can try to negotiate these values
larger.
> If negotiation suceeds, then future steps of negotiation can use the
> larger values. Negotiation can't lower the values below the minimum
> required.

That sounds workable but I don't see the justification for that extra
complexity.  Luben brought up the original issue as a denial of
service concern.  Is there a plausible real-world example where
someone will want to send a meaningful negotiation exchange that's
"very large"?  I don't know of one.  If there isn't a real need for
the complexity, let's make the minimal fix needed, which is to say
"everyone must support at least x" without negotiating x.

     paul

---

From: Paul Koning <[email-masked]>
Date: Sat, 30 Mar 2002 17:10:30 -0500

> on the keywords supported.

Maybe not if you want to be picky.  Is there a limit on the number of
leading zeroes that a numeric value may have?  I suppose a way to
handle that is "a receiver is not required to accept values other than
zero that begin with 0".
 
> you can compute the Max size of the total key=value buffer needed.

From what I remember about certificates, it isn't easy -- or even
feasible -- to specify a sensible upper bound on their size.
Especially as people start putting more and more crud into
certificates.
 
> I do not see anything broken here.  Hence, I do not think a fix is needed.

Let's make sure that we can indeed specify an upper bound on each
value for each key -- and document in the spec what that limit is.  If
that can be done then indeed we're done.

(I wouldn't worry about X-foo keys; if you don't support them then it
doesn't matter how long they are, and if you do support a particular
one, then it's up to the spec of that specific key to bound its size.)

     paul