Page History

...

SAML Certificates in

...

Federation

...

Metadata

This article discusses the use of InCommon accepts X.509 server certificates from the following certificate providers:

1. Self-Signed
2. InCommon Certificate Authority
3. InCommon discourages but will also accept certificates from a third-party Certificate Authority (CA). Be forewarned that there are potential pitfalls with this approach (see the Backgrounder section below for more detail).

Requirements

InCommon sets the following security and trust parameters around certificates that are included in federation metadata:

1. Keys with a minimum size of RSA-2048 must be used for all new submissions. We still allow current InCommon certs that are 1024. However, all participants must migrate old 1024-bit certificates out of the metadata and upgrade to 2048 by December 2012. We recommend that participants submit a new certificate with a mininum size of RSA-2048 created with a new key every 3 years.

   Panel
   No certificates less than RSA-2048 bit size will be allowed in federation metadata after December 2012.

2. Expired certificates will not be accepted. However, current certificates that do expire may be retained in the metadata at the discretion of the participant. Shibboleth does not check expiration dates of certificates, but this practice may cause interoperability issues with other software. We recommend that participants submit a 2048 certificate with a new key every 3 years.
3. Because the fields in the certificate are not relevant to any runtime processing or security in the federated context, InCommon will not verify or impose any requirements on certificate fields, with one caveat. At its own choosing, InCommon will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresentative Subject information as decided by InCommon on a case by case basis. Generally, your subject information should express somewhat reasonably to you and others a relationship between the certificate and your organization. This is up to you. Again, InCommon does not validate Subject information in self-signed certificates because this information is irrelevant to the federated security context. See also "Points to Consider" below.

Points to Consider for Interoperability

To increase the chances of your deployment interoperating with other products:

1. Make sure your self-signed certificate's CN value matches the intended hostname. This will maximize the chances that your implementation will work. This SSL/TLS configuration is left to your discretion and responsibility. InCommon highlights this point as one that may likely cause problems if not met.
2. For key management, InCommon allows multiple certificates per end point at any time. You can log in to the site administration tool, select the particular endpoint, then choose the one or more certificates you want to associate with this endpoint. This is helpful for migrating from one certificate to another during a finite period of time.

InCommon Will No Longer Issue Certificates Beginning January 2010

As stated above, we are moving the federation toward self-signed certificates in the metadata. As your InCommon certificates expire, you may decide to:

1. Continue using the same certificate. Shibboleth does not rely on expiration dates of certificates. Some software may check expiration dates, therefore, we recommend the following.
2. Submit a self-signed 2048 bit certificate.
3. For key management and migration, InCommon allows multiple certificates per end point at any time. Select the new certificate from your list of submitted certs, while keeping the old certificate associated with the endpoint for as long as your transition process requires.

Backgrounder: Security and Certificate Authorities

certificates in Federation metadata. It has security implications so please read it carefully.

A SAML entity uses public key cryptography to secure the data transmitted to trusted partners. Public keys are published in the form of X.509 certificates in metadata whereas the corresponding private keys are held securely by the entity. These keys are used for message-level signing and encryption, and to create secure back channels for transporting SAML messages over TLS. They are not used for browser-facing TLS transactions on port 443. See the Key Usage topic for more information.

The InCommon Federation is based on the Explicit Key Trust Model, one of several possible metadata trust models. Consequently, the use of long-lived, self-signed certificates in metadata is strongly recommended. Certificates signed by a Certification Authority (CA) are allowed, and in most situations will work just fine, but the use of certificates other than self-signed certificates is discouraged. See the Background information and the Interoperability notes below for further discussion.

Any certificates you want to use with your SAML software are uploaded via the Federation Manager. Typically only one certificate is required per entity but multiple certificates may be uploaded and used as needed. In particular, multiple certificates may be used to facilitate the controlled rollover of expired certificates or compromised keys. To avoid interoperability problems, refer to the Certificate Migration topic for recommended guidelines regarding the rollover process.

It is easy to create a self-signed certificate with the OpenSSL command-line tool. Before you do this, however, take a moment to consider how best to handle the all-important private key.

Contents

Background

In the base SAML metadata specification [1], a certificate signing authority (CA) has no assumed In the SAML metadata specification (saml-metadata-2.0-os), a certificate signing authority has no necessary relevance to the trust model that secures the interactions among a federation's participants. In fact, certificates signed by a CA are discouraged since they can create interoperability issues in certain situations and lead to configurations that mistakenly establish trust based on the certificate signer. Allowing self-signed certificates simplifies the work of participants who may be required to join multiple federations, or who support local systems that are not registered in the Federation.

InCommon conforms to the SAML V2.0 Metadata Interoperability Profile [2] from OASIS. Participant site administrators securely transmit X.509 certificates and metadata to InCommon via the administrative web interface. InCommon signs the entire metadata file, securing the keys of its participants whether they are represented in the context of those keys are bound to self-signed certificates or certificates signed by an authoritya CA. The critical element in the certificate is the public key, which is associated with the participant's "entityID." The other elements in the certificate are irrelevant for security and trust processingan entity via its entity ID. Theoretically, if all the relevant software systems could accept a public key without a certificate wrapper, InCommon would only need to include the public key of each end pointentity. As it is, the certificate is a practical shell convenient container for the public key, the critical element being that the key is bound to a particular entity in the metadata.

Futhermore, allowing self-signed certificates simplifies the work of participants who may be required to join multiple federations, or who support local systems that are not enrolled in the federation.

Third-party certificates signed by an authoritative CA are discouraged since they can create interoperability issues in certain cases, and lead to configurations that mistakenly rely on the certificate signer to establish trust in the certificate. Where necessary they can be accommodated because of constraints imposed on participants from other sources.

Requirements

InCommon sets the following security and trust requirements around certificates included in Federation metadata:

• The use of long-lived, self-signed certificates in Federation metadata is strongly RECOMMENDED.
  • Certificates with lifetimes of at least 10 years are RECOMMENDED to avoid unnecessary technically-imposed deadlines on key rollover.
  • Certificates SHOULD expire before 2038 to avoid the so-called Year 2038 problem.
• RSA keys with a minimum size of 2048 bits MUST be used for all new certificates introduced into Federation metadata.
  • New certificates with key sizes less than 2048 bits are not allowed in Federation metadata.
  • Certificates with keys greater than 2048 bits are NOT RECOMMENDED since such keys force relying parties to perform unnecessary computation.
• Expired certificates SHOULD NOT be introduced into Federation metadata. An expired certificate in metadata SHOULD be removed once a certificate migration process to a new certificate has been completed.
  • A certificate's expiration date has nothing to do with the security of the corresponding private key, which is an ongoing concern.
• If a private key is lost or stolen, immediate steps MUST be taken to configure a new private key and to introduce the corresponding public key certificate into metadata. Since there are no other known attacks on RSA 2048-bit keys, generating a new private key for any other purpose is NOT RECOMMENDED.
• Service providers MUST include an encryption key in SP metadata.
  • The encryption key is used by IdPs to encrypt SAML V2.0 assertions transmitted to the SP.
• InCommon does not validate Subject information in self-signed certificates because this information is irrelevant from a security perspective. However, at its discretion, InCommon will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresented Subject information as decided by InCommon on a case-by-case basis. Generally, Subject information should express a somewhat reasonable relationship between the certificate and the organization.

Interoperability

Consider the following interoperability issues as you set up and maintain your deployment:

• A potential federation partner (especially a partner not using the Shibboleth software) may question the use of self-signed certificates. As discussed in the Background section, there are, in fact, fewer interoperability issues with self-signed certificates compared to CA-signed certificates.
• The Shibboleth software does not check the expiration dates of certificates [4], but expired certificates often cause interoperability issues with other software (such as AD FS 2.0 and the OIOSAML Java SP) and with older versions of Apache used to deploy the Shibboleth IdP. InCommon recommends that you plan ahead and migrate to an unexpired certificate well ahead of your certificate's expiration date.
• For key management purposes, InCommon allows multiple certificates per role descriptor at any time. (You can log into the administrative interface, select a particular role, and associate more than one certificate with that role for the purposes of migrating from one certificate to another.) Bear in mind, however, that some SAML implementations do not support multiple keys properly and you may want to test this capability with your non-Shibboleth partners. For example:
  • EZProxy is known to ignore additional keys beyond the first.
  • AD FS 2.0 will not consume an <md:EntityDescriptor> element containing more than one encryption key.
• At the deployer's convenience, a single certificate may be bound to multiple SPs in InCommon metadata. However, some implementations (e.g., AD FS 2.0) do not allow the same certificate to be used by two distinct entities.
• If the certificate will be used for TLS server authentication, the certificate's CN (and/or subjectAltName) value should match the server's hostname. This is especially true for IdPs but may also be true in certain advanced scenarios where the SP acts as a SOAP responder.
• Avoid certificates with special certificate extensions, since some implementations will actually try to use them. For example, AD FS 2.0 will attempt to access the CRL at the location given in the CRL Distribution Point certificate extension.

References

[1] This approach is supported by the SAML set of specifications. References are here for Metadata for the OASIS Security Assertion Markup Language (SAML)
V2 V2.03 <0http://saml.xml.org/saml-specifications> and SAML V2
[2] SAML V2.0 Metadata Interoperability Profile <http://wiki.oasis-open.org/security/SAML2MetadataIOP>.

Example: Generating a Self-Signed Certificate using OpenSSL

openssl req -new -x509 -days 1095 -keyout key.pem -out cert.pem -newkey rsa:2048 -subj "/CN=hostname.example.org

What's left on the ToDo List prior go Going live:

1. Disclaimer in the metadata itself
2. Disclaimer check box upon submission

Communication Plan

...

[3] X.509 Certificates in the Federation Metadata: A technical webinar presented by the InCommon Technical Advisory Committee (October 22, 2009)
[4] The Shibboleth ExplicitKey Trust Engine https://wiki.shibboleth.net/confluence/display/SHIB2/ExplicitKeyTrustEngine
]5] Shibboleth Security and Networking https://wiki.shibboleth.net/confluence/x/VoEOAQ