Guidance on securely configuring network protocols (ITSP.40.062)

Foreword

This document, ITSP.40.062 Guidance on Securely Configuring Network Protocols, is an UNCLASSIFIED publication issued by the Canadian Centre for Cyber Security (Cyber Centre) and provides an update to the previously published version.

We recommend that you also read ITSP.40.111 Cryptographic Algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B Information. The configurations in this document comply with the cryptographic requirements in ITSP.40.111 [1].

Effective date

This publication takes effect on October 13, 2020.

Revision history

Revision	Amendments	Date
1	First Release	August 2, 2016.
2	Second Release	August 21, 2020.

Overview

This document identifies and describes acceptable security protocols, and their appropriate methods of use, that organizations can implement to protect sensitive information. For GC departments and agencies, the guidance in this document applies to UNCLASSIFIED, PROTECTED A, and PROTECTED B information.

An organization’s ability to securely transmit sensitive data and information is fundamental to the delivery of its programs and services. Using cryptographic security protocols ensures the confidentiality, integrity, and availability of information and helps provide protection against certain cyber intrusion threats.

Data confidentiality, integrity, availability, stakeholder authentication and accountability, and non-repudiation are all benefits of properly configured security protocols. Various protocols may be required to satisfy your organization’s specific security requirements, and each protocol should be selected and implemented to ensure all requirements are met.

For more information on securely configuring network protocols, contact us:

Canadian Centre for Cyber Security Contact Centre
contact@cyber.gc.ca
613-949-7048 or 1-833-CYBER-88

Table of Contents

• 1 Introduction
  • 1.1 IT Security Risk Management Process
  • 1.2 Recommendations
• 2 Public Key Infrastructure
• 3 Transport Layer Security
  • 3.1 TLS Cipher Suites
  • 3.2 TLS Extensions
  • 3.3 Client and Server Authentication
  • 3.4 Other TLS Configuration Guidelines
• 4 Internet Protocol Security
  • 4.1 IKEv2
    • 4.1.1 Authentication
    • 4.1.2 Message Encryption
    • 4.1.3 Key Exchange
    • 4.1.4 Pseudo-Random Functions for Key Generation
    • 4.1.5 IKEv2 Integrity Protection
    • 4.1.6 Extensible Authentication Protocol
    • 4.1.7 DDoS Protection
    • 4.1.8 Key and Authentication Lifetimes
    • 4.1.9 Session Resumption
  • 4.2 IPsec
    • 4.2.1 Key Generation
    • 4.2.2 Data and Integrity Protection
    • 4.2.3 Replay Protection
• 5 Secure Shell
  • 5.1 SSH Authentication
  • 5.2 SSH Port Forwarding
  • 5.3 SSH Root Access
  • 5.4 SSH Parameter Selection
    • 5.4.1 Encryption Algorithm Selection
    • 5.4.2 MAC Algorithm Selection
    • 5.4.3 Key Exchange Algorithm
    • 5.4.4 Public Key Algorithm
• 6 Secure/Multi-Purpose Internet Mail Extensions
  • 6.1 Digest Algorithms
  • 6.2 Signature Algorithms
  • 6.3 Key Encryption Algorithms
    • 6.3.1 Key Wrap Algorithms
  • 6.4 Content Encryption Algorithms
• 7 Commercial Technologies Assurance Programs
• 8 Summary
  • 8.1 Cyber Centre Contact Information
• 9 Supporting Content
  • 9.1 List of Abbreviations
  • 9.2 Glossary
  • 9.3 References

List of Figures

• Figure 1: IT Security Risk Management Process

List of Tables

• Table 1: Three Recommendation Categories Used in this Document
• Table 2: Recommended Cipher Suites for TLS Version 1.3
• Table 3: Recommended Cipher Suites for TLS 1.2
• Table 4: Supported Groups that Conform to ITSP.40.111
• Table 5: Signature Algorithms that Comply with ITSP.40.111
• Table 6: Recommended IKEv2 Authentication Schemes
• Table 7: Recommended IKEv2 Message Encryption Algorithms
• Table 8: Recommended IKEv2 Key Exchange Groups
• Table 9: Sufficient PRF for IKEv2 Key Generation
• Table 10: Sufficient and Phase Out Integrity Protection Mechanisms
• Table 11: Recommended ESP Packet Encryption Algorithms
• Table 12: Sufficient and Phase Out Integrity Protection Mechanisms
• Table 13:Recommended SSH Encryption Algorithms
• Table 14: Sufficient and Phase Out SSH MAC Algorithms
• Table 15: Recommended SSH Key Exchange Algorithms
• Table 16: Recommended SSH Public Key Algorithms
• Table 17: Sufficient and Phase Out Digest Algorithms
• Table 18: Recommended Signature Algorithm and Digest Algorithm Pairs
• Table 19: Recommended Key Encryption Algorithms
• Table 20: Recommended Key Wrap Algorithms
• Table 21: Content Encryption Algorithms

1 Introduction

Organizations rely on information technology (IT) systems to achieve business objectives. These interconnected systems can be the targets of serious threats and cyber attacks that jeopardize the availability, the confidentiality, and the integrity of information assets. Compromised networks, systems, or information can have adverse effects on business activities and may result in data breaches and financial loss.

This document provides guidance on the following topics:

• Securely configuring network protocols to protect sensitive information^{Footnote 1};
• Approved algorithms that the Cyber Centre recommends for use with these network protocols;
• Standards and National Institute of Standards and Technology (NIST) special publications that provide additional information on these network protocols.

This document aids technology practitioners in choosing and using appropriate security protocols for protecting sensitive information (UNCLASSIFIED, PROTECTED A, and PROTECTED B information) and complements the Treasury Board of Canada Secretariat (TBS) Guideline on Defining Authentication Requirements [2]. This document also provides cryptographic guidance for IT solutions at the UNCLASSIFIED, PROTECTED A, and PROTECTED B levels. ^{Footnote 2} Organizations are responsible for determining their security objectives and requirements as part of their risk management framework.

1.1 IT Security risk management process

When implementing security protocols, practitioners should consider the IT security risk management activities described in ITSG-33 IT Security Risk Management: A Lifecycle Approach [3]. ITSG-33 addresses two levels of IT security risk management activities (departmental-level activities and information system-level activities) and includes a catalogue of security controls (i.e. standardized security requirements to protect the confidentiality, integrity, and availability of IT assets). See Figure 1 for an overview of the IT security risk management activity levels.

Additionally, organizations should consider the following activity areas: Define, Deploy, Monitor and Assess. See Annex 1 of ITSG 33 [3] for more information on these activities.

Departmental level activities (or organizational level activities for non GC organizations) are included in departmental or organizational security programs to plan, manage, assess, and improve the management of IT security risks.

Information system level activities are included in an information system’s lifecycle through the information system security implementation process (ISSIP). When implementing network security protocols, you should consider all the steps in the ISSIP. See Annex 2 of ITSG 33 [3] for more information.

Figure 1: IT Security Risk Management Process

Long description

IT Security Risk Management Process

1.2 Recommendations

Throughout this document, we make recommendations that fall within three categories: Recommended, Sufficient, and Phase Out. These three categories are explained further in Table 1.

Table 1: Three Recommendation Categories Used in this Document

Recommended	Sufficient	Phase Out
Configurations listed in the Recommended column have advantages over those in the Sufficient column. Recommended configurations should always be implemented if allowed by the remote connection profile.	Configurations listed in the Sufficient column are appropriate to be used as deemed necessary to support the profile of remote connections. Sufficient configurations should be applied when it is not possible to implement a Recommended profile.	Configurations listed in the Phase Out column are marked for transition according to guidance in ITSP.40.111 [1] or due to protocol specific concerns. If you have systems that use Phase Out selections, we recommend that you transition to Recommended or Sufficient alternatives as soon as possible.

Note: Systems do not need to be configured with all the selections listed in the Recommended or Sufficient columns. The chosen configurations will depend on an organization’s remote connection profile. The protocol selections should be implemented to limit the network attack surface.

2 Public key infrastructure

Public Key Infrastructures (PKIs) support the management of public keys for security services in PKI enabled protocols, including Transport Layer Security (TLS), Internet Protocol Security (IPsec), and Secure/Multipurpose Internet Mail Extensions (S/MIME).

PKI key management guidance is provided in NIST Special Publication (SP) 800-57 Part 3 Rev 1 Recommendation for Key Management Part 3: Application-Specific Key Management Guidance [4]. We recommend that you refer to section 2 of NIST SP 800-57 Part 3 Rev 1 [4] for the guidance on installing and administering PKI.

Your implementations must not reuse public key pairs across multiple protocols within the PKI. For example, key pairs used in IKEv2 must not be reused for SSH.

You should format public key certificates in the X.509 version 3 certificate format, as specified in Request for Comments (RFC) 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [5].

To support algorithm and key size agility, protocol implementations should support multiple certificates with their associated private keys. Public key certificates used for signing, key agreement, or key encipherment should be distinguished by the key usage extension, asserting one of the following bit-valued flags:

• digitalSignature;
• keyEncipherment; and
• keyAgreement.

To satisfy the cryptographic guidance provided in ITSP.40.111 [1], SHA-1 should not be used to generate or verify public key certificate digital signatures.

3 Transport layer security

TLS is a protocol developed to protect the confidentiality, integrity, and availability of Internet communications between server and client applications.

As specified in RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 [6], we recommend configuring TLS servers and clients to use TLS 1.3. Using TLS version 1.2, updated in RFC 8446 [6], is sufficient if it is required for wider compatibility, internal audit compliance, or threat monitoring systems. You should phase out versions of TLS older than 1.2 or any versions of Secure Sockets Layer (SSL).

Servers that use TLS to protect HTTP traffic (i.e. HTTPS) should support HTTP Strict Transport Security (HSTS), as specified in RFC 6797 HTTP Strict Transport Security (HSTS) [7].

An email server acting as a Message Transfer Agent (MTA) for Simple Mail Transfer Protocol (SMTP) should support the negotiation of TLS with other MTAs. SMTP traffic can be upgraded to TLS using STARTTLS, as specified in RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security [8]. To ensure the use of TLS for SMTP traffic, MTAs should support RFC 8461 SMTP MTA Strict Transport Security (MTA-STS) and configured to use the "enforce" policy mode [35] or RFC 7672 SMTP Security via Opportunistic DNS Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) [9].

Note: These opportunistic encryption techniques are only supported on a hop by hop basis. End to end message protection is provided by S/MIME (see section 6 of this document).

When TLS is used to protect the confidentiality of PROTECTED A or PROTECTED B information or the integrity of UNCLASSIFIED, PROTECTED A, or PROTECTED B information, you should use X.509 version 3 certificates to mutually authenticate between the server and the client.

3.1 TLS Cipher suites

If the server or the client is configured to support TLS version 1.3, then the server or the client should be configured to support only the cipher suites listed in Table 2.

Table 2: Recommended Cipher Suites for TLS Version 1.3

Recommended	Sufficient
TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256	TLS_AES_128_CCM_8_SHA256

If TLS 1.2 support is required, a TLS server or client should be configured to support only the TLS 1.2 cipher suites listed in Table 3.

Table 3: Recommended Cipher Suites for TLS 1.2

Recommended	Sufficient	Phase out
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CCM TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CCM TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_CCM TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_CCM TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256	TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS servers and clients may use any or all the listed cipher suites according to the deployment profile. However, if an Internet facing deployment requires cipher suites listed in the Phase Out column, we recommend you transition away from these as soon as possible. Your internal enterprise or data centre deployments of TLS may continue to use cipher suites with RSA key transport if required for audit compliance or threat monitoring systems.

Cipher suites do not specify a key size for the public key algorithm. TLS servers and clients should ensure that the server and client ephemeral key pairs that are used to establish the master secret satisfy the key length requirements specified in ITSP.40.111 [1]. Table 4 lists the Supported Groups that conform to ITSP.40.111 [1].

Table 4: Supported Groups that Conform to ITSP.40.111

Recommended	Sufficient	Phase Out
secp256r1 secp384r1 secp521r1	ffdhe3072 ffdhe4096 ffdhe6144 ffdhe8192 sect283k1 sect283r1 sect409k1 sect409r1 sect571k1 sect571r1	secp224r1 sect233r1 sect233k1 ffdhe2048

Table 5 lists the Signature Algorithms that comply with ITSP.40.111 [1].

Table 5: Signature Algorithms that Comply with ITSP.40.111

Recommended	Sufficient	Phase Out
ecdsa_secp256r1_sha256 ecdsa_secp384r1_sha384 ecdsa_secp521r1_sha512 rsa_pss_pss_sha256 rsa_pss_pss_sha384 rsa_pss_pss_sha512 rsa_pss_rsae_sha256 rsa_pss_rsae_sha384 rsa_pss_rsae_sha512	rsa_pkcs1_sha256 rsa_pkcs1_sha384 rsa_pkcs1_sha512	ecdsa_secp224r1_sha224 rsa_pkcs1_sha224 dsa_sha224 dsa_sha256 dsa_sha384 dsa_sha512

3.2 TLS Extensions

We recommend that TLS servers and clients support the following extensions:

• Certificate Signature Algorithms;
• Certificate Status Request;
• Cookie (TLS 1.3 only);
• Encrypt then MAC (TLS 1.2 only);
• Extended Master Secret (TLS 1.2 only);
• Key Share (TLS 1.3 only);
• Multiple Certificate Status (TLS 1.2 only);
• Pre-Shared Key (TLS 1.3 only);
• Pre-Shared Key Exchange Modes (TLS 1.3 only);
• Renegotiation Indication (TLS 1.2 only);
• Server Name Indication;
• Signature Algorithms;
• Signed Certificate Timestamps List;
• Supported Groups;
• Supported EC Point Formats (TLS 1.2 only);
• Supported Versions (TLS 1.3 only); and
• Trusted CA Indication (TLS 1.2 only).

Note: Do not enable extensions in your configurations that are not listed above.

3.3 Client and server authentication

The client must validate the server certificate according to RFCs 5280 [5] and 8446 [6]. The revocation status of the certificate must be checked using a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP). The client must check that the certificate contains a value in the Subject Alternative Name extension or in the Subject Distinguished Name field that matches the DNS or IP address requested.

If the client included the certificate signature algorithms extension, the client should verify that the certificate signature algorithm matches one of the proposed values. Otherwise, the client should verify that the certificate signature algorithm matches one of the proposed values in the signature algorithms extension.

Finally, the client should verify the public key length in the certificate satisfies the key length requirements specified in ITSP.40.111 [1].

If client authentication (also referred to as mutual authentication) is configured, the server must validate the client certificate according to RFCs 5280 [5] and 8446 [6]. The server must verify that the certificate validation path chains to a certificate authority (CA) that is trusted by the server to validate access to the requested resource. The revocation status of the certificate must be checked using a CRL or the OCSP. The server should check that the certificate contains a value in the Subject Alternative Name extension or in the Subject Distinguished Name field that matches an authorized client.

Finally, the server should verify that the public key length in the certificate satisfies the key length requirements specified in ITSP.40.111 [1].

3.4 Other TLS configuration guidelines

TLS clients and servers must be configured to disable TLS compression, which is done by negotiating the null compression method.

Due to the complication of mitigating replay attacks, we recommend that configurations do not support the 0-RTT mode of TLS version 1.3.

TLS 1.2 renegotiation without the Renegotiation Indication extension (see RFC 5746 Transport Layer Security [TLS] Renegotiation Indication Extension [10]) must be disabled. Furthermore, we recommend that TLS servers are configured to not accept client initiated renegotiation at all in favour of establishing a new TLS connection.

If support for session resumption is desired, we recommend that you use the session identifier method in TLS 1.2 or session resumption via pre shared keys (PSKs) in TLS 1.3. You should use PSKs with a (EC)DHE key exchange to provide forward secrecy.

4 Internet protocol security

You can use a combination of the protocol pair Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec to create secure data tunneling at the network layer. The IKEv2 protocol establishes secure key material that can be used in the IPsec protocol to secure the data that is exchanged between peers.

4.1 IKEv2

IKEv2 is specified in RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2) [11].

Note: IKEv1 should no longer be used.

4.1.1 Authentication

When IKEv2 is used to set up an IPSec security association (SA) to protect the confidentiality of PROTECTED A or PROTECTED B information or the integrity of UNCLASSIFIED, PROTECTED A, or PROTECTED B information, digital signatures should be used for authentication. Pre-shared keys should not be used for authentication.

Table 6 lists the authentication schemes that comply with ITSP.40.111 [1].

Table 6: Recommended IKEv2 Authentication Schemes

Recommended	Sufficient	Phase Out
ECDSA with SHA-256 on the P 256 curve ECDSA with SHA-384 on the P 384 curve ECDSA with SHA-512 on the P 521 curve RSASSA-PSS with bit length 3072 and SHA-384 RSASSA-PSS with bit length 4096 and SHA-384	RSASSA-PKCS1-v1.5 with bit length 3072 and SHA-384 RSASSA-PKCS1-v1.5 with bit length 4096 and SHA-384	RSASSA-PSS with bit length 2048 and SHA-256 RSASSA-PKCS1-v1.5 with bit length 2048 and SHA-256

4.1.2 Message encryption

Table 7 lists the IKEv2 message encryption algorithms that comply with ITSP.40.111 [1].

Table 7: Recommended IKEv2 Message Encryption Algorithms

Recommended	Sufficient	Phase Out
ENCR_AES_GCM_16 ENCR_AES_CCM_16	ENCR_AES_GCM_12 ENCR_AES_CCM_12 ENCR_AES_CBC ENCR_AES_CTR	ENCR_3DES ENCR_CAST

We recommend using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) to encrypt IKEv2 messages. If GCM or CCM is not supported, use an integrity protection mechanism from subsection 4.1.6.

4.1.3 Key exchange

Table 8 lists the IKEv2 key exchange groups that comply with ITSP.40.111 [1].

Table 8: Recommended IKEv2 Key Exchange Groups

Recommended	Sufficient	Phase Out
256-bit Random ECP Group 384-bit Random ECP Group 521-bit Random ECP Group	3072-bit MODP Group 4096-bit MODP Group 6144-bit MODP Group 8192-bit MODP Group	2048-bit MODP Group 2048-bit MODP Group with 224-bit Prime Order Subgroup 2048-bit MODP Group with 256-bit Prime Order Subgroup 224-bit Random ECP Group

Implementations must check that received public values are between 1 and p 1 and, in the case of Elliptic Curve Diffie Hellman (ECDH), satisfy the elliptic curve equation.

We recommend that every key exchange uses a freshly generated ephemeral ECDH/DH key pair.

4.1.4 Pseudo-random functions for key generation

IKEv2 uses a pseudo random function (PRF) to generate key material. Table 9 lists PRFs that comply with ITSP.40.111 [1].

Table 9: Sufficient PRF for IKEv2 Key Generation

Sufficient
PRF_HMAC_SHA2_256 PRF_HMAC_SHA2_384 PRF_HMAC_SHA2_512 PRF_AES128_CMAC

4.1.5 IKEv2 Integrity protection

When not using an authenticated encryption (AEAD) algorithm (such as GCM) for message encryption, an additional integrity protection mechanism is required. Table 10 lists the integrity protection mechanisms that comply with ITSP.40.111 [1].

Table 10: Sufficient and Phase Out Integrity Protection Mechanisms

Sufficient	Phase Out
AUTH_HMAC_SHA2_256_128 AUTH_HMAC_SHA2_384_192 AUTH_HMAC_SHA2_512_256 AUTH_AES_128_GMAC AUTH_AES_192_GMAC AUTH_AES_256_GMAC AUTH_AES_CMAC_96	AUTH_HMAC_SHA1_160

4.1.6 Extensible authentication protocol

RFC 7396 JSON Merge Patch [13] specifies that Extensible Authentication Protocol (EAP) in IKEv2 can be used if it is used with the IKEv2 responder public key based authentication. RFC 5998 An Extension for EAP-Only Authentication in IKEv2 [14] lists the methods that can be used in IKEv2 to provide mutual authentication and that do not require responder public key based authentication.

While many authentication methods are listed as safe EAP methods in RFC 5998 [14], we recommend that you use methods that support channel binding. We also recommend that you maintain the use of responder public key based authentication.

4.1.7 DDOS protection

IKEv2 is prone to distributed denial of service attacks (DDoS). In a DDoS attack, a threat actor overwhelms a responder with a huge number of SA requests that are sent from spoofed IP addresses, creating half open SAs.

To protect against DDoS attacks, you should configure IKEv2 so that either the lifetime of half open SAs or the upper limit to the maximum number of half open SAs are allowed for a given IP before you take protective measures. You should implement the protection mechanisms described in RFC 8019 Protecting IKEv2 Implementations from DDoS Attacks [15].

You should not use IP fragmentation, as it is prone to DDoS attacks. Instead, use IKEv2 fragmentation and configure the size of the IKEv2 fragments.

RFC 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation [16] recommends a maximum datagram size of 1280 bytes for IPv6 traffic and 576 bytes for IPv4 traffic.

4.1.8 Key and authentication lifetimes

In the context of IKEv2, re keying creates new key material for the IKE SA or a CHILD SA via the CREATE_CHILD_SA exchange. Re authentication requires a complete IKE exchange and creates a new IKE SA. In this case, the old SAs are deleted.

We recommend that you ensure that the re key period or key lifetime of a CHILD SA (including the Encapsulated Security Payload [ESP] SA) does not exceed 8 hours. The re authentication period or authentication lifetime of the IKE SA should not exceed 24 hours.

4.1.9 Session resumption

RFC 5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption [17] offers a means for peers to reconnect a broken connection by using a previously established IKE SA.

If session resumption is used, the ticket by reference method is recommended, under the condition that the peers can be trusted to maintain the security of stored SA information. We also recommend that you limit the lifetime of a ticket to no more than the re keying time.

4.2 IPsec

IPsec is a suite of network protocols developed to protect the confidentiality, integrity, and availability of Internet communications between network hosts, gateways, and devices. IPsec also provides access control, replay protection, and traffic analysis protection.

IPsec hosts, gateways, and devices should be configured as specified in RFC 4301 Security Architecture for the Internet Protocol [18], RFC 4303 IP Encapsulating Security Payload (ESP) [19,] and RFC 7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) [20].

IPsec key management guidance is provided in NIST SP 800-57 Part 3 Rev 1 [4]. Refer to section 3 of NIST SP 800 57 Part 3 Rev 1 [4] for guidance on installing and administering IPsec.

4.2.1 Key generation

An IPsec SA specifies the key material used to encrypt and provide integrity protection for the traffic protected under a specific IPsec session. An IPsec SA must be established by a prior IKEv2 exchange as specified above.

4.2.2 Data and integrity protection

You should use digital signatures for authentication when IPsec is used to protect the confidentiality of PROTECTED A or PROTECTED B information or the integrity of UNCLASSIFIED, PROTECTED A, or PROTECTED B information. You should not use PSKs for authentication.

IPsec should use ESP protocol in tunnel mode to protect the confidentiality, integrity, and availability of the packets and packet headers. Do not use the Authentication Header (AH) protocol. AH protocol cannot protect confidentiality.

Table 11 lists the ESP packet encryption algorithms that comply with ITSP.40.111 [1].

Table 11: Recommended ESP Packet Encryption Algorithms

Recommended	Sufficient	Phase Out
ENCR_AES_GCM_16 ENCR_AES_CCM_16	ENCR_AES_GCM_12 ENCR_AES_CCM_12 ENCR_AES_CBC ENCR_AES_CTR	ENCR_3DES   ENCR_CAST

We recommend that you use AES in GCM for the encryption of ESP packets, as described in RFC 4106 [18]. If GCM or CCM is not supported, an integrity protection mechanism must be configured. Table 12 lists the integrity protection mechanisms that comply with ITSP.40.111 [1].

Table 12: Sufficient and Phase Out Integrity Protection Mechanisms

Sufficient	Phase Out
AUTH_HMAC_SHA2_256_128 AUTH_HMAC_SHA2_384_192 AUTH_HMAC_SHA2_512_256 AUTH_AES_128_GMAC AUTH_AES_192_GMAC AUTH_AES_256_GMAC AUTH_AES_CMAC_96	AUTH_HMAC_SHA1_160

4.2.3 Replay protection

Replay protection for IPsec implementations should be used. If performance allows, use the recommended anti-replay window size of 128.

5 Secure shell

Secure Shell (SSH) is a protocol developed to protect the confidentiality, integrity, and availability of remote access, file transfer, and point to point tunneling over the Internet.

SSH servers and clients should be configured to use SSH protocol version 2.0. SSH is a family of protocols that is specified in RFC 4251 The Secure Shell (SSH) Protocol Architecture [21], RFC 4252 The Secure Shell (SSH) Authentication Protocol [22], RFC 4253 The Secure Shell (SSH) Transport Layer Protocol [23], and RFC 4254 The Secure Shell (SSH) Connection Protocol [24].

SSH protocol version 1.0 has serious vulnerabilities. Administrators should verify that it is not running on their systems.

NIST SP 800-57 Part 3 Rev 1 [4] provides SSH key management guidance. Refer to section 10 of NIST SP 800 57 Part 3 Rev 1 [4] for guidance on installing and administering SSH.

5.1 SSH authentication

SSH offers both server only and server client mutual authentication.

You should use server client mutual authentication. In this case, the server is first authenticated via the Transport Layer Protocol, followed by client authentication via the SSH Authentication protocol.

Server authentication is performed with public key cryptography. Client authentication to the server can use various mechanisms. Client authentication that is based on public keys or Kerberos is preferred rather than the various forms of password authentication. You should not use SSH host based authentication; it is vulnerable to IP address spoofing.

If using public key authentication, you should use public key certificates that are managed by a PKI framework for both server and client authentication.

A PKI framework provides digital signing of keys by a trusted source. The framework also provides key management functions, such as revocation CRLs, key lifetime controls, and key usage restrictions. RFC 6187 x509.v3 certificates for Secure Shell Authentication [25] specifies the use of x509.v3 certificates in SSH.

Since SSH keys are typically system-level keys, keys should be generated upon session initialization to ensure uniqueness across devices and virtual machine images.

5.2 SSH Port forwarding

With SSH port forwarding, a host can access an insecure network service on a machine residing behind a server that acts as an SSH VPN gateway. Port forwarding should be disabled for interactive user accounts. For devices that require SSH tunneling, the traffic should be secured with a second tunnel (e.g. IPSec).

5.3 SSH root access

You should disable remote root user account logins.

5.4 SSH parameter selection

This section details the cryptographic algorithms recommend for SSH that satisfy the cryptographic guidance of ITSP.40.111 [1] and align with NIST SP 800-57 Part 3 Rev 1 [4]. We recommend that you refer to subsection 10.2.1 of NIST SP 800 57 Part 3 Rev 1 for cryptographic guidance on the SSH Transport Layer Protocol.

5.4.1 Encryption algorithm selection

Do not use Cipher Block Chaining (CBC) mode in SSH. CBC mode is vulnerable to plain text recovery attacks. RFC 4344 The Secure Shell (SSH) Transport Layer Encryption Modes [26] recommends using Counter (CTR) mode in SSH in place of CBC mode. Even better, authenticated encryption with associated data (AEAD) algorithms (such as AES GCM) protect both authenticity and confidentiality. Therefore, when you use AEAD algorithms, you do not need to use a separate MAC algorithm.

Table 13 lists the SSH encryption algorithms that satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 13: Recommended SSH Encryption Algorithms

Recommended	Sufficient	Phase Out
AEAD_AES_128_GCM AEAD_AES_256_GCM	aes128-ctr aes192-ctr aes256-ctr	cast128-ctr 3des-ctr

The AEAD GCM encryption algorithms are vulnerable to nonce reuse. You should ensure that the (key, nonce) pair is unique for each encrypted message.

5.4.2 Mac algorithm selection

In addition to the AEAD algorithms specified above, Table 14 lists the SSH MAC algorithms that satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 14: Sufficient and Phase Out SSH MAC Algorithms

Sufficient	Phase Out
hmac-sha2-256 hmac-sha2-512	hmac-sha1

5.4.3 Key exchange algorithm

Table 15 lists the SSH key exchange algorithms that satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 15: Recommended SSH Key Exchange Algorithms

Recommended	Sufficient	Phase Out
ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 ecmqv-sha2 gss-nistp256-sha256-* gss-nistp384-sha384-* gss-nistp521-sha512-*	diffie-hellman-group15-sha512 diffie-hellman-group16-sha512 diffie-hellman-group17-sha512 diffie-hellman-group18-sha512 gss-group15-sha512-* gss-group16-sha512-* gss-group17-sha512-* gss-group18-sha512-*	rsa2048-sha256 diffie-hellman-group14-sha256 gss-group14-sha256-*

The SSH protocol allows the session keys to be renewed by either the client or the server. Re keying schedules are based on a time limit or a data volume, as described in RFC 4344 [26].

To avoid MAC collisions, RFC 4344 [26] recommends re keying after receiving 232 packets when a 32 bit sequence number is used.

5.4.4 Public key algorithm

SSH optionally allows for authentication using public keys. Table 16 lists the SSH public key algorithms that satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 16: Recommended SSH Public Key Algorithms

Recommended	Sufficient	Phase Out
ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 x509v3-ecdsa-sha2-nistp256 x509v3-ecdsa-sha2-nistp384 x509v3-ecdsa-sha2-nistp521	rsa-sha2-256 rsa-sha2-512 x509v3-rsa2048-sha256	x509v3-ecdsa-sha2-nistp224

6 Secure/multi-purpose internet mail extensions

S/MIME is a standard developed to protect the confidentiality, integrity, and availability of electronic messages over the Internet.

S/MIME 4.0 as specified in RFC 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification [27] and RFC 8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling [28] should be used. S/MIME 4.0 includes support for AES GCM.

RFC 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) [29] provides guidance on the use of elliptic curve cryptography (ECC) in Cryptographic Message Syntax (CMS) for generating digital signatures and exchanging keys to encrypt or authenticate messages.

Software vendors should implement multi part isolation with security considerations for dealing with HTML and multi part/mixed messages, as discussed in RFC 8551 [27]. Until such multi part isolation is supported, S/MIME clients must be configured to disable the loading of remote content or only display messages in plain text.

6.1 Digest algorithms

Digest algorithms are used in S/MIME for digesting the body of a message or as part of a signature algorithm. Table 15 lists the digest algorithms that satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 17: Sufficient and Phase Out Digest Algorithms

Sufficient	Phase Out
SHA-256 SHA-384 SHA-512 SHA3-256 SHA3-384 SHA3-512	SHA-224 SHA3-224

Using SHA-1 to generate digital signatures does not satisfy the cryptographic guidance provided in ITSP.40.111 [1]. For S/MIME 3.2 or earlier versions, SHA 1 should not be used as a digest algorithm to sign messages.

6.2 Signature algorithms

Signature algorithms should be used with a digest algorithm. Table 18 lists the signature algorithms, which are paired with a digest algorithm from Section 6.1, that satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 18: Recommended Signature Algorithm and Digest Algorithm Pairs

Recommended	Sufficient	Phase Out
ECDSA with NIST P-256 curve ECDSA with NIST P-384 curve ECDSA with NIST P-521 curve RSASSA PSS with 3072-bit or larger modulus	RSASSA PKCS1v1.5 with 3072-bit or larger modulus DSA with 3072-bit or larger group	ECDSA with NIST P-224 curve RSASSA PSS with 2048-bit modulus RSASSA PKCS1v1.5 with 2048-bit modulus DSA with 2048-bit group

We recommend using RSASSA-PSS (instead of PKCS #1 v1.5) as the encoding mechanism for RSA digital signatures. This applies to both X.509 certificates, as specified in RFC 5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters [30], and signed data content types, as specified in RFC 4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS) [31]. If signing with multiple signature algorithms, you should use the multipleSignatures CMS attribute as specified in RFC 5752 Multiple Signatures in Cryptographic Message Syntax (CMS) [32].

Implementations of RSASSA-PSS should protect against possible hash algorithm substitution attacks. Implementations should check that the hash algorithm used to compute the digest of the message content is the same as the hash algorithm used to compute the digest of signed attributes.

6.3 Key encryption algorithms

Most key encryption algorithms for S/MIME require a key wrap algorithm to be specified as a parameter. Acceptable key wrap algorithms are specified in subsection 6.3.1 of this document. Table 19 lists the key encryption algorithms that satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 19: Recommended Key Encryption Algorithms

Recommended	Sufficient	Phase Out
dhSinglePass stdDH SHA256 KDF with the NIST P-256 curve dhSinglePass stdDH SHA384 KDF with the NIST P-384 curve dhSinglePass stdDH SHA512 KDF with the NIST P-521 curve	RSAES OAEP with a 3072-bit or larger modulus dhSinglePass cofactorDH SHA256 KDF with the NIST P-256 curve dhSinglePass cofactorDH SHA384 KDF with the NIST P-384 curve dhSinglePass cofactorDH SHA512 KDF with the NIST P-521 curve mqvSinglePass SHA256 KDF with the NIST P-256 curve mqvSinglePass SHA384 KDF with the NIST P-384 curve mqvSinglePass SHA512 KDF with the NIST P-521 curve	dhSinglePass stdDH SHA224 KDF with the NIST P-224 curve dhSinglePass cofactorDH SHA224 KDF with the NIST P-224 curve RSA KEM with a 2048-bit modulus or larger RSAES OAEP with a 2048-bit modulus RSAES PKCS1v1.5 with a 2048-bit or larger modulus

We recommend the use of standard Elliptic Curve Diffie-Hellman, as specified in RFC 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) [33].

If you are using RSA encryption, RSAES-OAEP should be implemented, as specified in RFC 3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS) [34] and RFC 5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters [30], to meet the cryptographic guidance of ITSP.40.111 [1].

Careful checking or random filling mitigations should be implemented, as described in RFC 3218 Preventing the Million Message Attack on Cryptographic Message Syntax [36], if you have S/MIME implementations that allow the decryption of PKCS #1 v1.5 encoding.

6.3.1 Key wrap algorithms

Table 20 lists the key wrap algorithms that can be used with an appropriate key encryption algorithm to satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 20: Recommended Key Wrap Algorithms

Recommended	Phase Out
AES-128 Wrap AES-192 Wrap AES-256 Wrap AES-128 Wrap Pad AES-192 Wrap Pad AES-256 Wrap Pad	3DES Wrap CAST5 CMS Key Wrap with a key length of 128 bits

6.4 Content encryption algorithms

The following encryption algorithms are appropriate for S/MIME content encryption and satisfy the cryptographic guidance provided in ITSP.40.111 [1].

Table 21: Content Encryption Algorithms

Recommended	Phase out
AES-128 GCM AES-192 GCM AES-256 GCM	AES-128 CBC AES-192 CBC AES-256 CBC

7 Commercial technologies assurance programs

When implementing PKI, TLS, IPsec, SSH and S/MIME, the implementation assurance guidance in Section 11 of ITSP.40.111 [1] should be followed.

8 Summary

Your organization can implement cryptographic security protocols to provide the security mechanisms to protect the confidentiality, integrity, and availability of information. As a first step, you should determine your organizational security requirements before determining which protocols to implement. Although your organization will have its own specific security requirements, various protocols can be used. You should select and implement each protocol in a manner that supports and meets these specific requirements.

8.1 Cyber Centre contact information

If you would like more information on securely configuring network protocols, contact us by phone or email:

Contact Centre
contact@cyber.gc.ca
613-949-7048 or 1-833-CYBER-88

9 Supporting content

9.1 List of abbreviations

Term

Definition

AEAD

Authenticated Encryption with Associated Data

AES

Advanced Encryption Standard

AH

Authentication Header

CA

Certificate Authority

CBC

Cipher Block Chaining

CMS

Cryptographic Message Syntax

CMVP

Cryptographic Module Validation Program

CRL

Certificate Revocation List

DANE

DNS-Based Authentication of Named Entities

DDoS

Distributed Denial of Service

DH

Diffie-Hellman

DTLS

Datagram Transport Layer Security

ECC

Elliptic Curve Cryptography

ECDH

Elliptic-Curve Diffie-Hellman

ECDHE

Ephemeral Elliptic Curve Diffie-Hellman

ECDSA

Elliptic Curve Digital Signature Algorithm

ECP

Elliptic Curve Groups modulo a Prime

ESP

Encapsulating Security Payload

GC

Government of Canada

GCM

Galois/Counter Mode

HMAC

Keyed-Hash Message Authentication Code

HSTS

HTTP Strict Transport Security

IKE

Internet Key Exchange

IPsec

Internet Protocol Security

IT

Information Technology

MAC

Message Authentication Code

MTA

Message Transfer Agent

PFS

Perfect Forward Secrecy

PKI

Public Key Infrastructure

PRF

Pseudo-Random Function

NIST

National Institute of Standards and Technology

RFC

Request for Comments

RSA

Rivest Shamir Adleman

SA

Security Association

SHA

Secure Hash Algorithm

SSH

Secure Shell

S/MIME

Secure/Multipurpose Internet Mail Extensions

SMTP

Simple Mail Transfer Protocol

SP

Special Publication

SSL

Secure Socket Layer

TBS

Treasury Board of Canada Secretariat

TLS

Transport Layer Security

9.2 Glossary

Term

Definition

Authentication

A process or measure used to verify a user’s identity.

Authenticity

The state of being genuine and being able to be verified and trusted; confidence in the validity of a transmission, a message, or message originator.

Availability

The ability for the right people to access the right information or systems when needed. Availability is applied to information assets, software, and hardware (infrastructure and its components).

Classified Information

A Government of Canada label for specific types of sensitive data that, if compromised, could cause harm to the national interest (e.g. national defence, relationships with other countries, economic interests).

Confidentiality

The ability to protect sensitive information from being accessed by unauthorized people.

Cryptography

The study of techniques used to make plain information unreadable, as well as to convert it back to a readable form.

DDoS Attack

An attack in which multiple compromised systems are used to attack a single target. The flood of incoming messages to the target system forces it to shut down and denies service to legitimate users.

Decryption

A process that converts encrypted voice or data information into plain form by reversing the encryption process.

Digital Signature

A cryptologic mechanism used to validate an item's (e.g. document, software) authenticity and integrity.

Encryption

Converting information from one form to another to hide its content and prevent unauthorized access.

Forward Secrecy

A property of key establishment protocols where the compromise of the long-term private key will not allow an adversary to re-compute previously derived keys or sessions.

Integrity

The ability to protect information from being modified or deleted unintentionally when it’s not supposed to be. Integrity helps determine that information is what it claims to be. Integrity also applies to business processes, software application logic, hardware, and personnel.

Key Management

The procedures and mechanisms for generating, disseminating, replacing, storing, archiving, and destroying cryptographic keys.

Replay Attack

A form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed.

9.3 References

Number

Reference

1

Canadian Centre for Cyber Security. ITSP.40.111 Cryptographic Algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B Information. August 2016.

2

Treasury Board of Canada Secretariat. Guideline on Defining Authentication Requirements. November 2008.

3

Canadian Centre for Cyber Security. ITSG-33 IT Security Risk Management: A Lifecycle Approach. December 2014.

4

National Institute of Standards and Technology. Special Publication 800-57 Part 3 Rev 1 Recommendation for Key Management Part 3: Application-Specific Key Management Guidance. January 2015.

5

Cooper, D., et al. RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Internet RFCs. ISSN 2070-1721. May 2008.

6

Rescola, E. RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3. Internet RFCs. ISSN 2070-1721. August 2018.

7

Hodges, J., C. Jackson, and A. Barth. RFC 6797 HTTP Strict Transport Security (HSTS). Internet RFCs. ISSN 2070-1721. November 2012.

8

Hoffman, P. RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. Internet RFCs. ISSN 2070-1721. February 2002.

9

Dukhovni, V., et al. RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). Internet RFCs. ISSN 2070-1721. October 2015.

10

Ray, M. and S. Dispensa. RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension. Internet RFCs. ISSN 2070-1721. February 2010.

11

Kaufman, C., et al. RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2). Internet RFCs ISSN 2070-1721. October 2014.

12

Kivinen, T., and J. Snyder. RFC 7427 Signature Authentication in IKEv2. Internet RFCs. ISSN 2070-1721. January 2015.

13

Hoffman, P. and J. Snell. RFC 7396 JSON Merge Patch. Internet RFCs. ISSN 2070-1721. October 2014.

14

Eronen, P. and H. Tschofeniq. RFC 5998 An Extension of EAP-Only Authentication in IKEv2. Internet RFCs. ISSN 2070-1721. September 2010.

15

Nir, Y. and V. Smyslov. RFC 8019 Protecting IKEv2 Implementations from Distributed Denial-of-Service Attacks. Internet RFCs. ISSN 2070-1721. November 2016.

16

RFC 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation.

17

RFC 5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption.

18

Kent, S., and K. Seo. RFC 4301 Security Architecture for the Internet Protocol. Internet RFCs. ISSN 2070-1721. December 2005.

19

Kent, S. RFC 4303 IP Encapsulating Security Payload (ESP). Internet RFCs. ISSN 2070-1721. December 2005.

20

McGrew, D., and P. Hoffman. RFC 7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH). Internet RFCs. ISSN 2070-1721. August 2014

21

Ylonen, T., and C. Lonvick, Ed. RFC 4251 The Secure Shell (SSH) Protocol Architecture. Internet RFCs. ISSN 2070-1721. January 2006.

22

Ylonen, T., and C. Lonvick, Ed. RFC 4252 The Secure Shell (SSH) Authentication Protocol. Internet RFCs. ISSN 2070-1721. January 2006.

23

Ylonen, T., and C. Lonvick, Ed. RFC 4253 The Secure Shell (SSH) Transport Layer Protocol. Internet RFCs. ISSN 2070-1721. January 2006.

24

Ylonen, T., and C. Lonvick, Ed. RFC 4254 The Secure Shell (SSH) Connection Protocol. Internet RFCs. ISSN 2070-1721. January 2006.

25

Igoe, K., and D. Stebila. RFC 6187 x509.v3 certificates for Secure Shell Authentication. Internet RFCs. ISSN 2070-1721. March 2011.

26

Bellare, M., T. Kohno, and C. Namprempre. RFC 4344 The Secure Shell (SSH) Transport Layer Encryption Modes. Internet RFCs. ISSN 2072-1721. January 2006.

27

Schaad, J., B. Ramsdell, and S. Turner. RFC 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification. Internet RFCs. ISSN 2070-1721. April 2019.

28

Schaad, J., B. Ramsdell, and S. Turner. RFC 8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling. Internet RFCs. ISSN 2070-1721. April 2019.

29

Turner, S., and D. Brown. RFC 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). Internet RFCs. ISSN 2070-1721. January 2010.

30

Turner, S., et al. RFC 5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters. Internet RFCs. ISSN 2070-1721. January 2010.

31

Schaad, J. RFC 4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS). Internet RFCs. ISSN 2070-1721. June 2005.

32

Turner, S., and J. Schaad. RFC 5752 Multiple Signatures in Cryptographic Message Syntax (CMS). Internet RFCs. ISSN 2070-1721. January 2010.

33

Turner, S. and Brown, D. RFC 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). Internet RFCs. ISSN 2070-1721. January 2010.

34

Housley, R. RFC 3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS). Internet RFCs. ISSN 2070-1721. July 2003.

35

Margolis, D. Risher, M., Ramakrishnan, B., Brothman, A., Jones, J. RFC 8461 SMTP MTA Strict Transport Security (MTA-STS). ISSN: 2070-1721. September 2018.