SAML metadata lifecycle issues

["Eve L. Maler" <Eve.Maler@Sun.COM>]

At the last meeting I raised the issue of the "orderly expiration of 
certs in metadata" (as recorded in the minutes).  Here is my 
colleague Rajeev Angal's writeup of the issues he would like to explore.

	Eve
-- 
Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.
Aug 15, 2007.
Contacts for clarifications, etc:
  rajeev.angal@sun.com
  eve.maler@sun.com
  emily.xu@sun.com


Metadata Lifecycle: notes and proposals
-----------------------------------------

This document identifies certain real deployment related issues and
their solutions that potentially may benefit from standardization
and/or guidelines, ie in addition to the basic pieces already
supplied in the specs. "Publisher" and "Consumer" terms are used to
represent entities that publish and consume metadata respectively


These issues can be divided into two scenarios:

(i) Reactive
(ii) Proactive

(i) Reactive scenario :

    This scenario arises from situations when metadata is
    compromised for misc reasons :

      - signing/encryption certs are not valid any more
      - SSL certs used in trasport are not vaolid any more
      - protocol endpoints are compromised, etc.

      In general things that must result in the consumer abandoning
      the existing/cached metadata immediately.

      Standard CRL/OCSP facilities go a long way resolving these
      issues - so there is no specific proposal to the specs except
      maybe to add some guidance for completion.

      There are some possibilities along the lines of notifying
      consumers of changes to metadata info.

(ii) Proactive scenario :

     This scenario involves planned transition from one version of
     the metadata to the next.

     Signing certs last 1-2 years - metadata needs to be revved up
     to accomodate new certs.

     Existing metadata spec already provides "validUntil" and
     "cacheDuration" related attributes at a fairly fine grained
     level. This is sufficient to provide adequate warning to
     Consumers to plan a transition. From schema perspective - it
     also provides a mechanism to add multiple signing and
     encryption keys for the same entity. Overlap issue : The issue
     is that all Consumers will not transition to the new metadata
     instantly at the "expiry" time. There is therefore potential
     for disrupted service until all Consumers catchup.

     Two solutions are proposed :

     (a) A solution is for the Publisher to include both the old and
     the new certificate in the new revision of its metadata and use
     the old cert for a reasonable amount of time to allow all
     Consumers to catchup with the new metadata. First, the metadata
     spec could provide mandatory text on handling of multiple
     signing/encryption keys to mean an "the publisher may use
     either keys + expired keys must be ignored". Second, the spec
     could provide guidance on possible use for adressing the
     "overlap issue" as described above.

     One side effect of the this solution is that the Consumer needs
     to check for both certs in situations where the data (eg a saml
     assertion) being verified does not include the
     signing/encrypting pub key leading to major performance issues
     - eg, worse case doubling the effect of an attack. If multiple
     certs are used only in the context of the "overlap issue",
     guidance can be provided that recommends deployments to
     minimize this window. But if used for a different purpose small
     spec changes to SAML protocol that indicate a "hint" to the
     Consumer on which cert to use woule be useful.

     (b) Another solution suggested is to not include pub keys (or
     references to specific certs in <KeyDescriptor>) in the
     metadata at all - instead to completely rely on the cert chain.
     Since its possible the same CA may issue multiple certs - hence
     to avoid an unauthorized signature/encryption, one could
     specify special attributes in the cert that identity acceptable
     signing/encrypting cert(s). This way the Producer can switch
     certs at its convenience without putting a burden on the
     Consumers to sync up.

PS: Please note that all the discussion above specifically
concentrates on metadata changes resulting from signing/encryting
cert changes, which is the focus of our current customers. Metadata
ofcourse changes overtime for other reasons, such as endpoints,
profiles, etc. To cover the general case an earlier rev of this
document proposed a versioning scheme for metadata - this way two
versions of the same metadata (old and new) can coexist (overlap)
for some duration to allow for all producers to catchup with the
latest metadata beyond which the older version is invalidated. This
scheme could get complicated  - however I am mentioning it here for
a possible wider discussion in case others in the spec team have
come across it in their deployments.