RE: [wssqop-discuss] Comments on wssqop scope and WSSQoP draft

[Ahmed, Zahid]

Title: RE: [wssqop-discuss] Comments on wssqop scope and WSSQoP draft

>Currently the discussion is considering the inclusion of TLS and message level security.

>If we're going to include possible combinations of TLS and message level security,

>it might be a good idea to use the approach of introducing "Profiles" similar to the

>WSS profiles;

 

I agree that we should create profiles of when we want to combine two or more

security policies associated with different levels of the web services communication

stack. Using OASIS WSS profiles as the format is fine. I also believe that eventually

the combination of multiple web services "features" together for a particular class of

web services applications/scenario will be an interesting interoperability problem

and will require fomalized definition of profiles. However, lets stick to WSS profile

templates for now.

 

>in other words: let us create a framework extending WSDL.

>Within this framework, mandatory/optional security tokens may be specified within the

>following WSDL elements:  definitions/portType/[operation|operation/input|operation/output|operation/fault]:

>specify message level security for the operation and/or the input/output/fault messages 

>definitions/binding: specify transport level security and/or message level security

>about wsse:Security elements in the SOAP header section

 

Some point in time we would need to decide on the required set of security policies

that we are interested in standardizing and exposiong to web service requestors and

providers at design- and run-time.

 

Right now we have informally collected some of the key transport, message, and

service level aspects of security properties that require policy control and interoperability.

However, we are missing some additional ones for example, NRR and NRO. In latest

OASIS WSS Core Specification there is support for message timestamp. In OASIS

ebXML v. 2.0 there is support for NRR/NRO which I believe could be used for both

message-level and payload-level.

 

A (security) policy abstraction for WSDL would be useful in the current schema

included in the strawman.

 

>An open issue is, to what level of detail we should describe the mandatory security

>features/tokens. Should it be possible to describe "To call this web service successfully,

>use either SSL with client authentication, or use a SAML authentication statement and

>encrypt [parts of] the message body". My feeling is, that we should limit ourselves to the

>case specification of one feature/tokens per binding. If different options are available (i.e.

>SSL or SAML), multiple bindings should be made; one for SSL and a different one for

>SAML.

 

 

This is related to the above discussion, I believe. It is certainly easier to focus on

specifying security properties per ferature rathen than multiple feature combinations.

Profile specifications for multiple web services features such as:

 

"To call supplier service successfully send Purchase orders over reliable delivery

channels such that all purchase order line items in SOAP payload are encrypted

and an SAML assertion exists of the buyer."

 

These are complex profiles and no standards exists currently for such scnearios.

 

My recommendation is that we decide this issue after a formation of a TC. For example,

if this group's work gets formalized into a TC, we could possible push some profile

requirements to other standards bodies or TC groups within OASIS.

 

thanks,

Zahid

 

 

 

-----Original Message-----
From: De Boer, Martijn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 09, 2002 6:44 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [wssqop-discuss] Comments on wssqop scope and WSSQoP draft

Hi all,

 

Currently the discussion is considering the inclusion of TLS and message level security. If we're going to include possible combinations of TLS and message level security, it might be a good idea to use the approach of introducing "Profiles" similar to the WSS profiles;

in other words: let us create a framework extending WSDL.

 

Within this framework, mandatory/optional security tokens may be specified within the following WSDL elements:

    definitions/portType/[operation|operation/input|operation/output|operation/fault]: specify message level security for the operation and/or the input/output/fault messages

    definitions/binding: specify transport level security and/or message level security about wsse:Security elements in the SOAP header section

 

Based on this, we should create different profiles (TLS, WSS (UsernamePassword, dsig, xml encr.), SAML, Kerberos, X.509, ...).

The profile would then define a XML-Element that describes the security features/tokens that must be enclosed in the SOAP message to successfully call a web service.

 

By using profiles, we can put the complexity in the profile (and are independent from any release cycles of SAML etc.).

 

An open issue is, to what level of detail we should describe the mandatory security features/tokens. Should it be possible to describe "To call this web service successfully, use either SSL with client authentication, or use a SAML authentication statement and encrypt [parts of] the message body".

My feeling is, that we should limit ourselves to the case specification of one feature/tokens per binding. If different options are available (i.e. SSL or SAML), multiple bindings should be made; one for SSL and a different one for SAML.

 

Other suggestions?

 

Best Regards,

Martijn de Boer

 

 

 

Transport-Level :             port/service
Messaging Framework :  binding
Abstract Operation:         message/portType

-----Original Message-----
From: Ahmed, Zahid [mailto:[EMAIL PROTECTED]]
Sent: Mittwoch, 9. Oktober 2002 07:27
To: 'Tim Moses'; 'Mishra, Prateek'; [EMAIL PROTECTED]
Subject: RE: [wssqop-discuss] Comments on wssqop scope and WSSQoP draft

>To be clear, is the proposal for transport-level QoP to be able to specify server-auth

>or client-auth SSL

 

I think we should be able to specify transport-level authentication properties for both

SSL client (consumer end-point) as well as for the SSL server (provider end-point).

 

Two clarification questions here:

1) What authentication options should be supported for SSL clients? SSL client

certificate authentication is an obvious choice. Should any other option be available

(e.g., HTTP Basic Authentication for HTTP/S or anonymous)?

 

2) Although specifying transport security characteristics w.r.t. SSL is fine should

we should consider supporting TLS as the primary transport security layer protocol?

 

>and to indicate which root-keys are trusted by the provider end-point and which

>root-keys the consumer end-point certificate must chain to? 

 

Yes, we should specify the trusted root certificates (and possibly intermediary

CA certificates) information for client and server in the transport specifications.

 

>And, that this information be associated with the <Bindings> element in the WSDL? 

 

We may need to discuss this further. I would agree with Prateek that transport

security specification should be associated with the WSDL document's service/port

part since that is where the exact location of the end-point service provider is

available (using soap:address location attribute).

 

 

thanks,

Zahid

 

 

 

 

-----Original Message-----
From: Tim Moses [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 7:35 PM
To: 'Ahmed, Zahid'; 'Mishra, Prateek'; [EMAIL PROTECTED]
Subject: RE: [wssqop-discuss] Comments on wssqop scope and WSSQoP draft

Colleagues - To be clear, is the proposal for transport-level QoP to be able to specify server-auth or client-auth SSL and to indicate which root-keys are trusted by the provider end-point and which root-keys the consumer end-point certificate must chain to?  And, that this information be associated with the <Bindings> element in the WSDL?  All the best.  Tim.

-----Original Message-----
From: Ahmed, Zahid [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 4:26 PM
To: 'Mishra, Prateek'; [EMAIL PROTECTED]
Subject: RE: [wssqop-discuss] Comments on wssqop scope and WSSQoP draft

>Further, such a syntax should cover both session-based conversations and
document-oriented
>models.
 
 
Generally, I agree.
 
W.r.t. session-based conversations currently there are no publicly available
specification for
secure conversational message exchanges - as was hinted earlier on this list
- except for a
discussion in the IBM/Microsoft WS-Security roadmap document at:
 
http://msdn.microsoft.com/library/default.asp?url="">
tml/securitywhitepaper.asp
<http://msdn.microsoft.com/library/default.asp?url="">
html/securitywhitepaper.asp>
 
 
I would expect that we can separate out the secure conversation mechanism
from the policy
that can be employed to support that behaviour between a web service
requestor and
provider. However, it would be most useful if the former work could be
available as standards
or an understanding be reached of where that work is going to be done in the
future.
 
W.r.t. document-oriented models, I believe in the strawman, we have a
place-holder for
WSDL invocations that use document-style messaging (DSM) and for RPC-style
messaging.
I agree the syntax should support both binding styles.
 
thanks,
Zahid Ahmed
 
 

-----Original Message-----
From: Mishra, Prateek [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 03, 2002 2:43 PM
To: [EMAIL PROTECTED]
Cc: Mishra, Prateek
Subject: [wssqop-discuss] Comments on wssqop scope and WSSQoP draft

(1)
 
In terms of scope, our interest is in a syntax for expressing security
properties
which can be applied at any one of the following levels of WSDL:
 
Level                                 WSDL term
------------------------------------------
Transport-Level :             port/service
Messaging Framework :  binding
Abstract Operation:         message/portType
 
While it might seem surprising to include Transport-Level descriptions in
the requirements list,
the reality is that schemes such as Basic/SSL are widely used to protect a
web service. But there
is no standard syntax available to express this information.
 
Further, such a syntax should cover both session-based conversations and
document-oriented
models. Notice that WSS supports attachment of an arbitrary binary token to
an XML document, such
as for example, a proprietary session token created by a security engine. So
maybe this issue can be dealt
with at that level (e.g., requirement for some proprietary security token).
 
(2) The WSSQoP draft is restricted to security descriptions at the messaging
framework or binding (WSDL)
level only. We view it as well within the scope of the proposed TC but feel
that a broader discussion along
the lines of (1) would meet the overall business requirement.
 
 
- prateek mishra