This page documents the history of SAFIRE's Key Management Practice Statement and will display the most recent version. You should always reference this page when linking to the Key Management Practice Statement, unless you intend to link to a specific, versioned document.
- Key Management Practice Statement v20170117 (Draft) (2016-11-01)
- Key Management Practice Statement v20160817 (Draft) (2016-08-17)
Current Version: v20170117 (Draft)
This is a working draft, and may change…
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 the Tertiary Education and Research Network of South Africa, NPC.
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.
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.
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
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 [BlueKrypt];
- 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.
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.
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.
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. Tokens used in production SHOULD be housed within the chassis of the server to which they are connected, and chassis intrusion detection SHOULD be enabled.
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
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.
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.
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.
[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.
[BlueKrypt] Giry, D., “Cryptographic Key Length Recommendations”. BlueKrypt, September 2015.