[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SAML metadata lifecycle issues
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: firstname.lastname@example.org email@example.com firstname.lastname@example.org 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.