RE: [security-services] Proposed text for schema change:"TargetR estriction" condition

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

This has been done.

It is not possible to constrain the cardinality since the element is a
condition and there can always be multiple conditions attached.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu]
> Sent: Tuesday, November 27, 2001 11:11 AM
> To: OASIS Security Services TC
> Subject: [security-services] Proposed text for schema change:
> "TargetRestriction" condition
> 
> 
> 
> The "Form POST" web browser profile of SAML (bindings-06, section
> 4.1.6) identifies a particular security threat (4.1.6.1.1, bullet 3),
> which is that a malicious site, receiving an asserted authentication
> statement via POST, might replay the assertion to some other site, in
> an attempt to pose as the subject of the statement (ie, the
> authenticated user).  The identified countermeasure for this threat is
> to include information in the assertion that restricts its use to the
> site to which the POST is done.  In that case, if the malicious site
> attempts to replay the assertion somewhere else, the receiver will see
> the mismatch and reject the assertion.
> 
> Up to now the profile has called for the use of the
> AudienceRestrictionCondition element to carry this information.
> However, we have argued that this condition, though similar, is
> actually different in use, so a new condition is needed.  There was
> discussion of this point at the recent F2F in San Francisco, and the
> group agreed to add a new condition for this purpose.
> 
> The justifications are as follows.  First, the existing text on
> AudienceRestrictionCondition (core-20, section 1.7.2) describes a more
> policy-based use, to limit the use of the assertion to receivers
> conforming to some policy statement.  Shibboleth, for example, would
> use this condition to indicate that an assertion conforms to
> conditions including non-traceability of subject name, user agreement
> with attribute release, etc.  This description would have to be
> rewritten to also support the more specific restriction required by
> the POST profile (which could be done).
> 
> A more telling issue is matching.  While the current description of
> Audience doesn't say how matching is done (should it?), it seems
> likely that in practice these policy URIs would be complete and
> opaque; that is, the receiver would simply do a string match on its
> available set of policy URIs.  A URI "http://example.com/policy1" has
> no necessary relation to "http://example.com/policy2".  On the other
> hand, for the POST profile, the most likely approach would be for the
> assertion issuer to include the entire target URL in the assertion.
> The assertion receiver would then have to match on some substring of
> the URL to determine whether to accept the assertion.  If the same
> condition were to be used for both purposes the receiver would have to
> do matching based on the value of the URI, which seems suboptimal.
> 
> Cardinality is another issue.  It's reasonable for multiple
> AudienceRestriction elements to be included to indicate that the
> recipient should be bound by all the indicated policies.  But it
> doesn't really make sense to say the recipient has to be named by
> multiple names.
> 
> Below are proposed changes to core-20.
> 
>  - RL "Bob"
> 
> ---
> 
> In the text describing the Conditions element (section 1.7.1) add:
> 
>   <TargetRestriction> [Optional]
>     The <TargetRestriction> condition is used to limit the use of the
>     assertion to a particular relying party.
> 
> The "[Optional]" is intended to mean that there could be zero or one
> of these conditions present.  It doesn't make sense to have more than
> one TargetRestriction condition present, since Conditions are and-ed
> together.
> 
> And add the schema:
> 
>   <element ref="saml:TargetRestriction"/>
> 
> to the set of choices under ConditionsType.  This schema needs to be
> written differently to express zero-or-one instances of this
> condition, but I don't know how to do that right now.
> 
> Then, a new section:
> 
>   N.N.N.  Condition Type TargetRestrictionType
> 
>   The <TargetRestriction> element is used to limit the use of the
>   assertion to a particular relying party.  This is useful to prevent
>   malicious forwarding of assertions to unintended recipients.
> 
>   The target is identified by a URI.  The condition evaluates to true
>   if one or more URIs identify the recipient or a resource managed by
>   the recipient.
> 
>   The following schema defines this type:
> 
>   <element name="TargetRestriction"
> 	type="saml:TargetRestrictionType"/>
> 
>   <complexType name="TargetRestrictionType">
>     <complexContent>
>       <extension base="saml:ConditionAbstractType">
>         <sequence>
>           <element ref="saml:Target"
>               minOccurs="1" maxOccurs="unbounded"/>
>         </sequence>
>       </extension>
>     </complexContent>
>   </complexType>
> 
>   <element name="Target" type="anyURI"/>
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

Phillip Hallam-Baker (E-mail).vcf