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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: Suggested text for replacement/enhancement of Recipient attribute


The consensus (ok, maybe a bit strong) on the focus call was to go ahead and
lock down the front-channel bindings with a properly defined Recipient
attribute on the protocol envelopes.

Note: I'm not talking about the SubjectConfirmationData attribute. Different
thing, though similar.

I propose we rename this to something else. I suggest "Destination", which
more strongly connotes "address" as opposed to "identity". I reviewed
WS-Addressing, and the best choices to me were "Destination", "Address" or
"To" and Destination seemed the most clear.

Changes to core:

Add to section 3.2.1, RequestAbstractType definition:

<<<
Destination [Optional]
A URI reference indicating the address to which this request has been sent.
This is useful to prevent malicious forwarding of requests to unintended
recipients, a protection that is required by some protocol bindings. If it
is present, the actual recipient MUST check that the URI reference
identifies the location at which the message was received. If it does not,
the request MUST be discarded. Some protocol bindings may require the use of
this attribute (see [SAMLBind]).
>>>

In section 3.2.2 (currently it's mis-numbered as 3.2.1.1),
StatusResponseType definition, remove the Recipient attribute, and replace
with:

<<<
Destination [Optional]
A URI reference indicating the address to which this response has been sent.
This is useful to prevent malicious forwarding of responses to unintended
recipients, a protection that is required by some protocol bindings. If it
is present, the actual recipient MUST check that the URI reference
identifies the location at which the message was received. If it does not,
the response MUST be discarded. Some protocol bindings may require the use
of this attribute (see [SAMLBind]).
>>>

Changes to bindings:

Add text to the Security Considerations sections of the Redirect and POST
bindings, sections 3.4.5.2 and 3.5.5.2:

<<<
If the message is signed, the Destination XML attribute in the root SAML
element of the protocol message MUST contain the URL to which the sender has
instructed the user agent to deliver the message. The recipient MUST then
verify that the value matches the location at which the message has been
received.
>>>

I will subsequently update the examples in the document as well.

I don't believe we have to say anything in profiles, per the layering in the
spec. Various profiles require signing when using POST or Redirect, and
signing thus implies use of the attribute as above across all of them.

-- Scott



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