Sweden Connect - Security Requirements - draft 00

Table of Contents

1. Introduction

Sweden Connect operates an identity federation comprising both a SAML 2.0 federation and an OpenID Connect federation. Participants of either federation include Identity Providers, OpenID Providers, Service Providers, Relying Parties, and other supporting entities, all of which rely on cryptographic mechanisms to authenticate peers, protect messages in transit, and assert claims about subjects.¶

To ensure a consistent and adequate level of security and interoperability across the federation, a common set of requirements is needed for how transport security is applied, which cryptographic algorithms and key lengths are acceptable, and how keys are rolled over without disrupting other parties.¶

This specification collects these requirements in one place. It is intended to be read together with the "Sweden Connect SAML Deployment Profile" [SAML.SC.Profile] or the "OpenID Connect Profile for Sweden Connect" [OIDC.SC.Profile], extending and, where applicable, tightening the requirements stated in those documents.¶

2. General Security Requirements

All transactions MUST be protected in transit by TLS as described in [NIST.800-52].¶

For the Sweden Connect SAML federation, all parties MUST conform to the applicable recommendations in [SAML.Security].¶

For the Sweden Connect OpenID Connect federation, all parties MUST conform to the applicable recommendations in section 16, "Security Considerations", of [RFC6749], and to those found in "OAuth 2.0 Threat Model and Security Considerations" [RFC6819].¶

3. Cryptographic Requirements

All entities compliant with this profile MUST follow the guidelines in [NIST.800-131A] regarding the use of algorithms and key lengths. Specifically, the following requirements apply to signature and encryption keys:¶

• RSA public keys MUST be at least 2048 bits in length. 3072 bits or more is RECOMMENDED.¶

• EC public keys MUST be at least 256 bits in length (signature only).¶

  • The curves NIST Curve P-256, NIST Curve P-384, and NIST Curve P-521 MUST be supported (see [RFC5480]).¶

4. Key Rollover

A participant in the Sweden Connect federation wishing to update any of its keys MUST do so without disrupting other parties in the federation. This is especially important for SAML Identity Providers and OpenID Connect Providers.¶

The following requirements regarding key rollover apply:¶

• An entity wishing to start using a new signature key MUST publish this key (or certificate) in its metadata before putting it into use. The time between publication and initial use MUST be at least as long as the validity period of the published metadata.¶

  • For SAML, this time is the validity period of the federation metadata publication (one week).¶
  • For OpenID Connect, this time is given by the exp claim of the entity's Entity Statement; see Section 3.1.1 of [OpenID.Federation].¶

• Once a new signature key has been put into use, the previous key SHOULD be removed from the entity's metadata.¶

• An entity that begins using a new encryption/decryption key MUST remove the previous key from its metadata immediately, but MUST retain the ability to use it for decryption for a limited time afterwards. This time MUST be at least as long as other parties may hold a valid cached version of the entity's metadata. The same validity periods as for signing keys above apply.¶

• For SAML entities, Section 2.1.1.2 of [SAML.SC.Profile] MUST be adhered to.¶

• OpenID Connect entities consuming peer metadata MUST be able to handle multiple keys with the same usage.¶

  • Sections 5.2 and 6 of [OIDC.Sweden.Profile] state that an entity should include a kid parameter for all keys in its JWK Set. This specification changes this requirement to REQUIRED.¶

Appendix A. Notices

Copyright (c) The Swedish Agency for Digital Government (Digg), 2015-2026. All Rights Reserved.¶

Appendix B. Document History

[[ To be removed from the final specification ]]¶

-00¶

• Initial version¶

Author's Address