interpretation of cacheDuration
Adam Lantos
it seems that SimpleSAMLphp refuses the use of those SAML entities,
for which the cacheDuration has elapsed, even though the validUntil
attribute is present and the entity should otherwise be considered
valid.
According to [1, line 319-321], cacheDuration is a "optional attribute
indicates the maximum length of time a consumer should cache the
metadata contained in the element and any contained elements."
As far as I understand from this normative description, cacheDuration
is meant to serve as a basis for cache policies, and not entity
validity. For example our federation uses cacheDuration with a
duration of 90 minutes. If we're running metarefresh hourly, but it
fails to retrieve metadata for whatever reasons, in 30 minutes all our
entities are invalidated without further retrieval tries.
I think this interpretation of cacheDuration is too restrictive. On
the other hand, if the validUntil is missing, this behavior is fine,
because then there is no other way to restrict the use of stale
metadata instances.
In my opinion Shib people are approaching this problem in a better
way, see the sections 'Sign and Expire', 'Download and Cache' in [2].
[1] http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
[2] https://spaces.internet2.edu/display/SHIB2/TrustManagement
thanks,
Adam
Kristof Bajnok
> I think this interpretation of cacheDuration is too restrictive. On
> the other hand, if the validUntil is missing, this behavior is fine,
> because then there is no other way to restrict the use of stale
> metadata instances.
IMHO invalidating any entities based on cacheDuration is bogus.
cacheDuration controls only caching, so it's just for the metarefresh cron
job (if it's the way simplesaml does metadata fetching), while the IdP+SP
part should only look at validUntil.
Kristof
Olav Morken
> Hi,
>
>
> it seems that SimpleSAMLphp refuses the use of those SAML entities,
> for which the cacheDuration has elapsed, even though the validUntil
> attribute is present and the entity should otherwise be considered
> valid.
>
> According to [1, line 319-321], cacheDuration is a "optional attribute
> indicates the maximum length of time a consumer should cache the
> metadata contained in the element and any contained elements."
>
> As far as I understand from this normative description, cacheDuration
> is meant to serve as a basis for cache policies, and not entity
> validity. For example our federation uses cacheDuration with a
> duration of 90 minutes. If we're running metarefresh hourly, but it
> fails to retrieve metadata for whatever reasons, in 30 minutes all our
> entities are invalidated without further retrieval tries.
>
> I think this interpretation of cacheDuration is too restrictive. On
> the other hand, if the validUntil is missing, this behavior is fine,
> because then there is no other way to restrict the use of stale
> metadata instances.
>
> In my opinion Shib people are approaching this problem in a better
> way, see the sections 'Sign and Expire', 'Download and Cache' in [2].
I agree with you somewhat, and a new metadata aggregator that I am
working on only uses the cacheDuration attribute as a hint for when
that metadata file should be updated. But I also think that the current
behaviour is reasonable when downloading and consuming metadata from
third-parties.
The reason is that if you are not allowed to cache the metadata for
more than 90 minutes, it implicitly follows that you are expected to
discard that metadata after 90 minutes, and instead download new
metadata. If you are unable to download the new metadata, you are then
left with no metadata.
[1, lines 1401-1402] states:
When a document or element has expired, the consumer MUST retrieve
a fresh copy, which may require a refresh of the document
location(s).
[2] also states:
A cacheDuration attribute can be placed into the metadata to limit
the time for which the information should be kept without contacting
a trusted source to update it.
The two sections that you refer to in [2] describe two different
methods for downloading metadata. In one, you periodically download new
metadata, and in the other you download it on demand.
[2] does not say how the cacheDuration should be interpreted in the
"Sign and Expire" model that it looks like you are using. I would say
that if you are using the "Sign and Expire" model, you should not
include a cacheDuration attribute at all.
> [1] http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
> [2] https://spaces.internet2.edu/display/SHIB2/TrustManagement
--
Olav Morken
UNINETT / Feide
Adam Lantos
That's correct, it does not. However, if you use the "sign and expire"
model with several days (weeks) of validity and you don't include
cacheDuration, your entities may choose not to refresh metadata until
the validity expires, and you left with no control over their caching
policy.
This is not an intended behavior, because short update intervals are
needed to achieve reasonably fast entity revocation. So I think the
cacheDuration makes sense in the "sign and expire" model, because it
serves as a hint for end entities to frequently update metadata.
I agree that if you are using cacheDuration, then the entity must
contact the trusted source upon expiration of the cache. However, if
the network or the trusted source is down, and the metadata can not be
updated, the world should not stop, because the cached copy itself may
be valid (because of the validUntil). It is an error condition indeed,
and steps must taken in order to obtain a new, trusted metadata, but
until then, the software should be resilient to those transient
errors.
Long story short, if you omit cacheDuration, you can not revoke your
entities as fast as you should, nor can you ensure the propagation of
other changes. If the entities expire and throw away their cached
metadata upon cacheDuration expiry, your federation is vulnerable to
DoS attacks.
Olav Morken
> That's correct, it does not. However, if you use the "sign and expire"
> model with several days (weeks) of validity and you don't include
> cacheDuration, your entities may choose not to refresh metadata until
> the validity expires, and you left with no control over their caching
> policy.
>
> This is not an intended behavior, because short update intervals are
> needed to achieve reasonably fast entity revocation. So I think the
> cacheDuration makes sense in the "sign and expire" model, because it
> serves as a hint for end entities to frequently update metadata.
Is this specified anywhere?
> I agree that if you are using cacheDuration, then the entity must
> contact the trusted source upon expiration of the cache. However, if
> the network or the trusted source is down, and the metadata can not be
> updated, the world should not stop, because the cached copy itself may
> be valid (because of the validUntil). It is an error condition indeed,
> and steps must taken in order to obtain a new, trusted metadata, but
> until then, the software should be resilient to those transient
> errors.
>
>
> Long story short, if you omit cacheDuration, you can not revoke your
> entities as fast as you should, nor can you ensure the propagation of
> other changes. If the entities expire and throw away their cached
> metadata upon cacheDuration expiry, your federation is vulnerable to
> DoS attacks.
You can - you just need to have a policy in your federation that states
how often entities must attempt to refresh the metadata. That interval
does not need to be set by the metadata.
Adam Lantos
>> needed to achieve reasonably fast entity revocation. So I think the
>> cacheDuration makes sense in the "sign and expire" model, because it
>> serves as a hint for end entities to frequently update metadata.
>
> Is this specified anywhere?
I guess it's not, it's just an instinct, and some behavioral testing
with newer shib components. I'll ask Scott Cantor about this, maybe he
can clear things up (or just tell me I'm misunderstanding/misusing the
concepts here, which could easily be the case :) ).
> You can - you just need to have a policy in your federation that states
> how often entities must attempt to refresh the metadata. That interval
> does not need to be set by the metadata.
I don't really like relying on formal policies if I feel it would be
possible to enforce them on the technical level.
cheers,
Adam