[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 5133Title: 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 CallFrom Kavi. Meeting was quorate. 2 Review and approval of the agenda1) 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 minutesNeed 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 InteropThe 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 CDMarc 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 Reviewhttp://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-callEmail 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 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 89http://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 94http://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 91http://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 92Anish stated we should work on this at the next meeting. 3.5 Proposed 04Anish 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]