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: Proposal on removing or clarifying use of Recipient attribute


Fulfilling action item from today's call:

There are two optional attributes in core named "Recipient". One is in
StatusResponseType, the other is in SubjectConfirmationDataType.

The new one in <SubjectConfirmationData> is a functional replacement for the
use of the old <Response> Recipient attribute in the SAML 1.1 POST profile,
preventing a bearer assertion from being reused at the wrong relying party
by an attacker. This attack is also mitigated by the use of
<AudienceRestrictionCondition>, which indicates *who* can use the assertion;
Recipient is used in the new SSO profile to also indicate *where* the
assertion can be confirmed by the bearer. They are somewhat duplicative, but
it was agreed on the call that this isn't a major problem. If people feel
differently after reading a better explanation, that's fine too. It's mostly
a historical thing.

However, the original Recipient attribute in the protocol message remains in
the schema, inherited from 1.1. It isn't normatively referenced anywhere at
this point. It's purpose, if it were used, is essentially as before, to
"target" a protocol message at a specific recipient or endpoint (it's
probably reasonable to draw an analogy to the actor/role attribute in SOAP).

It is currently unspecified whether this attribute could be used in the
protocols we have defined, and it could be a source of interop problems if
it's not clarified.

I see two options:

A) Remove the attribute, given that it's original purpose has been met with
other message content. ID-FF protocols do not use such an attribute, and
there are no related attacks against anything except the SSO protocol, which
is already addressed. Therefore, one might conclude it isn't needed.

B) Use the attribute, and add it to RequestAbstractType. Normatively specify
within the HTTP front-channel bindings that the HTTP endpoints to which the
SAML protocol messages are being sent MUST be placed in the attribute
(though it can only be trusted if the message is signed, of course).

Either option seems fine to me. I do think if we keep it that the bindings
are the right place to specify the use of it. But I lean toward removal.

-- Scott



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