NIST SP 800-57 Part 3 Rev. 1 日本語訳

Elaine Barker Quynh Dang

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-57pt3r1

Elaine Barker Quynh Dang

Computer Security Division Information Technology Laboratory

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-57pt3r1

January 2015

U.S. Department of Commerce Penny Pritzker, Secretary

National Institute of Standards and Technology

Willie May, Acting Under Secretary of Commerce for Standards and Technology and Acting Director

Authority

This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-57 Part 3, Revision 1 Natl. Inst. Stand. Technol. Spec. Publ. 800-57 Part 3, Revision 1, 102 pages (January 2015) CODEN: NSPUE2

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-57pt3r1

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by Federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, Federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: SP80057Part3@nist.gov

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

NIST Special Publication 800-57 provides cryptographic key management guidance. It consists of three parts. Part 1 provides general guidance and best practices for the management of cryptographic keying material. Part 2 provides guidance on policy and security planning requirements for U.S. government agencies. Finally, Part 3 provides guidance when using the cryptographic features of current systems.

accreditation; assurances; authentication; authorization; availability; backup; certification; compromise; confidentiality; cryptanalysis; cryptographic key; cryptographic module; digital signature; key management; key management policy; key recovery; private key; public key; public key infrastructure; security plan; trust anchor; validation.

Acknowledgements

The co-authors of this version of SP 800-57, Part 3 greatly appreciate the contributions of previous co-authors of this document, namely William Burr, Alicia Jones, Timothy Polk, Scott Rose and Miles Smid. We also appreciate contributions by Katrin Reitsma, Sheila Frankel, David Cooper, Judith Spencer, the National Security Agency (NSA) and many others in the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of this publication.

Application-Specific Key Management Guidance, Part 3 of the Recommendation for Key Management is intended primarily to help system administrators and system installers adequately secure applications based on product availability and organizational needs and to support organizational decisions about future procurements. This document also provides information for end users regarding application options left under their control in normal use of the application. Recommendations are given for a select set of applications, namely:

Section 2 – Public Key Infrastructures (PKI) Section 3 – Internet Protocol Security (IPsec) Section 4 – Transport Layer Security (TLS) Section 5 – Secure/Multipurpose Internet Mail Extensions (S/MIME) Section 6 – Kerberos Section 7 – Over-the-Air Rekeying of Digital Radios (OTAR) Section 8 – Domain Name System Security Extensions (DNSSEC) Section 9 – Encrypted File Systems (EFS) Section 10 – Secure Shell (SSH)

The following is provided for each topic:

Following Section 10 are five appendices with a glossary, an explanation of acronyms, basic information for novice and end users on obtaining and using keys, references for documents cited herein, and changes incorporated into this revision.

This document does not reflect a comprehensive view of current products and technical specifications. Future versions of this document will include updates to the topics covered, and may include additional subjects as new techniques are widely implemented.

Part 3 of the Recommendation for Key Management, Application-Specific Key Management Guidance, is intended to address the key management issues associated with currently available cryptographic mechanisms. General Guidance, Part 1 of the Recommendation for Key Management, contains basic key management guidance for users, developers and system managers regarding the “best practices” associated with the generation and use of the various classes of cryptographic keying material [SP 800-57 Part 1]. General Organization and Management Requirements, Part 2 of the Recommendation, provides a framework and general guidance to support establishing cryptographic key management within an organization, and a basis for satisfying the key management aspects of statutory and policy-based security planning requirements for Federal Government organizations.

This document, Part 3 of the Recommendation, is designed for system installers, system administrators and end users of existing key management infrastructures, protocols, and other applications, as well as the people making purchasing decisions¹ for new systems using currently available technology. Note that end users who act as their own system installers, administrators and purchasing agents may find the guidance intended for administrators, installers and purchasers to be beneficial. In centrally managed organizations, the organization’s management must establish a security policy that acts as a foundation for all end-user guidance.

Recommendations are made for mechanisms designed to protect stored data and data in transit. This document will not provide a complete restatement of existing standards or implementation directives. Standards and guidelines with this level of detail are referenced where appropriate.

For each of the key management infrastructures, protocols, and applications addressed in Part 3, the following is provided:

The logistics of how one should obtain, store or transfer keys or key pairs within a given application or system are application and implementation-specific and beyond the scope of this document. In large federal systems, these functions are frequently handled by system administrators or completed with direct guidance from system administrators. For end users faced with these tasks on their own, an informative appendix has been included with general information intended to point the end user in the right direction.

Since some of the infrastructures, protocols and applications addressed in this Recommendation will be refined or replaced over time, the guidance provided herein will become obsolete. Similarly, it is anticipated that new infrastructures, protocols, and applications will be developed. Although this document will be updated as mechanisms and techniques evolve, it may not always reflect a comprehensive view of current products and technical specifications. Hence, references to version numbers or other implementation status information are provided to enable an evaluation of the applicability of particular elements of guidance to the specific version of an infrastructure, protocol, or application into which a mechanism is integrated.

Note that many of the applications described in Part 3 are currently in use by U.S. government agencies. Some of these applications were developed and implemented prior to the release of Part 1 of this Recommendation, and therefore, may not follow all of the principles identified in Part 1 [SP 800-57 Part 1]. The use of current implementations of these applications may be necessary until more carefully designed applications are available. It is very important that each implementation that does not comply with NIST standards and guidelines be evaluated for associated risks and that steps be taken to mitigate those risks as discussed in this Recommendation.

This Recommendation often uses “requirement” terms; these terms have the following meaning in this document:

There are a number of general issues associated with the protocols discussed in Part 3. Four of these issues are briefly discussed in order to familiarize the reader with concepts that will be repeated throughout the document and to help frame the upcoming discussions:

Many of the cryptographic security services described in this document are based on public standards (e.g., Internet Engineering Task Force (IETF) Requests for Comment (RFCs), American National Standards, etc.). In these standards, algorithms are frequently described as mandatory-to-implement or optional-to-implement. Neither of these terms provides information about the security of the algorithm.

Mandatory-to-implement algorithms will be in any product that meets the public standards, allowing interoperability between products.

Optional-to-implement algorithms tend to be next-generation algorithms that may become mandatory-to-implement algorithms in a future version of the standard. There could be considerable delay in the widespread use of these new algorithms for a variety of reasons, ranging from a need for supporting hardware or software upgrades, to issues of interoperability. For example, an algorithm that is optional-to-implement within an S/MIME protocol may not currently be supported by the system’s cryptographic module. However, these algorithms often offer improved security that could significantly increase the longevity of the system. Therefore, one may want to consider buying products that support the optional-to-implement algorithms, even if those algorithms will not be available to all end users immediately.

As previously defined, the terms shall and should are used to provide information about whether algorithms have adequate security for use on federal computer networks. As such, there may be mandatory-to-implement algorithms that do not provide adequate security (e.g., Data Encryption Standard (DES) or RC2), and this document will say they shall not be used. Similarly, there may be optional-to-implement algorithms that have greater security (e.g., Advanced Encryption Standard (AES)), and this document may say that these algorithms should or shall be used in a given situation.

The distinction between mandatory-to-implement and optional-to-implement is important when two users on different systems desire to communicate or when different levels of security may be required for different applications running on the same system. This is further discussed in the next section on cryptographic negotiation.

Parts 1 and 2 of this Recommendation establish a sound basis for selecting appropriate cryptographic algorithms and managing the corresponding cryptographic keys. However, enforcing these guidelines can be problematic for a number of reasons, including the unavailability of certain algorithms or key sizes, the preferences of the communicating parties or other system limitations. When servers dictate the algorithms used, the server may select the algorithms that optimize overall system performance, rather than the ones that provide the highest level of security.

In some multi-party protocols where multiple algorithms are supported for the same purpose, a client can enforce the rules in Parts 1 and 2 through negotiation within the protocol. Some protocols (e.g., S/MIME) allow the initiating client to select the cryptographic algorithms without negotiating with the receiving client. In this case, as in the case where applications do not permit negotiation, a receiving client may be presented with information that has been inadequately protected. For example, a receiving client may receive a signed and encrypted S/MIME e-mail message that was encrypted using DES and signed with a 512-bit RSA key². Rejecting such messages does not necessarily enhance security (in this case, the message has already been sent over the Internet), but the receiving user should be aware that the security services purportedly provided by the digital signature and content encryption are suspect and cannot be depended upon. It may be appropriate to reject the message or terminate the protocol. A risk assessment and subsequent organizational policy may be required to determine the appropriate course of action.

In other protocols (e.g., Transport Layer Security (TLS)), the client proposes a set of options, and the server chooses from the proposed list during a negotiation phase of the protocol. Where negotiation is supported, protocols may be designed to negotiate cipher suites or to negotiate each algorithm independently. In either case, a client or server may be faced with a situation where the preferred algorithms of the client or server and the proposed algorithms of the other party are not of the same security strength, or where approved algorithms are not available.

Another issue may arise when a protocol is designed to negotiate algorithms, but not key sizes. In such a case, the clients may find themselves communicating with approved algorithms, but inadequate key sizes. For example, after negotiating for RSA signatures, the client might get a message signed with a 512-bit RSA key³.

Enforcing the recommendations from Parts 1 and 2 may also be complicated by system or application design decisions. Systems may have application-specific controls for cryptographic algorithms, or they may have system-wide controls. For example, a user may wish to restrict one application to using AES, and another to using TDEA, while the system design may only allow the use of TDEA. Often the only limitation on public key sizes is an indirect limitation through the choice of root Certificate Authority (CA) keys (see Section 2.1).

When there are a variety of algorithms or key sizes available for a given communication protocol, the following questions need to be addressed:

A good start at ensuring communication security in a multi-algorithm setting would be to:

A major thrust from Part 1 of this Recommendation is that, in general, keys shall not be used for multiple cryptographic purposes. For example, the same key shall not be used to generate a digital signature and to establish other keying material (see [SP 800-57 Part 1, Sec. 8.1.5.1.1.2 ] for the rare exceptions to this guidance). It is less clear as to whether a digital signature key, for example, can be used only for a specific application (e.g., signing e-mail) or for multiple applications (e.g., for both signing e-mail and signing documents). In some cases, it may be acceptable for an application to share keys with other applications. In other cases, sharing keys may not be desirable. For example, best practices indicate that a server’s TLS keys should not be used to support other applications. Even where keys are used to perform the same cryptographic operation (e.g., digital signatures), sharing keys may be inappropriate because one application could be providing one service (e.g., authentication), while a second application could be providing a different service (e.g., non-repudiation). It is important to remember that it may be a bad idea to use keys for multiple applications.

An agency should perform a risk assessment when considering the use of the same key for multiple applications.

Part 1 of this Recommendation provides timeframes for transitioning from algorithms and key sizes currently in use by many applications and protocols in order to increase the strength of the security mechanisms in the future [SP 800-57 Part 1]. In many cases, the algorithms and key sizes required to provide adequate security are not available within the current implementations or are unavailable uniformly across the community of users that need to interoperate. Transitions to new algorithms or key sizes will not necessarily occur instantaneously, but will require gradual upgrades across a system. For example, a system owner may have the need to upgrade his system’s e-mail package before upgrading the cryptographic module. Hence, for a period of time, the system may be running with an e-mail package capable of TDEA and AES 128 encryption, but a cryptographic module that can only handle TDEA. There will be a need to upgrade components of a system with new capabilities, while continuing to support the old capabilities, until all components have been upgraded.

During this transition period, interaction between components can proceed in one of the following ways:

Most of the applications and protocols discussed in Part 3 require an upgrade of the available security mechanisms to be compliant with Part 1. The following sections provide guidance on how the existing mechanisms may best be used until appropriate upgrades can be made. Organizations and system administrators must determine the approach for transitioning to stronger security mechanisms within a system.

A PKI is the most common key management approach for the distribution of public keys. As described in SP 800-57 Part 1, Recommendation for Key Management, Part 1: General [SP 800-57 Part 1], public keys are used to establish security services after obtaining a variety of assurances: assurance of integrity, assurance of domain parameter validity (where appropriate), assurance of public key validity, and assurance of private key possession. In most cases, applications must also establish the identity of the user associated with this key pair. In a PKI, the infrastructure establishes the user’s identity and the required assurances to provide a strong foundation for security services in PKI-enabled applications and protocols, including IPsec (Section 3), Transport Layer Security (Section 4), S/MIME secure e-mail (Section 5) and some versions of Kerberos (Section 6). This section presents basic guidance for PKI-based key management. For broader and more detailed information on PKI, see [SP 800-32].

Public key certificates bind two names to a public key, the user’s name and the issuer’s name, using a digital signature generated by the issuer. The user is the party authorized to use the private key associated with the public key in the certificate. The issuer is a trusted third party that generates and signs the certificate after verifying: the identity of the user; the validity of the public key, associated algorithms and any relevant parameters; and the user’s possession of the corresponding private key. The issuer is known as a Certificate Authority (CA). In many cases, the CA will delegate responsibility for the verification of the subject’s identity to a Registration Authority (RA). The certificate is used to distribute the user’s public key to other interested parties, known as relying parties, since they rely on the assurances provided by the PKI and the certificate creation process.

CAs generally issue a self-signed certificate called a root certificate (sometimes also called a trust anchor); this is used by applications and protocols to validate the certificates issued by a CA. CA certificates play a key role in many protocols and applications, and are generally kept in what is often called a root certificate store. Much of the business of properly configuring applications and protocols consists of ensuring that only appropriate root certificates are loaded into the root certificate store. In Microsoft Windows operating systems, there are root certificate stores that are maintained by the operating system for various purposes that are shared by various Microsoft protocols and applications, and by other applications that may choose to use them. There is a similar “Keychain” facility in the Apple operating systems. Some applications, intended to be portable between operating systems, can maintain their own root certificate stores and also have a feature that allows them to share a root certificate store with other applications.⁶

Certificates are generally issued in accordance with a certificate policy. Generally that policy can be found on the issuing CA’s website. If an organization’s policy, for example, is to accept only certificates that use at least 2048-bit RSA, 2048-bit DSA or 224-bit elliptic curve cryptography, and either, SHA-224 or SHA-256, then the only practical way to ensure that public key sizes meet the requirements is usually to ensure that the root certificate store contains only root certificates with a certificate policy that requires these algorithms and key sizes in its subordinate certificates. Current applications that use PKI will check to ensure that a certificate has been issued under the root certificate in the application’s root store, and that it has not been subsequently revoked, but will not otherwise check the suitability of the public key or hash algorithms used in the certificate – the application will simply use the specified keys to compute the mathematically correct results. So, correctly configuring root certificate stores is a critical step in key management.

The specifics of where the root certificate store is located and how it is managed for each application and protocol are beyond the scope of this Recommendation. Typically, however, there are menus for viewing and managing certificate stores in the browser applications, but this is subject to change with each product update. There may also be utilities and features in the operating system or application for centralized management by the system administrator. When a browser or other application encounters an unrecognized CA certificate, end users may be prompted to add that certificate to their permanent trusted certificate store, temporarily trust the certificate, or reject the certificate and close the application.

The most common certificate format is the X.509 version 3 (X.509v3) certificate [RFC 5280]. In addition to the user and issuer names and the public key, all X.509 certificates also include a digital signature, validity (starting and expiring times), and identifiers that specify the cryptographic algorithm(s) to be used with the public key and signature. X.509v3 certificates include an extensibility feature; CAs usually include standard extensions in their certificates to indicate which cryptographic operations the public key was intended to support, the policy that governed certificate issuance, and where to find out if the certificate has been revoked (i.e., an authoritative source for certificate status information). CAs may also include “private” extensions in their certificates that contain information particular to an application or domain of users.

A relying party is an individual or organization that relies on the certificate and the CA that issued the certificate to provide valid information (see Appendix A). Before a relying party uses the public key in a certificate, he must determine whether the key used by the issuer to sign this certificate can be trusted. In the simplest case, the relying party knows about the issuer, and has already decided to trust certificates issued by that CA. CAs that a relying party trusts directly are called trust anchors. When multiple trust anchors are recognized, the set of trust anchors is referred to as the trust list.

In some cases, a relying party will wish to process user certificates that were signed by issuers other than a CA in its trust list. To support this goal, CAs issue cross certificates that bind another issuer’s name to that issuer’s public key. Cross certificates are an assertion that a public key may be used to verify signatures on other certificates. A relying party may be able to develop a certification path – a sequence of certificates – demonstrating that a user’s public key certificate can be trusted, even though it was issued by a CA that is not in the relying party’s trust list. All certification paths begin with a trust anchor, include zero or more intermediate certificates, and end with the certificate that contains the user’s public key.

The entire path must be examined to ensure that the certificates have not been revoked, were issued under appropriate policies, and that each public key is suitable for the use to which it has been put. This process is known as path validation.

As noted above, the certificate itself will usually include a pointer to an authoritative source for certificate status information. Certificate status information may be provided using one of two standard mechanisms:

In many cases, PKIs will also provide key recovery services (using Recovery Servers) to support business continuity. Key recovery services store private keys that support key establishment to ensure that the plaintext of encrypted data may be recovered in the future. These services can provide the private key to the user in the event of loss or failure of their cryptographic module, or to the user’s management when policy or legal requirements exist. When supported, this service removes a key management burden from PKI-enabled applications. A PKI should include a key recovery services system.

This section provides guidance for general-purpose PKIs when users from different organizations need to support a variety of applications. For large, general-purpose PKIs, interoperability is an important consideration. Less commonly, PKIs may be deployed to support a small, closed community of users or for a single application, where wider interoperability is less important. The requirements within this section are focused on large, general-purpose PKIs, such as the Federal PKI. For PKIs requiring less interoperability, these requirements should be evaluated for appropriateness within their systems. In general, cryptographic algorithm and key size standards should be met by all PKIs.

Table 2-1 below summarizes the recommended key sizes for key pairs used by PKI users and infrastructure components. The PKI uses the term digital signature key to refer to a private signature key or public signature verification key (as defined in Part 1) that provides a non-repudiation service. The term authentication key is used by the PKI to refer to a private authentication key or public authentication key as defined in Part 1. Note that both a digital signature key and an authentication key are used with a digital signature algorithm.

The dates in this table are consistent with those that appear in Part 1, where:

Approved algorithms and key sizes specified in Table 2-1 and certificate expiration dates are two different things. These algorithms and key sizes are approved for use beyond the year 2013. However, a digital signature or key establishment certificate may expire at any time, depending on the organization’s security policy.

Table 2-1: Recommended Algorithms and Key Sizes

Note that some approved algorithms and key sizes, such as DSA 2048, are omitted to enhance interoperability. RSA and ECDSA, which are included in Table 2-1 above, have been widely deployed in PKIs. Therefore, they are recommended for use to enhance interoperability. However, DSA (2048 and 3072) as specified in [FIPS 186-4] are allowed as long as the required security strength is satisfied. For ECDSA, only the two elliptic curves listed in Table 2-1 above of the elliptic curves are recommended for use in PKIs for digital signatures [FIPS 186-4]. Similarly, Elliptic Curve Diffie-Hellman (ECDH) is recommended to support key establishment, rather than Elliptic Curve MQV.

While Table 2-1 is focused on the strength of the public key contained in a certificate, the strength of the digital signature on a certificate itself is equally important. The signature security strength also reflects the security strength of the hash algorithm, and possibly the padding scheme⁸, in addition to the strength of the private key used to generate the signature. Table 2-2 below summarizes the recommended algorithms, key sizes, hash functions, and padding schemes for signing certificates and CRLs by CAs, and OCSP status messages by OCSP responders.

Table 2-2: Digital Signature Recommendations for CAs and OCSP Responders

User certificates containing RSA or Diffie-Hellman public keys should be signed using the RSA signature algorithm. User certificates containing elliptic curve public keys should be signed using ECDSA.

Not all combinations of algorithms and key sizes are appropriate for the protection of Federal Government information. To enhance interoperability, users should obtain authentication, signature, and key establishment certificates with complementary algorithms for all public keys.⁹ For most users, signature and key establishment keys should provide the same cryptographic strength. Table 2-3 below shows preferred combinations for user keys.

While symmetric key cryptography is not strictly required, block ciphers are used in practically all PKI implementations and PKI-enabled applications. All components using block ciphers shall support the AES-128 algorithm. To support legacy implementations, components that process RSA keys should support three-key Triple-DEA [SP 800-67]. Components that support P-384 elliptic curve keys and the SHA-384 algorithm shall support AES-256.

Table 2-3: Recommended Combinations for the Recommended Algorithms and Key Sizes

The following provides guidance for those responsible for making decisions about which products to purchase in support of a PKI.

a) Ensure that CAs that implement federal agency-specific policies are able to generate certificates and CRLs that meet the agency profile and the Federal PKI Certificate Profile [FPKI PROF]. b) Ensure that CAs that implement the Common Policy Framework [COMMON] are able to generate certificates and CRLs meeting the Shared Services Certificate and CRL Profile [COMMON PROF].

The system installer and administrator is the person (or people) who are responsible for establishing the PKI and who are responsible for the tasks associated with its day-to-day operation. The system administrator shall ensure that end users are trained and that the organization’s security policy is enforced.

a) CAs should be configured to authenticate and process revocation requests electronically. b) Where the CA can authenticate a digitally signed request submitted by the user of the associated key pair or an RA, the request should be handled without manual intervention.

For federal agencies, detailed configuration guidance for OCSP responders is specified in Draft Guidance for OCSP Responders in the U.S. Federal PKI.¹⁷

In a PKI, the subject is the identity of the user associated with a public key. The subject may be a person or a device. For the purposes of this section, the term “user” is means either the person associated with a public key, or the administrator of a device associated with a public key.

IPsec is a suite of protocols for securing Internet communications at the network layer and operates within the Internet Protocol (IP). It is frequently used to establish Virtual Private Networks (VPNs)¹⁸, requiring both parties to share keying material, and enabling telecommuters or travelers to gain secure access to their business networks. IPsec provides the cryptographic security functions for both versions 4 and 6 of the Internet Protocol.

IPsec operates by inserting one of two special IPsec headers after the IP header in each message. The Authentication Header (AH) provides integrity protection. The Encapsulating Security Protocol (ESP) Header provides confidentiality and/or integrity protection. Hereafter, the terms AH and ESP will be used as shorthand for messages using AH and ESP headers, respectively. Both ESP and AH provide data origin authentication, and optionally provide replay protection. AH protects the IP header and the data following the IP header. ESP, when applied directly to a packet (i.e., in transport mode), protects the data, but not the IP header. However, ESP in tunnel mode (with a new IP header inserted) does protect the original IP header. Furthermore, using ESP with automated keying protects the source and destination addresses in the IP header in either transport or tunnel mode. Since AH processing introduces unnecessary complexity, and since ESP can provide equivalent functionality, the use of AH is not recommended.

There have been three versions of IPsec.¹⁹ All new systems should implement IPsec-v320, as it has many enhancements not found in the previous versions. However, IPsec-v2 is still implemented in numerous current systems, despite the fact that it is obsolete.²¹

Two classes of key management methods are specified for IPsec: manual keying and automated keying. Manual keying involves an agreement (in an unspecified manner) by the parties in a communication on the IPsec protections to be applied and the symmetric keys to be used. This has a major downside in that it severely limits the scalability of the security solution and requires re-keying to be done in an unspecified manner. A Security Association (SA, i.e., a relationship between two or more entities that describes how each entity will use the security services to communicate securely) and its secret keys cannot be easily renewed in the cases where the SA expires, has been used for the maximum allowable volume of traffic, or if its keys are compromised.

To use automated keying, an automated negotiation between peers prior to exchanging IPsec-protected traffic determines the IPsec protections to be applied and the symmetric keys to be used. The same method can be used to maintain, delete, or renegotiate the SA

(e.g., to rekey). This approach permits a decoupling of the key management mechanism from the other security mechanisms, thus facilitating the use of alternative key management methods without having to modify other security mechanisms.

The preferred automated keying method is IKE, the Internet Key Exchange protocol that was designed specifically for use with IPsec. IKE generates the necessary keying material for IPsec via an authenticated secure channel between the two IKE peers. There are two versions of IKE in use: IKEv1 ([RFC 2407], [RFC 2408] and [RFC 2409]) and IKEv2 [RFC 5996]; both versions perform mutual authentication, and establish and maintain security associations. SAs will be valid for a specified period of time or volume of traffic. IKEv1 is still implemented in numerous current systems, despite the fact that it is obsolete. These two versions of IKE are not interoperable. IKEv2 was designed to be more reliable and efficient than IKEv1; therefore, IKEv2 should be used.

Table 3-1 provides the IETF reference materials for versions 2 and 3 of IPsec.

Table 3-1: Summary of References for IPsec

The IPsec security mechanisms are not tied to any specific cryptographic algorithms; in fact, many algorithms and modes have IETF Requests For Comment (RFCs) describing their use with IPsec. This, however, can result in a situation where there are so many choices for typical system administrators to make that it is difficult to achieve interoperability. To improve interoperability in IPsec-v3, two cipher suites: VPN-A and VPN-B were specified [RFC 4308]. However, these two cipher suites are not NIST-approved cipher suites. Four additional cipher suites have been defined in [RFC 6379]: Suite-B-GCM-128, Suite-B-GCM-256, Suite-B-GMAC-128 and Suite-B-GMAC-256 and they are NIST-approved.

Implementers may allow the individual selection of security algorithms (i.e., rather than selecting one of the pre-specified suites of algorithms) specified in [RFC 6379], but users must be aware that picking non-standard groupings of algorithms may result in limited interoperability. However, when IPsec is used in the context of a VPN, security policy can be centrally managed, thus ensuring interoperability without the use of pre-defined cipher suites. Current IETF algorithm guidance is in [RFC 7321].

Table 3-2 below gives cryptographic algorithm recommendations for use within IPsec. The algorithms that are specified for IKE are used to protect IKE’s own traffic. The algorithms used in ESP and AH are used to provide IPsec protection to data traffic; for these algorithms to be used within ESP or AH, IKE must be capable of negotiating their use.

In Table 3-2 below, column four lists the IETF conformance requirements as specified in the RFCs by using the three IETF requirement levels: MUST, SHOULD and MAY to indicate whether the algorithm needs to be implemented. See [RFC 2119] for definitions of these requirement levels and further information on IETF Conformance language. Column five, however, states federal conformance requirements using two levels: Mandatory and Optional. Mandatory means that the feature is required to be available in an implementation, and Optional means that implementation of the technique is permitted.

Table 3-2: Cryptographic Algorithm Recommendations

In [RFC 4835] and [RFC 2410], ESP provides options for NULL integrity protection or NULL encryption, which means that either no integrity protection would be applied or no encryption would be used, respectively; however, [RFC 4835] specifies that at least one of them MUST be applied. In the RFCs, NULL integrity protection (often referred to as NULL authentication) is intended for use in situations where confidentiality is required without the need for integrity protection. NULL integrity protection shall not, and in fact cannot, be used with NULL encryption. ESP, for example, could send unencrypted packets, (encryption set to NULL), but would be required to integrity-protect them, for example, by using HMAC-SHA1. On the other hand, ESP could send packets encrypted with AES-128 in CBC mode, but omit the integrity check (integrity protection set to NULL).

However, to be compliant with this Recommendation, IPsec ESP-protected traffic shall always be integrity-protected, either through the use of an integrity-protection algorithm, such as HMAC-SHA1-96, or through the use of a combined-mode algorithm, such as AES-128 in Galois/Counter Mode. Therefore, encrypted ESP shall not be used with NULL integrity-protection.

When IPsec-protected traffic is integrity-protected, an Integrity Check Value (ICV) is stored in the Integrity Check Value field of the ESP payload [RFC 4303] or in the Integrity Check Value field of the Authentication Header (AH) [RFC 4302]; this field is referred to as the “Authentication Data” field in IPsec-v2 ([RFC 2406], [RFC 2402]).

When HMAC is used for integrity protection, the length of the ICV value is at most the size of the output value of the hash function. For example, the ICV value for HMAC-SHA1-96 and HMAC-SHA256-128 is 96 and 128 bits, respectively [RFC 4868].

Although the IETF still recommends supporting AES-XCBC-MAC ([RFC 3566], [RFC 4434], [RFC 7321]), it is not approved for use by the Federal Government. As such, AES-XCBC-MAC shall not be used for integrity protection.

A new class of algorithms, called combined-mode algorithms, appears in the above table. They can be negotiated by IKE and used within IPsec-v3 cipher suites. These algorithms provide both encryption and integrity protection. Two combined-mode algorithms have been approved for Federal Government use: AES in Galois/Counter Mode (GCM) [RFC 4106] and AES in counter mode with CBC-MAC (AES-CCM) [RFC 4309].

There is also a variant of AES-GCM, referred to as AES-GMAC [RFC 4543], that provides integrity protection, but does not provide encryption. This mode may be used within either the ESP or AH header.

The maximum size of the ICV for AES-CCM, AES-GCM and AES-GMAC is 16 bytes. Implementations shall support an ICV size of 16 bytes for these three algorithms ([RFC 4309], [RFC 4106], [RFC 4543]).

AES-GCM, AES-CCM, AES-CTR, and AES-GMAC shall not be used with manually distributed keys. If the counter value, in AES-CTR or AES-CCM, or the IV value, in AES-GCM or AES-GMAC, is used for more than one packet with the same key, the security of the algorithm’s confidentiality mechanism is compromised. Since manual keying presents a major challenge to this limit, manually distributed keys shall not be used with these algorithms. Automated keying using IKE establishes secret keys for the two peers within each Security Association, with an extremely small probability of duplicate keys.

In previous IETF guidance, single DES using the CBC mode [RFC 2405] was mandatory-to-implement; however, this algorithm shall not be used to protect information.

IPsec allows the individual selection of security algorithms. As an example, an implementer using Table 3-2 and following the guidance of Part 1 [SP 800-57 Part 1], could select the following algorithms to form an IPsec suite with an overall security strength of 112 bits:

The Suite-B-GCM-128 and Suite-B-GCM-256 suites are both defined in [RFC 6379]. At present, these cipher suites are not widely available or deployed. [SP 500-267] states that support for these cipher suites is optional. However, wherever practical, implementations should be procured that support these cipher suites, and they should be selected for use wherever very high performance and security strength are required. As discussed above, AES-GCM is a combined-mode algorithm that provides both encryption and integrity protection; therefore these suites provide integrity, despite the fact that the integrity mechanism is listed in [RFC 6379] as NULL for both suites.

These recommendations are written to assist individuals responsible for selecting security products that include IPsec for the security of the IP layer.

Systems installers are those individuals that install products that include IPsec for security.

System administrators are those individuals responsible for the day-to-day functioning of the security product containing IPsec. System administrators shall:

An end user is the individual using a product that relies on IPsec for security. End users shall:

This section was moved to SP 800-52 Revision 1, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations [SP 800-52].

Secure/Multipurpose Internet Mail Extensions (S/MIME) provides a consistent way to send and receive secure Internet mail. S/MIME is a set of specifications that are defined by a series of IETF RFCs, namely [RFC 5751], [RFC 5652], [RFC 2045], [RFC 2046], [RFC 2047], [RFC 4288], [RFC 4289] and [RFC 2049]. S/MIME provides the following cryptographic security services for electronic messaging applications:

S/MIME, therefore, requires a suite of algorithms for creating digital signatures, generating hash values, establishing keys and encrypting the content of the e-mail, as well as some means of establishing and sharing digital identities. Federal implementations rely on a public key infrastructure, specifically X.509 PKI, to establish S/MIME user identities, to bind those identities to the user’s public key through public key certificates, to provide digital signatures, to provide keys to be used for content encryption, or to establish symmetric keys for use on a per message basis. For detailed information on PKIs, see Section 2 of this Recommendation.

Stored electronic mail encompasses key management issues associated with encrypted file integrity and with transmission over a network. It is therefore necessary 1) to establish pair-wise and/or multicast (sent to more than one recipient) key management relationships between the sender and receiver(s) and 2) to securely store the key(s) associated with encrypted e-mail until it is no longer necessary for a recipient to be able to decrypt or verify the integrity of the e-mail.

S/MIME is not restricted to e-mail; it can be used with any transport mechanism that employs MIME protocols, such as the Hypertext Transfer Protocol (HTTP).

S/MIME products can be implemented with different combinations of security features and a variety of cryptographic algorithms. Senders and receivers may have different capabilities and may be sending messages protected with algorithms of different strengths. This can lead to numerous interoperability issues. Federal clients using secure e-mail shall be able to perform the following:

Furthermore, federal systems shall:

Federal clients should be capable of sending and processing e-mail with security labels and securely binding senders’ certificates to their signatures through the signing certificate attribute as described in [RFC 5035].²²

The most widely accepted, standard S/MIME profile is [RFC 5751]. Not all cryptographic algorithms available for use in support of the features in the profile are appropriate for the protection of Federal Government information. The S/MIME specifications allow the selection of individual algorithms. However, a number of cipher suites have been specified to define a specific combination of algorithms. Federal organizations shall use approved algorithms within S/MIME implementations for key establishment and transmitting messages. Tables 5-1 through 5-3 specify a variety of cipher suites that may be used to protect federal information and information systems (based on [SP 800-49] and [RFC 6318]). Any of the algorithms listed in the following tables may be used, in accordance with security strength time frame restrictions given in Part 1 and [SP 800-131A] to protect federal information in combinations other than those displayed.

Table 5-1: Cipher Suite 1

Table 5-2: Cipher Suite B, Level 1*

*see [RFC 6318]

Table 5-3: Cipher Suite B, Level 2*

* see [RFC 6318]

Federal clients shall be supported by a Public Key Infrastructure with valid Federal PKI X.509 certificates for senders and receivers.

Cryptographic modules used in federal systems shall comply with FIPS 140-2 [FIPS 140-2].

Federal S/MIME implementations may, in accordance with organizational policies, be capable of receiving messages protected with algorithm suites that are not approved for federal use in sending protected messages. In those instances, users should be presented with a warning banner explaining that the cryptographic mechanisms used are weak and, therefore, that integrity and authentication cannot be assured.

The following recommendations are for any individual that makes a purchasing decision for acquiring an S/MIME-enabled component.

If an S/MIME client needs to generate a key pair, ensure that the S/MIME client or some related administrative utility or function is capable of generating public/ private key pairs on behalf of the user.

The system installer is the individual that installs the S/MIME application and performs the initial configuration of the system.

The System Administrator is the individual who runs the S/MIME application on a day-to-day basis and, on client implementations, interacts with the end user.

An end user is the individual using a client to access the system. Even within a centrally managed environment, end users may find that they have a significant amount of control over some of the security features within an SMIME implementation.

The Kerberos authentication mechanism was developed at the Massachusetts Institute of Technology (MIT) to enable the secure authentication of users to Target Servers (TSs) over an unprotected network, where client software acts on behalf of a user²⁴. The original design and implementation of Kerberos and its first three revisions (i.e., versions 1 through 4) was primarily the work of Steve Miller, Clifford Neuman, Jerome Saltzer and Jeffrey Schiller²⁵. Kerberos is used for local logins, remote (over the network) authentication, and for client-to-TS requests. It can also be extended to provide for the establishment of cryptographic keys between a client and a TS. Kerberos has been designed so that a user and a TS rely on a trusted third party to provide assurance of each party’s identity. This assurance is granted by means of tickets and authentication information, each encrypted with symmetric keys.

The trusted third party is a Key Distribution Center (KDC), which consists of an Authentication Server (AS) and a Ticket Granting Service (TGS). The AS and TGS may or may not reside on the same machine. The KDC has a database of user, TS, and TGS symmetric keys. All KDC symmetric keys are accessible by the TGS. The user’s key is normally created by hashing a user’s password with other information.

An overview of the Kerberos version 5 protocol is shown in Figure 6-1. The following is a simplification of the process (e.g., the generation of most keys and the use of most cryptographic operations are not specified). For example, tickets and authentication information are protected with checksums and encryption when transmitted.

The protocol may be extended to authenticate the TS to the user, and a ticket may be re-used within its validity period.

Figure 6-1: The Kerberos Protocol

Each TGS has its own “realm” of clients and TSs. However, different realms may be linked by the sharing of inter-realm keys between TGS's (see Figure 6-2). A client in Realm 1 wishing a service on a TS in Realm 2 may obtain a ticket from TGS1 that introduces the client to TGS2. This ticket is encrypted with the inter-realm key shared between TGS1 and TGS2. The client can then request a ticket from TGS2 for the desired service on the TS in Realm 2. Thus, realms may be networked to provide clients with inter-realm services.

AS

Realm1

TGS1

2 3 Realm1 5. Ticket Granting Ticket for TGS2

4

5

6

TGS2

Client

Realm2

Realm1

7

1

TS

8

Realm2

User

Figure 6-2: Cross-Realm Authentication

In an alternative Kerberos protocol between the client and the AS (as specified in [RFC 4556]), either both the user and the AS have key-establishment public key pairs with corresponding certificates, or the user has a key-establishment key pair and associated certificate, and the AS has a digital signature key pair and digital signature certificate. The user symmetric key can then be established between the client and the KDC in one of two ways:

Once the user symmetric key is established, the remainder of the protocol proceeds as previously described. In this case, the need for user symmetric keys generated from passwords can thus be avoided.

Kerberos implementations may provide an additional authentication capability that is called pre-authentication, as described in [RFC 6113]. TLS may also be implemented to protect all communication between the clients and KDCs as described in [RFC 6251].

The following recommendations are for any individual that makes a purchasing decision for acquiring a Kerberos capability.

The system installer is any individual(s) that installs a Kerberos capability and performs the initial configuration of the system.

The System Administrator is any individual(s) who runs a system with a Kerberos capability on a day-to-day basis and interacts with the end user.

An end user is the individual using the Kerberos capability.

A key management protocol has been specified for over-the-air rekeying of digital radios (OTAR) [OTAR]. This protocol has been designed to handle several types of cryptographic security, one of which, Type 3, has been designed for unclassified, sensitive communications and is discussed herein. The only differences between the security types are the cryptographic algorithms used and the security requirements. The Type 3 algorithms and security requirements are addressed in both OTAR and OTAR1 [OTAR1]³².

For key management, a secure mobile system consists of Key Management Facilities (KMFs) and mobile radios that are subordinate to each KMF. Key Management Messages (KMMs) are exchanged between each KMF and its subordinate mobile radios (see Figure 7-1). Cryptographic keys are transferred from a KMF to a mobile radio and protected using a key-wrapping algorithm and key wrapping key; many of the KMMs are protected by encrypting the data in the messages; the integrity of the messages is protected using a Message Authentication Code (MAC).

Figure 7-1: Radio Communications with OTAR

Three general types of keys are used in OTAR: a Key-Wrapping Key (KWK)³³, a Traffic-Encryption Key (TEK) and a key to be used for the computation of a Message Authentication Code (MAC).

Although the protocol has been designed to allow the use of any block cipher algorithm to apply the cryptographic protection, only three block cipher algorithms have been included in the specification: DES, TDEA and AES.

Approval for DES has been withdrawn because DES no longer provides the security that is needed to protect Federal Government information.

TDEA, as specified in [SP 800-67], uses three DES encryption/decryption operations with a “key bundle” consisting of three separate DES keys. Two versions of TDEA have been included in the OTAR specification: a one-key version, whereby all three keys are the same for compatibility with DES, and a three-key version (3-TDEA), whereby the three keys are different. Since DES is no longer considered secure, the one-key version of the TDEA is also no longer considered secure and shall not be used.

A Message Authentication Code (MAC) is used to authenticate and protect the integrity of many of the KMMs as specified in OTAR1, using the CBC-MAC mode of operation. The security of a MAC depends, in part, on the block size of the MAC algorithm. AES has a larger block size than 3-TDEA, and so the security of AES CBC-MAC is better than 3-TDEA CBC-MAC. The OTAR documentation provides no guidance on the length of cryptoperiods (i.e., the number of messages or the length of time that a key may be used before it must be changed).

For AES, the number of messages that can be authenticated using a given key is, in practice, not an issue. However, AES keys shall be periodically updated because of other threats to the system, e.g., lost radios or an undetected compromise of a key.

When using 3-TDEA, no more than 1 000 000 messages shall be sent using a given key because of threats to the security of the algorithm. However, like AES, it may be prudent to update the 3-TDEA keys more frequently because of other threats to the system.

Part 1 of this Recommendation states that keys shall be used for only one purpose.³⁴ However, OTAR1 states that the key used to generate a MAC must be either a key reserved for authentication and integrity protection purposes, or a key derived from a Traffic-Encryption Key (TEK) using a key wrapping algorithm. In this latter case, note that the TEK might be used for both encryption and for key derivation. In order to comply with the recommendation to use a key for only one purpose, the MAC key shall be a key reserved for a single purpose.

The KMF should backup all keying material shared with and among the mobile radios so that it can be recovered if necessary. When a key is no longer required, it should be deleted from both normal operational storage and backup storage.

Procedures shall be in place to rekey all radios in the network in the event of a key compromise. If a radio is lost, procedures shall enable rekeying other radios in the network so that the lost radio no longer has the capability of communicating securely with other radios in the network.

Keys shall be generated at the KMF using an approved random bit generator that provides sufficient randomness for the desired security strength of the cryptographic processes. NIST-approved random bit generation methods are specified in [SP 800-90A], [SP 800-90B] and [SP 800-90C] (under development).

The following recommendations are for any individual(s) that makes a purchasing decision for acquiring OTAR equipment.

The system installer is the individual(s) that installs an OTAR capability and performs the initial configuration of the system components.

The System Administrator is the individual who manages the OTAR system or its components on a day-to-day basis and interacts with the end users.

An end user is the individual using a radio that has an OTAR capability.

The Domain Name System (DNS), as defined in [RFC 1034] and [RFC 1035], is the global hierarchical distributed database system for mapping Internet addresses, Simple Mail Transfer Protocol (SMTP) servers, and other information to a human-readable name. Its main purpose is handling mappings between host domain names and Internet addresses, but it can handle other forms of data as well, such as host system information, the geographic location of servers, even encoded digital certificates. DNS data is stored as individual Resource Records (RRs) each associates a piece of data (e.g., IP address, mail server name) with a domain name and an identifying Resource Record type code (RR type). All the RRs for a particular organization are stored in an administrative unit called a zone. Multiple zones form a domain. A domain is hierarchical, in that one zone may act as a delegating parent to one or more child-delegated zones. For example, most federal agencies are child delegations under the “.gov” parent zone.

Zone information is maintained on authoritative servers, which are distributed all over the Internet to answer queries according to the DNS network protocols. The DNS infrastructure is comprised of a small group (or single server) known as a primary master authoritative server that has a local zone database, and multiple secondary servers that obtain their copies of the zone database from the primary authoritative master server. Another set of components are caching recursive servers³⁶, which query the authoritative servers and cache any replies. On the end user’s client system, software components known as resolvers make DNS queries to recursive caches and/or authoritative servers. Figure 8-1 depicts the relationship between the DNS components.

Figure 8-1: DNS Components

The basic DNS does not have many security features [SP 800-81]. A suite of RFCs has been developed to provide security enhancements contained in three IETF documents, collectively called the DNS security extensions (DNSSEC) ([RFC 4033], [RFC 4034], [RFC 4035]). DNSSEC provides a layer of authentication and integrity protection for any kind of data stored in the DNS, including data used by other protocols. For example, there are RR types allocated for storing Secure Shell (SSH) keys in the DNS, which then rely on DNSSEC to protect the integrity of that information.

Cryptographically generated public key-based digital signatures provide authentication for DNS data. Commonly, there will be two or more digital signature public-key pairs (which make up the key set) used to implement DNSSEC in a zone. One key pair is used to sign the zone data (referred to as the Zone Signing Key or ZSK), and a separate key pair is used to sign the zone key set (known as the Key Signing Key or KSK). While some zones may only use one key pair for both ZSK and KSK, it is not recommended for federal agency zones. This KSK is also known as the Secure Entry Point (SEP) key for the zone – using it, a client can authenticate the ZSK (by validating the signature over the ZSK using the KSK public key), and then use the ZSK to authenticate the zone data. The KSK is also used to link the security chain³⁷ from the zone to its delegating parent. Since the KSK is used to link security from the zone (e.g. “example.gov”) to the delegating parent zone (e.g. “.gov”) [RFC 4035], it is often longer lived, and used infrequently (used only to sign the zone key set). Multiple digital signature algorithms can be supported, so there may be multiple keys (one for each algorithm), as there is no algorithm negotiation in DNSSEC, and clients may only understand certain digital signature algorithms. There is one mandatory-to-implement algorithm as defined by the IETF, so there is at least one agreed-upon digital-signature algorithm that all servers and clients will understand.

Currently, both RSA using SHA-1 and SHA-256 have been specified and can be used with DNSSEC zones. Most modern implementations either support both or will do so after an upgrade. Zones deploying DNSSEC for the first time can start with RSA using SHA-256. Zones that initially deployed with RSA using SHA-1 should migrate to RSA (2048-bit RSA key) using SHA-256: see [SP 800-131A] for information about guidelines for using RSA with different key sizes and hash algorithms. However, both hash algorithms (i.e., SHA-1 and SHA-256) should be used to generate digital signatures for DNS data for a period of time to ensure that client systems that cannot validate RSA with SHA-256 can still authenticate DNS data. The length of this transition period depends on the widespread availability and deployment of client-system software that understands RSA with SHA-256.

Additional authentication mechanisms are used for server-server communication and administrative control. Transaction authentication is performed by computing an HMAC over the entire DNS message and a secret random string that is known by both authoritative DNS servers in the transaction, and transmitting the result in a Transaction Signature (TSIG) RR appended to the original message. Transaction authentication is usually used for special transactions, such as zone transfers or dynamic updates. A zone transfer is a special query type that is used to keep secondary authoritative servers up-to-date with the most recent version of the zone data. Dynamic update is a feature that allows an authorized administrator to add or delete DNS data by sending a specially formatted message. This is frequently used in local area networks where the Dynamic Host Configuration Protocol (DHCP) is used to assign IP addresses dynamically. The DHCP server may update the DNS server by sending a dynamic update message to reflect network changes.

The currently defined algorithms used in TSIG authentication are HMAC using SHA-1 and the SHA-2 family of hash algorithms (SHA-224, SHA-256, SHA-384 and SHA-512). The use of SHA-1 is acceptable for current security practices when using HMAC with a suitably random secret string. All DNS server administrators taking part in the transaction must agree on which algorithm and secret string size will be used for transaction authentication and must ensure that all parties have the same secret random string (which may include out-of-band transactions to distribute keys).

DNS does not support algorithms in isolation, but specifies suites of algorithms and schemes. Algorithm/scheme combinations for zone data signing and for message authentication are provided in Table 8-1 ([RFC 6944], [RFC 6605]) and Table 8-2 ([RFC 3645], [RFC 4635]):

Table 8-1: Recommended Algorithm and Scheme Combinations for Zone Data Signing

Table 8-2: Recommended Message Authentication Algorithms

It should be noted that HMAC-MD5.SIG-ALG.REG.INT is a suite that is widely implemented and often set as the default choice. However, it shall not be used for federal implementations. Since TSIG message authentication is used between servers where there is an existing trust relationship, the administrators must agree on the method used and the secret (random) string used with the TSIG method.

Due to message size constraints (See Section 8.1.4 below), large RSA keys may result in DNS transaction failures that are often interpreted by clients as DNS failures. It is recommended that, instead, a digital signature algorithm that has the same security strength, but with smaller sized keys be used, such as ECDSA [RFC 6605]. It is recommended that DNS administrators plan to migrate to ECDSA for zone signing by October 1, 2015, or plan to migrate earlier as soon as it becomes available in DNS software components.

There are some special considerations needed when choosing the size of the RSA DNSSEC signing keys. Early deployments have shown that large RSA keys can result in protocol issues, such as response messages that are too large to fit in a standard UDP packet. DNSSEC requires the use of larger DNS packet sizes up to 4 KB, but practical limits are around 1500 bytes or less.

It is recommended that DNS administrators maintain 1024-bit RSA/SHA-1 and/or RSA/SHA-256 ZSK’s until October 1, 2015, or until it is proven that the majority of routers, caches and other network middle boxes can handle packet sizes over 1500 bytes (if before 2015). However, 1024-bit RSA keys are allowed until the 2015 date to accommodate older versions of DNS clients that may be older network components that cannot handle UDP packets with sizes over 1500 bytes. This is an exception to the security guidance provided in [SP 800-131A]. However, this exception on RSA key sizes does not apply to Key Signing Keys. KSK’s shall follow the guidance set in Part 1 of this Recommendation [SP 800-57 Part 1].

It is recommended that zone administrators migrate DNSSEC zone signing algorithms to ECDSA by 2015 or when support for ECDSA appears in DNSSEC components, whichever is sooner.

To minimize the risk when using 1024-bit RSA ZSK’s with DNSSEC, ZSK’s should be changed more frequently: every one to three months, with a signature validity period of five to seven days. The ZSK-rollover sequence discussed in [SP 800-81] is recommended to maintain a valid chain of authentication in DNS data.

There is a special variant to DNSSEC that minimizes the risk of information leakage and is known as the Hashed Next Secure (NSEC3) RR [RFC 5155]. In DNSSEC, a client can map the contents of the zone by sending a series of queries for the Next Secure (NSEC) RR type found in error messages. These NSEC RRs provide signed proof that the queried name did not exist, but also provides two names that do exist in the zone as part of that proof. NSEC3 attempts to minimize this information leakage of zone names by using the hash values of the two existing names (currently using SHA-1 only). However, this requires the server and client to be able to perform multiple SHA-1 hash calculations during runtime; note that this method could be used to mount a Denial of Service attack against the server if multiple requests are made.

NSEC3 was designed to solve a specific class of information leakage that could lead to a complete mapping of network resources in a DNS zone. NSEC3 deployment risks are often greater than the usefulness provided by using NSEC3, unless there is an overriding need to deploy NSEC3 beyond zone content protection (examples include protecting personally identifying information that may be contained in the DNS). However, it is a good idea to use NSEC3-aware client software, because a client may access a zone that uses NSEC3 RRs with DNSSEC.

System installers and administrators should develop a transition plan to migrate from SHA-1 to SHA-256, and to do so when SHA-256 becomes available in major software distributions. This would involve deploying both SHA-1 and SHA-256-based NSEC3 RRs until it is observed that SHA-256-aware implementations have become widely used in the Internet community.

TSIG-shared secret strings should be random for use in providing integrity protection for DNS message transactions, and generated at appropriate security strengths. The system installers using the TSIG secret string shall agree on which TSIG algorithm to use.

The following recommendations are for any individual that makes a purchasing decision for acquiring DNSSEC-capable components for their network infrastructure.

The system installer is the individual(s) that installs a DNS component and performs the initial configuration of the component.

The System Administrator is the individual who runs the DNS application on a day-to-day basis and interacts with the end user.

An end user is the individual using a client to access the system.

The encryption of data files and complete disk volumes presents a somewhat different set of key management issues than those for encryption of network-communicated data. While network communications security focuses on the privacy and integrity of information in transit, storage (e.g., file) security focuses on the privacy and integrity of persistent data and the secure sharing of this data. The key management guidance surrounding file and volume encryption are sufficiently similar to consolidate into a single section.

Unlike the previous sections, where the protocols and/or standards have been thoroughly studied by the network security community, the commercial solutions for file encryption utilize a wide variety of security schemes and methods for storing keys. Due to this range of solutions, this section will not be comprehensive, but will cover a variety of methods used for file encryption.

The most important questions that designers of a file encryption system must answer are:
• How are keys used in the system, and what protection are they afforded?
• Where are the keys stored on the system?
• Does the method scale upward for numerous user communities (without requiring an impractical number of keys to be stored)?

For an Encrypted File System, keys are used to encrypt a file or group of files. The system can either encrypt each file with a distinct symmetric key or encrypt a set of files using the same symmetric key. In the first case, it is very easy to provide access to a sharing user, for example, by simply giving the key to that user. In this way, only that single file can be accessed by the sharing user without providing access to any of the other files in the system. The drawback with this first method is that if many files are encrypted, the model can quickly become unwieldy, since a key is required for each encrypted file and must be provided to the sharing user.

In the second case, many fewer keys are required, which eases the key distribution process. However, when a sharing user requires access to a single file, giving access to that user is more problematic. By simply sending a key to the sharing user, access would be provided to all of the owner’s⁴⁰ files that were encrypted using that key, rather than to the single file.

However, there are several cryptographic management actions that could be used to grant access to an individual file in the second case above. One option to limit access in this second system is for the owner or system to decrypt the file and re-encrypt it using a new key for transmission to the sharing user (e.g., using network security mechanisms and session keys). In the increasingly rare case of both users sharing a common file server, the decrypted and re-encrypted file would be placed in the sharing user’s file space. This would require significant processing overhead and a key management protocol for exchanges between the owner and the sharing user, or between the file system management process and the sharing user. This process requires proper protection for these new keys at the same security strength as the original key protecting that file.

Another option is for the sharing user to be provided with the encrypted file and the owner’s decryption key that could be used to decrypt all of the owner’s files, including the one provided to the sharing user. System overhead is reduced, and it may be possible to protect the key from third-party administrators, but it is unlikely that the owner would agree that the requester should be granted access to all files protected under the common key.

Having provided more extreme examples in the previous two cases, the following is a more common approach that is used. In this case, each user on the system has an asymmetric key pair. Each owner’s file is encrypted under a different randomly generated symmetric File Encrypting Key (FEK). The FEK is then encrypted using the public key of the owner and stored with the encrypted file. When the owner of a file wants to share it with another user, the owner decrypts the encrypted FEK (using her private key) and then encrypts the FEK using the sharing user’s public key. The encrypted file and re-encrypted FEK can then be provided to the requester. This system has several advantages. First, the owner needs to manage only a single asymmetric key pair. Second, it permits easier file sharing between users. Third, it is very efficient because files do not have to be re-encrypted in order to be shared. Finally, the system need not manage any keys separately, since the asymmetric keys are managed by the owners, and the FEKs are stored in encrypted form with the files.

The owner can, of course, use different keys to encrypt different files or sets of files. The fewer files that the owner chooses to encrypt with a given key results in more keys and associations (e.g., associations of keys with file identities, file groups, individual identities, or access groups) that would need to be maintained.

Another important concept within an encrypted file system that must be considered is how data recovery is implemented. If a user loses his keys, without a data recovery capability within the system, the user’s data is permanently lost. As such, it is vital that some form of data recovery, such as master administrator passwords, be included.⁴¹ This requires a file encryption system that allows multiple passwords to decrypt the file, one of which is provided to the user, and the second is provided to the administrator, in the form of a master administrator password. Another possibility is that the administrator has a method of storing the user’s passwords for use only when the user has lost or forgotten their password.

When the scope of the system expands from a pair of individuals to a large network or internet-work, the factors associated with the management of keys can become unwieldy. Key management challenges associated with large systems include the following:

After the decision has been made about the number of files to be protected with a single symmetric key, key management questions can be considered. How does the File Encryption System generate the encryption keys? How will the keys be stored and protected? This section identifies common ways of answering these questions, as well as discussing their strengths and weaknesses. As technology advances, additional techniques will be developed, and as such, the list below is not complete nor should be considered mandatory.

Consider common answers to the important questions above. First, how do file encryption systems generate symmetric keys? A simple method is to derive the key from a password as described in [SP 800-132]. In this case, the security of the system depends on the randomness of the password; normally, passwords do not contain enough randomness to be used for generating keys (i.e., they can be guessed relatively easily). A standard dictionary attack can often recover weak passwords, so a strong password is vital for the security of this type of system. It is preferable to utilize a good random bit generator within the system to generate keys. Approved random bit generators can be found in [SP 800-90A], [SP 800-90B] and [SP 800-90C].

Next, consider the question of how to protect the keys. There is a great deal of effort underway by the Trusted Computing Group (TCG) to develop secure storage of keys on computers. As this effort continues to mature, the Trusted Platform Module chip, through its key cache management, offers another format for protecting keys used in EFS.

Then, consider where these keys will be stored. If keys need to be stored, they could simply be stored on the computer itself or on a hardware token. Alternatively, the key could be split into two (or more) key components with, for example, one component stored on a hardware token and the other key component stored on the computer itself. If a split key is employed, the method used to combine the key components is important; performing an XOR operation on equal length key components is better than simply concatenating the components. Common hardware tokens include smartcards. The advantage of using a hardware token is that if the user stores the hardware token away from the computer, and the key is split between the token and the computer, an adversary needs to recover both pieces of hardware to recover the key. Additional security may be provided by encrypting the key splits, perhaps by using a password.

There are many permutations of answers to the questions above. Four examples of how these questions can be answered will be considered, along with the pros and cons of each system. It is important to consider the specific environment in which the File Encryption System will be used, as that will usually point to a specific type of system that is preferable for that case.

The first example that will be considered is a file encryption system that uses a single symmetric key to encrypt every file on the system. This single key is generated using a method in [SP 800-132] from a user’s password.

The second example is a system that utilizes per-file encryption keys, which are stored on the hard disk, encrypted by a key encryption key. The key encryption key (which is also used to decrypt each file encryption key) is securely stored on the hard drive (e.g., using the Trusted Platform Module (TPM) [TPM]).

The third example is a system that utilizes per-file encryption keys that are split into two key components that will be XORed to recreate the key, with one key component stored on a hardware token and the other component derived from a password (e.g., using a method in [SP 800-132] to derive the key).

The fourth example uses per-file encryption keys, which are encrypted under the file owner’s asymmetric private key as previously described. This system is common in current file-encryption packages, while the previous three are extreme to show the pros and cons of the systems more clearly.

Table 9-1: Summary of File Encryption Examples

The following recommendations are for any individual(s) that makes a purchasing decision for acquiring an EFS component.

The system installer is the individual(s) that installs EFS components and performs the initial configuration of the components.

The system administrator is the individual that manages the EFS on a day-to-day basis and interacts with the end user.

An end user is the individual that uses the EFS to secure and share their information.

SSH is a protocol between clients and servers for secure remote login and other secure network services over an insecure network or the Internet. The Internet Engineering Task Force (IETF) governs the SSH protocol [RFC 4251]⁴². The SSH protocol consists of three major components: the Transport Layer Protocol [RFC 4253], the User Authentication Protocol [RFC 4252] and the Connection Protocol [RFC 4254].

The Transport Layer Protocol (TLP) provides server authentication, confidentiality, and integrity with perfect forward secrecy⁴³. The establishment of an SSH connection is initiated using the TLP, which negotiates the algorithms to be used and authenticates the server. TLP does not provide client authentication.

The algorithm-negotiation step of the protocol is used to determine the algorithms to be used by the client and server for key agreement (called key exchange in the protocol), server authentication, encryption and data integrity. The encryption and data-integrity algorithms that protect communications from the client to the server and from the server to the client are independently selected, i.e., the encryption algorithm protecting communication from the client to the server may be different than the encryption algorithm protecting communication from the server to the client.

After the algorithm negotiation is completed, the TLP authenticates the server to the client in a key-exchange process [RFC 4253, Sec. 8]) that provides keys and IVs for the selected cryptographic algorithms. The key-exchange process provides assurance that the server is the owner of the public key, but additional steps may be required to verify the server’s identity; see Section 10.2.1.2 for a discussion on the verification of the server’s public host key.

The protocol provides data- integrity protection by choosing a MAC algorithm for each communication direction between the server and the client. However, the protocol also allows this service (i.e., data-integrity protection) to be disabled.

The User Authentication Protocol authenticates the client to the server. After the TLP is completed, the server and the client communicate using an encrypted SSH tunnel⁴⁴ that uses the selected encryption algorithm(s) from the negotiation process and the keys from the key exchange (see the SSH TLP protocol discussion in Section 10.1.1). Using the encrypted SSH tunnel, the server can securely perform any client authentication. The UAP provides a single authenticated tunnel for the SSH connection protocol.

The Connection Protocol [RFC 4254] multiplexes the encrypted tunnel used by SSH into several logical channels. The CP defines how interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections [X11] can be run simultaneously over an established SSH Transport Layer and User Authentication connection.

In this step of the TLP, the algorithms to be used for the key exchange (i.e., key agreement), public key authentication, data encryption and message authentication are selected.