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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: Prelim WS-RX TC Weekly Meeting Minutes Aug 3rd 2006 (kavi send)


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
TBD

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 i149.

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?


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 i151.

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 i152.

Proposed-05 - Possible interop issue with WS-Addressing


Accepted as i153.

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.

i149 - 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.

i150 - 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.

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

i152 - New section 6 wording too specific
not discussed

i153 - 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

OASIS Kavi web interface for TC mail list works. Sending directly to list is still broken.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/mail_to_wg.php




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