[security-services] Proposed text for schema change:"TargetRestriction" condition

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

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"/>