Key Management Practice Statement v20160817 (Draft)

Definitions and terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC2119].

Federation, Identity Federation: An association of organisations that come together to securely exchange information as appropriate about their users and resources to enable collaborations and transactions.

Federation Operator: Organisation providing the infrastructure for Authentication and Authorisation to Federation Participants.

Key, Private Key, Certificate, Certificate Authority: components of the X.509 public-key infrastructure [RFC5280].

South African Identity Federation, SAFIRE: A federation established to serve the South African research and education community, and operated by TENET NPC.

Introduction

Recognising that the trust relationships established by Identity Federations are underpinned by the cryptographic private keys the Federation uses to sign data, this document sets out to describe the key management practices of the South African Identity Federation (SAFIRE) with effect from the publication date shown on the cover sheet until such time as it superseded.

The document is aimed at providing transparency about current key management practices within the Federation, and is not intended to reflect what is or may be technically possible. As such, these practices MAY evolve as the Federation matures.

This document SHALL be published on the Federation website at https://safire.ac.za/safire/policy/kmps/.

Types of certificates and private keys

The Federation makes use of three distinct certificates and corresponding private keys, each with clearly defined purposes and different risk profiles. These are documented below.

Web site (HTTPS)

The web site (HTTPS) certificate is used to securing communication between end users’ browsers and the Federation hub and web sites. Because it is publicly visible, this certificate uses commercial public-key infrastructure. The certificate used for all SAFIRE web sites, including the Federation hub, is signed by a commercial certificate authority in accordance with their certificate practice statement.

The Federation Operator uses Comodo as a certificate authority for this purpose.

The certificate and public key are supplied to the client during TLS negotiation and SHOULD be verified using the CA root certificates typically embedded within a browser.

SAML signing

The SAML signing key is used to sign some of the SAML assertions made by the Federation hub infrastructure during authentication. This certificate is only intended used to establish trust between the hub and SAML endpoints; it MUST NOT be presented to an end user’s web browser. For this reason it is a self-signed certificate with a long expiration date.

The certificate and public key are supplied within the Federation’s metadata, which SHALL be the definitive source of such information. Signatures on SAML assertions SHOULD be verified against the certificate in the corresponding entity’s metadata.

Metadata signing

The metadata signing key is used to sign the Federation’s aggregate metadata before distribution. This certificate is used by Federation Participants to verify the authenticity of metadata they have fetched from the Federation. This certificate is only used to authenticate metadata; it MUST NOT be presented to an end user’s web browser. For this reason it is a self-signed certificate with a long expiration date.

The certificate and public key are distributed out-of-band, and are available at https://metadata.safire.ac.za/safire.crt.

Consumers of Federation metadata SHOULD verify the signature against the certificate fingerprint each time the fetch metadata from the Federation Operator.

Key management practices

General principles

The Federation Operator SHALL endeavour to protect private key materials so as to minimise the risk of loss or compromise. Mechanisms for doing so SHOULD include:

  • Separation of the SAML signing and metadata signing keys onto different servers;

  • Process separation, so that public-facing web servers have minimal access to private key material;

  • Limited access by Federation Operators staff and service providers on a need-to-have basis;

  • Different certificates and private keys for production and test environments

  • Routine security updates of all critical software;

  • Routine backups of certificates and private key material to off-site storage.

However, as a small pilot federation, there are no comprehensive privilege separation mechanisms and a single employee or service provider MAY have access to all three private keys. In addition, operational constraints MAY dictate lower technical standards than are desired.

Web site (HTTPS)

The web site private key is stored as a flat file on disk. Whilst password protected, the password is hardcoded within the web server configuration. Whilst the certificate MAY be shared across different servers, the same password SHOULD NOT be used for private keys across test and production servers.

Given the ease of replacement, the relatively low risk should compromise occur, and the technical difficulty of implementing higher levels of security within a web server, this arrangement is considered acceptable.

SAML signing

The SAML signing key is stored as a flat file on disk. Whilst password protected, the password is hardcoded within the SAML hub software’s configuration.

In future, the SAML signing key MAY be entrusted to a hardware security module (HSM). Provision for the PKCS #11 cryptographic token interface has been made in the SAFIRE roadmap. However a software emulation of an HSM MAY be used instead of an HSM.

Metadata signing

The Federation metadata forms the basis of the trust relationships established within the federation. However, as the metadata certificate is distributed out-of-band, it is also recognised that this is the hardest form of key compromise to recover from and recovery will involve significant effort on the part of the Federation Operator. Accordingly the metadata signing key is the most valuable private key and SHOULD be protected accordingly.

The metadata signing key is stored as a flat file on disk. Whilst password protected, the password is hardcoded within the software’s configuration.

In future, the metadata signing key SHOULD be entrusted to a hardware security module. Provision for the PKCS #11 cryptographic token interface has been made in the the SAFIRE roadmap. However a software emulation of an HSM MAY be initially be used instead of an HSM.

Certificate revocation and private key roll-over

Web site (HTTPS)

The web site certificate is re-issued annually, in accordance with the validity of the signature from the upstream certificate authority. The previous private key MAY be re-used, unless technical requirements dictate that it should be replaced.

In the event of a private key compromise, the certificate SHALL be revoked according to the certificate authority’s certificate practice statement. A new private key SHALL be generated, and a new certificate issued.

SAML signing

No procedures currently exist for rolling over the SAML signing key or re-issuing the corresponding certificate. However, it is recognised that this SHOULD be done periodically, and that because of the risk of poor implementations, the certificate SHOULD NOT be allowed to expire. Rollover can be achieved by timeously publishing new certificates within the Federation metadata.

Participants SHOULD periodically attempt fetch updated metadata from the Federation. It is RECOMMENDED that this process be automated.

In the event of a private key compromise, the certificate SHALL be removed from metadata as soon as practical. A new private key SHALL be generated, and a new certificate published in metadata. Federation participants SHALL be notified and MAY be requested to update their metadata.

Metadata signing

No procedures currently exist for rolling over the metadata signing key or re-issuing the corresponding certificate. Rollover of this key would be an entirely manual process, requiring that the contact the Registered Representatives of each participant. However the certificate SHOULD NOT be allowed to expire.

In the event of a private key compromise, a new private key SHALL be generated, and Federation metadata SHALL be re-signed with the new key. The Federation Operator WILL contact the Registered Representative of each participant and RECOMMEND that they update their configuration to correctly validate the new certificate.

References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC5280] Cooper, D. et al., “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”. RFC 5280, May 2008.

South African Identity Federation