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 Minutes of WSRX TC telecon 2/9/06


Prelim Minutes are attached.

Please provide corrections to the list before Next Monday.

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Preliminary Minutes WSRX TC Teleconf

Prelim Minutes OASIS TC Teleconf

Thursday February 9, 2006

 

4:00 to 5:30 EST

 

Textual Conventions

 

Ø  Action Item

Motion

§    Resolution

 

1         Roll Call

From Kavi.

 

Meeting was quorate.

2         Review and approval of the agenda

1) Roll Call

 

2) Review and approval of the agenda

 

3) Approval of the previous meeting minutes

 

4) Editor's team and Interop - WD/CD basis of the Interop

The Interop committee have requested that the Editor's team could produce a new WD including all the pending issues agreed by the end of last weeks call

(i058, 75, 78, 82, 83, 85, 86, 87, 88, 93 by my calculation), by Feb 17th.

i) Status check.

ii) Conversion to CD

 

5) AI Review

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

 

6) New issues since last conf-call

Email to follow

 

7) Issue Discussion:

 

i089 suggest the restricted use of anonymous URI

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

 

i094 Doug Davis New WSRMRequired Fault

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

 

i091 Bob Freund-Hitachi Unexpected UnknownSequenceFault or

SequenceTerminatedFault

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

 

i092 Anish Karmarkar Where is the SequenceAcknowledgement sent on

receipt of AckRequested header?

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

 

i061 Doug Davis Anonymous AcksTo

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

 

i090 Daniel Millwood Use of offered sequences unclear in current

spec

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

 

i021 Jacques Durand An RM Policy applies two-way

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

 

i008 Tom Rutt Policy assertions granularity

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

3         Approval of the previous meeting minutes

Need to add reference to Umit’s email

 

http://lists.oasis-open.org/archives/ws-rx/200602/msg00041.html

 

Tom will add and post new version for approval next week.

4         Editor's team and Interop - WD/CD basis of the Interop

The Interop committee have requested that the Editor's team could produce a new WD including all the pending issues agreed by the end of last weeks call

(i058, 75, 78, 82, 83, 85, 86, 87, 88, 93 by my calculation), by Feb 17th.

 

Doug D: It is still my goal to lead the editors to meet these dates.

 

 

4.1                              i) Status check.

4.2                              ii) Conversion to CD

Marc G: when will the CDs be put into the website at the proper locations.

 

Gil: I will take care of it.

 

Ø  Action: Gill will work with OASIS staff to get the CD 2 artifacts posted properly.

 

Paul F : suggest we have New wd on feb 17, with a vote to convert to CD 3 , March 2.

 

Paul C: will the namespaces change from cd 2 to cd 3.

 

Ø  Action: namespace should change with Candidate draft 3 (Doug D)

 

 

1         AI Review

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

 

#0056: Ensure that the final WSA specifications include text for handling of anonymous IRI values for non-WSA EPRs

Owner: Robert Freund

Status: Open

Assigned: 2005-12-13

Due: ---

Leave Open

--------------------------------------------------------------------------------#0070: Paul F will discuss OASIS hosted TC teleconferences with the OASIS staff, making clear the unacceptable quality of some “free call” bridge services

Owner: Paul Fremantle

Status: Closed

Assigned: 2006-01-18

Due: ---

To Close, Oasis staff response posted to list.

--------------------------------------------------------------------------------#0076: Bob F will provide proposal to close issue 084 with clarification text

Owner: Robert Freund

Status: Open

Assigned: 2006-01-31

Due: ---

Leave Open

--------------------------------------------------------------------------------#0079: Paul F to propose message override to endpoint policy assertions for Issue 21

Owner: Paul Fremantle

Status: Closed

Assigned: 2006-02-07

Due: ---

Close.

2         New issues since last conf-call

Email Sent by Marc G:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00066.html

 

2.1                              Proposed-01

 

Title: RM Sequence Hijacking threat

 

Description:

 

For RM to work in the full generality of the Web services security model it needs to support sequence creation based on specific claims not just identity (in fact no identity credentials may even be present).  This means that if session-specific credentials beyond the initial authorizing credentials are not identified, any party with the authorizing credentials can hijack the session.  For example, if anyone in group X can create a sequence, then Alice can use a sequence that Bob created so long as both Alice and Bob are in group X.

 

Such security relies on the confidentiality of the sequence ID imposing limitations on the ID (to prevent brute force attacks and guessing), risks to logging sequence information (which is a desirable action), and increased complexities in allowing front-end and intermediary systems to process and direct messages in intermediary scenarios (the sequence header has to be added and encrypted for each intermediary and signed by the originator eliminating dynamic intermediaries, etc…)

 

This can be mitigated by mechanisms such as TLS. It is important that when using such mechanisms that they be bound to the RM session to prevent gaps in the security through potential intermediate hops. However TLS has at least two shortcomings in mitigating against this threat. One is that if an RM session may run longer than the TLS session, this is particularly true for mobile clients. The other is that it may not be available on every transport that RM may be used with. There are other problems such as end-to-end security, TLS is needed at each hop and untrusted intermediaries will have access to the ID without additional precautions.

 

Therefore a richer binding of a security context to a RM session should not be left undefined.

 

This binding is accomplished as follows. A service user establishes a security context with their credentials prior to creating the RM session. This security context has the claims necessary for creating a sequence. The keys associated with the security context are only known to the two parties, other users in group X are not part of this security context. This security context is used in the RM sequence creation thus binding the two at creation time. With this coupling in place, the RM sequence is effectively "owned" by the security context identified in the sequence creation that establishes the security context in this example. Establishing security semantics after the resource is created leaves an attack window for creation attacks.

 

The binding of a token to the RM sequence creation can be done by including a STR to the token in the CS message.

 

Target: core

 

Type: design

 

Origin: Marc Goodner

 

http://lists.oasis-open.org/archives/ws-rx/200602/msg00037.html

 

Proposal:

 

Add the threat as described in the issue description to the security considerations as “Hijacking” in the list of enumerated threats after line 817.

 

 

-----------------------------

Dave O: I sent a message to the list on proposed 01 and 01, which proposes a reversal to the resolution of I29.  My suggestion is to reopen I 29 with this new information.

 

Paul F: I agree they are related to I29, but my preference is to treat these as new issues to the spec as it exists today.  There is value to treat them separately to track as new issues.

 

Sanjay: I do not see any new information from the discussions we had before resolving I029.  Other companies wanted to use their own mechanisms to solve the problem.  It was discussed to express such a usage in a profile.  These new issues seem to seek a reversal of I029.

 

Marc G: I agree with Paul F to discuss these threats as issues..  I do not care about the reopening of I029, but this would be most relevant to my proposed 03.  There is more there than the earlier resolution.

 

Sanjay: There is not substantially new information on the table to warrant reopening the issue.

 

Marc G: These threats are better characterized now than they were during the prior discussions.

 

Paul F: If there are security issues with the spec, then we need issues to track them.  We should focus on whether to accept these as new issues.

 

Anish: I do not think these are new issues.  P03 is directly a reversal of I29, and the others are use cases to drive a different solution to I028.  I see all three of them as new issues.

 

Umit: a composition profile, while useful, should not be relinked to past resolutions.

 

Paul F: are there issues in the spec that need to be solved.  How is the committee going to work on that without a new issue.

 

Umit: is this the core alone, or the Core with something else.

 

Glen: Opening issues does not mean we will be doing things to resolve it here.  There are other WS specs which can be composed to solve these problems.

 

Sanjay: the security threats which have been listed are not complete.  It is ok to point out potential security issues.  I do not think we should accept these as new issues.

 

Gil: proposed 01 and proposed 02 seem ok, but proposed 03 seems like a simple reversal of I029.    There does not seem to be sufficient new information to open a closed issue.  Proposed 01 and proposed 02 were proposed at the face to face in the discussion.  

 

Paul F: are there objections to accepting proposed 01 and 02.

 

Dave O: I can accept the proposed issues  1 and 2, but without the proposal to change the resolution to I099.

 

Paul F: all proposed resolutions have no status.

 

Dave O:  I think that the issues 1 and 2 are goodness.  The more detail we provide in a security section the better.  Some folks want to have new issues, and want to reopen i029, while others do not want to accept resolution to reopen I029.  I propose a compromise, which removes the proposed solution which reopens I029.

 

Paul F: would Marc G accept this proposal. To accept the new issues 1 and 2 without proposed text, and do not accept proposed 03.

 

Marc G: I do not agree  We should accept the issues and discuss them.

 

Dave O: some people see 03 is a reopening of I029.

 

Chris F: Move to accept proposed 1, 2 and 3, seconded by Marc G.

 

Jeff M made Motion to divide , Umit seconded.

 

§    Motion to divide accepted, will vote p 01 , 2, and 3 separately.

 

Tom: The protocol can support all these use cases.  There is an extension.  Such solutions should be out of band of this protocol.  Application level constructs can prevail, just as we decided previously for security and DA.

 

Paul C: I call the question.

 

Paul F: any objection to calling the question.

 

Gil : Paul C put something in the web chat to join p01 and p01.

 

Jeff M: this is out of order.

 

Separated Motion to accept proposed issue 1

 

Objections:

 

Vote taken by chair:

11 yes, 16 No

 

§    Motion to accept proposed issue 01 not passed

 

 

2.2                              Proposed-02

 

Title: Signature replacement threat

 

Description:

 

Signature confirmation for an RM session is important so that signature replacement can be quickly detected. This is important to protect against the unintended processing of user data. If an attacker replaces the signature on the CS message, then the signature confirmation will indicate the replacement and the initiator knows not to use the sequence. Assume there is an RM session initiated without having its signature compromised, the associated signature has specifically chosen privileges required for the service. In this case the signature could be replaced with a new signature that has different privileges associated with it to execute functions at the service other than what the provider intends. In this case the initiator would be able to detect this on confirmation (if they receive it) but the service would have already processed the compromised message.

 

However, if the token (keys) were bound to the sequence during the RM sequence creation the service would detect that the message was altered before processing it. This is because a different token will not be allowed for the entire RM session which would prevent an attacker from being able to replace a signature and have the message processed before the signature was confirmed by the initiator (if at all).

 

On a related note there is also the threat of associating the wrong or superset credentials in scenarios where messages require multiple signatures because of other headers and message aspects. Binding a token to the RM sequence at creation also disambiguates which token is intended for the RM CreateSequence message if there is more than one primary token.

 

The binding of a token to the RM sequence creation can be done by including a STR to the token in the CS message.

 

Target: core

 

Type: design

 

Origin: Marc Goodner

 

http://lists.oasis-open.org/archives/ws-rx/200602/msg00038.html

 

Proposal:

 

Add the threat as described in the issue description to the security considerations as “Signature replacement” in the list of enumerated threats after line 817.

 

-----------------------------

 

Separated Motion to accept proposed issue 2

 

Objections:

 

Vote taken by chair:

14 yes, 17 No

 

§    Motion to accept proposed issue 02 not passed

 

 

2.3                              Proposed-03

 

Title: Scoping an RM sequence to a security context      

 

Description/Justification:

 

There are several threats, hijacking [1] and signature replacement [2], that can best be mitigated by binding the RM sequence to a specific security context identified by a token. For the sake of interoperability it is best that this capability be defined in the protocol rather than be left to a implementation detail for implementers and/or users of the protocol. Likewise it should be possible for an RMD to represent that it does or does not support this capability.

 

Target: core

 

Type: design

 

Origin: Marc Goodner

 

http://lists.oasis-open.org/archives/ws-rx/200602/msg00048.html

 

Proposal:

 

WS-RM Changes

 

Line numbers from WS-RM CD 02

 

Add “An RM Destination MUST fault if it does not understand information passed using this extensibility mechanism.” to the end of lines 297 and 300.

 

The above would mean prevent an RMD from silently ignoring use of the extensibility points in the create sequence and would read in the spec as follows:

 

/wsrm:CreateSequence/{any}

 

This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, to be passed. An RM Destination MUST fault if it does not understand information passed using this extensibility mechanism.

 

/wsrm:CreateSequence/@{any}

 

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element. An RM Destination MUST fault if it does not understand information passed using this extensibility mechanism.

 

Add the following after line 300:

 

/wsrm:CreateSequence/wsse:SecurityTokenReference

 

This optional element uses the extensibility mechanism defined above to communicate an explicit reference to the security token to be used to authorize messages for the created outbound Sequence and if offered the inbound Sequence, using a <wsse:SecurityTokenReference> as documented in WS-Security [WSSecurity]. All subsequent messages in the outbound Sequence and if offered the inbound Sequence MUST demonstrate proof-of-possession of the referenced key.

 

WS-RM Policy Changes

 

Line numbers from WS-RM Policy CD 02

 

Line 96

 

Change: “defines a single RM policy assertion”

 

To: “defines two RM policy assertions”

 

Add a new assertion description as follows after line 116:

 

WS-SecurityPolicy [WS-SecurityPolicy] provides a framework and grammar for expressing the security requirements and characteristics of entities in a XML web services based system. The Secure Sequence Binding assertion allows the expression of additional security requirements particular to RM sequences to be used in conjunction with WS-SecurityPolicy. Specifically it defines that an RM sequence MUST be bound to an explicit token.

 

The RM Security assertion MUST NOT be used for an endpoint that does not also use the RM assertion.

 

Add the following after line 141:

 

The normative outline for the Secure Sequence Binding Assertion is:

 

<wsrmp:SecureSequenceBinding

 

[wsp:Optional="true"]? ... >

 

</wsrmp:SecureSequenceBinding >

 

/wsrmp:SecureSequenceBinding

 

A policy assertion that specifies security requirements which MUST be used with an RM Sequence that are particular to WS-RM and beyond what can be expressed in WS-SecurityPolicy.

 

/wsrm:SecureSequenceBinding /@wsp:Optional="true"

 

Per WS-Policy [WS-Policy], this is compact notation for two policy alternatives, one with and one without the assertion. The intuition is that the behavior indicated by the assertion is optional, or in this case, that the RM Sequence binding to a specific token MAY be used.

 

Line 143

 

Change: “Because the RM policy assertion indicates endpoint behavior over an RM Sequence, the assertion has”

 

To: “Because the RM policy assertions indicate endpoint behavior over an RM Sequence, the assertions have”

 

Assertion example and schema outline TBD

 

Reference:

 

1 hijacking threat http://lists.oasis-open.org/archives/ws-rx/200602/msg00037.html

 

2 signature replacement threat http://lists.oasis-open.org/archives/ws-rx/200602/msg00038.html

 

-----------------------------

 

Separated Motion to accept proposed issue 3

 

Objections:

 

Vote taken by chair:

12 yes, 21 No

 

§    Motion to accept proposed issue 03 not passed

 

 

2.4                              Proposed-04

 

Title: CloseSequenceResponse and TerminateSequenceResponse messages are inconsistent wrt presence of wsrm:Identifier

 

Description/Justification: Both the CloseSequenceResponse and

 

TerminateSequenceResponse follow a similar pattern, but the CSR message

 

does not contain the wsrm:Identifier whereas the TSR does.

 

Target: wsrm spec

 

Type: design

 

Origin: Anish Karmarkar

 

http://lists.oasis-open.org/archives/ws-rx/200602/msg00056.html

 

Proposal: Either (1) add the wsrm:Identifier element to the

 

CloseSequenceResponse message OR (2) remove the wsrm:Identifier element in the TerminateSequenceResponse message.

 

 

No objections to accepting Propose 04 as new issue.

 

3         Issue Discussion:

3.1                              Issue 89

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

 

Doug: Proposed For issue 089:

add this text after line 447 of CD2:

Messages sent using this protocol MUST NOT use a wsa:To value that would prohibit the RM Source from retransmitting unacknowledged messages. For example, using WS-Addressing's anonymous IRI, without any additional transmission mechanism, would restrict an RM Source's ability to re-establishing a new connection to the RM Destination when a re-transmission of a message is needed.  Note, that this implicitly impacts possible values used in other places - for example, in wsa:ReplyTo when responses are expected to be transmitted reliably.

 

Umit: are you putting restriction on the back channel.

 

Anish: is it replyTo or To.  

 

Doug D: the replyTo becomes the To.

 

Umit: it is generally agreed that the use of anonymous on a request is not useful.  Are you saying there are problems with reply.

 

Doug D: there can be problems even in replyTo.  This is intended to make it consistent with Ack To.

 

Chris F: move to accept Doug D proposal for resolving I 89.  Doug D seconded.

Paul F: the RMD relies on the rms to make calls to it, and can use the back channel to respond.  While happy with warning, I do not want to prohibit its usage.

 

Doug D: It does not prohibit, but gives warning.

 

Umit: I have similar concern from Paul F.  It seems to imply a prohibition.

 

Paul F: if the back channel messages have a wsa:to of anonymous this would be prohibited.

 

Umit: I need to carefully review the text in the proposal.

 

Anish: I am ok with the text, but id should include the example of replyTo being converted to To., which calls the problem.

 

Paul F: I am not happy with adding this text to the spec.

 

Umit: I agree with Paul.

 

Call question.

 

No objection to call question.

 

Umit: I am objecting to this text.

 

Paul F: I think there is a semantic problem here, the text does not capture agreed semantics.  It is not sufficient to have the editors fix this editorially.

 

Umit moved to table motion, seconded by Paul F::

 

§    Agreed to Table the motion on I89 , to allow Doug D to provide new text.

 

 

3.2                              I 94

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

 

 

Doug D moved to accept proposal to resolve I 94, Anish seconded.

 

§    No objections, I94 closed with Doug D proposal.

 

 

3.3                              I 91

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

 

Chair asked for any objections to Bob’s proposed resolution to I 91.

 

§    No objections to accepting Bob’s proposed resolution to I 91

 

3.4                              I 92

 

Anish stated we should work on this at the next meeting.

 

 

3.5                              Proposed 04

 

Anish sent out proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00070.html

Here is the detailed proposal to resolve the as yet unnumbered issue:

 

All changes are wrt CDII

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16271/wsrm-1.1-spec-cd-02.pdf

 

1) After line 398 insert:

      <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

 

2) After line 404 insert:

/wsrm:CloseSequenceResponse/wsrm:Identifier

This REQUIRED element MUST contain an absolute URI conformant with

RFC3986 that uniquely identifies the Sequence that is closed.

 

/wsrm:CloseSequenceResponse/wsrm:Identifier/@{any}

This is an extensibility mechanism to allow additional attributes, based

on schemas, to be added to the element.

 

3) After line 1049 (in schema) insert:

          <xs:element ref="wsrm:Identifier"/>

 

-Anish

 

Chair asked for objections to close Proposed 04 with Anish proposal,

 

§    No objection, proposed 04 closed by accepting Anish proposal.



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