RE: [ws-sx] Issue 78 Rationale and New Proposal

["Hal Lockhart" <hlockhar@bea.com>]

I am ok with this. (I was on vacation last week.)

Hal

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: Thursday, August 10, 2006 10:23 AM
> To: Hal Lockhart; ws-sx@lists.oasis-open.org
> Cc: Marc Goodner
> Subject: RE: [ws-sx] Issue 78 Rationale and New Proposal
> 
> Hal,
> 
> Please find below an amended proposal for replacement text for section
8
> (actually prepared by Jan, but he's on vacation this week).
> 
> Regards
> 
> Gudge
> 
> -------------
> 
> For a variety of reasons it may be necessary to reference a Security
> Context Token. These references can be broken into two general
> categories: references from within the <Security> element to a token
also
> within the <Security> element, generally used to indicate the key used
in
> a signature or encryption operation and references from other parts of
the
> SOAP envelope, for example to specify a token to be used in some
> particular way. References within the <Security> element can further
be
> divided into reference to an SCT found within the message and
references
> to a SCT not present in the message.
> 
> The Security Context Token does not support references to it using key
> identifiers or key names.  All references MUST either use an ID (to a
> wsu:Id attribute) or a <wsse:Reference> to the <wsc:Identifier>
element.
> 
> References using an ID are message-specific. References using the
> <wsc:Identifier> element value are message independent.
> 
> If the SCT is referenced from within the <Security> element or from an
RST
> or RSTR, it is RECOMMENDED that these references be message
independent,
> but these references MAY be message-specific.
> 
> When an SCT located in the <Security> element is referenced from
outside
> the <Security> element, a message independent referencing mechanisms
MUST
> be used, to enable a cleanly layered processing model unless there is
a
> prior agreement between the involved parties to use message-specific
> referencing mechanism.
> 
> When an SCT is referenced from within the <Security> element, but the
SCT
> is not present in the message, (presumably because it was transmitted
in a
> previous message) a message independent referencing mechanism MUST be
> used.
> 
> ----------------
> 
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > Sent: 27 July 2006 17:43
> > To: ws-sx@lists.oasis-open.org
> > Subject: [ws-sx] Issue 78 Rationale and New Proposal
> >
> > Problems with the Use of Local References to ID Attributes in
> > STRs which
> > annotate <CreateSeq> or other applications or infrastructure
services.
> >
> > Summary
> >
> > The use of local ID references to bind a particular Token to a WS-RM
> > Sequence makes it difficult to design a cleanly layered
implementation
> > of WS-RM with WS-Security (specifically WS-SecCon). The basic
> > reason for
> > this is that the ID is message-specific, whereas the layers need to
> > continue to communicate and compare Token references over
> > many messages.
> > The problem is relatively obvious on the sending side, but equally
> > problematic on the receiving side.
> >
> > My Assumptions
> >
> > Security and RM (and Applications) are implemented as distinct
layers
> > with a clean interface between them. There are distinct
> > implementations
> > of the sending and receiving components of each. Messages and
> > associated
> > data (in an unspecified internal format) pass from one layer to the
> > next. The processing order on the send side is first Application,
then
> > RM, then security. On the receiving side messages are
> > processed first by
> > security.
> >
> > The interface between RM and security on the send side is
> > something like
> > this. The SOAP message is passed along with indications of
> > what portions
> > of the message should be signed and encrypted with what tokens.
> >
> > The interface on the receive side is similar. Security replaces any
> > encrypted data with cleartext and passes along the message along
with
> > indications of what was signed and what was encrypted using
> > what tokens.
> > Security verifies signatures and checks for expirations, but the RM
> > layer must determine if the right things have been signed
> > with the right
> > tokens.
> >
> > The idea is that Applications and services such as RM know
> > What to sign
> > (and encrypt) and Security knows How to sign.
> >
> > Use of a local ID on send side
> >
> > On the sending side, the problem with using a local ID is
> > that since the
> > security header has not yet been constructed, the Application or RM
> > layer cannot determine what ID to use. Their are various kludged
> > solutions to this, like some sort of id naming convention, but these
> > kinds of approaches are likely to just cause unexpected bugs
> > in existing
> > applications as messages get more complex with more services and
> > applications.
> >
> > Use of a local ID on the receive side
> >
> > A local ID is just as much of a problem on the receive side. What
the
> > RMD has to do is process the <CreateSeq> and save the reference so
it
> > can later determine that all of the messages in the sequence have
been
> > signed using the proper token. But if the STR contains a
> > reference to a
> > local ID, the RMD has to dig thru all the tokens which were
> > passed up by
> > the Security layer and determine (if it can) which one of
> > them is being
> > pointed to. Then it has to create and save some kind of
> > message-independent reference to use later. How much easier if a
> > message-independent pointer is used in the first place!
> >
> > Recommended Approach
> >
> > In the case of an SCT, the simple solution is to use the
> > <wsc:Identifier> whenever the application or another infrastructure
> > service needs to reference it. This is supposed to be globally
unique
> > and therefore will be the same in every message. Using it makes life
> > easy on both the send and receive side.
> >
> > The RST & RSTR Problem
> >
> > One objection raised to my proposal that references to an SCT from
> > outside of the <Security> Element MUST use the
> > <wsc:Identifier> (and not
> > a wsu:Id) is that a RST may reference a Token that is in the
Security
> > header. It is claimed that in this case it is easier to use a
> > wsu:Id. I
> > don't really understand why this should be so, but let us examine
the
> > cases.
> >
> > First consider an RSTR. Since the Token is being sent from the STS
for
> > use by the client, I can see no case in which the STS would use that
> > Token to identify itself or integrity protect the message. It
> > is barely
> > possible that the Token might be used to encrypt parts of the
message.
> > However, since the STS needs to establish an encryption key with the
> > client in order to protect secrets associated with the SCT, this
case
> > seems marginal at best. (The discussion below about Perfect Forward
> > Secrecy also applies here.)
> >
> > Now consider the RST. WS-SC defines 4 operations: Issue, Amend,
Renew
> > and Cancel. Obviously an Issue request will never reference the SCT
> > since it does not exist yet.
> >
> > In the case of Amend, WS-SC does not specify what Authentication is
> > required. In the case of Renew, it says the original claims must be
> > re-authenticated. If the SCT has expired, its key must not be used
to
> > authenticate. The examples for Amend and Renew both show signatures
> > which use both the long term Token and the SCT.
> >
> > In the case of Cancel, WS-SC says that the client must provide PoP
of
> > the SCT secret. The example shows only one signature, which uses the
> > SCT.
> >
> > It seems to me that the Principle of Perfect Forward Secrecy
suggests
> > that the long term Identity be used in all these cases to
authenticate
> > the client. That way if the SCT secret is compromised, the
> > request will
> > still be protected. (If the long term secret is compromised, all
bets
> > are off anyway.) I don't understand why a Cancel requires
specifically
> > PoP of the SCT secret.
> >
> > The <IssuedTokens> Element
> >
> > In section 4.4 of WS-Trust an element called IssuedTokens is
defined.
> > This is intended to be a top level element in the SOAP header which
> > contains tokens referenced from different protocols, e.g. RST/RSTR
and
> > WSS. It is not entirely sure what problem this element is supposed
to
> > solve, but curiously WS-SC does not use it at all. I suggest
> > that either
> > a) WS-SC specify that when tokens are referenced both in the
Security
> > element and the RST, they be put in an IssuedTokens element or b)
the
> > IssuedTokens element be dropped from WS-Trust.
> >
> > Using wsc:Identifier vs. wsu:Id
> >
> > It has been asserted that using a wsu:Id to reference an SCT
> > is somehow
> > easier than using a wsc:Identifier. It has also been asserted that
> > referencing the same token in two different ways somehow causes
> > problems. I do not really understand either of these. First note
that
> > the wsc:Identifier is required and thus if one wanted to use one
> > mechanism exclusively, it would be the better choice.
> > Further, if the Id
> > is not present or conflicts with another Id in the message,
> > it will need
> > to be added or changed. This is an extra step and in some scenarios
> > would break the issuer's signature.
> >
> > The only reason I can think that using two different reference
> > mechanisms might cause a problem is in determining if two
> > references are
> > to the same token or different ones. It seems to me that
> > implementations
> > will have to be able to make this determination anyway. For
> > example, the
> > same token might be labeled with different Id's in different
messages.
> >
> > Revised Proposal
> >
> > Based on these considerations I propose replacing section 8 with:
> >
> > -----
> > For a variety of reasons it may be necessary to reference a Security
> > Context Token. These references can be broken into two general
> > categories: references from within the <Security> element to a token
> > also within the <Security> element, generally used to indicate the
key
> > used in a signature or encryption operation and references from
other
> > parts of the SOAP envelope, for example to specify a token to
> > be used in
> > some particular way. References within the <Security> element can
> > further be divided into reference to an SCT found within the
> > message and
> > references to a SCT not present in the message.
> >
> > The Security Context Token does not support references to it using
key
> > identifiers or key names.  All references MUST either use an ID (to
a
> > wsu:Id attribute) or a <wsse:Reference> to the
> > <wsc:Identifier> element.
> >
> > {Question: when the <wsc:Identifier> element value is used, is it
> > necessary to also specify the <wsc:Instance> element value, if
present
> > to disambiguate the key?}
> >
> > References using an ID are message-specific. References using the
> > <wsc:Identifier> element value are message independent.
> >
> > If the SCT is referenced from within the <Security> element
> > and from an
> > RST or RSTR, the SCT MUST be placed in a <IssuedTokens> element at
the
> > top level in the SOAP Header. The <IssuedTokens> element SHOULD
appear
> > prior to the <Security> element. It is RECOMMENDED that these
> > references
> > be message independent, but these references MAY be
message-specific.
> >
> > When an SCT located in the <Security> element is referenced
> > from outside
> > the <Security> element, a message independent referencing mechanisms
> > MUST be used, to enable a cleanly layered processing model.
> >
> > When an SCT is referenced from within the <Security> element, but
the
> > SCT is not present in the message, (presumably because it was
> > transmitted in a previous message) a message independent referencing
> > mechanism MUST be used.
> >
> > When an SCT located in the <Security> element is referenced
> > from within
> > the <Security> element, a message-specific referencing
> > mechanism MAY be
> > used.
> >
> >
> > [examples]
> > ----
> >
> > Note the second paragraph is copied from lines 144-146. I suggest
> > deleting these.
> >
> > ----
> >
> > I also have suggested that the rules for Authentication of
> > Amend, Renew
> > and Cancel requests be changed. I will open a new Issue for these
> > changes.
> >
> > Hal
> >