Changes to the Key Management Practice Statement must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. This version reached rough consensus on ….

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 BCP 14¹.

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².

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.

The most recent version of 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 types of 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 has entered into an Enterprise Certificate Agreement with Comodo and uses them 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. Certificate revocation checks SHOULD be performed by the client 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://safire.ac.za/technical/metadata/.

Consumers of Federation metadata SHOULD verify the signature against the certificate fingerprint each time they 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 development environments;
• Offline generation of production private keys using known-good software;
• Private key bit lengths chosen taking into consideration the expiry of the corresponding certificate, the risk profile, and industry best practices³;
• Routine security updates of all critical software;
• Backups of certificates and private key material to secure 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 development and production servers.

Federation web servers SHOULD be configured to support OSCP stapling and HTTP Strict Transport Security. The safire.ac.za domain SHALL be registered in Google’s HSTS preload list.

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

In future, the above measures MAY be supplemented by HTTP Public Key Pinning . Likewise, DNS-Based Authentication of Named Entities MAY be used. However, this requires that DNS delegations are capable of supporting DNSSEC.

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.

Given that this key can be rolled over during the next publication of a metadata aggregate, and that all metadata consumers SHOULD automatically refresh this within a few hours, this arrangement is considered acceptable.

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 SHOULD be stored in a hardware security module. In development environments, a software emulation of an HSM is used; in production, a PKCS#15-based smartcard HSM is used. Private keys SHOULD be generated offline and within a master token, and backed up onto a number of separate tokens.

Those tokens not used in production MUST be securely stored for disaster recovery purposes. Any device key encryption key (DKEK) used for the smartcard backup process MUST be stored separately to hardware tokens. Offline materials MUST be stored in a fire proof safe. Appropriate commercial tamper evident bags/envelopes SHOULD be used to store offline materials, and the serial numbers of those bags/envelopes MUST be recorded.

Tokens used in production SHOULD be housed within the chassis of the server to which they are connected. Chassis openings SHOULD be secured with appropriate commercial tamper evident seals, and the serial numbers of those seals MUST be recorded. Where possible, chassis intrusion detection MAY also be enabled.

In order to preserve the chain of custody, tokens in transit MUST be stored in appropriate commercial tamper evident bags/envelopes. The serial numbers of such envelopes MUST be bags/recorded before dispatch and MUST be verified by the Federation Operator on receipt.

Interaction between the HSM and the metadata aggregation software SHOULD be via the PKCS #11 cryptographic token interface.

Certificate revocation and private key roll-over

General principles

In the event of a private key compromise, the Federation Operator SHALL publish a security advisory on the Federation web site. It SHOULD also attempt to contact directly affected parties via email and draw their attention to this advisory.

Web site (HTTPS)

The web site certificate is re-issued regularly, 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