Subject: Disman WG last call: expression MIB

From: Randy Presuhn <[email-masked]>
Date: Wed, 10 Mar 1999 16:30:12 -0800 (PST)

Hi -

I have seen no comments since the editor posted the updated
<draft-ietf-disman-express-mib-08.txt>, so let's start a
two-week WG last call, expiring at 1999-03-25 01:00:00 UTC
(5 pm pacific time on March 24).

If you are committed to reviewing this document and need
more time, PLEASE let me know before the Minneapolis
meeting.

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Mar 1999 11:56:08 -0800 (PST)

Hi -

> Date: Mon, 29 Mar 1999 13:16:00 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: Disman WG last call: expression MIB
> References:  <[email-masked]>
> 
> 
> >>>>> Randy Presuhn writes:
> 
> >> 15) The text in the description of expValueEntry starting "To
> >> maintain security of MIB information, when creating a new row in
> >> this table, ..." seems to be misplaced since a manager does not
> >> create entries in this table. Its probably sufficient to point to
> >> the description of expExpressionEntry which already has similar
> >> text.
> 
> Randy> The text talks about "managed system", not manager.  I'm
> Randy> missing something here...
> 
> Here is the text in the third paragraph of the description of
> expValueEntry:
> 
> :    To maintain security of MIB information, when creating a new
> :    row in this table, the managed system must record the security
> :    credentials of the requester.  These security credentials are
> :    the parameters necessary as inputs to isAccessAllowed from [1].
> :    When obtaining the objects that make up the expression, the
> :    system must (conceptually) use isAccessAllowed to ensure that
> :    it does not violate security.
> 
> Entries in the expValueTable are created by the expression MIB
> implementation itself. I do not understand why you want to record any
> "security credentials of the requester" in this case. I think the
> description of expValueEntry wants to say the following:
> 
> 1) In case of 'deltaValue' and 'changedValue', the evaluation of the
>    expression takes place under the security credentials of the
>    creator of the associated expExpressionEntry. These security
>    credentials are recorded when the expExpressionEntry is created.

This is how I had understood the current text.

> 2) In case of 'absoluteValue', the evaluation of the expression takes
>    place under the security credentials associated with the message
>    which contains the read operation to the ExpValueTable.

I don't understand the motivation for treating 'absoluteValue'
differently from  'deltaValue' and 'changedValue'.  The description of
expExpressionEntry gives the special handling, but it seems to me that
it would be dramatically simpler if all expressions were handled this way.

> I had the impression that the current text in the description is not
> to the point and potentially misleading. Note, the text describing the
> two cases above is also not 100 % clear since you can have mixed
> expressions which include 'absoluteValue' and 'deltaValue' objects.

I think the penultimate  paragraph of expExpressionEntry's description
tries to explain this.  I think it would be simpler if all expression
types were handled consistently.

> In the case of a mixed expression, is the whole expression evaluated
> under the recorded security credentials? Or are parts evaluated under
> the recorded security credentials while other parts are evaluated
> under the security credentials of the read request?

I think the current text leads to the conclusion that if any element
of an expression would required using the recorded credentials, then
the whole expression is evaluated using those credentials.

> [The key here is that 'deltaValue' and 'changedValue' implement a
> `setuid model' where a user X installs an expression and users Y and Z
> may be able to obtain the results of the expression evaluation. This
> is pretty different from 'absoluteValue' where the credentials
> associated with Y and Z determine whether they are able to evaluate
> the expression.]
...

Agreed.  Personally, I'd prefer a more consistent model, but as
chair, I'll go along with whatever we can reach consensus on.