Re: [wss] Discussion of Issue 72 - Expiration

[Peter Dapkus <pdapkus@bea.com>]

It seems like the security benefit of Expires is marginal unless you
specifying the processing rules:  Expires is for the benefit of the
sender.  If the receiver's processing isn't predicatable from the
sender's point of view, what does the sender gain by including an
Expires element?   If the processing isn't defined here, then how does
the sender know what processing rules the receiver will use?   What
risks have we reduced for the sender?   

On the other hand, it seems clear we're introducing risks:  The spec is
more complex with Expires than without it -- complexity entails risk on
several levels.  Also, if we specify the syntax but not the processing,
it seems like there's a risk that applications and/or future
specifications will define incompatible processing for Expires, and
those incompatibilities might be exploitable.  It's easy to see several
ways this might happen.  Why open the door to this?

The non-security benefits seem marginal -- we may conserve a few dozen
bytes on the wire by providing a single way of expressing Expires for
future specs (assuming they can define orthogonal/compatible processing
rules).  And we've saved future spec writers a little bit of effort by
providing a syntax for Expires.  What else do we get by including it?

It seems like we should either nail down Expires processing or leave
expiries to future standards that are ready to tackle a complete
specification for the behavior.    

I have no opposition to trying to nail it down in this spec, tho I think
the work to nail it down is substantial:  it's easy to see how this
would work predictably in a synchronus, request-response environment; 
it's much less clear how it should work in an environment that uses 
asynchronus and/or reliable transport or where messages are routed to
several recipients, each of which contributes to the processing.    

I suspect it might be easier to define this in the context of a specific
protocol, where the processing environment is more constrained  (e.g.
clocks are synchronzed, interactions are synchronus, request-response,
etc) or where other resources (e.g. message ids, policy statements, etc)
are available.  

cheers, 

-Pete Dapkus
pdapkus@bea.com


On Mon, 2003-06-02 at 18:26, Anthony Nadalin wrote: 
> 
> Hal,
> 
> It seems that the issues you bring up here are clarification (and maybe not
> even that) issues and not issues to remove the Expiration feature. Its
> clear that receives may not want to process and messages that the requester
> has indicated that may not be valid and this could be for many reasons. Its
> clearly pointed out that the exact meaning and processing rules for
> expiration depend on the context in which the element is used. So as you
> point out that this element could be used for security reasons, or a real
> world security constraint.
> 
> Its very reasonable to say that the message I as a requestor send expires
> in 60 min. The receiver should as per specification Upon determining that
> the message has expired, the requestor asserts that the message is no
> longer valid and will not process the message. How the requestor asserts
> that the message is no longer is a policy decision, very much like
> signature validation.
> 
> .Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
> 
> 
> |--+-->
> |         |           "Hal Lockhart"   |
> |         |           <hlockhar@bea.com|
> |         |           >                |
> |         |                            |
> |         |           06/02/2003 03:29 |
> |         |           PM               |
> |--+-->
>   >--|
>   |                                                                                                                                              |
>   |       To:       <wss@lists.oasis-open.org>                                                                                                   |
>   |       cc:                                                                                                                                    |
>   |       Subject:  [wss] Discussion of Issue 72 - Expiration                                                                                    |
>   >--|
> 
> 
> 
> 
> We believe the Expiration feature is ill considered and should be removed.
> We do not understand how to determine what values to set it to when sending
> it, what its semantics have to do with security or how to process it on
> receipt.
> 
> General observation: in distributed systems security, it is the receipient
> that must insure that security policy is being followed. The sender can
> perform various steps to try to provide the information the receipient
> needs, but the decision belongs to the receipient. This becomes especially
> clear when the sender and receipient are in different security domains
> whose
> trust realationship is quite narrow and specific.
> 
> At first glance, the Creation and Expiration elements would appear to be
> opposite sides of the same coin. However, this is not the case.
> 
> When a sender sends a Creation, it is merely recording an observed fact.
> The
> receipient can ignore this information or use it in any way it choses. It
> can decide based on any criteria it likes whether the Creation is a reason
> the message should not be processed or be processed in a different fashion.
> 
> Expiration is different. It is a command or request from the sender to the
> receipient that if the indicated date/time has passed, the message should
> not be processed for some reason. It is not clear if this is a security
> reason, e.g. fear of a replay atttack, a real world contraint, e.g. the
> auction is over so there is no need to process the bid, or some other
> reason. Note that the specification defines other adequate means to prevent
> replay. If it is not a security mechanism, it does not need to be in this
> specification.
> 
> Second, the sender has to decide what to send the Expiration to. It has to
> estimate the effects of processing and network delays as well as queuing
> for
> performance smoothing as well as system outages. As a sender, it will be
> hard to estimate actual delays, since they are often not symmetic along
> both
> directions of a given path.
> 
> Third, how is the receipient to interpret Expiration? Is it the time the
> message is received, the time the application sees it or the time a
> response
> is sent? Is it necessary to estimate how long processing will take in order
> not to start on work that may have to be discarded? Or is it ok to send a
> response to an expired message that was first received before expiring?
> What
> if there is no response?
> 
> For all these reasons we would prefer to see Expiration dropped from the
> WSS
> core. Alternatively we would like to see its use depricated until such time
> as a protocol that defines specific semantics and processing steps for its
> use has been defined.
> 
> Hal
> 
> 
> 
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
> 
> 
> 
> 
> 
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php


-- 

Peter Dapkus <pdapkus@bea.com>