Re: [wss] Discussion of Issue 72 - Expiration

[Anthony Nadalin <drsecure@us.ibm.com>]

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