OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-sx] RE: Issue 162: no way to specify the policies forrenew and cancel


Here is the updated proposal that explains the behavior when there are multiple policy alternatives.

 

Thanks,

--Jan

 

I propose to add the following text after line 1261 in the current WS-SecurityPolicy editor’s draft (http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/27578/ws-securitypolicy-1.3-spec-ed-02.doc).

 

----------

If the bootstrap policy assertion is used to indicate the security binding and policy in effect when requesting a secure conversation token from the target service, then subsequent Amend, Renew and Cancel messages MUST comply with the following rules.

 

Amending Context

To amend an existing secure conversation token, a requestor uses the context amending mechanism as described by the WS-SecureConversation specification. The message exchange MUST be secured using the existing (to-be-amended) SCT in accordance with the target service (outer) policy, combined with endorsing supporting tokens carrying the new claims to be associated with the amended context with the inclusion mode set to http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient. See the EndorsingSupportingTokens Assertion section for more details on the usage of the endorsing supporting tokens.

 

Renewing Context

To renew an existing secure conversation token, a requestor uses the context renewal mechanism as described by the WS-SecureConversation specification. The message exchange MUST be secured according to the requirements of the bootstrap policy assertion, combined with the existing (to-be-renewed) secure conversation token used as an endorsing supporting token with the inclusion mode set to http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient. See the EndorsingSupportingTokens Assertion section for more details on the usage of endorsing support tokens.

 

Canceling Context

To cancel an existing secure conversation token, a requestor uses the context cancelling mechanism as described by the WS-SecureConversation specification. The message exchange MUST be secured using the existing (to-be-cancelled) SCT in accordance with the target service (outer) policy.

 

Handling Policy Alternatives

If there are policy alternatives present in either the bootstrap policy assertion or the target service (outer) policy assertion, the following rules MUST be followed.

 

·         The policy alternative used as a basis for the context renewal MUST be the same as the policy alternative used for the context issuance.

·         If the target service (outer) policy has policy alternatives and SecureConversationToken assertion appears in multiple alternatives as follows:

Policy

  Policy-alternative-1

    SecureConversationToken-assertion-1

  Policy-alternative-2

    SecureConversationToken-assertion-2

 

The policy alternative used as basis for context amend and cancel MUST be the same as the policy alternative that was used to obtain the context. This means that Policy-alternative-1 above cannot be used to amend and cancel SecureConversationToken-assertion-2 and vice-versa.

·         If the target service (outer) policy has policy alternatives that are outside the SecureConversationToken assertion as follows:

Policy

  SecureConversationToken-assertion-1

  Policy-alternative-1

  Policy-alternative-2

 

Any policy alternative can be used to amend or cancel the context. This means that either Policy-alternative-1 or Policy-alternative-2 can be used to amend or cancel SecureConversationToken-assertion-1.

 

 

 

From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Tuesday, April 29, 2008 10:24 PM
To: Jan Alexander; Corinna Witt; Will Hopkins; Marc Goodner
Cc: Symon Chang; Thorick Chow; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

 

Although our original proposal was different, we can live with this approach if it can be made sufficiently precise and comprehensive. So far we have identified the following issues:

 

1. Both the Bootstrap and Outer policies may contain alternatives. We need rules on how to handle this. At first I thought we could make it easier on the receiver by insisting that the synthetic policies be based on the policy alternative actually chosen for Issue or the first Service call. However, I cannot see a way to have a simple consistent rule for this. For example, a call to Cancel or Amend might occur before any call to the Service. It now seems that the receiver must be willing to accept synthetic policies based on any bootstrap policy alternative. For Cancel and Amend it must be based on any outer policy alternative which makes use of the SCT.

 

2. The Outer policy may consist of multiple effective policies depending on the operation and message. We need to specify whether all of these or any particular one forms the basis for the policy used for Cancel and Amend.

 

Hal

 


From: Jan Alexander [mailto:janalex@microsoft.com]
Sent: Friday, April 25, 2008 8:34 PM
To: Hal Lockhart; Corinna Witt; Will Hopkins; Marc Goodner
Cc: Symon Chang; Thorick Chow; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

 

In attempt to resolve this issue, here is a proposal to address the ambiguity around bootstrap policy and SCT renew/cancel/amend message exchanges. I propose to add the following text after line 1261 in the current WS-SecurityPolicy editor’s draft (http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/27578/ws-securitypolicy-1.3-spec-ed-02.doc).

 

Thanks,

--Jan

 

----------

 

If the bootstrap policy assertion  is used to indicate the security binding and policy in effect when requesting a secure conversation token from the target service, then subsequent Amend, Renew and Cancel messages MUST comply with the following rules.

 

Amending Context

To amend an existing secure conversation token, a requestor uses the context amending mechanism as described by the WS-SecureConversation specification. The message exchange MUST be secured using  the existing (to-be-amended)  SCT in accordance with  the target service (outer) policy, combined with endorsing supporting tokens carrying the new claims to be associated with the amended context with the inclusion mode set to http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient. See the EndorsingSupportingTokens Assertion section for more details on the usage of the endorsing supporting tokens.

 

Renewing Context

To renew an existing secure conversation token, a requestor uses the context renewal mechanism as described by the WS-SecureConversation specification. The message exchange MUST be secured according  to the requirements of the bootstrap policy assertion, combined with  the existing (to-be-renewed) secure conversation token used as an endorsing supporting token with the inclusion mode set to http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient. See the EndorsingSupportingTokens Assertion section for more details on the usage of endorsing support tokens.

 

Canceling Context

To cancel an existing secure conversation token, a requestor uses the context cancelling mechanism as described by the WS-SecureConversation specification. The message exchange MUST be secured using  the existing (to-be-cancelled)  SCT in accordance with  the target service (outer) policy.

 

 

 

From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Monday, April 14, 2008 11:20 AM
To: Jan Alexander; Corinna Witt; Will Hopkins; Marc Goodner
Cc: Symon Chang; Thorick Chow; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

 

Jan,

 

Using a description more familiar to security professionals, a long term secret is used to perform authentication and key exchange of a session key. Later it is possible to perform other operations such as canceling and renewing the session key. The bootstrap policy describes the initial handshake, while a standard security policy describes the use of the SCT to protect the application messages.

 

In our view, the bootstrap policy is merely a convenience, particularly in the common case that the STS and Application Service are co-located. It is a convenience and not required, since we can easily arrange for the Endpoint, Operations and Messages of the STS to be distinct from those of the Application Service, even when these are co-located.

 

However, we like this convenience and simply propose to extend this convenience to the other defined operations of an SC-compliant STS. We need this because the policies for operations such as Cancel and Renew will often be different from those for Issue. For example, see lines 1121-1132 and lines 1221-1226 of the current editor’s draft (http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/18833/ws-trust-1%5B1%5D.3-spec-ed-01-r08-diff.pdf) which make it clear that

 

A) policies for Cancel and Renew are, or at least can be different from Issue, and

 

B) the required policies for Cancel and Renew cannot be determined in advance because of the variability allowed by the spec.

 

We believe that the same motives that make it convenient to have a bootstrap mechanism which applies to Issue, would make it convenient to have the same type of shortcut for other operations such as Renew and Cancel. We do not understand your insistence that the shortcut be reserved for a single (admittedly most common) operation.

 

Hal

 

 


From: Jan Alexander [mailto:janalex@microsoft.com]
Sent: Friday, April 11, 2008 5:24 PM
To: Corinna Witt; Will Hopkins; Marc Goodner
Cc: Hal Lockhart; Symon Chang; Thorick Chow; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

 

Hi Corinna,

 

Let me step back for a moment and try to explain what is the WS-SecureConversation specification about and the reasoning behind not providing explicit support for binding assertions outside the bootstrap binding assertion (e.g. SCT issuance).

 

The whole purpose of WS-SecureConversation is to serve as a mechanism for establishing and maintaining security sessions between an initiator and a recipient. The primary scenario for WS-SecureConversation is to help when there is a need for frequent or chatty communication between two parties where each message needs to be properly authenticated and secured. Most of the authentication schemes today require pretty large payloads and usually a complex computation to be performed by both parties for every message that is being exchanged during the conversation. The WS-SecureConversation attempts to help in such situations by providing means to perform the authentication only once and to tie the messages exchanged during the conversation to that initial authentication step without having to perform the actual authentication for each such message. It does that by providing a concept of security context token (SCT) that essentially represents the fact that the initial authentication was performed. The SCT has an associated secret key that is used by both parties to prove possession of the SCT. The SCT has also a lifetime in which it can be used.

 

As I said above, the SCT represents or substitutes the initial authentication step for the messages exchanged during the conversation and it can be used to substitute any initial authentication step that the communicating parties are capable of performing. In other words, the specification does not limit or prescribe the initial authentication step by any means. This is the reason why we have bootstrap policy assertion inside the secure conversation token assertion; without this assertion you will not be able to describe how to establish the SCT. If the service wouldn’t use WS-SecureConversation (secure conversation token assertion), the bootstrap binding would be THE security binding that you would use to authenticate every message exchanged during the conversation.

 

Once the SCT has been established, there are variety of things you can do with it and the WS-SecureConversation defines all of them. You can use the SCT to protect and authenticate the messages between the two parties. You can also dispose the established SCT, ask for the secret key renewal to extend the lifetime of the SCT and you can update the communicating entities information exchanged during the initial authentication step by amending the token. All of those usages are described by the specification and the message formats for those actions are also defined by the specification. The idea is that by knowing the initial authentication mechanism (e.g. bootstrap binding) you are be able to deterministically tell what is the required message format (or security binding if you will) for the SCT maintenance calls as described by the WS-SecureConversation. Therefore, there should be no need for additional assertions to describe those in the security policy. As matter of fact, such thing would just cause confusion and create unnecessary flexibility by which it would be even possible to make the SCT maintenance calls non-secure. It was never the intention of the WS-SecureConversation specification to make the message format for the SCT maintenance calls flexible for this very reason.

 

That being said, from the fact that you’ve raised this issue and from my previous interop experience, it seems that we haven’t done a good job in the TC to exactly and precisely describe the required message formats for the various SCT verbs that the WS-SecureConversation specification defines. Therefore, I would like to propose to change your current proposal below to a set of updates to the WS-SecureConversation document that would make the message format description for the SCT maintenance calls clear and explicit. Would you be open to such suggestion? If so, I will be more than happy to work with you to come up with the set of changes into the WS-SecureConversation document to make the message formats explicit.

 

Thanks,

--Jan

 

 

From: Corinna Witt [mailto:cwitt@bea.com]
Sent: Monday, April 07, 2008 9:33 PM
To: Will Hopkins; Marc Goodner
Cc: Hal Lockhart; Symon Chang; Thorick Chow; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

 

Hi,

 

Here is some additional material for the discussion of issue 162, e.g. example WSDL/Policies (attached) and comparison of processing steps.

 

The proposal in issue 162 suggests to add RenewPolicy and CancelPolicy assertions as optional child elements of the SecureConversationToken assertion. This is a shortcut that simplifies the processing for the client (no need to retrieve STS WSDL) for the renew and cancel operations, as it already exists for the issue operation.

 

Below is a comparison of the service’s  WSDL and policy and STS’s WSDL and policy for SecureConversationToken according to existing assertion and with additions proposed in issue 162:

Sample WSLD/Policy with added assertions for renew/cancel according to issue 162:

 

Service WSDL/Policy: issue162_service_cancel_renew.wsdl

 

  • has assertion for bootstrap policy (using UNT over SSL) inside of SCT assertion
  • has assertion for RenewPolicy and CancelPolicy asssertion (same as ‘outside policy’ minus bootstrap policy) inside of SCT assertion

 

STS WSDL/Policy: none (not necessary)

 

In this case the service client can directly read the policy to use for renew/cancel from the service WSDL. There is no need for the STS to publish a WSDL/Policy.

 

Sample WSDL/Policy without added assertions for renew/cancel :

 

Service WSDL/Policy: issue162_service.wsdl

 

  • has bootstrap policy (using UNT over SSL) inside of SCT assertion

 

STS WSDL/Policy: issue162_STS.wsdl

 

  • has policy that corresponds to bootstrap policy attached to issue operation (UNT/SSL)
  • has SCT policy (‘outside policy’ minus bootstrap policy) attached to renew and cancel operation

 

The service client needs to retrieve the STS WSDL/Policy before making a renew/cancel call. For this the STS WSDL URI needs to be derived from the SCT/Issuer URI. Afaik, WS-SecurityPolicy does not define a rule for this, although a convention to use the STS URI with “?wsdl” appended to it exists. The STS needs to publish a WSDL/Policy and the policy for the Issue operation is repeated in the service’s bootstrap policy.

 

Corinna


From: Will Hopkins
Sent: Wednesday, March 19, 2008 6:43 AM
To: Marc Goodner
Cc: Corinna Witt; Hal Lockhart; Symon Chang; Thorick Chow; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

 

Hi Marc,

 

We agree that it's possible to attach policy to STS WSDL in the fashion you describe.  We also agree that, in general, it's better to use existing mechanisms rather than invent new ones.

 

That said, we still believe there's an argument for adding renew and cancel semantics to the bootstrap mechanism:

  • The existing standard provides for bootstrap policy even though the same "attach policy to STS WSDL" argument could be made for the issue semantic as well -- if issue is OK, why not renew and cancel?
  • Having renew and cancel policy available from service's WSDL is very convenient for the WS-SC case.
  • WSDL for STS service is pretty minimally specified, and there is no normative text or WSDL file that expresses issue, renew, cancel, or validate as distinct operations.
  • For the case that service and STS are co-located, dependence on STS WSDL implies that the hosting service's WSDL must include WSDL for the STS itself, along with appropriate policy attached at the proper points.  While legal, this construction is a bit odd, and must be accounted for by implementations in any number of different contexts.  (Think about, e.g., tools that generate web service code starting from a WSDL file.)

 

I suspect that many, if not most, implementations have punted on generating/consuming strict WSDL for STS services co-located with WS-SC services, and interoperate today only by virtue of bootstrap policy and various guesses (often faulty) about policy for renew and cancel.  The ability to express renew and cancel policy as <boostrap> will provide for a high degree of interop at a minimum cost to implementors.  The alternative -- reliance on policy attached to WSDL -- is likely to be a high barrier to compliance (and thus interop) for many vendors.

 

Regards,

 

Will

 

 


From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Friday, March 07, 2008 1:01 PM
To: Marc Goodner; Corinna Witt; ws-sx@lists.oasis-open.org
Subject: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

So let’s start with a basic SCT baseline for this discussion:

·         The policy for S (SPol) describes the requirement for a SCT token and (optionally) indicates that the issuer is “STS”. 

·         The policy for STS (StsPol) describes the requirements that it requires for authentication.

·         The client issues an RST to the STS that conforms to StsPol and obtains an SCT which it uses to communicate with S in accordance SPol.

·         The policy for renew and other operations are defined specific to the STS actions within StsPol.

 

Given that baseline, let’s consider the scenario where S hosts the STS itself but uses a separate port.  In this scenario, the flow is the same except that both S and STS are in the same service but using separate WSDL ports.

 

The final scenario is where S hosts the STS itself and uses the same WSDL port for both the STS and the service S.  In this case there are two different kinds of message arriving at the port which have different security policies (SPol and StsPol).  In this case the policy on the WSDL port could be described as:

·         When the action is an STS action use StsPol

·         When the action is a S action use SPol

 

As a simplification for this last scenario the bootstrap semantic was defined so that you could use a notation like Bootstrap(x) where “x” defines the policy for Action=STS-Issue.  This is really just a shorthand mechanism for the generalized conjunctions of WS-Policy.

 

In this scenario if S wanted to have policy for “STS-Renew” it simply needs to use the generalized WS-Policy mechanism that associates policy with the STS-Renew action.

 

 

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Wednesday, February 06, 2008 9:54 AM
To: Corinna Witt; ws-sx@lists.oasis-open.org
Subject: [ws-sx] Issue 162: no way to specify the policies for renew and cancel

 

Issue 162

 

From: Corinna Witt [mailto:cwitt@bea.com]
Sent: Tuesday, February 05, 2008 8:48 PM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: NEW Issue: no way to specify the policies for renew and cancel

 

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. 

The issues coordinators will notify the list when that has occurred.

 

Protocol: ws-sp

 

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf

 

Artifact: spec

 

Type: design

 

Title: No way to specify the policies for WS-SecureConversation renew and cancel

 

Description:

 

WS-SecurityPolicy currently allows to define the WS-SecureConversation bootstrap policy, but there is no way to specify the policies for renew and cancel. WS-Trust and WS-SecureConversation don't talk about how to agree on policy for this either (they just talk about some general requirements for such a policy). The following proposal is intended to start discussion on a solution that would eliminate the need for out-of-band agreements.

 

Proposed Resolution:

 

Add the following to the chapter "5.4.7 SecureConversationToken Assertion" of WS-SecurityPolicy (additions in bold):

 

<sp:SecureConversationToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
  (

  <sp:Issuer>wsa:EndpointReferenceType</sp:Issuer> |

  <sp:IssuerName>xs:anyURI</sp:IssuerName>

  ) ?
  <wst:Claims Dialect="..."> ... </wst:Claims> ?
  <wsp:Policy xmlns:wsp="...">
    (
      <sp:RequireDerivedKeys ... /> |
      <sp:RequireImpliedDerivedKeys ... /> |
      <sp:RequireExplicitDerivedKeys ... />
    ) ?
    <sp:RequireExternalUriReference ... /> ?
    <sp:SC13SecurityContextToken ... /> ?

    <sp:MustNotSendCancel ... /> ?

    <sp:MustNotSendAmend ... /> ?

    <sp:MustNotSendRenew ... /> ?
    <sp:BootstrapPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp:BootstrapPolicy> ?

    <sp:RenewPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp: RenewPolicy> ?

    <sp:CancelPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp:CancelPolicy> ?

   <sp:AmendPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp:AmendPolicy> ?
  </wsp:Policy>
  ...
</sp:SecureConversationToken>

 

/sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy

This optional element is a policy assertion that contains the policy indicating the requirements for obtaining the Security Context Token.

/sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy/wsp:Policy

This element contains the security binding requirements for obtaining the Security Context Token. It will typically contain a security binding assertion (e.g. sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts) describing the parts of the RST/RSTR messages that are to be protected.

/sp:SecureConversationToken/wsp:Policy/sp:Renew Policy

This optional element is a policy assertion that contains the policy indicating the requirements for renewing the Security Context Token.

/sp:SecureConversationToken/wsp:Policy/sp:RenewPolicy/wsp:Policy

This element contains the security binding requirements for renewing the Security Context Token. It will typically contain a security binding assertion (e.g. sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts) describing the parts of the RST/RSTR messages that are to be protected.

/sp:SecureConversationToken/wsp:Policy/sp:CancelPolicy

This optional element is a policy assertion that contains the policy indicating the requirements for cancelling the Security Context Token.

/sp:SecureConversationToken/wsp:Policy/sp:CancelPolicy/wsp:Policy

This element contains the security binding requirements for cancelling the Security Context Token. It will typically contain a security binding assertion (e.g. sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts) describing the parts of the RST/RSTR messages that are to be protected.

/sp:SecureConversationToken/wsp:Policy/sp:AmendPolicy

This optional element is a policy assertion that contains the policy indicating the requirements for amending the Security Context Token.

/sp:SecureConversationToken/wsp:Policy/sp:AmendPolicy/wsp:Policy

This element contains the security binding requirements for amending the Security Context Token. It will typically contain a security binding assertion (e.g. sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts) describing the parts of the RST/RSTR messages that are to be protected.

 


Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]