[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New proposed issues 2/2 - 2-8
Four new proposed issues this week, let me and the list know if any were missed. – Marc g
-----------------------------
Proposed-01
Title: RM Sequence Hijacking threat
Proposed-02
Title: Signature replacement threat
Proposed-03
Title: Scoping an RM sequence to a security context
Proposed-04 Title: CloseSequenceResponse and TerminateSequenceResponse messages are inconsistent wrt presence of wsrm:Identifier
----------------------------- 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.
----------------------------- 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.
----------------------------- 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
----------------------------- 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.
Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/mrgoodner/
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]