WS-RX TC Weekly Meeting Minutes

 

Date:  Thursday, 03 August 2006

Time:  01:00pm - 02:30pm PT

 

Event Description:

Dial-in: Thanks to BEA

IRC/Q Mgmt(thanks to DougD): http://webconf.soaphub.org/conf/room/wsrx

 

Agenda:

1) Roll Call

Name

Company

Lei Jin

BEA Systems, Inc.*

Dave Orchard

BEA Systems, Inc.*

Gilbert Pilz

BEA Systems, Inc.*

Ian Jones

BTplc*

Kazunori Iwasa

Fujitsu Limited*

Robert Freund

Hitachi, Ltd.*

Nobuyuki Yamamoto

Hitachi, Ltd.*

Doug Davis

IBM*

Christopher Ferris

IBM*

Matt Lovett

IBM*

Anthony Nadalin

IBM*

Peter Niblett

IBM*

Stefan Batres

Microsoft Corporation*

Paul Cotton

Microsoft Corporation*

Colleen Evans

Microsoft Corporation*

Marc Goodner

Microsoft Corporation*

Ondrej Hrebicek

Microsoft Corporation*

Asir Vedamuthu

Microsoft Corporation*

Chouthri Palanisamy

NEC Corporation*

Paul Knight

Nortel Networks Limited*

Lloyd Burch

Novell*

Steve Carter

Novell*

Martin Chapman

Oracle Corporation*

Anish Karmarkar

Oracle Corporation*

Ashok Malhotra

Oracle Corporation*

jeff mischkinsky

Oracle Corporation*

Sanjay Patil

SAP AG*

Steve Winkler

SAP AG*

Umit Yalcinalp

SAP AG*

Glen Daniels

Sonic Software Corp.*

Doug Bunting

Sun Microsystems*

Dan Leshchiner

Tibco Software Inc.*

Shivajee Samdarshi

Tibco Software Inc.*

Lily Liu

webMethods, Inc.*

Paul Fremantle

WSO2*

 

2) Allocation of a minute taker

Marc Goodner volunteered

 

3) Review and approval of the agenda

Approved.

 

4) Approval of the July 27th meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00184.html

Approved with unanimous consent.

 

5) a) Discussion of the PR schedule (see Sanjay's note)

 

8/3 – End of conf-call: Cut-off time for resolved issues that will go into the PR

8/4 - Editors produce a candidate PR draft (version 1).

8/10 -TC review begins conf-call: TC review of PR candidate draft (version 1) ends. Disposition of the received comments is decided on the conf-call

8/11 - Editors produce a new PR candidate draft (version 2)

8/17 - Ballot is conducted on the conf-call to decide whether the PR candidate draft version 2 should be submitted for public review.

 

Votes will be held on the TC call.

 

Above schedule accepted by TC.

 

 

   b) Update from editors

 

Editors find the above schedule acceptable.

Editors request TC send in editorial comments ASAP, preferably today.

  

6) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php.

 

PR Issue list.

In progress.

 

State tables, should have been closed.

 

I140 should have been closed.

 

I145 should have been closed.

 

7) New issues since last conf-call

Proposed-01 - MsgNumRollover Fault is too restrictive

Description:
After this week's f2f MsgNumRolloverFault now says that " The RM Source MUST NOT send any new messages" upon receipt of this fault.  I think this is too restrictive.  One possible recovery algorithm could be for the RMS to negotiate with the RMD for a larger # for this sequence - and then continue to use the sequence.  This applies to cases where we didn't reach 9,223,372,036,854,775,807.

Proposal:
Remove this sentence.
Remove the "Rollover" column from the RMS state table since fixing this would make this column the exact same as the "Created" one.

Accepted as i153.

 

Proposed-02 - Editorial issues with the latest editor's draft

Log Question on wsaw:Action at end of this list as new issue i150.

 

Comments on the wsdl file:

This should be pulling in the new WS-A WSDL namespace, and replace

wsa:Action with wsaw:Action. That might mean a second update to the

namespaces table at the start of the spec. Perhaps we are waiting for

this to become a reccomendation?

 

Accepted as i154.

 

Proposed-03 - RMS and RMD should not both use same STR when sending

*Description*

The current WD[1] describes a single STR for use in both directions.

However, two systems should never share private keys or other asymmetric security claims.  Such sharing is unfortunately necessary for both to demonstrate proof of possession of the same tokens.

 

When the WS-RM protocol and a request / response MEP are used together for example, the WSS[2] implementation at the recipient verifies claims

(tokens) but does not use the same claims to secure the response.

 

*Justification*

Use of same STR for offered Sequence weakens the security of the WSS / WS-RM solution.  The current approach also introduces a special case for offered Sequences where the two directions are otherwise closely aligned.

 

*Target*

core

 

*Type*

technical

 

*Proposal*

 

    * Remove the clause "(and, if present, the offered)" where it

      appears (twice) in lines 1270-1271.

    * Duplicate lines 1266-1308, with appropriate (request -> response,

      created -> offered) substitutions, to allow inclusion of an

      <wsse:SecurityTokenReference> and <wsrm:UsesSequenceSTR> in the

      Create Sequence Response message.

 

The addition above could introduce fault cases I (at least) don't know how to handle: How to handle mustUnderstand faults a SOAP response causes?  May be best to limit use of an STR in the Create Sequence Response to those where the Request message included a <wsrm:UsesSequenceSTR>.  Not sure if the <wsrm:UsesSequenceSTR> element would then be needed in the Create Sequence Response.

 

*References*

[1] Latest WS-RM WD

<http://www.oasis-open.org/committees/download.php/19430/wsrm-1.1-spec-wd-15.pdf>

 

[2] WSS 1.1 core OS

<http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

 

Accepted as i155.

 

Proposed-04 - New section 6 wording too specific

*Description*

The current WD[1] mentions (line 1272) "demonstrate proof-of-rights to the referenced key" but "The <wsse:SecurityTokenReference> element provides an extensible mechanism for referencing security tokens and other key bearing elements." according to [2] (lines 829-830).  Security tokens, in turn, include any "claims" such as username / password pairs.  The WD wording is thus too specific.

 

*Justification*

Should support any WSS profile defined now or in the future.  Therefore, should word WS-RM as generally as WSS.

 

*Target*

core

 

*Type*

Editorial though the text appears normative

 

*Proposal*

change line 1272 to read "demonstrate proof-of-rights to the referenced *claim*"

 

*References*

[1] Latest WS-RM WD

<http://www.oasis-open.org/committees/download.php/19430/wsrm-1.1-spec-wd-15.pdf>

 

[2] WSS 1.1 core OS

<http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

 

 

Accepted as i156.

 

Proposed-05 - Possible interop issue with WS-Addressing

Description:

The WS-Addressing WSDL wsaw:Anonymous element indicates whether or not the use of the anonymous URI is optional, required or prohibited.  This causes a problem for MakeConnection since it doesn't use the WSA anonymous URI - instead it defines it own.  Which means that an endpoint compliant to WSA may reject a use of the RM anon URI not because it doesn't support MakeConnection but rather because the definition of this WSDL element doesn't allow for other specs to define their own anon URIs.

Proposal:
The RX TC, thru its connections with the WS-Addressing WG, should see if its possible to modify the language of this element such that it doesn't tie itself to just the one anonymous URI defined by WSA, rather phrase its requirements more broadly, saying that this element indicates whether or not a URI referring to the transport-specific back-channel is optional, required or forbidden.  This would allow for other specs to define their own anon-like URI (like RM did) but still, in essence, mean the transport back-channel.

 

Accepted as i157.

 

8) Issue Discussion:

 

i146 Need Fault to indicate security constraints have been violated

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i146

 

New proposal:

 

 

Proposed fault is needed to report that the security is not correct, could be very helpful in debugging situations.

 

Some concerns expressed that this fault is not needed.

 

Concern that this proposal has an implicit requirement to use the exact token from the STR, could impact use of derived keys. Proposed modification to address:

Change proposed text for 6.1 to: Once the association between a Sequence and a secret has been established, the receipt of any message using that Sequence and not properly demonstrating knowledge of, or rights to, the secret MAY be signaled by the RM Source or RM Destination via the wsrm:SecurityViolation exception. This specification does not mandate that this fault be returned to the sending party as this could be used as part of a denial of service attack.

 

Concerns over information disclosure in using this fault, no impact on receiver, it is an implementation detail.

 

Motion to close with no action, from Chris Ferris, seconded by Matt Lovett

No objections.

 

i153 - MsgNumRollover Fault is too restrictive

Description:

After this week's f2f MsgNumRolloverFault now says that " The RM Source MUST NOT send any new messages" upon receipt of this fault.  I think this is too restrictive.  One possible recovery algorithm could be for the RMS to negotiate with the RMD for a larger # for this sequence - and then continue to use the sequence.  This applies to cases where we didn't reach 9,223,372,036,854,775,807.

 

Proposal:

Remove this sentence.

Remove the "Rollover" column from the RMS state table since fixing this would make this column the exact same as the "Created" one.

 

Motion to accept proposal by Chris Ferris, seconded by Stefan Batres

Discussion of error conditions related to this fault, renegotiation for new sequences.

Text was added as part of issue 140 on faults.

Motion failed.

 

i154 - Question on wsaw:Action

Comments on the wsdl file:

This should be pulling in the new WS-A WSDL namespace, and replace

wsa:Action with wsaw:Action. That might mean a second update to the

namespaces table at the start of the spec. Perhaps we are waiting for

this to become a reccomendation?

 

Concern over impact of namespace between CR and REC

Plan to keep namespace stable

No issues logged against spec right now

Concern over syntactic changes that would happen between CR and REC

 

Motion to replace wsa:Action with wsaw:Action using the CR namespace, add wsaw to namespace table.

Reopen issue if namespace changes between CR and REC.

Made by Chris Ferris, seconded by Matt Lovett.

No objections.

 

i155 - RMS and RMD should not both use same STR when sending

not discussed

 

i156 - New section 6 wording too specific

not discussed

 

i157 - Possible interop issue with WS-Addressing

not discussed

 

9) Interop schedule and next steps

8/4 Candidate PR

8/10 Call, review PR1, decide on actions

8/11 - Editors produce a new PR candidate draft (version 2)

8/17 conf-call:  Ballot to accept PR draft 2 as CD4, Ballot to accept CD4 as PR

8/21 PR begins

9/11 Interop2 scenarios ready

9/25 Start interop

10/2 Virtual interop day 1

10/3 Virtual interop day 2

10/6 End interop

10/20 PR ends

 

Dug, Eric, Matt and Stefan checking their availability to work on interop scenarios.

Suggestions to add security, make connection and more “real world” scenarios.

Counter suggestion made for the mimum required to declare victory approach.

No objections to covering security, make connection, and both in combination in this round.

 

 

10) AOB