NIST Special Publication 800-57

RECOMMENDATION FOR KEY 

ENT 

Part 3: Application-Specific Key 

Management Guidance 

ine Barker 

illiam Burr 

licia Jones 

Timothy Polk 

Scott Rose 

Miles Smid 

MANAGEM

Ela

W

A

1
NIST Special Publication 800-57 

RECOMMENDATION FOR KEY 

ENT 

Part 3: Application-Specific Key 

Management Guidance 

Elaine Barker 

William Burr 

Alicia Jones 

Timothy Polk 

Scott Rose 

National Institute of Standards and Technology 

Miles Smid 

Orion Security Solutions

DRAFT – August 2008 

U.S. Department of Commerce 

Carlos M. Gutierrez, Secretary 

National Institute of Standards and Technology 

Patrick Gallagher, Acting Director 

MANAGEM

2
Abstract 

ce. It consists 

anagement of 

 availability; 

graphic key; 

aphic module; digital signature; key management; key management policy; key 

recovery; private key; public key; public key infrastructure; security plan; trust anchor; 

validation. 

Special Publication 800-57 provides cryptographic key management guidan

of three parts. Part 1 provides general guidance and best practices for the m

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. 

KEY WORDS: accreditation; assurances; authentication; authorization;

backup; certification; compromise; confidentiality; cryptanalysis; crypto

cryptogr

3
Acknowledgements 

owledges and 

by Chris Bean 

and private sectors whose thoughtful and constructive comments improved the quality 

and usefulness of this publication. 

The National Institute of Standards and Technology (NIST) gratefully ackn

appreciates contributions by Quynh Dang and Sheila Frankel of NIST and 

of the National Security Agency. NIST also thanks the many contributions by the public 

4
Authority 

rds and Technology 

er the Federal Information 

minimum 

y operations and 

 systems. 

ent and 

130, Section 8b(3), Securing Agency Information Systems, as 

mental information is 

used by 

 copyright. 

ade 

r superseding 

B, or any other 

d in this 

Validation Program (CMVP), a joint effort of NIST and the Communications Security 

Establishment of the Government of Canada. Cryptographic implementations must 

adhere to the requirements in this Recommendation in order to be validated under the 

CMVP. The requirements of this Recommendation are indicated by the word “shall.” 

This document has been developed by the National Institute of Standa

(NIST) in furtherance of its statutory responsibilities und

Security Management Act (FISMA) of 2002, Public Law 107-347. 

NIST is responsible for developing standards and guidelines, including 

requirements, for providing adequate information security for all agenc

assets, but such standards and guidelines shall not apply to national security

This guideline is consistent with the requirements of the Office of Managem

Budget (OMB) Circular Aanalyzed in A-130, Appendix IV: Analysis of Key Sections. Supple

provided in A-130, Appendix III. 

This guideline has been prepared for use by Federal agencies. It may be 

nongovernmental organizations on a voluntary basis and is not subject to

(Attribution would be appreciated by NIST.) 

Nothing in this document should be taken to contradict standards and guidelines m

mandatory and binding on Federal agencies by the Secretary of Commerce under 

statutory authority. Nor should these guidelines be interpreted as altering o

the existing authorities of the Secretary of Commerce, Director of the OM

Federal official. 

Conformance testing for implementations of key management as specifie

Recommendation will be conducted within the framework of the Cryptographic Module 

5
Overview 

endation for 

ystem 

organizational 

ents. The guide also 

tion for end users regarding application options left under their control 

in normal use of the application. Recommendations are given for a select set of 

et Protocol Security (IPsec) 

ons (S/MIME) 

 (OTAR) 

SEC) 

s (EFS) 

Section 10 – Secure Shell (SSH) 

orithm suites and key sizes and associated security and 

cerning the use of the mechanism in its current form for the 

key 

management processes, 

• General recommendations for purchase decision makers, system installers, system 

administrators and end users. 

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. 

“Application Specific Key Management Guidance”, Part 3 of the Recomm

Key Management is intended primarily to help system administrators and s

installers adequately secure applications based on product availability and 

needs and to support organizational decisions about future procurem

provides informa

applications, namely: 

Section 2 - Public Key Infrastructures (PKI) 

Section 3 - Intern

Section 4 – Transport Layer Security (TLS) 

Section 5 - Secure/Multipurpose Internet Mail Extensi

Section 6 – Kerberos 

Section 7 - Over-the-Air Rekeying of Digital Radios

Section 8 - Domain Name System Security Extensions (DN

Section 9 – Encrypted File System

Section 11 – IEEE 802.1x Port Based Network Access Control 

The following is provided for each topic: 

• A brief description of the system under discussion that is intended to provide 

context for the security guidance, 

• Recommended alg

compliance issues, 

• Recommendations con

protection of Federal government information, 

• Security considerations that may affect the security effectiveness of 

6
EMENT 

............. 10

.1 .................... 10 

.................... 11 

.................... 12 

.................... 12 

.................... 13 

.................... 14 

.................... 15 

17

.................... 17 

.................... 20 

.................... 20 

.................... 23 

.................... 23 

.................... 24 

.................... 25 

.................... 25 

.................... 25 

.................... 26 

.................... 26 

.................... 27 

.................... 28 

.................... 28 

.................... 28 

.................... 29 

.................... 29 

................. 29 

.................... 30 

.............. 32

.1 .................... 32 

3 ....................................... 33 

.................... 33 

.................... 39 

3.3 Procurement Guidance...................................................................................................... 39 

3.4 Recommendations for System Installers........................................................................... 40 

3.5 Recommendations for System Administrators................................................................. 40 

3.6 Recommendations for End Users...................................................................................... 40 

4 Transport Layer Security (TLS) and Secure Socket Layer 

(SSL)......................................................................................................... 41

4.1 Description........................................................................................................................ 41 

RECOMMENDATION FOR KEY MANAG

Part 3: Application-Specific Key Management Guidance 

Table of Contents 

1 Introduction ..........................................................................

1 Purpose..........................................................................................................

1.2 Requirement Terms.......................................................................................

1.3 General Protocol Considerations..................................................................

1.3.1 Mandatory-to-Implement versus Optional-to-Implement.............................

1.3.2 Cryptographic Negotiation............................................................................

1.3.3 Single or Multi-Use Keys.............................................................................

1.3.4 Algorithm and Key Size Transition ..............................................................

2 Public Key Infrastructure..................................................................

2.1 Description....................................................................................................

2.2 Security and Compliance Issues ...................................................................

2.2.1 Recommended Key Sizes and Algorithms ...................................................

2.3 Procurement Guidance..................................................................................

2.3.1 CA/RA Software and Hardware: ..................................................................

2.3.2 OCSP Responders:........................................................................................

2.3.3 Cryptographic Modules ................................................................................

2.3.4 Key Recovery Servers...................................................................................

2.3.5 Relying Party Software .................................................................................

2.3.6 Client Software .............................................................................................

2.4 Recommendations for System Installers/Administrators..............................

2.4.1 Certificate Issuance.......................................................................................

2.4.2 Certificate Revocation Requests...................................................................

2.4.3 Certificate Revocation List Generation ................................................. ..... . .

2.4.4 PKI Repositories for the Distribution of Certificates and CRLs ..................

2.4.5 OCSP Responders.........................................................................................

2.4.6 Backup and Archive......................................................................................

2.4.7 Relying Party Integration and Configuration...................................................

2.5 User Guidance (Subscribers) ........................................................................

3 IPsec..................................... ............................................... .

3 Description....................................................................................................

.2 Security and Compliance Issues ................................................

3.2.1 Cryptographic Algorithms............................................................................

3.2.2 Additional Recommendations.......................................................................

7
4.2 Security and Compliance Issues ....................................................................................... 42 

.................... 42 

.................... 44 

.3 .................... 47 

.4 .................... 49 

.................... 50 

.................... 50 

.............. 51

.................... 51 

.2 .................... 51 

.3 .................... 55 

.................... 55 

.................... 56 

.6 .................... 57 

.............. 58

.1 .................... 58 

.2 .................... 61 

6 ................................. 62 

.................... 62 

.................... 63 

.6 .................... 64 

ges 

.............. 65

.................... 65 

.................... 66 

.................... 66 

.................... 66 

.................... 67 

.................... 67 

7 .................... 67 

.................... 67 

.................... 67 

.................... 68 

.................... 68 

............... 69 

.......... 70

.1 .................... 70 

.................... 71 

.................... 72 

8.1.3 DNS Cryptographic Algorithms/Schemes, Modes and Combinations............................. 72 

8.1.4 Special Considerations for NSEC3................................................................................... 73 

8.2 Security/Compliance Issues.............................................................................................. 74 

8.3 Procurement Guidance...................................................................................................... 74 

8.4 Recommendations for System Installers........................................................................... 75 

8.4.1 Recommendations for System Installers (Authoritative Servers)..................................... 75 

8.4.2 Recommendations for System Installers (Caching Recursive Servers)............................ 75 

4.2.1 General..........................................................................................................

4.2.2 Recommended Cipher Suites for Federal Government Use .........................

4 Procurement Guidance..................................................................................

4 Recommendations for System Installers.......................................................

4.5 Recommendations for System Administrators.............................................

4.6 Recommendations for End Users..................................................................

5 Secure/Multipart Internet Mail Extensions (S/MIME)........

5.1 Description....................................................................................................

5 Security and Compliance Issues ...................................................................

5 Procurement Guidance..................................................................................

5.4 Recommendations for System Installers.......................................................

5.5 Recommendations for System Administrators.............................................

5 Recommendations for End Users..................................................................

6 Kerberos...............................................................................

6 Description....................................................................................................

6 Security and Compliance Issues ...................................................................

.3 Procurement Guidance.....................................................................

6.4 Recommendations for System Installers.......................................................

6.5 Recommendations for System Administrators.............................................

6 Recommendations for End Users..................................................................

7 Over-The-Air Rekeying (OTAR) Key Management Messa

(KMMs) .......................................................................................

7.1 Description....................................................................................................

7.2 Security and Compliance Issues ...................................................................

7.2.1 Cryptographic Algorithms............................................................................

7.2.2 Message Authentication and Cryptoperiods.................................................

7.2.3 Key Usage.....................................................................................................

7.2.4 Backup ..........................................................................................................

.2.5 Rekeying .......................................................................................................

7.2.6 Random bit generators..................................................................................

7.3 Procurement Guidance..................................................................................

7.4 Recommendations for System Installers.......................................................

7.5 Recommendations for System Administrators.............................................

7.6 Recommendations for End Users.......................................................................

8 Domain Name System Security Extensions (DNSSEC).......

8 Description....................................................................................................

8.1.1 DNS Data Authentication .............................................................................

8.1.2 DNS Transaction Authentication..................................................................

8
8.4.3 Recommendations for System Installers (Client Systems)............................................... 76 

.................... 76 

.................... 76 

.................. 76 

.................... 76 

.................... 77 

.............. 78

.................... 78 

.................... 78 

.................... 80 

.2 .................... 82 

.3 .................... 82 

.................... 83 

.................... 83 

.................... 83 

.............. 85

.............. 85

.............. 86

Appendix B: Acronyms.......................................................................... 94

Appendix C: A Word to Novice End Users........................................... 96

Appendix D: References........................................................................ 98

8.5 Recommendations for System Administrators.............................................

8.5.1 Recommendations for System Administrators (Authoritative Server).........

8.5.2 Recommendations for System Administrators (Caching Recursive Servers)

8.5.3 Recommendations for System Administrators (Client Systems)..................

8.6 Recommendations for End Users..................................................................

9 Encrypted File Systems (EFS) ...........................................

9.1 Description....................................................................................................

9.1.1 Number of Keys Required ............................................................................

9.1.2 Access to Symmetric Keys used in File Encryption.....................................

9 Security and Compliance Issues ...................................................................

9 Recommendations for Procurement Officials...............................................

9.4 Recommendations for System Installers.......................................................

9.5 Recommendations for System Administrators.............................................

9.6 Recommendations for End Users..................................................................

10 Secure Shell (SSH)..............................................................

11 IEEE 802.1x ..........................................................................

Appendix A: Glossary..............................................................

9
RECOMMENDATION FOR KEY MANAGEMENT 

Part 3: Application-Specific Key Management Guidance

duction 

ic Key 

es associated 

rt 1 of the 

idance for 

 the 

ion, provides a 

framework and general guidance to support establishing cryptographic key management 

cts of statutory 

rganizations. 

 installers, system 

ctures, protocols, and 

ew systems 

logy. Note that end users who act as their own system 

ended for 

rity policy that acts as 

ser guidance. 

a and data in 

l not provide a complete restatement of existing standards or 

detail are 

anagement infrastructures, protocols, and applications addressed in 

tended to provide 

urity guidance, 

• Recommended algorithm suites and key sizes and associated security and 

• Recommendations concerning the use of the mechanism in its current form for the 

protection of Federal government information, 

• Security considerations that may affect the security effectiveness of key 

management processes, 

 

1 Intro

1.1 Purpose 

Part 3 of the Recommendation for Key Management, Application-Specif

Management Guidance, is intended to address the key management issu

with currently available cryptographic mechanisms. General Guidance, Pa

Recommendation for Key Management, contains basic key management gu

users, developers and system managers regarding the "best practices" associated with

generation and use of the various classes of cryptographic keying material. General 

Organization and Management Requirements, Part 2 of the Recommendat

within an organization, and a basis for satisfying the key management aspe

and policy-based security planning requirements for Federal government o

This document, Part 3 of the Recommendation, is designed for system

administrators and end users of existing key management infrastru

other applications, as well as the people making purchasing decisions1

 for n

using currently available techno

installers, administrators and purchasing agents may find the guidance int

administrators, installers and purchasers to be beneficial. In centrally managed 

organizations, the organization’s management must establish a secu

a foundation for all end u

Recommendations are made for mechanisms designed to protect stored dat

transit. This document wil

implementation directives. Standards and guidelines with this level of 

referenced where appropriate. 

For each of the key m

Part 3, the following is provided: 

• A brief description of the system under discussion that is in

context for the sec

compliance issues, 

1

 This is not necessarily a procurement officer but likely a person making the decision on the IT product to 

be used. 

10
• General recommendations for purchase decision makers, system installers, system 

administrators and end users. 

within a given 

nd the scope 

andled by 

stem administrators. For 

end users faced with these tasks on their own, an informative appendix has been included 

rection. 

is 

uidance 

 infrastructures, 

t will be updated as 

comprehensive view of 

 to version numbers or 

aluation of the 

d. 

se by U.S. 

ented prior 

w all of the 

principles identified in Part 1. The use of current implementations of these applications 

more carefully designed applications are available. It is very 

dards and 

ed for associated risks and that steps be taken to mitigate those risks. 

e following 

l Information 

st be fulfilled to claim 

ay be coupled with not to 

n. Ignoring the 

endation could result in undesirable results. Ignoring recommendations to 

accommodate the acceptance of messages protected with commonly used, 

unapproved ciphers may create interoperability issues. Ignoring 

recommendations to select new products with approved, seldom used 

cryptographic mechanisms may leave an organization ill-prepared to migrate 

away from mechanisms that will soon be inappropriate for the protection of 

Federal systems. Note that should may be coupled with not to become should 

not. 

The logistics of how one should obtain, store or transfer keys or key pairs 

application or system are application and implementation-specific and beyo

of this document. In large Federal systems, these functions are frequently h

system administrators or completed with direct guidance from sy

with general information intended to point the end user in the right di

Since some of the infrastructures, protocols and applications addressed in th

Recommendation will be refined or replaced over the next few years, the g

provided herein will become obsolete. Similarly, it is anticipated that new

protocols, and applications will be developed. Although this documen

mechanisms and techniques evolve, it may not always reflect a 

current products and technical specifications. Hence, references

other implementation status information are provided to enable an ev

applicability of particular elements of guidance to the specific version of an

infrastructure, protocol, or application into which a mechanism is integrate

Note that many of the applications described in Part 3 are currently in u

government agencies. Some of these applications were developed and implem

to the release of Part 1 of this Recommendation, and therefore, may not follo

may be necessary until 

important that each implementation that does not comply with NIST stan

guidelines be evaluat

1.2 Requirement Terms 

This Recommendation often uses “requirement” terms; these terms have th

meaning in this document: 

1. shall: This term is used to indicate a requirement of a Federa

Processing Standard (FIPS) or a requirement that mu

conformance to this Recommendation. Note that shall m

become shall not. 

2. should: This term is used to indicate an important recommendatio

recomm

11
1.3 General Protocol Considerations 

There are a number of general issues associated with the protocols discuss

Four of these issues are briefly discussed in order to familiarize th

that will be repeated throughout the docu

ed in Part 3. 

e reader with concepts 

 to help frame the upcoming 

plement, 

• Single or multi-use keys, and 

ent are based on 

tandards (e.g., IETF RFCs, American National Standards, etc.). In these 

ment or optional-tocurity of the 

 public 

at may 

s for a variety 

upgrades, to issues 

, an algorithm that is optional-to-implement within an 

odule. 

cantly increase 

 products that 

mation about 

works. As 

2) that do not 

hey shall not be used. Similarly, 

there may be optional-to-implement algorithms that have greater security (e.g., AES) and 

which this document may say 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. 

ment and

discussions: 

• Mandatory-to-implement vs. optional-to-im

• Cryptographic negotiation, 

• Algorithm and key size transitions. 

1.3.1 Mandatory-to-Implement versus Optional-to-Implement 

Many of the cryptographic security services described in this docum

public s

standards, algorithms are frequently described as mandatory-to-imple

implement. Neither of these terms provides information about the se

algorithm. 

Mandatory-to-implement algorithms will be in any product that meets the

standards, allowing interoperability between products. 

Optional-to-implement algorithms tend to be next-generation algorithms th

become mandatory-to-implement algorithms in a future version of the standard. There 

could be considerable delay in the widespread use of these new algorithm

of reasons, ranging from a need for supporting hardware or software 

of interoperability. For example

S/MIME protocol may not currently be supported by the system’s cryptographic m

However, these algorithms often offer improved security that could signifi

the longevity of the system. Therefore, one may want to consider buying

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 infor

whether algorithms have adequate security for use on Federal computer net

such, there may be mandatory-to-implement algorithms (e.g., DES or RC

provide adequate security, and this document will say t

12
1.3.2 Cryptographic Negotiation 

Parts 1 and 2 of this Recommendation establish a sound basis for selecting 

cryptographic algorithms and managing the corresponding cryptograph

enforcing these guidelines can be problematic for a number of reasons, in

unavailability of certain algorithms or key sizes, the preferences of the parti

communication or other system limitations. Wh

appropriate 

ic keys. However, 

cluding the 

es in 

en servers dictate the algorithms used, 

the server may select the algorithms that optimize overall system performance rather than 

the same 

ithin the 

ect the 

n this case, as in 

ay be presented 

iving client 

pted using 

ot necessarily 

nternet), but 

eceiving 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 

ment and 

priate course of 

e server chooses 

e proposed list during a negotiation phase of the protocol. Where negotiation is 

tiate each 

h a situation 

orithms of the 

ithms are not 

available. 

ms, but not key 

pproved 

A signatures, 

the client might get a message signed with a 512-bit RSA key3

. 

plicated by system or 

on-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 

 

the algorithms that provide the highest level of security. 

In some multi-party protocols where multiple algorithms are supported for 

purpose, a client can enforce the rules in Parts 1 and 2 through negotiation w

protocol. Some protocols (e.g., S/MIME) allow the initiating client to sel

cryptographic algorithms without negotiating with the receiving client. I

the case where applications do not permit negotiation, a receiving client m

with information that has been inadequately protected. For example, a rece

may receive a signed and encrypted S/MIME email message that was encry

DES and signed with a 512-bit RSA key2

. Rejecting such messages does n

enhance security (in this case, the message has already been sent over the I

the r

be appropriate to reject the message or terminate the protocol. A risk assess

subsequent organizational policy may be required to determine the appro

action. 

In other protocols (e.g., TLS), the client proposes a set of options, and th

from th

supported, protocols may be designed to negotiate cipher suites or to nego

algorithm independently. In either case, a client or server may be faced wit

where the preferred algorithms of the client or server and the proposed alg

other party are not of the same security strength, or where approved algor

Another issue may arise when a protocol is designed to negotiate algorith

sizes. In such a case, the clients may find themselves communicating with a

algorithms, but inadequate key sizes. For example, after negotiating for RS

Enforcing the recommendations from Parts1 and 2 may also be com

application design decisions. Systems may have applicati

2

 The DES algorithm and the 512-bit RSA key size do not provide adequate security (see Part 1). 

3

 A 512-bit RSA key does not provide an acceptable security strength (see Part 1). 

13
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 CA keys. (See Section 2.1). 

s available for a given communication 

ssed: 

echanisms to be 

m proposed 

ty for the negotiation: just algorithms, both algorithms and 

ersions? 

etting would be to: 

 suited for 

adequate level of 

opt a policy explaining how to respond to messages received without adequate 

protection, and 

ining what to do when faced with a need for secure 

dequate key 

should not

ses, the same keys 

eying material 

ce). It is less clear as 

a specific 

 signing e-mail 

cation to share 

keys with other applications. In other cases, sharing keys may not be desirable. For 

sed to support 

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

When there are a variety of algorithms or key size

protocol, the following questions need to be addre

• Is negotiation mandatory, optional or unsupported? 

• When negotiation is supported, who proposes the cryptographic m

used, who selects the mechanisms, and what are the selection criteria? 

• Is negotiation based on predefined cipher suites, or is each algorith

independently? 

• What is the granulari

key sizes, combinations of algorithms and/or key sizes, or protocol v

• What cannot be specified? 

A good start at ensuring communication security in a multi-algorithm s

• Limit the list of algorithms available to the application to those best

users of the system and those needed for interoperability, 

• Adopt a policy that disallows sending messages using an in

protection, 

• Ad

• Adopt a policy expla

communications with a party using un-approved algorithms or ina

sizes. 

1.3.3 Single or Multi-Use Keys 

A major thrust from Part 1 of this Recommendation is that, in general, keys

be used for multiple cryptographic purposes. For example, in most ca

should not be used to generate a digital signature and to establish other k

(See Part 1, Section 8.1.5.1.1.2 for the rare exceptions to this guidan

to whether a digital signature key, for example, can be used only for 

application (e.g., signing e-mail) or for multiple applications (e.g., for both

and signing documents). In some cases, it may be acceptable for an appli

example, best practices indicate that a server’s TLS keys should not be u

other applications. E

14
s 

 to increase the 

thms and key 

e current 

s that need to 

ample, a system 

upgrading the 

unning with an 

DEA and AES 128 encryption, but a cryptographic module 

 of a system 

abilities, while continuing to support the old capabilities, until all 

Dur d in one of the 

foll

hanism is 

stead of the 

curity 

vailable to all 

 be used. This 

er mechanism, 

tected at a higher security level. The disadvantage is that 

ll protected; this 

 in different 

y mechanisms of 

 provided by 

y mechanism until all components have been 

 new capability. 

ould not be 

or all information 

during the period following the deadline until such time as all components have 

e same data will 

ity levels.5

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 

 

1.3.4 Algorithm and Key Size Transition 

Part 1 of this Recommendation provides timeframes for transitioning from algorithm

and key sizes currently in use by many applications and protocols in order

strength of the security mechanisms in the future. In many cases, the algori

sizes required to provide adequate security are not available within th

implementations or are unavailable uniformly across the community of user

interoperate. Transitions to new algorithms or key sizes will not necessarily occur 

instantaneously, but will require gradual upgrades across a system. For ex

owner may have the need to upgrade his system’s email package before 

cryptographic module. Hence, for a period of time, the system may be r

email package capable of T

that can only handle TDEA. There will be a need to upgrade components

with new cap

components have been upgraded. 

ing this transition period, interaction between components can procee

owing ways: 

1. Some means is provided to determine when the new security mec

available to all parties in a given transaction so that it can be used in

old security mechanism (e.g., using a protocol that negotiates the se

mechanisms to be used). When the new security mechanism is not a

parties involved in a transaction, the old security mechanism can

approach has the advantage that when a set of parties have the new

their transactions are pro

those transactions using the old security mechanism are not as we

also raises the possibility that the same information could be sent

transactions between two or more sets of parties using securit

different strengths – in effect, nullifying the higher security strength

the new security mechanism4. 

2. All components use the old securit

updated; at that time, the system immediately transitions to the

This approach has the potential problem that all components w

updated by the deadline, thus providing inadequate protections f

been upgraded. However, this approach has the advantage that th

not be sent at two different secur

4

 This becomes an issue when higher security level users are unaware that others may be using a lower 

security level mechanism to protect the same information. 

5

 Assuming that data sent before the transition is not also sent after the transition. 

15
upgrades can be made. Organizations and system administrators must determine the 

approach for transitioning to stronger security mechanisms within a system. 

16
2 Public Key Infrastructure 

pproach for the

 are used to 

e of integrity, 

nd assurance 

 the identity of 

hes the user’s 

curity services 

Security (Section 4), S/MIME secure mail (Section 5) and some versions of Kerberos 

agement. For 

 the issuer’s 

y authorized to 

er is a trusted 

ntity of the user; 

eters; and the 

n as a Certificate 

verification of 

 is used to 

 parties, since 

n process. 

etimes also 

 the 

plications, and 

f the business 

ing that only 

appropriate root certificates are loaded into the root certificate store. In Microsoft 

tained by the 

ft protocols and 

re is a similar 

“Keychain” facility in the Apple operating systems. Some applications, intended to be 

ores.6 

ance 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 

 

2.1 Description 

A Public Key Infrastructure (PKI) is the most common key management a

distribution of public keys. As described in SP 800-57, Part 1, public keys

establish security services after obtaining a variety of assurances: assuranc

assurance of domain parameter validity, assurance of public key validity, a

of private key possession. In most cases, applications must also establish

the user associated with this key pair. In a PKI, the infrastructure establis

identity and the required assurances to provide a strong foundation for se

in PKI-enabled applications and protocols, including IPsec (Section 3), Transport Layer 

(Section 6). This section presents basic guidance for PKI-based key man

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

name, using a digital signature generated by the issuer. The user is the part

use the private key associated with the public key in the certificate. The issu

third party that generates and signs the certificate after verifying: the ide

the validity of the public key, associated algorithms and any relevant param

user’s possession of the corresponding private key. The issuer is know

Authority (CA). In many cases, the CA will delegate responsibility for the

the subject’s identity to a Registration Authority (RA). The certificate

distribute the user’s public key to other interested parties, known as relying

they rely on the assurances provided by the PKI and the certificate creatio

CAs generally issue a self-signed certificate called a root certificate (som

called a trust anchor); this is used by applications and protocols to validate

certificates issued by a CA. They play a key role in many protocols and ap

are generally kept in what is often called a root certificate store. Much o

of properly configuring applications and protocols consists of ensur

Windows operating systems, there are root certificate stores that are main

operating system for various purposes that are shared by various Microso

applications, and by other applications that may choose to use them. The

portable between operating systems, maintain their own root certificate st

Certificates are generally issued in accord

6

 The various Mozilla browsers and E-mail clients, and the Apache web servers are examples. Microsoft 

Internet Explorer, Outlook and Internet Information Server all use the Windows root certificate store; 

Apple Safari and Mail use the Keychain; and Mozilla Firefox, Thunderbird and SeaMonkey all use root 

certificate stores associated specifically with the application. 

17
224-bit elliptic curve cryptography, and either SHA-1, SHA-224 or SH

only practical way to ensure that public key sizes meet the requirements is u

ensure that the root certificate store contains only root certificates with a certificate po

that requires these algorithms and key sizes in its subordinate certificates. 

applications that use PKI will check to ensure that a certificate has been iss

root certificate in the application’s root store, and that it has not been subse

revoked, but will not otherwise check the suitability of the public key or has

used in the certifica

A-256, then the 

sually to 

licy 

Current 

ued under the 

quently 

h algorithms 

te – the application will simply use the specified keys to compute the 

anaged for each 

ypically, 

es in the browser 

re may also be 

 management 

When a browser or other application encounters an 

ficate to their 

t the 

09 certificates 

ifiers that 

ignature. 

re; CAs usually include standard 

extensions in their certificates to indicate which cryptographic operations the public key 

here to find 

icate status 

es that contain 

lies on the certificate and the CA 

y used by the 

ng party knows 

 that CA. CAs that 

st anchors are 

In most 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 

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 m

application and protocol are beyond the scope of this Recommendation. T

however, there are menus for viewing and managing certificate stor

applications, but this is subject to change with each product update. The

utilities and features in the operating system or application for centralized

by the system administrator. 

unrecognized CA certificate, end users may be prompted to add that certi

permanent trusted certificate store, temporarily trust the certificate, or rejec

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

also include a digital signature, an issuance and expiration date, and ident

specify the cryptographic algorithm(s) to be used with the public key and s

X.509v3 certificates include an extensibility featu

was intended to support, the policy that governed certificate issuance, and w

out if the certificate has been revoked (i.e., an authoritative source for certif

information). CAs may also include “private” extensions in their certificat

information particular to an application or domain of users. 

A relying party is an individual or organization that re

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 ke

issuer to sign this certificate can be trusted. In the simplest case, the relyi

about the issuer, and has already decided to trust certificates issued by

a relying party trusts directly are called trust anchors. When multiple tru

recognized, the set of trust anchors is referred to as the trust list. 

18
issued by a CA that is not in the relying party’s trust list. All certifica

with a trust anchor, include zero or more intermediate certificates, and

certificate that contains the user’s public key. This can be an iterative pro

finding t

tion paths begin 

 end with the 

cess, and 

he appropriate intermediate certificates (a.k.a., path discovery) is one of PKI’s 

tificates have not been revoked, 

were issued under appropriate policies, and that each public key is suitable for the use to 

y be provided 

. An X.509 CRL 

ed, indicates 

 (see [RFC 

ear on the 

 they can 

re distributed 

te Status Protocol 

a trusted system, 

ificate basis, in response to a 

esponse by 

esponder is 

formal (e.g., 

overy Servers) to 

rvices store private keys that support key 

overed in the 

f loss or 

licy or legal 

ment burden 

 

m different 

l purpose PKIs, 

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 

 

challenges. 

The entire path must be examined to ensure that the cer

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 ma

using one of two standard mechanisms: 

• The most common source is a certificate revocation list, or CRL

contains a list of certificates issued by that CA that have been revok

when they were revoked, and may include the reason for revocation

5280]). If the serial number of an unexpired certificate does not app

CRL, then it is still valid. CRLs are digitally signed, like a certificate, so

be distributed through untrusted systems. Most commonly, CRLs a

via LDAP7 directories or web servers. 

• An alternative source for this information is an Online Certifica

(OCSP) responder (see [RFC 2560]). An OCSP responder is 

and provides signed status information, on a per cert

request from a relying party. Relying parties can authenticate the r

verifying the OCSP responder’s digital signature. As the OCSP r

providing authoritative status information, there is generally a 

contractual) relationship between the CA and OCSP responder. 

In many cases, PKIs will also provide key recovery services (using Rec

support business continuity. Key recovery se

establishment to ensure that the plaintext of encrypted data may be rec

future. These services can provide the private key to the user in the event o

failure of their cryptographic module, or to the user’s management when po

requirements exist. When supported, this service removes a key manage

from PKI-enabled applications. 

This section provides guidance for general purpose PKIs when users fro

organizations need to support a variety of applications. For large, genera

interoperability is an important consideration. Less commonly, PKIs may be deployed to 

7 Lightweight Directory Access Protocol (LDAP) is a software protocol for enabling anyone to locate 

organizations, individuals, and other resources, such as files and devices in a network, whether on the 

Internet or on a corporate intranet. See RFC 4511 Lightweight Directory Access Protocol (LDAP): The 

Protocol and RFC 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models. 

19
interoperability, these requirements should be evaluated for appropriatenes

sys

s within their 

tems. In general, cryptographic algorithm and key size standards should be met by all 

PKIs. 

sed by PKI 

htly different 

hose specified 

cate PKI, with 

s and the other for key 

for a digital 

s a pragmatic, 

Since 

plications, 1024 bit authentication keys are 

approved for use through 2013. On the contrary, keys used for digital signatures do have 

forward security implications and given anticipated advances in factoring techniques 

must be phased out by 2008. 

 

2.2 Security and Compliance Issues 

2.2.1 Recommended Key Sizes and Algorithms 

The following table summarizes the recommended key sizes for key pairs u

users and infrastructure components. Some of the dates in this table are slig

than those that appear in Part 1 of this document, but are consistent with t

in [SP 800-78-1]. 8 At the writing of Part 1, the Federal PKI was a 2 certifi

one certificate being used for authentication and digital signature

transport or key agreement. Part 1 states that a 1024 bit RSA key used 

signature and for authentication is approved for use through 2010. This wa

product-based compromise aimed at supporting FIPS 201 compliance. 

authentication has no forward security im

8 1024 bit RSA is permitted to leverage current products and promote efficient adoption 

of FIPS 201, but must be phased out by 12/31/2013 for authentication keys and 

12/31/2008 for digital signature and key management keys. Two key Triple-DES 

(2TDEA) authentication keys must be phased out by 12/31/2010. These requirements 

anticipate that digital signature and key management keys will be used to protect data for 

longer periods of time, while data enciphered solely for authentication is usually a 

random challenge (rather than sensitive information) and is generally not retained. 

20
Table 2-1 Recommended Key Sizes 

Key Type Time Period for Algorithms and Key Sizes 

Use 

Through 

12/31/2013 

r 2048 bits) 

urve P-256) 

RSA (1024 o

ECDSA (C

Authentication ke

(for Users or 

Devices) fter 12/31/

ECDSA (Curve P-256) 

ys 

A 2013 RSA (2048 bits) 

Through 

12/31/2008 

24 or 2048 

48 bits) 

256 or P-384) 

RSA signature or key transport (10

bits) 

Diffie-Hellman (1024 or 20

ECDSA, ECDH (Curves PDigital Signa

Key Establishment 

ture and 

keys (for Users o

Devices) 

After 12/31/ key transport (2048 bits) 

48 bits) 

ECDSA, ECDH (Curves P-256 or P-384) 

r 

2008 RSA signature or

Diffie-Hellman (20

CA and OCSP 

Responder Signing 

Keys 

N/A RSA: 2048, 3072

ECDSA: Curves P-256 or P-384

, or 4096 bits 

Note that some approved algorithms and key sizes are omitted to enhanc

interoperability. For example, only two of the e

e 

lliptic curves are recommended for use in 

ended to support 

section, other approved algorithms may be used where PKIs are deployed to support a 

small, closed community of users or a single application. 

The following table summarizes the recommended algorithms, key sizes, and padding 

schemes for signing certificates, CRLs, and OCSP status messages. 

PKIs [FIPS 186-3]. Similarly, Elliptic Curve Diffie-Hellman is recomm

key establishment, rather than Elliptic Curve MQV. As stated in the introduction to this 

21
Table 2-2 Recommended Signature Algorithms 

Signature 

Generation Date 

Public Key Algorithms 

and Key Siz

Hash Algorithms Padding Scheme 

es 

RSA (2048, 3072, or 409 SHA-1 PKCS #1 v1.5 

72, or 409 SHA-256 PKCS #1 v1.5 

6 bits) 

RSA (2048, 30 6 bits) 

ECDSA (Curve P-256) SHA-256 N/A 

Through 

12/31/2009 

ECDSA (Curve P-384) SHA-384 N/A 

SHA-1 PKCS #1 v1.5 

RSA (2048, 3072, or 409 SHA-256 PKCS #1 v1.5, 

PSS 

6 bits) 

ECDSA (Curve P-256) SHA-256 N/A 

1/1/2010 thro

12/31/2010

 P-384) SHA-384 N/A 

ugh 

ECDSA (Curve

RSA (2048, 3072, or 409 SHA-256 PKCS #1 v1.5, 

PSS 

6 bits) 

ECDSA (Curve P-256) SHA-256 N/A After 12/31/2010 

ECDSA (Curve P-384) SHA-384 N/A 

User certificates containing RSA or Diffie-Hellman public keys should

the RSA signature algorithm. User certificates containing elliptic cur

should be signed using ECDSA. 

Not all combinations of algorithms and key sizes are appropriate for the p

Federal government information. To enhance i

 be signed using 

ve public keys 

rotection of 

nteroperability, users should obtain 

lementary 

ent keys 

s preferred 

 be calculated 

using the most conservative dates specified in Table 2-1. 

ponents using 

 implementations, 

A [SP800-67]. 

authentication, signature, and key establishment certificates with comp

algorithms for all public keys.9

 For most users, signature and key establishm

should provide consistent cryptographic strength. The following table show

combinations for user keys; periods of use for these combinations should

While symmetric key cryptography is not strictly required, block ciphers are used in 

practically all PKI implementations and PKI-enabled applications. All com

block ciphers shall support the AES-128 algorithm. To support legacy

components that process RSA keys should support three key Triple-DE

 

9

 In general, protocols and applications are designed to use cryptographic algorithms from one 

mathematical family. For example, applications that encounter ECDSA digital signatures would expect to 

use elliptic curve Diffie-Hellman or MQV for key establishment services. Users that obtain an ECDSA 

certificate and an RSA key establishment certificate, for example, may find they cannot use the keys 

together in a single application. Other combinations, such as DSA and Diffie-Hellman certificates, are 

commonly used in combination. Users should obtain authentication, signature, and key establishment 

certificates that are complementary to ensure that the keys can be used together in applications and 

protocols. 

22
Components that support P-384 elliptic curve keys and the SHA-384 algorithm shall 

support AES-256.

Table 2-3 Recommended Combinations of Algorithms and Key Sizes 

Authentication Key Signature Key Key Establishment Key 

Type 

RSA 1024 RSA 2048 RSA 2048 

RSA 1024 RSA 2048 Diffie-Hellman 2048 

RSA 2048 RSA 2048 RSA 2048 

RSA 2048 RSA 2048 Diffie-Hellman 2048 

ECDSA P-256 ECDSA P-256 ECDH P-256 

ECDSA P-256 ECDSA P-384 ECDH P-384 

ECDSA P-384 ECDSA P-384 ECDH P-384 

2.3 Procurement Guidance 

r those responsible for making decisions on which 

re and Hardware: 

ol (CMP) [RFC 

 CA software 

 generate and process certificate requests using PKCS #7, [PKCS-7] and 

rtificates and CRLs that conform to [RFC 

5280]. (Specific requirements with respect to certificate and CRL extensions are 

d for all said 

4. CAs shall be capable of including the CRL distribution points extension. At a 

o specify the 

location of CRLs. CAs shall be capable of specifying an authoritative OCSP 

responder in the Authority Information Access extension. 

5. Each PKI has its own certificate profile, identifying certificate extensions that appear 

in the certificates and CRLs it issues.10 CAs shall be able to generate all mandatory 

 

The following provides guidance fo

products to purchase in support of a PKI. 

2.3.1 CA/RA Softwa

1. CA and RA software shall support the Certificate Management Protoc

4210] or Certificate Management Using CMS (CMC) [RFC 5272]. 

should also

PKCS # 10 [PKCS-10]. 

2. All CAs shall support the generation of ce

detailed below.) 

3. CAs shall be capable of issuing multiple certificates to users, an

certificates, asserting the key usage extension, including the Extended Key Usage 

extension and the “anyExtendedKeyUsage” value. 

minimum, CAs shall support the inclusion of LDAP and HTTP URLs t

10 This profile is often documented explicitly, but may be implicitly specified through the certificate policy. 

23
extensions in the appropriate profiles. For CAs owned or operated on behalf of 

Federal agencies, the following specific guidance applies: 

o generate 

 PKI Certificate 

ommon Policy Framework [COMMON] shall be able 

to generate certificates and CRLs meeting the Shared Services Certificate and 

ates and CRLs.11

ort at least one of the following algorithms for digitally signing 

certificates and CRLs: RSA with PKCS#1 v1.5 padding; RSA with PSS Padding 

 all of the 

s to support reconstitution of the CA 

backup and 

nd revoked, 

ose authority. 

ts shall be shipped or delivered via controlled methods that provide 

 CA’s or RA's 

onform to [RFC 2560], Online Certificate Status Protocol. 

nd unsigned requests 

and shall be capable of processing requests that either include or omit the name of the 

relying party making the request. However, OCSP responders may ignore signatures 

uests and 

19]. 

 

a) CAs that implement Federal agency-specific policies shall be able t

certificates and CRLs that meet the agency profile and the Federal

Profile [FPKI PROF]. 

b) CAs that implement the C

CRL Profile [COMMON PROF]. 

6. CAs should support the inclusion of “private” extensions in certific

7. CAs shall supp

[RFC 3447], or ECDSA. To maximize flexibility, CAs should support

above algorithms.12

8. CAs shall include backup and archive capabilitie

in the event of a disaster (e.g., fire, earthquake).13 CAs should include 

archive capabilities in order to establish when certificates were issued a

and under wh

9. CA/RA componen

a continuous chain of accountability, from the purchase location to the

physical location. 

2.3.2 OCSP Responders: 

1. OCSP responders shall c

2. OCSP responders shall be capable of processing both signed a

and requester names, if present. 

3. OCSP responders shall be capable of processing certificate status req

generating responses for non-error conditions as specified in [RFC 50

11 Private extensions are defined by an organization to meet their own unique requirements. Note that 

noncritical private extensions do not impact the interoperability of certificates or CRLs. 

12 The algorithm used to sign certificates and CRLs in an operational CA is dependent upon both the 

cryptographic module in use and the CA’s software. The selected algorithm must appear in both sets of 

supported algorithms. 

13 In cases where the root key has been compromised, destroyed or lost, it is necessary to rebuild the CA 

using a backup root key, rather than simply recover the lost state of the CA. 

24
4. Where supported, the OCSP responder should sign the OCSP response

algorithm used to sign the certificate. OCSP responders shall support a

the following algorithms for digitally signing response messages: RSA 

v1.5 padding; RSA with PSS Padding, or ECDSA. The supported algor

include the algorithm(s) used by the corresponding CA when signing th

whose status is in question. To support future algorithm

 with the 

t least one of 

with PKCS#1 

ithms should

e certificate 

 transitions by the CA, OCSP 

responders should support all of the aforementioned algorithms.14

onders shall

modules validated 

0-2 Level 2 or higher. 

r cryptographic modules shall be validated as meeting FIPS 

.e., certificates will include key transport or 

key agreement keys), the PKI should include a key recovery mechanism. 

d support automated, user-initiated key recovery; key recovery 

 path validation 

a) Relying party implementations shall implement RFC 5280-conformant path 

validation [RFC 5280]. 

ederal 

th validation modules should conform to requirements for 

.509 Path 

 

2.3.3 Cryptographic Modules 

1. Cryptographic modules for CAs, Key Recovery Servers, and OCSP resp

be hardware modules validated as meeting FIPS 140-2 Level 3 or higher. 

2. Cryptographic modules for RAs should be hardware cryptographic 

as meeting FIPS 14

3. Relying party and use

140-2 Level 1 or higher. 

2.3.4 Key Recovery Servers 

1. If the PKI supports key establishment (i

2. Implementations shoul

by the organization should also be supported.15 

2.3.5 Relying Party Software 

1. Relying party

b) Where interoperability outside a single organization (e.g., a single F

agency) is required, pa

an Enterprise PVM, as specified in NIST Recommendation for X

Validation.16 

14 As with CAs, the algorithm used to sign responses in an operational OCSP responder is dependent upon 

both the cryptographic module in use and the OCSP responder’s software. The selected algorithm must 

appear in both sets of supported algorithms. 

15 Organizational key recovery should emphasize security and privacy, rather than performance. Dual 

control for recovery of a user’s keys by the organization is strongly recommended. 

16 This document is available in draft form and can be found at 

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/NIST_Recommend

ation_for_X509_PVMs.pdf. 

25
c) Where interoperability across organizations is required, path validat

should conform to requirements for

ion modules 

 a Bridge-Enabled PVM, as specified in NIST 

ll support CRLs for certificate status, and 

OCSP for certificate status. 

n paths. 

 be able to obtain CA 

tionally-designated local 

3. Relying parties that work within a single organizational PKI (e.g., a PKI that supports 

ificates issued by 

dinate to the trust anchor CA. 

 that accept certificates from other organizations should be able to 

d certificates per end 

e, the client 

implementation should support and differentiate between private keys associated 

d private keys 

certificates supporting key establishment. 

 140-2 Level 1 or higher. 

tocol 

2.4 Recommendations for System Installers/Administrators 

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 

ned and that the 

 

Recommendation for X.509 path validation. 

d) Relying party implementations sha

should support 

2. Building certificate paths 

a) Relying party implementations shall be able to build certificatio

b) At a minimum, relying party implementations should

certificates and CRLs using LDAP from an organiza

directory, as well as locations specified within a user certificate. 

c) Implementations should support http-based certificate retrieval. 

a company or agency) should be able to discover paths for user cert

CAs that are hierarchically subor

4. Relying parties

discover paths in non-hierarchical PKIs. 

2.3.6 Client Software 

1. Client implementations shall support multiple private keys an

user in order to support different cryptographic services. For exampl

with public keys in certificates supporting digital signatures, an

associated with public keys in 

2. Client cryptographic modules shall be validated at FIPS

3. Client implementations should support the certificate management pro

supported by the organization’s CA.17

operation. The system administrator shall ensure that end users are trai

organization’s security policy is enforced. 

17 Where keys and certificates are stored on smart cards, and all updates are performed at the RA, user 

implementations need not support the certificate management protocol. 

26
2.4.1 Certificate Issuance 

1. CAs shall be configured to ensure that certificates specify public keys with approved 

should use RSA key pairs for digital 

3. For maximum security and performance, CAs and users should use elliptic curve key 

in Table 2-2. When signing certificates or CRLs with RSA, digital signatures should

mize 

re certificates with a key whose security strength is equal to or 

ecurity strength of the key in the certificate. For key establishment 

ey in the certificate than will be 

. 

ay generate key pairs for key establishment on the user’s 

 establishment private 

key to permit key recovery. 

 proof of possession on all key pairs before issuing 

usage extension should restrict acceptance of the private key to a single 

: digital signatures, user authentication, or key 

to support legacy 

ications. 

9. Extended Key Usage extension. 

a) Certificates may include the extended key usage extension to support specific 

applications (e.g., smart card logon). 

b) If a certificate is intended for general use, in addition to some list of specific 

applications, the extended key usage extension shall also specify “Any Key 

Usage”. 

key sizes, valid domain parameters, and approved algorithms. 

2. For maximum interoperability, CAs and users 

signatures and key transport. 

pairs for digital signatures and key agreement. 

4. When signing certificates or CRLs, CAs shall generate digital signatures as specified 

be generated using the SHA-1 hash algorithm until 12/31/2010 to maxi

interoperability. 

5. CAs shall sign signatu

greater than the s

keys, the signature may be generated using a weaker k

used for key establishment. 

6. Generating key pairs: 

a) Users should generate their own digital signature key pairs

b) The user or the PKI m

behalf; where required, the PKI may retain copies of the key

c) CAs should perform

certificates. 

7. CAs shall obtain assurance of public key validity before issuing certificates. 

8. Key usage extension. 

a) All certificates issued shall include the key usage extension. 

b) The key 

cryptographic function

establishment. 

c) Dual-use certificates (where a single key is used for both digital signatures and 

key establishment) should not be issued to users. 

d) Dual-use certificates may be issued to devices where required 

appl

27
10. All certificates shall include the CRL distribution points extension to support the 

shall include an appropriate URL in 

the Authority Information Access extension. 

ctical: 

equests 

b) Where the CA can authenticate a digitally signed request submitted by the user of 

hout manual 

 digitally signed revocation requests on behalf of 

2.4.3 Certificate Revocation List Generation 

erate full CRLs. A 

 issued by 

2. CAs that serve a large community should generate CRL distribution points in 

subset of the revoked 

ered by a CRL distribution 

distribution point 

ot grow to an unmanageable size. 

2.4.4 PKI Repositories for the Distribution of Certificates and CRLs 

uesters without 

2. PKI repositories shall be configured to require authenticated access to modify the set 

3. At a minimum, repositories shall support either the HTTP version 1.1 or LDAP 

version 3 interface. 

4. For maximum interoperability, both HTTP and LDAP should be supported. 

5. Replication of repositories (e.g., through directory shadowing or web server 

replication) to maximize availability should be considered. 

retrieval of status information. 

11. If an OCSP responder is supported, a certificate 

2.4.2 Certificate Revocation Requests 

1. CAs should be configured to automate revocation processing where pra

a) CAs should be configured to authenticate and process revocation r

electronically. 

the associated key pair or an RA, the request should be handled wit

intervention. 

2. RAs should be configured to submit

users or the organization. 

1. To maximize interoperability, all CAs should be configured to gen

full CRL is a single CRL that lists all revoked and unexpired certificates

this CA. 

addition to full CRLs. Each CRL distribution point lists a 

certificates for a given CA. The number of certificates cov

point should be limited to a maximum of 250,000 to ensure that the 

CRLs do n

1. PKIs should be configured to provide certificates and CRLs to req

authentication. 

of certificates and CRLs distributed by the repository. 

28
6. PKI repositories should contain all CA certificates issued by or to the corresponding 

7. PKI repositories shall contain all current CRLs. 

OCSP responders is specified 

18

all not require that requests be signed and shall not limit the 

set of relying parties to which certificate status information is provided. 

esponses shall not

a) OCSP responders may require signed requests, and may reject requests from 

messages may include private extensions known within the target 

1. To maintain the availability of status information, CAs shall ensure that sufficient 

r a disaster. 

ertificates were 

3. As a general rule, all audit logs should be maintained, along with any certificates 

keys should be archived, along with their 

icate expiration. 

1. Path discovery components shall be configured to enable path discovery, and 

require the retrieval of status information. 

2. Status information should be accepted in both CRL and OCSP formats. 

 

PKI. 

2.4.5 OCSP Responders 

For Federal agencies, detailed configuration guidance for 

in Draft Guidance for OCSP Responders in the U.S. Federal PKI. 

1. If maximum interoperability is required then: 

a) OCSP responders sh

b) The responders shall generate OCSP basic responses, and the r

include critical extensions. 

2. Where interoperability requirements are limited to a closed community: 

entities outside that community. 

b) OCSP response 

community. 

2.4.6 Backup and Archive 

information is stored in a secure location to reconstitute the CA afte

2. CAs should archive sufficient information to establish when c

issued, and under whose authority. 

and CRLs issued by the CA. 

4. User public signature verification 

corresponding certificates, for at least 7 1⁄2 years after certif

2.4.7 Relying Party Integration and Configuration 

18 Draft guidance is available at http://cio.nist.gov/esd/emaildir/lists/pkits/doc00000.doc. 

29
3. Relying party implementations shall be configured to recognize the smallest set 

A that is 

ements (e.g. 

uirements as specified in [OMB 04-04]) and high 

ements, agency applications may use the pre-installed trust 

tion modules: 

ty 

 accept any 

s with more significant security requirements (e.g., systems using 

PKI to satisfy Level 3 or Level 4 e-Authentication), path validation modules 

 to only accept paths that are valid under appropriate 

er Guidance (Subscribers) 

lic key. The subject 

ay be a person or a device. For the purposes of this section, the term user is either the 

 associated with a 

pub

 

) that control 

t the revocation of their certificates if they believe the 

authenticator or cryptographic module has been stolen, copied or compromised. 

5. Users shall control the disposition of “old” key pairs after certificates expire 

unless otherwise controlled in accordance with Federal agency policy and 

procedures 

a) Private signature keys should be destroyed after the corresponding 

certificate(s) expire. 

of acceptable trust anchors possible. 

4. For business-to-government and government-to-government applications, Federal 

agencies should use either the Common Policy Root CA or an agency C

cross certified with the Federal Bridge as the trust anchor. 

5. For citizen-to-government applications with limited security requir

Level 2 e-Authentication req

interoperability requir

anchors provided in COTS products. 

6. Path valida

a) For end user applications and applications with minimal securi

requirements, path validation modules should be configured to

valid path. 

b) For system

should be configured

policies. 

2.5 Us

In a PKI, the subject is the identity of the user associated with a pub

m

person associated with a public key, or the administrator of a device

lic key. 

1. Users should generate key pairs for digital signature and authentication. 

2. Users may generate their own key pairs for key establishment, or the key 

establishment key pairs may be imported from a trusted source. 

3. Users shall protect the authenticators (e.g., the PIN or password

access to their private keys. 

4. Users shall reques

30
b) Private key establishment keys need not be destroyed

certificate(s) expire. The user should not destroy the private

establishment key until all symmetric keys established using t

been recovered or otherwise protected (e.g., by encrypting und

key). Premature destruction of privat

 after the corresponding 

 key 

his key have 

er a different 

e key establishment keys may prevent 

recovery of the subscriber’s plaintext data. 

31
3 IPsec 

etwork layer 

ablish Virtual 

l, and enabling 

muters 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 

ader in each 

The 

or integrity 

ionally provide 

 header. ESP, 

, but not the IP 

original IP header. Furthermore, using ESP with automated keying protects the source 

equivalent 

ment IPsec-v3, 

er, IPsec-v2 is 

solete.21

ying and 

d manner) by 

d the symmetric 

rely limits the scalability of the 

 manner. A Security 

ach 

 keys cannot 

maximum 

allowable volume of traffic, or if its keys are compromised. 

ying, a negotiation between peers prior to exchanging IPsecions to be applied and the symmetric keys to 

aintain, delete, or renegotiate the SA (e.g., to 

rekey). This approach permits a decoupling of the key management mechanism from the 

 

3.1 Description 

IPsec is a suite of protocols for securing Internet communications at the n

and operates within the Internet Protocol (IP). It is frequently used to est

Private Networks (VPNs), requiring both parties to share keying materia

telecom

Protocol. 

IPsec operates by inserting one of two special IPsec headers after the IP he

message. The Authentication Header (AH) provides integrity protection. 

Encapsulating Security Protocol (ESP) Header provides confidentiality and/

protection. Both ESP and AH provide data origin authentication, and opt

replay protection. AH protects the IP header and the data following the IP

when applied directly to a packet (i.e., in transport mode), protects the data

header. However, ESP in tunnel mode (with a new IP header inserted) does protect the 

and destination addresses in the IP header, in either transport or tunnel mode. Since AH 

processing introduces unnecessary complexity, and since ESP can provide 

functionality, the use of AH is not recommended. 

There have been three versions of IPsec.19 All new systems should imple

as it has many enhancements not found in the previous versions.20 Howev

still implemented in numerous current systems, despite the fact that it is ob

Two classes of key management methods are specified for IPsec: manual ke

automated keying. Manual keying involves an agreement (in an unspecifie

the parties in a communication on the IPsec protections to be applied an

keys to be used. This has a major downside in that it seve

security solution and requires re-keying to be done in an unspecified

Association (SA, i.e., a relationship between two or more entities that describes how e

entity will use the security services to communicate securely) and its secret

be easily renewed in the cases where the SA expires, has been used for the 

To use automated ke

protected traffic determines the IPsec protect

be used. The same method can be used to m

19 There are no generally accepted names for IPsec-v3 and IPsec-v2; these terms are used in this document to make the 

requirements more understandable

20 IPsec-v3 is specified in RFC 4301, RFC 4302, and RFC 4303. 

21 IPsec-v2 is specified in RFC 2401, RFC 2402 and RFC 2406. 

32
other security mechanisms, thus facilitating the use of alternative key management 

methods without having to modify other security mechanisms. 

 protocol that 

keying 

IKE peers. There 

409]] and 

al authentication, and 

r a specified period of 

roperable. 

materials for versions 2 and 3 of IPsec. 

Table 3-1. Summary of References for IPsec 

ite

Pri n utomated Key 

Management 

The preferred automated keying method is IKE, the Internet Key Exchange

was designed specifically for use with IPsec. IKE generates the necessary 

material for IPsec via an authenticated secure channel between the two 

are two versions of IKE in use: IKEv1 [RFC 2407, RFC 2408, and RFC 2

IKEv2 [RFC 4306 and RFC 4718]; both versions perform mutu

establish and maintain security associations. SAs will be valid fo

time or volume of traffic. These two versions of IKE are not inte

Table 3-1 provides the IETF reference 

Version Security 

Arch cture 

vacy Authe tication A

IPsec-v2 RFC 2401 RFC 2406 RFC 2402, RFC 2407, RFC 

RFC2406 2408, RFC 2409 

IPsec-v3 RFC 4301 RFC 4303 RFC 4302, RFC 

4303 

RFC 430

4718 

6, RFC 

The IPsec security mechanisms are not tied to any specific cryptographic al

fact, many algorithms and modes have IETF Requests For Comment (RFC

their use with IPsec. This, however, can result in a situation where there are

choices for typical system administrators to make that it is difficul

interoperability. To improve interoperability in IPsec-v3, a small numbe

suites that cover typical security policies, referred to as user interface (UI

specified [RFC 4308]. The use of these suites is optional. Implementers 

individual selection of security algorithms (i.e., rather than selecting a pre

gorithms; in 

s) describing 

 so many 

t to achieve 

r of named cipher 

) suites, were 

may allow the 

-specified suite 

of algorithms), but users must be aware that picking non-standard groupings of 

algorithms may result in limited interoperability. However, when IPsec is used in the 

an be centrally managed, thus ensuring 

se of pre-defined cipher suites. Complete IETF algorithm 

3.2 Security and Compliance Issues 

3.2.1 Cryptographic Algorithms 

The following table gives cryptographic algorithm recommendations for use within 

IPsec. The algorithms that are specified for IKE are used to protect IKE’s own traffic. 

The ESP and AH algorithms 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. 

context of a VPN, security policy c

interoperability without the u

guidance is provided in [RFC 4835] (for AH and ESP), [RFC 4307] (for IKEv2) and 

[RFC 4109] (for IKEv1). 

33
Table 3-2 e

Protocol Cryptographic 

rvic

Algorithm e Approved 

for Federal 

Use 

. Cryptographic Algorithm R commendations 

/Mode IETF R

Se e 

quirement 

for Implementation 

ESP Encryption A in CBC 

mode 

[RFCs 24

] 

Mandatory Yes, with 

three distinct 

keys 

 TDE

51, 

4835

ESP Encryption NULL 

[RFCs 2410, 

4835] 

Mandatory Yes, for 

cases where 

integrity 

protection is 

required but 

not 

encryption 

ESP Encryption

 in C

s 3602, 

4835] 

 AES with 128-bit Mandatory Yes 

keys

mode 

BC 

[RFC

ESP Encryption AES-128 in 

s 3686, 

4835] 

Optional2 Yes but must 

be used with 

non-NULL 

integrity 

protection 

[RFC 3686] 

Counter mode 

[RFC

2

ESP or AH Integrity 

Protection 

C SHA1-96 

[RFCs 2404, 

4835] 

HMA Mandatory Yes 

ESP or AH Integrity 

Protection 

HMAC SHA256-128 

[RFC 4868]] 

Optional Yes 

 

22 The RFCs actually have 3 levels of requirements: Recommended (SHOULD), and Optional (MAY). 

Mandatory (MUST), This is actually IETF Recommended. In this table, IETF Recommended and IETF 

Optional are both listed as Optional in keeping with the use of the words Recommended and Optional 

throughout the rest of this document. 

34
Protocol Cryptographic 

Service 

Algorithm/Mode IETF Requirement 

for Implementation 

Approved 

for Federal 

Use 

ESP Integrity 

Protection 

NULL [RFC 

4835] 

Optional Yes, but only 

when 

combinedmode 

algorithms 

are used to 

provide 

integrityprotection. 

ESP Encryption

Integrity 

 in 

Galois/Counter 

e 

06, RFC 

 and AES-128 Optional Yes 

Protection Mod

[RFC 41

4835] 

ESP Encryption 

grity 

ction 

nter m

BC-MAC 

s 4309, 

and AES-128 in Optional Yes 

Inte

Prote

Cou

with C

ode 

[RFC

4835] 

ESP or AH Integrity 

tion 

-128 in 

 4543] 

Optional Yes 

Protec

AES

GMAC M

 [RFC

ode 

IKEv1 or Encryption A in CBC 

[RF

, 4307] 

Mandatory Yes, with 

three distinct 

keys 

IKEv2 

 TDE

mode 

4109

Cs 

IKEv1 

v2

or n 128 

, 4307] 

Optional22 Encryptio Yes 

IKE

 AESmode [RFCsin CBC 

4109

IKEv1 or

IKEv2 

n

nction 

S

s 4109, 

 Pseudo-ra dom HMACfu [RFCHA1 Mandatory Yes 

4307] 

IKE

IKEv2 

v1 or n S

86

 P Optional Yes 

Function 

seudo-ra dom HMA

256 

C- HA-

[RFC 4 8] 

IKEv1 Diffie-Hel

Group 

it MODP 

[RFCs 4109, 

4307] 

lman 1024-b Mandatory Yes 

IKEv1 or 

IKEv2 

Diffie-Hellman 

Group 

2048-bit MODP 

[RFCs 4109, 

4307] 

Optional22 Yes 

IKEv2 Integrity HMAC-SHA1-

96 [RFC 4307] 

Mandatory Yes 

35
Protocol Cryptographic 

Service 

Algorithm/Mode IETF Requirement 

for Implementation 

Approved 

for Federal 

Use 

IKEv2 Integrity C6-

486

HMA Optional Yes 

SHA25

[RFC 

128 

8] 

IKEv1 Peer 

Authentica

22 or DSA 

 SHA1 

4

, 4306] 

Optional Yes 

tion 

RSA

with

[RFCs 2

4109

09, 

IKEv2 Peer 

a

h

40

, 4306] 

Mandatory Yes 

Authentic tion 

RSA wit

[RFCs 2

4109

 SHA1 

9, 

IKEv2 Peer 

a

with

s 2409, 

, 4306] 

Optional Yes 

Authentic tion 

DSA 

[RFC

4109

 SHA1 

IKEv1 or Peer or DSA Optional Yes 

IKEv2 Authentication with SHA256 

[RFCs 2409, 

4109, 4306] 

RSA

NULL integrity protection or NULL encryption means that no integrity p

applied or no encryption is used, respectively. NULL integrity protection (

to as NULL authentication) is used for situations where confidentiality is 

without the need for integrity protection. NULL integrity protection shall 

cannot, be used with NULL encryption. ESP, for example, could send 

packets, (encryption set to

rotection is 

often referred 

required 

not, and in fact 

unencrypted 

NULL), but would be required to integrity protect them; for 

ection set to 

y protection! 

ity-protected, 

whether or not it is encrypted. 

e (ICV) is 

], or in the 

ion Header (AH) [RFC 4302]. (This field is 

 2402]). 

In the case of HMAC for integrity protection, the length of the ICV value is at most the 

size of the output value of the hash function. For IPsec applications, the ICV value shall

be truncated to 96 and 128 bits for HMAC-SHA1 and HMAC-SHA256, respectively, 

[RFCs 4307, 4868]. 

Although the IETF is transitioning to AES-XCBC-MAC, [RFC3566 and 4434], and also 

allows the use of HMAC-MD5 (not shown in the table), neither is approved for use by 

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 prot

NULL). ESP could not send packets both unencrypted and with no integrit

It is recommended that IPsec-protected traffic should always be integr

When IPsec-protected traffic is integrity-protected, an Integrity Check Valu

stored in the Integrity Check Value field of the ESP payload, [RFC 4303

Integrity Check Value field of the Authenticat

referred to as the “Authentication Data” field in IPsec V2 [RFCs 2406 and

36
the Federal government. As such, AES-XCBC-MAC and HMAC-MD5 shall not be used 

for integrity protection. 

e above table. 

ese algorithms 

s have 

been approved for Federal government use: AES in Galois/Counter Mode (GCM) [RFC 

4309]. 

GCM, referred to as AES-GMAC [RFC 4543] , that 

an be used 

The maximum size of the ICV for AES-CCM, AES-GCM and AES-GMAC is 16 bytes. 

s [RFCs 4309, 

 manually 

 the IV value, in 

h the same key, the 

security of the algorithm’s confidentiality mechanism is compromised. Since manual 

these algorithms. 

peers within each 

ate keys. 

ndatory-toment; however, this algorithm shall not be used to protect information. 

security algorithms. As an example, an 

 guidance of Part 1 of SP 800-57, could 

c suite with an overall security strength of 

• ESP Integrity Protection: HMAC-SHA1 

C-SHA1 

• IKEv2 Integrity: HMAC-SHA1 

• IKEv2 Peer Authentication: 1024-bit RSA with SHA-1 

Note that if the implementer wanted to ensure a security strength of 112 bits, he would 

have to make the following changes to the suite above: 

• IKEv2 Diffie-Hellman group: 2048-bit MODP 

• IKEv2 Peer Authentication: 2048-bit RSA with SHA-256 

A new class of algorithms, called combined-mode algorithms, appears in th

They can be negotiated by IKE and used within IPsec-v3 cipher suites. Th

provide both encryption and integrity protection. Two combined-mode algorithm

4106] and AES in counter mode with CBC-MAC (AES-CCM) [RFC 

There is also a variant of AESprovides integrity protection but does not provide encryption. This mode c

within either the ESP or AH header. 

Implementations shall support a size of 16 bytes for these three algorithm

4106, 4543]. 

AES-GCM, AES-CCM, AES-CTR, and AES-GMAC shall not be used with

distributed keys. If the counter value, in AES-CTR or AES-CCM, or

AES-GCM or AES-GMAC, is used for more than one packet wit

keying presents a major challenge to this limit, it shall not be used with 

Automated keying using IKE establishes secret keys for the two 

Security Association, with an extremely small probability of duplic

In previous IETF guidance, DES using the CBC mode [RFC 2405] was ma

imple

IPsec allows the individual selection of 

implementer using Table 3-2 and following the

select the following algorithms to form an IPse

80 bits: 

• ESP Encryption: AES in CBC mode 

• IKEv2 Encryption: AES in CBC mode 

• IKEv2 Pseudo-random function: HMA

• IKEv2 Diffie-Hellman group: 1024-bit MODP 

37
The following two cipher suites, described in Tables 3-3 and 3-4, i

algorithms from NSA’s Suite B. These algorithms are all approved for Fe

government use. The Suite-B-GCM-128 and Suite-B-GCM-256 suites 

in [RFC 4869]. At present, these cipher suites are not widely available o

However, wherever practical, implementations should be procured that sup

cipher suites, and they should be selected for use wherever very high perform

security strength are required. Recall that AES-GCM is a combined-mode 

ncorporate the 

deral 

are both defined 

r deployed. 

port these 

ance and 

algorithm that 

provides both encryption and integrity protection, so these suites provide integrity, 

m is listed in [RFC 4869] as NULL for both suites. 

able 3-3: Suite-B-GCM-128 Cipher Suite 

despite the fact the integrity mechanis

T

Suite-B-GCM128 

Mechanism Guidance 

ESP Encryption d 16-octet Integrity Check 

CV) in GCM mode 

06] 

and AES with 128-bit keys an

integrity 

protection [RF

Value (I

C 41

IKEv1

IKEv2

 or Encryption AES with 128-bit keys in CBC mode 

[RFC 3602] 

IKEv1 or 

v2 

udo-ra

function 

-256 

IKE C 4868] 

Pse ndom HMAC-SHA

[RF

IKEv1 or 

v2 

el bit random ECP group 

IKE C 4753] 

Diffie-H

Group 

lman 256-

[RF

IKEv1 or 

IKEv2 

Integrity HMAC-SHA-256-128 

[RFC 4868] 

IKEv1 or 

IKEv2 ation 

Peer CDSA-256 

Authentic

E

[RFC 4754] 

Table 3-4: Suite-B-GCM-256 Cipher Suite 

Suite-B-GCM256 

Mechanism Guidance 

ESP ryption

tection

S with 256-bit keys and 16-octet Integrity Check 

CM mode 

Enc and AE

integrity 

pro [RFC 4106] 

Value (ICV) in G

IKEv1 or ryption in CBC mode 

IKEv2 3602] 

Enc AES with 256-bit keys 

[RFC

IKEv1 or 

IKEv2 

a

function 

AC-SHA-384 

[RFC 4868] 

Pseudo-r ndom HM

IKEv1 or 

IKEv2 

Diffie-Hellman 

Group 

384-bit random ECP group 

[RFC 4753] 

IKEv1 or 

IKEv2 

Integrity HMAC-SHA-384-192 [RFC 4868] 

IKEv1 or 

IKEv2 

Peer 

Authentication 

ECDSA-384 

[RFC 4754] 

38
IKEv1 implementations shall support the pre-shared key format for peer a

for interoperability, as referenced in [RFC 2409]. The 

uthentication 

authentication method used with 

 IPsec protocol 

ets or exceeds 

bits of 

tection and 

d key shall have 

ncryption is used, the pre-shared 

ryption key. In 

red key shall be generated by one of the approved random bit generators as 

th, and is then 

Psec 

[RFC 4869] also defines two additional suites: Suite-B-GMAC-128 and Suite-B-GMACGMAC mode for GCM; thus, they provide ESP integrity 

r Federal use. 

3.2.2

1. NULL encryption and NULL integrity protection shall not both be used at the same 

 with AES-128 

Mode. 

3. 

3. IKE should be used for automated key management to ensure a re-keying capability 

and scalability. 

 ESP 

d by the system and kept secret as long 

3.3 Procurement Guidance 

These recommendations are written to assist individuals responsible for selecting security 

products that include IPsec for the security of the IP layer. 

1. Any IPsec system for use within the Federal government should include an IKE 

implementation for automated key management. 

IKEv1 may use either a pre-shared key or ECDSA [RFC4869]. 

 

A pre-shared key is a (symmetric) secret key that is established before an

is executed. The pre-shared key shall provide a security strength that me

the target security strength for the data to be protected. For example, if 112 

security is required, HMAC SHA1 is used for integrity (authentication) pro

AES-128 is used for encryption (confidentiality protection), the pre-share

at least 112 bits of security strength. In addition, when e

key should have a security strength that is equal to the length of the enc

this example, the pre-shared key should have 128 bits of security. 

A pre-sha

specified in [SP 800-90] that meets or exceeds the required security streng

securely distributed ( out-of-band) to the other communicating party in an I

connection. 

256. These suites substitute the 

protection without ESP encryption. These two suites are also approved fo

Additional Recommendations 

time within ESP. NULL integrity protection in ESP shall not be used

in Counter 

2. The Authentication Header (AH) should not be used in IPsec version 

4. Once an ESP Security Association has expired or is no longer in use, its

encryption keys shall continue to be protecte

as the data they were used to protect needs to be kept secret. 

39
2. IPsec implementations shall include approved algorithms for each IPse

component. In addition, the implementation should be capable of using

of the approved cipher suites specified in Secti

c security 

 one or more 

on 3.2. Being capable of using one or 

3. IPsec implementations should include the algorithms used in the Suite B cipher 

suites. 

Recommendations for System Installers 

ude IPsec for 

automated key management within any IPsec system. 

tion is required, but 

ot needed. 

rity component, as 

System administrators are those individuals responsible for the day-to-day functioning of 

ll: 

ly trained and that the organization’s security policy 

Ensure that a key used by the product is protected throughout its lifespan. 

3.6 Recommendations for End Users 

urity. End users 

shall: 

1. Be aware of and trained to follow the organization’s security policy for using the 

product. 

2. Operate their system as instructed by their organization and system administrator. 

more of these cipher suites will improve interoperability. 

3.4

Systems installers are those individuals that install products that incl

security. 

1. IKE should be used for 

2. NULL encryption shall only be employed when integrity protec

confidentiality is n

3. Installers should select approved algorithms for each secu

specified in Section 3.2. 

3.5 Recommendations for System Administrators 

the security product containing IPsec. System administrators sha

1. Ensure that end users are proper

is enforced. 

2. 

An end user is the individual using a product that relies on IPsec for sec

40
4 Transport Layer Security (TLS) and Secure Socket Layer 

cols are the 

nternet. TLS is 

 The Internet 

6]. The information 

ction generally applies to both TLS and SSL, except where otherwise noted. 

ake a 

tication server to 

ic guidance 

on has, 

acting as a 

of TLS (for example, dedicated network infrastructure applications primarily involving 

 purpose web 

are primarily 

r) and a server 

ants to conduct 

n are 

ey agreement or 

phemeral DH key and 

ent key. The server may request a 

t, client 

ut 

this 

y 

er suite) and to 

roughout the 

session. This negotiation takes the form of a series of "handshake" messages between the 

client and server. The client states the “cipher suites” that it can handle in the order that 

it prefers them and provides a non-secret random nonce. A cipher suite bundles the 

choice of key-establishment method (e.g., RSA key transport or DH key agreement 

method), symmetric key algorithm and data-integrity hash function to be used into a 

single value. The server then selects the "cipher suite" to be used from the list provided 

by the client, and provides its own random nonce and a certificate containing a signing or 

(SSL) 

4.1 Description 

The Transport Layer Security (TLS) and Secure Socket Layer (SSL) proto

primary end-to-end security protocols used to protect information on the I

an enhanced version of SSL; the protocols are similar, but not identical. 

Engineering Task Force (IETF) governs the TLS protocol [RFC 524

in this se

Only the term TLS will be used in the text, except when it is necessary to m

distinction. 

TLS is a robust protocol that is used to protect various links (e.g. authen

a wireless access point or the e-mail link between client and server). Specif

could vary greatly, based on the intended application. The current discussi

therefore, primarily been limited to the classic scenario where a browser is 

client for a human user, and is interfacing with a web site. Some of the other applications 

machines with no human user) may not require all of the features of general

browsers and servers. Moreover, some cipher suites, as indicated below, 

intended for these infrastructure or more restricted applications. 

A TLS session occurs between a client (typically an end user’s web browse

(typically a web server belonging to an entity with which the end user w

business or needs to exchange information). Symmetric keys for a sessio

determined during a protocol involving either Diffie-Hellman (DH) k

RSA key transport. The latter method implicitly authenticates the server to the client. In 

a DH key agreement, the server authenticates itself by signing an e

sending a certificate with its public signing key. Thus, the server will always send a 

certificate, with either a signing key or a key-agreem

certificate from the client. Except for non-Suite B static DH key-agreemen

certificates will always contain a signing key. An “anonymous” exchange, i.e., witho

server authentication, shall not be used by implementations conforming to 

Recommendation. Static-static DH key establishment should not be used b

implementations conforming to this Recommendation. 

A TLS session begins with a cryptographic negotiation between the client and the server 

to select a suite of algorithms to be used in the session (often called a ciph

establish a set of cryptographic keys to be used for a variety of functions th

41
key-establishment key. The server may also request certificate-based clie

authentication during the handshake.

nt 

 accordance 

, with the random numbers providing assurance of liveliness 

rity and 

erified. This 

t passwords 

f an end user 

e certain that he 

rd thief), but the 

valid. In this case authentication of the end user’s identity (and his authority to use the 

, by contacting 

munications 

s session. All 

 data, and most 

nded in this 

 provide authentication and integrity. Most also provide encryption. If 

encryption is provided, data is encrypted when sent, and decrypted when received. TLS 

graphic non-repudiation service to allow a validation 

r the communications session has ended, e.g., by 

. 

 the choices 

 client offers 

ect it, even 

eference is for 

d public key 

sizes shall be consistent with guidance in the PKI section above.24 Clients shall 

not accept any certificate signed using a key smaller than the approved key size 

 

23 Session keys are then established in

with the selected cipher suite

and freshness to the derived keys. 

When only the server supplies a certificate, the TLS protocol provides for integ

authentication services to a client whose identity has not necessarily been v

is sufficient under many circumstances, such as when TLS is used to protec

or credit card numbers during transactions over the Internet. For example, i

is trying to purchase something from Acme Flowers online, he wants to b

is doing business with Acme Flowers (and not Acme Flours, the credit ca

Acme Flowers server may only be concerned that the credit card number supplied is 

credit card supplied) could be handled outside of the TLS protocol (e.g.

the credit card company to verify the validity of the credit card number). 

After completion of the handshake sequence, TLS provides a secure com

channel between the server and client for the duration of a communication

cipher suites provide authentication and integrity protection for transferred

TLS cipher suites also provide encryption. All TLS cipher suites recomme

document

does not, however, provide a crypto

of the session data or authentication afte

a third party

4.2 Security and Compliance Issues 

4.2.1 General 

1. Servers make the selection of the cipher suite to be used, based on

offered by the client during the handshake protocol. Therefore, if a

any cipher suite not listed in the tables below, the server might sel

when the client indicates (by the order of its list of suites) that its pr

another cipher suite. 

2. Symmetric key sizes shall be compliant with guidance in Part 1, an

23 In the initial Client Hello Message the client proposes a list of all the TLS versions and cipher suites that 

it can use, and, in the Server Hello reply, the server selects a version and cipher suite from the choices 

offered by the client. TLS accommodates several versions (1.0, 1.1 and 1.2) as well as a bewildering 

number of cipher suites. While the ordering of the cipher suites in the Client Hello message is supposed to 

indicate the order of the client’s preference, experimentation reveals that few servers honor this; most 

simply follow their own preference, if it is anywhere on the client’s list. 

24 See Part 1 Sections 5.6.1 and 5.6.2. 

42
for the date of certificate verification by the client. This is generally 

accomplished through control of the root certificate key-store.25 

rtificates shall be consistent 

e value or 

e protected 

ubject public 

h that they are 

LS does not 

 session 

and attack it at a later time when more powerful technology is available. This 

o consideration when determining the security strength needed 

r suites have the form: 

_encryption alg_message authentication_alg.26

he example, 

his example, the 

server provides a public key certificate containing an RSA modulus and encryption 

n cipher block 

grity protection. 

essages with a 

IANA). 

rotection of 

l servers and clients shall use approved 

al clients should support the use of unce with organizational policy, 

interoperability. Not all combinations of algorithms are appropriate 

on of Federal government information; most options that use AES or 3-

IETF identifies 

one TLS cipher suite as mandatory-to-implement: 

 TLS_RSA_WITH_AES_128_CBC_SHA 

 

3. Hash functions used during the signing of TLS ce

with the public key sizes, as given in Section 5.6.2 of Part 1. 

4. In choosing algorithm suites, Federal agencies need to consider th

sensitivity of the information being protected and how long it must b

(see Part 1, Section 6). Public keys contained in certificates (i.e., s

keys) that are used only for authentication need only be large enoug

secure at the time they are used in a TLS session. However, while T

create encrypted files that are saved, an eavesdropper could record a TLS

should be taken int

for the session. 

TLS ciphe

TLS_key_establishment_alg_WITH

For example, 

TLS_RSA_WITH_AES_128_CBC_SHA. 

The “TLS” distinguishes these cipher suites from SSL protocol suites. In t

the key establishment method is the RSA public key algorithm. For t

exponent and the AES block cipher algorithm is used with 128-bit keys i

chaining (CBC) mode to encrypt data and HMAC_SHA1 to provide inte

Acceptable combinations of algorithms are referenced in the handshake m

two-byte indicator assigned by the Internet Assigned Numbers Authority (

Not all cryptographic algorithms available for use are appropriate for the p

Federal government information. Federa

algorithms for transmitting information. Feder

approved algorithms in receiving information in accordan

in order to support 

for the protecti

key TDEA (also called 3DES in TLS cipher suites) are acceptable. The 

25 See Section 2 above 

26 Beginning with TLS 1.2, the “message_authentication_alg” is also used in the PRF (pseudo-random 

function) for deriving keying material. 

43
As described in [RFC4346], all implementations are required to include t

cipher suite. All TLS cipher suites begin with “TLS” (this distinguishes them

original SSL protocol that was the ancestor of TLS). “TLS” is followed

establishment method; in the cipher suite example given above, this is th

key algorithm. For this method, the server is required to have a server publ

establishment certificate using the RSA algorithm. “WITH_AES_128

specifies the cipher mechanism actual

his particular 

 from the 

 by a key 

e RSA public 

ic key key 

_CBC_SHA” 

ly used to transfer “payload data.” In this example, 

the AES block cipher is used with 128-bit keys in cipher block chaining mode, and 

t suitable for 

ay be used to 

 not 

 algorithms 

ent information and are not included in the 

 suites, Elliptic 

uites that are 

e 4-1. All 

rovide integrity 

r payload data, and use the RSA, Diffie-Hellman and DSA public key 

algorithms for key establishment and server authentication. These cipher suites may be 

used with TLS Versions 1.0, 1.1 or 1.2. The [256] suffix means that similar cipher suites 

have also been defined, as of TLS 1.2, which use HMAC-SHA256 for integrity 

protection and for key derivation, replacing SSL’s original MD5/SHA1 pseudorandom 

function (PRF). 

HMAC-SHA1 provides integrity protection. 

4.2.2 Recommended Cipher Suites for Federal Government Use 

A large number of cipher suites have been defined for TLS. Many are no

Federal government use. The cipher suites listed in the following tables m

protect Federal government information. Anonymous cipher suites that do

authenticate the server, or that use HMAC-MD5 or unapproved encryption

shall not be used to protect Federal governm

tables below. Four tables are provided: Conventional Public Key cipher

Curve cipher suites, Pre-shared Key cipher suites and Elliptic Curve-AES s

specific to TLS version 1.2. 

Conventional public key cipher suites with HMAC-SHA1 are listed in Tabl

suites listed in the table are allowed for use in protecting Federal information. The cipher 

suites without the [256] suffix all use HMAC-SHA1 to authenticate and p

protection fo

44
Table 4-1: Conventional Public Key Cipher Suites Using HMAC-SHA1 and HMACSHA256 

SUITE Key Exchange Encryption 

TLS_RSA_WITH_NULL_SHA RSA NULL 

TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA * 3DES_EDE_CBC

TLS_RSA_WITH_AES_128_CBC_SHA [2 RSA 56] ** AES_128_CBC 

TLS_RSA_WITH_AES_256_CBC_SHA [2 RSA 56] AES_256_CBC 

TLS_DH_DSS_WITH_3DES_EDE_CBC_S DH_ HA DSS 3DES_EDE_CBC

TLS_DH_RSA_WITH_3DES_EDE_CBC_ DH_ SHA RSA 3DES_EDE_CBC

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 

*** DHE_DSS 3DES_EDE_CBC

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC

TLS_DH_DSS_WITH_AES_128_CBC_SH DH_ A [256] DSS AES_128_CBC 

TLS_DH_RSA_WITH_AES_128_CBC_SH DH_ A [256] RSA AES_128_CBC 

TLS_DHE_DSS_WITH_AES_128_CBC_SHA 

[256] DHE_DSS AES_128_CBC 

TLS_DHE_RSA_WITH_AES_128_CBC_SHA 

[256] DHE_RSA AES_128_CBC 

TLS_DH_DSS_WITH_AES_256_CBC_SHA [256] DH_DSS AES_256_CBC 

TLS_DH_RSA_WITH_AES_256_CBC_SHA [256] DH_RSA AES_256_CBC 

TLS_DHE_DSS_WITH_AES_256_CBC_SHA 

[256] DHE_DSS AES_256_CBC 

TLS_DHE_RSA_WITH_AES_256_CBC_SHA 

[256] DHE_RSA AES_256_CBC 

* This cipher suite is named by IETF as mandatory-to-implement for TLS version 1.1 

S version 1.2 

LS version 1.0 

. The cipher suites 

 integrity and use 

e Elliptic Curve 

or server authentication. These cipher 

suites may be used with TLS Versions 1.0, 1.1 or 1.2. The [256]/[384] suffix means that 

similar cipher suites have also been defined, as of TLS 1.2, which use HMAC-SHA256 

or HMAC-SHA384 for integrity protection and for key derivation, replacing SSL’s 

original MD5/SHA1 PRF. ECDHE denotes the use of a key exchange algorithm in 

which each side (client and server) each generate an elliptic curve Diffie-Hellman 

ephemeral key pair for use in that particular TLS session. 

[RFC 5246]. 

** This cipher suite is named by IETF as mandatory-to-implement for TL

*** This cipher suite is named by IETF as mandatory-to-implement for T

[RFC 2246]. 

Elliptic curve cipher suites using HMAC-SHA1 are listed in Table 4-2

without [256] or [384] suffixes all use HMAC-SHA1 for payload data

Elliptic Curve algorithms for key agreement. They may use either th

Digital Signature Algorithm (ECDSA) or RSA f

45
Table 4-2: Elliptic Curve Cipher Suites Using HMAC-SHA1/HMACSHA256/HMAC-SHA384 

SUITE Key Exchange Encryption 

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ECDH_ECDSA 3DES_EDE_CBC

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA[256] ECDH_ECDSA AES_128_CBC 

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA[384] ECDH_ECDSA AES_256_CBC 

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE_ECDSA 3DES_EDE_CBC

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA[256] ECDHE_ECDSA AES_128_CBC 

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA[384] ECDHE_ECDSA AES_256_CBC 

TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ECDH_RSA 3DES_EDE_CBC

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA[256] ECDH_RSA AES_128_CBC 

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA[384] ECDH_RSA AES_256_CBC 

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE_RSA 3DES_EDE_CBC

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA[256] ECDHE_RSA AES_128_CBC 

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA[384] ECDHE_RSA AES_256_CBC 

Pre-shared key (PSK) cipher suites using HMAC-SHA1 are listed in Table 

shared keys shall be distributed in a secure manner, such as secure manual 

using a digital signature or key establishment certificate. These cipher su

HMAC-SHA1 to authenticate and provide integrity protection f

4-3; predistribution or 

ites all use 

or payload data. They 

 client) and may 

blishment. For 

is combined 

ecause these 

cipher suites require pre-shared keys, these suites are not generally applicable to classic 

secure web site applications and are not expected to be widely supported in web browser 

clients or general web servers. NIST suggests that these suites be considered in particular 

for infrastructure applications, particularly if frequent authentication of the network 

entities is required. These cipher suites may be used with TLS Versions 1.0, 1.1 or 1.2. 

employ a pre-shared key for entity authentication (for both the server and

also use RSA or ephemeral Diffie-Hellman (DHE) algorithms for key esta

example, when DHE is used, the result of the Diffie Hellman computation 

with the pre-shared key and other input to determine the pre-master secret. 

The pre-shared key shall have a minimum security strength of 112-bits. B

46
Table 4-3: Pre-shared Key Cipher Suites Using HMAC-SHA1 

SUITE 

Key 

Exchange Encryption 

TLS_PSK_WITH_3DES_EDE_CBC_SH PS A K 3DES_EDE_CBC 

TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC 

TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC 

TLS_DHE_PSK_WITH_3DES_EDE_CB DHE_PSK 3DES_EDE_CBC C_SHA

TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC 

TLS_DHE_PSK_WITH_AES_256_CBC DH _SHA E_PSK AES_256_CBC 

TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC 

TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC 

TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC 

Four new cipher suites are introduced with TLS 1.2 using only Suite B alg

are listed in Table 4-4. These cipher suites are a departure from earlier 

in several respects, and only work with TLS version 1.2, which allows the

the Pseudo-Random Function (PRF) used in the process of deriving the sy

(used to protect payload data) from the “pre-master secret” arrived at by

agreement operation. Earlier TLS versions (1.1 and 1.0) use the original 

combination of MD5 and SHA-1 to derive keying material. (The hash func

data integrity was separate and negotiated as part of the cipher suite). For 

suites, ECDHE is used for key establishment. Moreover, TLS 1.2 adds auth

encryption as a symmetric cipher type. The AES GCM cipher suites offer the poten

for higher performance than the AES CBC suites. The CBC modes offer

with those

orithms. These 

TLS cipher suites 

 negotiation of 

mmetric keys 

 the key 

SSL PRF, a 

tion used for 

these cipher 

enticated 

tial 

 compatibility 

 implementations still using AES-CBC. Elliptic curve key establishment offers 

performance advantages over the RSA alternatives and at higher security strengths. 

et be widely available or deployed, but NIST suggests 

, wherever practical, servers and clients be procured that support these cipher suites, 

y orm security strength 

Table 4-4: TLS 1.2-Suite B Cipher Suites 

These cipher suites are too new to y

that

and that they be selected for use wherever ver high perf ance and 

are required. 

Suite MAC PRF

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 Galois Ctr. P_SHA256 

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Galois Ctr. P_SHA384 

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 

HMACSHA256 P_SHA256 

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 

HMACSHA384 P_SHA384 

4.3 Procurement Guidance 

The following recommendations are for any individual that makes a purchasing decision 

for acquiring a TLS/SSL component. Recommendations for purchasing are: 

47
General requirements: 

.0 or higher). 

.2 above). 

s shall use an approved random bit generator [SP 800-90]. 

1 e following cipher suites: 

_CBC_SHA 

ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 

shall protect the server’s private key from unauthorized 

disclosure. 

s should select cipher suites in the order of preference submitted 

by the client. 

C

1 rt at least one of the following four 

SHA 

vide the list of 

tion of the 

icate before trusting the server’s certificate 

ifier presented 

identifier displayed by the browser. 

5. Client implementations should give the end user an opportunity to verify that the 

site named in the certificate and displayed by the browser is consistent with the 

6. Client implementations for human users shall provide an indication to the user

(e.g, by generating a message) if the site named in the certificate does not match 

the URL27 that the end user requested. 

 

1. New procurements of clients and servers shall support TLS (SSL 3

2. Implementations shall support approved algorithms (see Section 4

3. Implementations shall support client authentication using public key certificates. 

4. Implementation

Server implementations: 

. Web server implementations should support th

TLS_ECDH_ECDSA_WITH_3DES_EDE

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 

TLS_

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 

2. Implementations 

3. Implementation

lient implementations: 

. Federal client implementations should suppo

cipher suites: 

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 

2. Client implementations should allow system administrators to pro

cipher suites to be provided to the server in order of preference. 

3. Client implementations shall support the recognition and verifica

certificate path for the server’s certif

(see Section 2 above). 

4. Client implementations shall be capable of verifying that the ident

in the server’s certificate matches the

site that the end user was attempting to reach. 

27 Uniform Resource Locator; the unique address for a file (e.g., a web page) that is accessible on the 

Internet. 

48
7. Client implementations shall be capable of supporting a well-managed root 

certificate key-store (see Section 2 above.) 

The system installer is the individual(s) that installs the TLS/SSL application and 

figuration of the system. 

28. 

tificates, in accordance with applicable 

to the server in 

ferred cipher suite 

Hello messages. 

 to a CA root 

 user population. 

rposes (e.g., 

ions use the 

server authentication, and this is 

 key agreement scheme. 

orithms and key sizes. 

BC_SHA, 

C_SHA, 

SHA, and 

C_SHA. 

11. Federal government clients should be configured to include at least one of the 

following four cipher suites: 

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 

 

4.4 Recommendations for System Installers 

performs the initial con

System installers should: 

1. Configure the root certificate store appropriately (See Section 2)

2. Disable unapproved cipher suites, wherever possible. 

3. Disable SSL 2.0 (most clients allow this). 

4. Properly configure and install client cer

policy. 

5. Configure client implementations to provide a list of cipher suites 

order of preference if allowed by the application. 

6. Configure server implementations to select the client’s most pre

from the cipher suite lists presented by the clients in their Client

7. Ensure that server certificates are not expired and that they chain

certificate that is normally in the root store of the intended

8. The public keys in certificates should not be used for multiple pu

digital signatures and key establishment). However, TLS applicat

RSA server keys for both key agreement and 

acceptable because it is a carefully analyzed

9. Systems shall be configured to use approved alg

10. Federal government servers should be configured to include the following four 

cipher suites: 

TLS_ECDH_ECDSA_WITH_3DES_EDE_C

TLS_ECDH_ECDSA_WITH_AES_128_CB

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_

TLS_ECDHE_RSA_WITH_AES_128_CB

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 

28 Note that some common desktop operating systems permit centralized management of root stores; 

however, many systems and browsers are shipped pre-configured with hundreds of root certificates preinstalled. 

49
4.5 Recommendations for System Administrators 

The System Administrator is the individual who runs the TLS/SSL appli

to-day basis and, on client implementations, interacts with the end user. T

acquiring certificates for the server and assisting the user in acquirin

system administrator shall ensure that end users are pr

cation on a dayhis includes 

g certificates. The 

operly trained and that the 

olicy for using the product is enforced. 

opriate strength 

lgorithm 

cryption. 

3. Configure the client system to provide the list of cipher suites to the server in the 

ipher suite presented first and 

ertificate store for the intended client 

certificates, 

d path discovery according to organizational policy 

shall: 

nd system 

y contained in the user’s 

certificate if it is contained outside the client (e.g., on a smart card), as advised by 

the system administrator. 

3. Look for browser indicators that a secure session is in progress (e.g., Internet 

Explorer’s closed padlock) 

4. Verify that the site named in the certificate and displayed by the browser is 

consistent with the site that the end user is attempting to reach. 

organization’s security p

System administrators should: 

1. Obtain and install an appropriate server certificate with an appr

public key that can be verified using the SHA-1 or SHA-256 hash a

2. Maintain the server such that it only accepts approved algorithms and cipher 

suites that use 3TDES or AES for en

order of their preference with the most preferred c

the least preferred cipher suite presented last. 

If client authentication is to be used, system administrators should: 

1. Maintain the root and intermediate c

2. Support policy processing an

if they are used, and 

3. Support CRL or OCSP responder processing. 

4.6 Recommendations for End Users 

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

1. Operate their client systems as instructed by their organization a

administrator. 

2. Protect the private key associated with the public ke

50
5 Secure/Multipart Internet Mail Extensions (S/MIME) 

t way to 

], [RFC 2045], [RFC 2046], 

[RFC 2047], [RFC 2048], and [RFC 2049]. S/MIME provides the following 

g applications: 

g party using digital signatures, 

l signatures, and 

natures, 

 email, as well 

lementations 

/MIME user 

identities, to bind those identities to the user’s public key through public key certificates, 

cryption or to 

d information on 

5.1 Description 

Secure/Multipurpose Internet Mail Extensions (S/MIME) provides a consisten

send and receive secure Internet mail. S/MIME is a set of specifications that are defined 

by a series of IETF RFCs, namely [RFC 3851], [RFC 3852

cryptographic security services for electronic messagin

• Authentication of a sendin

• Message integrity and non-repudiation of origin using digita

• Confidentiality using encryption. 

S/MIME, therefore, requires a suite of algorithms for creating digital sig

generating hash values, establishing keys and encrypting the content of the

as some means of establishing and sharing digital identities. Federal imp

rely on a public key infrastructure, specifically X.509 PKI, to establish S

to provide digital signatures and to provide keys to be used for content en

establish symmetric keys for use on a per message basis. For detaile

PKIs, see [SP 800-32]. 

Stored electronic mail encompasses key management issues associated with encrypted 

file integrity and with transmission over a network. It is therefore necessary 1) to 

ey management 

ly store the key(s) 

associated with encrypted email until it is no longer necessary for a recipient to be able to 

e email. 

anism that 

TP). 

5.2 Security and Compliance Issues 

d with different combinations of security features 

ers and receivers may have different 

s of different 

strengths. This can lead to numerous interoperability issues. Federal clients using secure 

email shall be able to perform the following: 

• Send and receive signed messages, 

• Send and receive encrypted messages, 

• Send and receive signed and encrypted messages, 

• Request, send and process signed receipts, and 

establish pair-wise and/or multicast (sent to more than one recipient) k

relationships between the sender and receiver(s) and 2) to secure

decrypt or verify the integrity of th

S/MIME is not restricted to email; it can be used with any transport mech

employs MIME protocols, such as the Hypertext Transfer Protocol (HT

S/MIME products can be implemente

and a variety of cryptographic algorithms. Send

capabilities and may be sending messages protected with algorithm

51
• Process messages from secure email list clients (includes suppressing receipts, as 

required, and nondisclosure of list recipients, as required). 

certified, 

5-2 below), 

• Require X.509 certificates that conform to Federal PKI X.509 Certificates and the 

sing email with security labels 

gh the signing 

appropriate for 

ations allow the 

ve been 

izations shall use 

ent and 

ollowing tables specify a variety of cipher suites that may 

be used to protect Federal information and information systems. Any of the algorithms 

may be used, in accordance with security strength time 

rictions given in Part 1, to protect Federal information in combinations other 

 those d

Table 5-1: Cipher Suite 1 (ALS1) 

Furthermore, Federal systems shall: 

• Utilize cryptographic modules that are FIPS 140-1 or FIPS 140-2 

• Support cryptographic suites ALS 1 and ALS 2 (see Tables 5-1 and 

and

CRL Extensions Profile. 

Federal clients should be capable of sending and proces

and securely binding senders’ certificates to their signatures throu

certificate attribute as described in [RFC 5035].29 

The most widely accepted, standard S/MIME profile is [RFC 3851]30. Not all 

cryptographic algorithms available for use in support of these features are 

the protection of Federal government information. The S/MIME specific

selection of individual algorithms. However, a number of cipher suites ha

specified to define a specific combination of algorithms. Federal organ

approved algorithms within S/MIME implementations for key establishm

transmitting messages. The f

listed in the following tables 

frame rest

than isplayed. 

Mechanism Guidance 

Digital 

Signatures 

RSA with; key

447] 

 sizes ≥ 1024 bits 

[RFC 3

Hash SHA-1 

[FIPS 180-3] 

Key Transport RSA with key sizes ≥ 1024 bits 

[RFC 3447] and [SP 800-56B]31 (SP 800-56B under development) 

Encryption TDEA in CBC mode 

[SP 800-67] 

 

29 Both of these services are defined in S/MIME V3 standards [RFC 2634]. 

30 RFC3851 is currently under revision. See http://www.rfc-editor.org/queue.html for additional 

information on draft 3851bis, draft-ietf-smime-3851bis-01.txt 

31 SP 800-56B is under development. A draft should be ready for public comment by the summer of 2008 

52
Table 5-2: Cipher Suite 2 (ALS2) 

Mechanism Guidance 

Di

Sig

gital 

natures 

ith; key sizes ≥ 1024 bits 

6-3] 

DSA w

[FIPS18

Hash SHA-1 

[FIPS 180-2]32

Key Transpo sizes ≥ 1024 bits 

 [SP 800-56B]31

rt RSA with key

[RFC 3447] and

Encryption TDEA in CBC mode 

[SP 800-67, RFC 3851] 

Table 5-3: Cipher Suite 3 (ALS3) 

Mechanism Guidance 

Digital 

Signatures 

RSA with keys ≥ 1024 

7] and [FIPS

bits 

[RFC 344 186-3] 

Hash SHA-1 

[FIPS 180-3] 

Key Transport RSA with key sizes ≥ 1024 bits 

B]311 [SP 800-56

Encryption AES-128 in CBC mo

0-38A] 

de 

[FIPS 197] and [SP 80

Table 5-4: Cipher Suite 4 (ALS4) 

Mechanism Guidance 

Digital 

Signatures 

DSA with key sizes ≥ 1024bits 

[FIPS186-3] 

Hash SHA-1 

[FIPS 180-3] 

Key 

Agreement 

Diffie-Hellman 

[RFC 2631] and [SP 800-56A] 

Encryption TDEA in CBC mode 

[SP 800-67], [SP 800-38A] 

 

32 FIPS 180-2 is under revision. See http://csrc.nist.gov/publications/PubsFIPS.html for additional 

information on FIPS 180-3. 

53
Table 5-5: Cipher Suite 5 (ALS5) 

Mechanism Guidance 

Di

Sig

gital 

natures 

ith key sizes ≥ 1024 bits 

86-3] 

DSA w

[FIPS 1

Hash SHA-256

[FIPS 180-3] 

Key 

Agreement 

an 

00-56A] 

Diffie-Hellm

[RFC 2631] and [SP 8

Encryption AES in CBC mode

[FIPS 197] and [SP 800-38A] 

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

Mechanism Guidance 

Digita

Signatur

l 

es 

ECDSA with P-256 

[X9.62] 

Hash SHA-256 

[FIPS 180-3] 

Key 

Agreement 

H with P-256 

] 

ECD

[SEC1

Key 

Derivation 

56 

1] 

Based on SHA-2

[SEC

Key Wrap AES-128 

[RFC 3394] 

Encryption AES-128 in CBC mode 

[FIPS 197] 

* RFC 5008

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

Mechanism Guidance 

Di

Signatu

gital 

res 

 P-384 

9.62] 

ECDSA with

[X

Hash SHA-384 

[FIPS 180-3] 

Key with P-384 

[SEC1] 

ECDH

Agreement 

Key 

Derivation 

Based on SHA-384 

[SEC1] 

Key Wrap AES-256 

[RFC 3394] 

Encryption AES-256 in CBC mode 

[FIPS 197] 

* see [RFC 5008] 

54
Note that after 2010, Federal systems shall not use SHA-1 as a hash alg

signatures. Also, a

orithm for digital 

t that time, algorithm and key size requirements may also change. 

ey Infrastructure with valid Federal PKI 

 140-2.

olicies, be 

pproved for 

ose instances, users should be presented 

with a warning banner explaining that the cryptographic mechanisms used are weak and, 

hentication cannot be assured. 

5.3 Procurement Guidance 

for acquiring an S/MIME-enabled component. 

ent, all 

d ALS 2. 

thms that 

provide more protection for digital signatures than SHA-1, such as ALS 5, Cipher 

sers receive 

ved algorithms. 

0. Therefore, 

 needs for cryptography beyond 2010 and 

purchase for the future. Cryptographic algorithm implementations should be 

rithms. 

 client or some 

r function shall be capable of generating public 

private key pairs on behalf of the user. 

5.4 Recommendations for System Installers 

The system installer is the individual that installs the S/MIME application and performs 

the initial configuration of the system. 

(See SP 800-57 Part 1.) 

Federal clients shall be supported by a Public K

X.509 certificates for senders and receivers. 

Cryptographic modules used in Federal systems shall comply with FIPS

Federal S/MIME implementations may, in accordance with organizational p

capable of receiving messages protected with algorithm suites that are not a

Federal use in sending protected messages. In th

therefore, integrity and aut

The following recommendations are for any individual that makes a purchasing decision 

1. In support of security and compatibility across the Federal governm

Federal information systems shall support ALS 1 an

2. Procurement officials should buy products that support hash algori

Suite B level 1 and Cipher Suite B level 2 (see [FIPS 180-3]). 

3. Federal clients should support MD5 and RC2 in the event that u

correspondence signed or encrypted with these weaker, unappro

4. Federal agencies shall not use SHA-1 for digital signatures after 201

when selecting a product with S/MIME functionality, procurement officials 

should consider organizational

modular so as to allow for new algo

5. If an S/MIME client needs to generate a key pair, then the S/MIME

related administrative utility o

55
1. Federal clients shall be configured to support cipher suites ALS1 and ALS2 for 

interoperability as described above in Section 5.2. 

ents shall be 

algorithms and key size requirements as 

s shall be configured so that they only permit the use of approved 

y default to 

ite. Furthermore, installers should

configure clients such that there is a straightforward means for end users to 

rability and in 

5. System installers should configure clients such that end users can use unique 

., encryption, digital signatures) at their 

who runs the S/MIME application on a dayor shall ensure that end users are properly trained and that 

shall be 

maintained to support cipher suites with algorithms and key size requirements as 

approved 

t or sign new 

fault to the use 

 approved cipher algorithm suite. Furthermore, administrators should

maintain a straightforward means for end users to change default settings and 

select algorithms as needed for interoperability and in accordance with 

organizational needs and policies. 

5. System administrators should provide training for users on the relative security 

provided by various cryptographic algorithms and on organizational policies for 

their use. 

2. In accordance with security requirements beyond 2010, Federal cli

configured to support cipher suites with 

described in SP 800-57, Part 1. 

3. System

cryptographic algorithms and approved key sizes to encrypt or sign new 

messages. 

4. Installers should install and configure S/MIME clients such that the

the use of an approved cipher algorithm su

change default settings and select algorithms as needed for interope

accordance with organizational needs and policies. 

certificates for each security function (e.g

disposal. 

5.5 Recommendations for System Administrators 

The System Administrator is the individual 

to-day basis and, on client implementations, interacts with the end user. 

1. The system administrat

the organization’s security policy is enforced. 

2. In accordance with security requirements beyond 2010, Federal clients 

described in SP 800-57 Part 1. 

3. Systems shall be maintained so that they only permit the use of 

cryptographic algorithms and approved key sizes to encryp

messages. 

4. Administrators should maintain S/MIME clients such that they de

of an

56
6. System administrators should provide end users with guidance on

certificates

 how 

 and keys are stored and managed, and identify the end user’s related 

responsibilities. 

stem. Even within a centrally 

nd system 

administrators. 

n at their disposal.33 

3. Users shall protect their private keys from unauthorized disclosure. 

4. Users should not send the same message both encrypted and in plain text. 

 

5.6 Recommendations for End Users 

An end user is the individual using a client to access the sy

managed environment, end users may find that they have a significant amount of control 

over some of the security features within an SMIME implementation. 

1. Users shall operate their system as instructed by their organization a

2. Users should use unique certificates for each security functio

33 If they have not been supplied with certificates by their home organizations, users can obtain certificates 

from a number of organizations via the web. 

57
6 Kerberos 

e secure 

rk, where client 

ation of Kerberos 

 work of Steve 

s is used for 

 between a 

s granted by means of 

. 

 of an 

GS). The AS and TGS may 

S, and TGS 

The user’s key is 

. 

The following is 

he process (e.g., the generation of most keys and the use of most 

tication 

ion are protected with checksums and encryption when transmitted. 

er symmetric 

. 

icket from the 

ity period, and 

 provides the Ticket Granting Ticket to the TGS, along with the client’s 

own authentication information, which includes the client identifier and a time 

riod of the 

ket Granting Ticket. The TGS then generates a Target Server Ticket and sends 

 

6.1 Description 

The Kerberos authentication mechanism was developed at MIT to enable th

authentication of users to Target Servers (TSs) over an unprotected netwo

software acts on behalf of a user34. The original design and implement

and its first three revisions (i.e., versions 1 through 4) were primarily the

Miller, Clifford Neuman, Jerome Saltzer and Jeffrey Schiller35. Kerbero

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

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 i

tickets and authentication information, each encrypted with symmetric keys

The trusted third party is a Key Distribution Center (KDC), which consists

Authentication Server (AS) and a Ticket Granting Service (T

or may not reside on the same machine. The KDC has a database of user, T

symmetric keys. All KDC symmetric keys are accessible by the TGS. 

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. 

a simplification of t

cryptographic operations are not specified). For example, tickets and authen

informat

1. A user logs onto a client by entering a password, from which a us

key is generated

2. The client, acting on behalf of the user, requests a Ticket Granting T

AS. 

3. The AS generates a Ticket Granting Ticket, for a specified valid

sends it to the client. 

4. The client

stamp. 

5. The TGS checks the authentication information and the validity pe

Tic

it to the client. 

34 Note that a single client implementation may be used by multiple users, and a single user may use 

multiple client implementations (e.g., a user could access different workstations, each with its own client 

implementation). 

35 The design was based in part upon a protocol proposed in by Needham and Schroeder [NEED] with 

modifications provided by Denning and Sacco [DENN]. For more detail on the goals, motivations, and 

rationale of Kerberos see [NEUM]. 

58
59

t sends authentication information and the Target Server Ticket to the 

d of the Target 

Server Ticket; if the information is reasonable, the user is authenticated to the TS. 

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

6. The clien

TS. 

7. The TS checks the authentication information and the validity perio

1

23 5 4

TS

AS

Client

TGS

1. User-Client Interface

2. Request for Ticket Granting Ticket

3. Ticket Granting Ticket

4. Request for Target Server Ticket

5. Target Server Ticket

6. Request for Service

KDC

6

User

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

Figure 6-1: The Kerberos Protocol 

Each TGS has it
60

1

4

2 3

5

TS

Realm2

AS

Realm1

Client

Realm1

TGS1

Realm1

1. User-Client Interface

2. Request for Ticket Granting Ticket

3. Ticket Granting Ticket for TGS1

4. Request for Ticket Granting Ticket

5. Ticket Granting Ticket for TGS2

6. Request for Target Server Ticket 

7. Target Server Ticket for TS

8. Request for Service

6

User

TGS2

Realm2

7

8

ternative Kerberos protocol between the client and the AS (as specified in [RFC 

y pairs with 

 associated 

ignature key pair and digital signature certificate. 

he KDC in one of 

 key agreement (e.g., Diffie-Hellman) between the AS and the client36, or 

2. using key transport (e.g., RSA), where the AS generates the user symmetric key, 

and sends the key to the client37. 

Once the user symmetric key is established, the remainder of the protocol proceeds as 

previously described. The need for user symmetric keys generated from passwords can 

thus be avoided. 

 

Figure 6-2: Cross-Realm Authentication 

In an al

4556]), either both the user and the AS have key establishment public ke

corresponding certificates, or the user has a key establishment key pair and

certificate, and the AS has a digital s

The user symmetric key can then be established between the client and t

two ways: 

1. using

36 In this case, both the user and the AS have key establishment key pairs. 

37 In this case, the user has a key establishment key pair, and the AS has a digital signature key pair. 
6.2 Security and Compliance Issues 

1. Kerberos version 5 was initially specified in [RFC 1510]. 

security was updated in version 5 [RFC 41

More recently, the 

20]; however, many existing 

r use in protecting 

of Kerberos 

ndomness) 

 (the client key 

ot provide enough 

s, a dictionary attack38 is feasible. 

e selected to 

sing the 

etric keys that 

he KDC stores 

t 

s require 

mensurate with the protection required for the data that they 

ared data). 

tion of these 

nd database do 

the TGS to obtain 

d prevent all users from obtaining services 

from the TS. 

ity of clock 

en previous 

 TS after they 

 

implementations still correspond to the initial RFC. 

2. Many current Kerberos implementations based on [RFC 1510] rely on DES for 

symmetric encryption functions. DES is no longer approved fo

Federal government information. 

3. If a keyless checksum computation is used for the data integrity 

messages, the integrity of the message may be inadequate. 

4. Some Kerberos implementations rely solely on the entropy (i.e., ra

provided by the user password to generate the symmetric client key

is a hash of the user’s password). Passwords, in general, do n

randomness for generating a key. In such case

If passwords are used to generate cryptographic keys, they should b

maximize the difficulty of a password guessing attack, thus increa

difficulty of an off-line dictionary attack [SP 800-118].39

5. Compromising the client, KDC, or TS could compromise the symm

they contain and thereby compromise the system. In particular, t

keying information for all the KDC users, the TGS, and any TS tha

communicates directly with the KDC TGS. These symmetric key

protection that is com

protect (e.g., tickets, other keys, authentication information, and sh

6. Tickets are kept in the memory of both a client and a TS. The protec

tickets is dependent on the strength of the access control protection afforded by 

the client and TS systems. 

7. The TGS has read-only access to the KDC database. If the TGS a

not reside on the same machine, a secure channel is required for 

the required TS keys. 

8. A failure of the AS or the TGS woul

9. Clocks must be synchronized in order to accurately assess the valid

authentication information and tickets. If the TS is running late, th

authentication information and tickets could be played back to the

have expired. 

38 A dictionary attack is a technique for guessing a password by selecting candidate passwords from a list 

of words commonly found in a dictionary, or derived from words commonly found in a dictionary. Each 

selected candidate is tested as though it were the actual password until the result of the test indicates that 

the correct password has been selected. 

39 SP 800-118 Guide to Enterprise Password Management is currently under development. A draft will be 

available viewing and comment by November 2008. 

61
6.3 Procurement Guidance 

The following recommendations are for any individual that makes a purchasing decision 

vernment procurements shall specify the inclusion of approved symmetric key 

S)) [RFC 

e available for data 

IPS 201 

ed; therefore, when tokens 

ing them on 

f passwords 

 token. 

sword mechanism 

39 and an approved hash 

rithm. 

shall enforce a 

assword policy in accordance with [SP 800-118].39

 establishment can 

should be 

r further 

8. Procurement officials should consider whether inter-realm networking is 

in the software if it’s needed. 

dated at FIPS 

and performs 

1. New systems shall conform to version 5 [RFC 4120]. 

2. Government systems shall be configured so that approved algorithms (e.g., AES) 

shall be used (see [RFC 3962]), and DES shall not be used. 

3. An approved MAC checksum (e.g., HMAC-SHA1) shall be installed and used in 

all implementations for data integrity purposes [RFC 3962]. 

for acquiring a Kerberos capability. 

1. New procurements shall conform to version 5 [RFC 4120]. 

2. Go

encryption algorithms (e.g., the Advanced Encryption Standard (AE

3962]. 

3. An approved MAC computation (e.g., HMAC-SHA1) shall b

integrity with encryption (See [RFC 3962]). 

4. Kerberos version 5 permits the use of smart cards or tokens (e.g., F

Personal Identity Verification cards, [FIPS 201]) to store a user's password. 

Passwords stored on tokens shall be randomly generat

are used, a means of generating random passwords and securely writ

the token shall be available. When tokens are used, manual entry o

shall not be permitted except to authenticate the user to the

5. If passwords are used to form user symmetric keys, then the pas

shall support the use of strong passwords, [SP 800-118],

algorithm (e.g., SHA-1 or stronger) shall be used as the hash algo

6. If passwords are generated by users, then the system software

strong p

7. Kerberos with public key authentication and subsequent key

provide stronger security than the use of password-based keys and 

available where PKI mechanisms are available. See [RFC 4556] fo

information. 

necessary and include the capability

9. Cryptographic modules used by CAs, TSs and clients shall be vali

140-2 Level 1 or higher.

6.4 Recommendations for System Installers 

The system installer is any individual(s) that installs a Kerberos capability 

the initial configuration of the system. 

62
4. The AS, TGS, TSs, and clients shall use strong access control mechanisms40

e.g., FIPS 

sword. 

therefore, when 

nd securely 

the token shall be used. When tokens are used, 

nticate 

ablishment can 

. See [RFC 

ll generate strong 

ords [SP 800-118]. 

roved hash 

rd hashing 

lg rithm. 

yptographic keys, the password 

words [SP 800-

10. A backup AS and TGS should be provided so as to minimize the impact in case 

s. 

ew system is 

dministrators 

1. System administrators shall ensure that users are properly trained and that the 

and client shall be physically secured. 

e encrypted or physically protected at the client, TS, and TGS sites. 

 

(physical and logical) for protecting and updating keys. 

5. Kerberos version 5 permits the use of smart cards or tokens (

201 Personal Identity Verification cards) to store a user's pas

Passwords stored on tokens shall be randomly generated; 

tokens are used, a means of generating random passwords a

writing them on 

manual entry of passwords shall not be permitted except to authe

the user to the token. 

6. Kerberos with public key-based user authentication and key est

provide stronger security than password-based keys and should be installed where 

PKI mechanisms are available and the software has the capability

4556] for further information. 

7. If user passwords are generated by the system, the system sha

passw 39

8. If passwords are used to form user symmetric keys, then an app

algorithm (e.g., SHA-1 or stronger) shall be used as the passwo

a o

9. If user passwords are used to generate cr

mechanism shall be configured to use and require strong pass

118].39

of operational failure or denial-of-service attack

11. Clocks should be synchronized periodically and whenever a n

brought on-line41 

6.5 Recommendations for System A

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. 

organization’s security policy is enforced. 

2. The AS, TGS, TS, 

3. Tickets shall b

40 Strong access control mechanisms either prevent or detect unauthorized attempts to access or replace 

sensitive data. These controls may be physical (e.g., locks, guards, or alarms) or logical (e.g., encryption, 

data integrity, or entity authentication). 

41 (see http://www.nist.time.gov). 

63
4. If the passwords are generated by the user, then the system admin

develop a p

istrator shall

olicy for selecting strong passwords that is enforced by the software 

5. System clocks shall be periodically verified to ensure synchronization. 

d in accordance 

heir password from unauthorized disclosure. If a token 

containing a password or key is provided, users shall protect the token from 

unauthorized use. Users shall report the loss of physical tokens or the 

compromise of passwords. 

 

 

[SP 800-118].39

6.6 Recommendations for End Users 

An end user is the individual using the Kerberos capability. 

1. If user-selected passwords are allowed, they shall be generate

with the organization’s password policy.

2. Users shall protect t

64
7 Over-The-Air Rekeying (OTAR) Key Management Messages 

rekeying of digital radios 

graphic 

sitive 

e security types 

e Type 3 

 [OTAR1]42. 

ment Facilities 

ent 

dinate mobile radios 

rred from a KMF to a mobile radio, 

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

 

(KMMs)

7.1 Description 

A key management protocol has been specified for over-the-air 

[OTAR]. This protocol has been designed to handle several types of crypto

security, one of which, Type 3, has been designed for unclassified, sen

communications and is discussed herein. The only differences between th

are the cryptographic algorithms used and the security requirements. Th

algorithms and security requirements are addressed in both [OTAR] and

For key management, a secure mobile system consists of Key Manage

(KMFs) and mobile radios that are subordinate to each KMF. Key Managem

Messages (KMMs) are exchanged between each KMF and its subor

(see Figure 7-1). Cryptographic keys are transfe

Key Management

Facility

O O O O

Mobile Radio Mobile Radio

KMMs

O O Portable Radio

: Normal radio communications (i.e., no KMMs)

Figure 7-1: Radio Communications with OTAR 

42 [OTAR] provides an overview of the key management techniques and the protocol. [OTAR1] specifies 

the general security requirements for transmitting Type 3 key management messages (KMMs), the 

requirements for wrapping the keys, the techniques used for KMM integrity and the mechanism used to 

protect against replay of the KMMs. 

65
Three general types of keys are used in OTAR: a Key-Wrapping K

Encryption Key (TEK) 

ey (KWK), a Trafficand a key to be used for the computation of a Message 

Authentication Code (MAC). 

ance Issues 

 allow the use of any block cipher algorithm 

ave been 

d AES. 

 security that 

 “key bundle” 

 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 

 secure, the one-key version of the TDEA is 

ect the integrity 

pecified in [OTAR1], using the CBC-MAC mode of operation. 

 algorithm. AES 

 is better 

o guidance on the length 

of cryptoperiods (i.e., the number of messages or the length of time that a key may be 

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

7.2 Security and Compli

7.2.1 Cryptographic Algorithms 

Although the protocol has been designed to

to apply the cryptographic protection, only three block cipher algorithms h

included in the specification: DES, TDEA an

Approval for DES has been withdrawn because DES no longer provides the

is needed to protect Federal government information. 

TDEA [SP800-67] uses three DES encryption/decryption operations with a

consisting of three separate

compatibility with DES, and a three-key version (3-TDEA), whereby the three keys are 

different. Since DES is no longer considered

also no longer considered secure. 

7.2.2 Message Authentication and Cryptoperiods 

A Message Authentication Code (MAC) is used to authenticate and prot

of many of the KMMs as s

The security of a MAC depends, in part, on the block size of the MAC

has a larger block size than 3-TDEA, and so the security of AES CBC-MAC

than 3-TDEA CBC-MAC. The OTAR documentation provides n

used before it must be changed). 

For AES, the number of messages that can be authenticated using a giv

66
7.2.3 Key Usage 

Part 1 of this Recommendation states that keys should be used for only

However, [OTAR1] states that the key used to generate a MAC must be 

reserved for authentication and integrity protection purposes, or a key der

Traffic-Encryption Key (TEK) using a key wrapping algorithm. In th

that the TEK might be used for both e

 one purpose.43

either a key 

ived from a 

is latter case, note 

ncryption and for key derivation. In order to 

comply with the recommendation to use a key for only one purpose, the MAC key 

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 

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 

dio no longer has the capability of communicating securely 

7.2.6 Random bit generators 

 the KMF using an approved random bit generator that 

e cryptographic 

The following recommendations are for any individual(s) that makes a purchasing 

gorithm. 

 be included. 

ents that include TDEA shall be capable of limiting the number of uses of a 

single TDEA key bundle to 1,000,000.44

4. KMFs and radios shall conform to [OTAR] and [OTAR1]. 

 

should be a key reserved for a single purpose. 

7.2.4 Backup 

deleted from 

7.2.5 Rekeying 

network so that the lost ra

with other radios in the network. 

Keys shall be generated at

provides sufficient randomness for the desired security strength of th

processes [SP 800-90]. 

7.3 Procurement Guidance 

decision for acquiring OTAR equipment. 

1. Procurements shall include the AES or TDEA al

2. If TDEA is provided in an implementation, the three-key version shall

3. Procurem

43 There is an allowed exception to this rule, but it does not apply to OTAR (see Section 5.2 in Part 1). 

44 See Section 7.2.2. 

67
5. When keys are generated within KMFs, they shall be generated using approved 

6. MF and the mobile radios shall be validated at 

7. KMFs shall include backup and archive capabilities to support reconstitution of the 

e, earthquake). 

stallers 

nd performs 

 mechanisms 

ssword token). 

ures to transition 

om a backup KMF to the primary 

d MAC keys should be 

e KMF in 

 and Section 7.2.2. 

n assessment of 

shall be made. The use of any 

 in place for 

 by the KMF or by other radios. 

hms, and to 

ree-key version shall be used, and the 

8. For implementations using TDEA in which the cryptoperiod of a key bundle is 

configurable, the cryptoperiod shall be set to a value less than 1,000,000 messages. 

7.5 Recommendations for System Administrators 

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. 

random bit generators. 

Cryptographic modules used by the K

FIPS 140-2 Level 1 or higher. 

KMF in the event of a disaster (e.g., fir

7.4 Recommendations for System In

The system installer is the individual(s) that installs an OTAR capability a

the initial configuration of the system components. 

1. The KMF shall use and have strong physical and logical access control

to protect the cryptographic keys (e.g., physical locks, alarms or pa

2. Backup KMFs should be provided, along with a strategy and proced

from a primary KMF to a backup KMF, and fr

KMF. 

3. A TEK should not be used for multiple purposes. Reserve

used for message authentication and integrity protection. 

4. Maximum cryptoperiods for each key type shall be determined at th

accordance with the organization’s security policy

5. Radios shall be accounted for; in the case of a lost or stolen radio, a

the effect of a loss of the keys contained in that radio 

key contained in that radio shall be discontinued. Procedures shall be

replacing these keys if used

6. Implementations shall be configured to use the AES or TDEA algorit

disallow the use of DES. 

7. If TDEA is provided and is to be used, the th

one-key version shall not be used. 

68
1. System administrators shall ensure that the organization’s security policy is enforced. 

ministrators shall protect the keying material from disclosure and 

ryptoperiod. 

aintain the availability of the KMF, system administrators shall ensure that 

te the KMF after a 

nd the 

case of lost radios or suspected key compromises. 

 at the KMF with sufficient information to indicate 

radios. 

ystem 

2. End users shall protect their radios from loss and unauthorized access. 

3. In the event that a radio is lost or a key is suspected of being compromised, end users 

shall immediately notify the system administrator in accordance with the 

organization’s security policy. 

2. System ad

modification. 

3. Procedures shall be in place for replacing keys at the end of their c

4. To m

sufficient information is stored in a secure location to reconstitu

disaster. 

5. System administrators shall train end users in the use of their radios a

procedures to be followed in the 

6. Audit logs should be maintained

which keys are shared by which 

 

7.6 Recommendations for End Users 

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

1. End Users shall operate radios as instructed by their organization and s

administrators. 

69
8 Domain Name System Security Extensions (DNSSEC) 

is the global 

TP servers, 

dling mappings 

e other forms of data 

en encoded 

(RR) that 

n name and an 

ular 

 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 

hild delegations 

ibuted all over 

e DNS 

s a primary master 

s that 

ry authoritative master server. 

Another set of components are caching recursive servers45, which query the authoritative 

servers and cache any replies user’s client system, software components 

known as r ke DNS queries to recursive caches and/or authoritative servers. 

Figure 8-1 depicts the relationship b tween the D omponents. 

Figure 8-1: DNS Components 

 

8.1 Description 

Domain Name System (DNS), as defined in [RFC 1034] and [RFC 1035], 

hierarchical distributed database system for mapping Internet addresses, SM

and other information to a human readable name. Its main purpose is han

between host domain names and Internet addresses, but it can handl

as well, such as host system information, geographic-location of servers, ev

digital certificates. DNS data is stored as individual Resource Records 

associates a piece of data (e.g., IP address, mail server name) with a domai

identifying Resource Record type code (RR type). All the RRs for a partic

organization are stored in

or more child delegated zones. For example, most Federal agencies are c

under the “.gov” parent zone. 

Zone information is maintained on authoritative servers, which are distr

the Internet to answer queries according to the DNS network protocols. Th

infrastructure is comprised of a small group (or single server) known a

authoritative server that has a local zone database, and multiple secondary server

obtain their copies of the zone database from the prima

. On th end e

esolvers ma

e NS c

45 Caching Recursive Server is sometimes shortened to “caching server” or “recursive server”. However, 

the role remains the same. 

Pri

Authoritative

Server 

mary Secondary 

Authoritative

Server 

Caching 

Server 

End User 

Resolver 

Zone 

(TSIG

Query/Response 

(DNSSEC) 

Query/Response 

Transfer 

) 

(DNSSEC) Query/Response 

(DNSSEC) 

70
The basic DNS does not have many security features [SP 800-81]. A sui

been developed to provide security enhancements contained in three IETF

collectively called the DNS security extensions (DNSSEC) [RFC 4033, R

RFC4035]. DNSSEC provides a layer of authentication and integrity prote

kind of data stored in the DNS, including data used by other protocols. For exam

there are RR types allocated for storing Secure Sh

te of RFC's has 

 documents, 

FC 4034, and 

ction for any 

ple, 

ell (SSH) keys in the DNS, which then 

rely on DNSSEC to protect the integrity of that information. 

thentication 

public key pairs 

ey pair is used 

separate, 

g Key or 

e zone – using 

K using the 

nt. Since the KSK is 

arent zone 

used only to sign 

ted, so there may 

tion in 

hms. There is 

 at least one 

erstand. 

orithm to use 

.

47 When the 

 an immediate 

lan to migrate from the use of RSA with SHA-1 to the use of RSA with SHA256 [FIPS 180-3] for DNS data authentication. 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 

the 

rstands RSA 

 

8.1.1 DNS Data Authentication 

Cryptographically generated public key-based digital signatures provide au

for DNS data. Commonly, there will be two or more digital signature 

(which make up the key set) used to implement DNSSEC in a zone. One k

to sign the zone data (referred to as the Zone Signing Key or ZSK), and a 

stronger key pair is used to sign the zone key set (known as the Key Signin

KSK). This KSK is also known as the Secure Entry Point (SEP) key for th

it, a client can authenticate the ZSK (by validating the signature over the ZS

KSK public key), and then use the ZSK to authenticate the zone data. The KSK is also 

used to link the security chain46 from the zone to its delegating pare

used to link security from the zone (e.g. “example.gov”) to the delegating p

(e.g. “.gov”) [RFC 4035], it is often longer lived, and used infrequently (

the zone key set). Multiple digital signature algorithms can be suppor

be multiple keys (one for each algorithm), as there is no algorithm negotia

DNSSEC, and clients may only understand certain digital signature algorit

one mandatory-to-implement algorithm as defined by the IETF, so there is

agreed-upon digital signature algorithm that all servers and clients will und

When this document was published, the only mandatory-to-implement alg

with DNSSEC data authentication is RSA using SHA-1 as a hash algorithm

use of SHA-256 (or greater) is included in the specification, there shall be

transition p

still authenticate DNS data. The length of this transition period depends on 

widespread availability and deployment of client system software that unde

with SHA-256. 

46 The security chain (also referred to as “chain of authentication”) is the collection of digital signatures and 

public keys that can be used to trace a logical path from the data to be validated back to a trusted, installed 

public key on the client [SP 800-81]. This chain of public keys and signatures is similar to a PKI certificate 

chain (see Section 2.1), but entirely contained within the DNS. 

47 Note that the transition away from SHA-1 in 2011 is necessary when the hash function is used for digital 

signatures, but not when used for HMAC. 

71
8.1.2 DNS Transaction Authentication 

Additional authentication mechanisms are used for server-server communic

administrative control. Transaction authentication is performed by compu

over the entire DNS message and a secret random string that is known by 

authoritative DNS servers in the transaction, and transmitting the result in 

Signature (TSIG) RR appended to the original message. Transaction authe

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 authorita

date with the most recent version of the zone data. Dynamic update is a f

allows an authorized administrator to add or delete DNS data by sending

formatted message. This is frequently used in local area networks where the Dynamic 

ation and 

ting an HMAC 

both 

a Transaction 

ntication is 

tive servers up-toeature that 

 a specially 

Host Configuration Protocol (DHCP) is used to assign IP addresses dynamically. The 

essage to 

g SHA-1. 

C with a 

for stronger 

s to be used (SHA-256 and stronger) and may be used when available. All 

DNS server administrators taking part in the transaction must agree on which algorithm 

must ensure that all 

f-band transactions 

8.1.3 DNS Cryptographic Algorithms/Schemes, Modes and Combinations 

does not support algorithms in isolation, but specifies suites of algorithms and 

sche lgorith b for zone data signing and for message 

auth tion are able and 8

Recom ded Algorithm and Scheme Combinations for Zone Data 

DHCP server may update the DNS server by sending a dynamic update m

reflect network changes. 

The currently defined algorithm used in TSIG authentication is HMAC usin

This is deemed acceptable for current security practices when using HMA

suitably random secret string [SP 800-90]. Newer implementations allow 

hash algorithm

and secret string size will be used for transaction authentication and

parties have the same secret random string (which may include out-o

to distribute keys). 

DNS 

mes. A

entica

m/Scheme com

 provided in T

inations 

s 8-1 -2: 

Table 8-1: men

Signing 

Suite Authentication Digest IETF Approved for 

Status Federal Use48

RSA_SHA1 RSA SHA-1 Mandatory YES until 2010 

DSA_SHA1 DSA SHA-1 Optional YES until 2010 

RSA_SHA256 RSA SHA-256 Optional YES 

RSA_SHA512 RSA SHA-512 Optional YES 

 

48 Using approved key sizes as discussed in Part 1 of this guide. 

72
Tab : Recomm age Authentication Algorithms 

 widely 

 used for 

ntication is used between servers 

ethod 

the IETF 

ained by the 

rithm codes has 

nalized and 

implemented in current software. However, the use of SHA-256 is encouraged and 

should be considered when supported by DNSSEC software. There should be a 

HA-256 would both be used to ensure that clients 

graded. 

tion leakage and 

C, a client can 

ure (NSEC) 

 that the 

e names by 

y). However, 

 hash calculations 

ervice 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 

3 deployment risks are 

 an overridding 

protection (examples include protecting 

personally indentifying information that may be contained in the DNS). However, it is a 

 

le 8-2 ended Mess

It should be noted that HMAC-MD5.SIG-ALG.REG.INT is a suite that is

implemented and often set as the default choice. However, it shall not be

Federal implementations. Since TSIG message authe

where there is an existing trust relationship, the administrators must agree to the m

used and the secret (random) string used with the TSIG method. 

Currently, there are plans for migrating to SHA-256 and SHA-512 by 

community for use with RSA in zone data signing. The registry maint

Internet Assigned Number Authority (IANA) function for DNSSEC algo

several entries available for use, but the use of SHA-256 has yet to be fi

transition period when SHA-1 and S

that are non-SHA-256-aware could still validate signatures until they are up

8.1.4 Special Considerations for NSEC3 

There is a special varient to DNSSEC that minimizes the risk of informa

is known as the Hashed Next Secure (NSEC3) RR [RFC 5155]. In DNSSE

map the contents of the zone by sending a series of queries for the Next Sec

RR type found in error messages. These NSEC RRs provide signed proof

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 zon

using the hash values of the two existing names (currently using SHA-1 onl

this requires the server and client to be able to perform multiple SHA-1

during runtime; note that this method could be used to mount a Denial of S

complete mapping of network resources in a DNS zone. NSEC

often greater than the usefulness provided by using NSEC3, unless there is

need to deploy NSEC3 beyond zone content 

49 As of the time of writing, SHA-256 has begun to be implemented in some DNS servers 

50 Generic Security Service Algorithm for Secret Key Transaction Authentication (GSS-TSIG [RFC3645]) 

may be found in some server implementations 

Suite IETF status Approved for 

Federal Use 

HMAC_SHA1 datory YES Man

HMAC_SHA256 Optional49 YES 

GSS_TSIG50 Optional YES 

73
good idea to use an NSEC3-aware client software, because a client may access a zone 

1 is the most 

widely 

sition plan to 

 major software 

against the 

 would involve 

deploying both SHA-1 and SHA-256-based NSEC3 RRs until it is observed that SHAe widely used in the Internet community. 

 or DSA) has both 

l government approval as a hash algorithm and is fully specified in DNSSEC 

ailable to use 

n DNSSEC 

should be 

one (e.g. 

arent 

cording to the policy and procedure established by the parent zone. 

tegrity protection 

strength. The 

system installers using the TSIG secret string shall agree on which TSIG algorithm to 

use. 

 use with digital 

F standards process. 

on for 

1. DNSSEC utilities shall use FIPS140-2 compliant cryptographic modules. 

2. DNS server software should generate and serve NSEC3 RRs, if required by zone 

policy. 

3. DNS server software shall use an approved random bit generator to generate random 

strings for use with TSIG message authentication using HMAC that is consistent with 

the hash algorithm security strength recommendations in Part 1. 

that uses NSEC3 RRs with DNSSEC. 

As with other issues in DNSSEC involving secure hash algorithms, SHAwidely used algorithm. As of the time of writing, SHA-256 has yet to be 

implemented. System installers and administrators should develop a tran

migrate from SHA-1 to SHA-256 when SHA-256 becomes available in

distributions to prevent an attacker from performing a brute force attack 

hashed names and obtain the entire contents of a zone database. This

256-aware implementations have becom

8.2 Security/Compliance Issues 

1. For digital signatures over DNS data, only SHA-1 (used with RSA

Federa

(as of the time of writing). It is the only approved hash algorithm av

until SHA-256 with RSA and SHA-512 with RSA is implemented i

software. 

2. Although not strictly necessary to the specification, a Key Signing Key 

used to maintain security chains from the parent zone (e.g. .gov) to the z

nist.gov). This KSK should be securely transmitted to the delegating p

ac

3. TSIG shared secret strings should be random for use in providing in

for DNS message transactions, and generated at an appropriate security 

4. System developers should implement SHA-256 [FIPS 180-3] for

signatures when the use of SHA-256 is specified through the IET

8.3 Procurement Guidance 

A purchase decision maker is any individual that makes a purchasing decisi

acquiring a DNS component. Recommendations for purchasing are: 

74
4. DNSSEC-enabled versions of network applications shall be purchased as required by 

ements when 

A/SHA-1 and 

 be used for some period of time until wide-scale deployment 

of SHA-256 is observed. 

System Installers 

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

8.4.1 Recommendations for System Installers (Authoritative Servers) 

er to serve 

rator (as 

e and configure an 

 secret string for use with TSIG in transactions. 

e data with a key 

sistent with the key size recommendations for digital signatures as 

set with a key 

y sizes recommended for digital signatures, as 

d secondary 

 the random bit generator process shall support the 

security strength required by the servers. 

eparate shared secret 

 security strength 

he random bit generator process shall support the security strength required by the 

8.4.2 Recommendations for System Installers (Caching Recursive Servers) 

1. Recursive caching server installers shall configure DNS servers to be DNSSECaware. 

2. Recursive caching server installers shall install at least one public key used for 

DNSSEC validation. 

security policy, if available. 

5. DNSSEC software implementing SHA-256 shall be included in procur

available. A transition plan deploying digital signatures using both RS

RSA/SHA-256 should

8.4 Recommendations for 

initial configuration of the component. 

1. Authoritative server installers shall configure a DNS authoritiative serv

DNSSEC signed zone data. 

2. Authoritiative server installers shall use an approved random bit gene

discussed in NIST Special Publication 800-90 [SP 800-90]) to creat

initial random

3. Authoritative servers shall be configured to generate and sign zon

pair that is con

specified in Part 1. 

4. Authoritative servers shall be configured to generate and sign the key 

pair that is consistent with the ke

specified in Part 1. 

5. Authoritative servers shall be configured to generate and use a random secret string 

for zone transfer message authentication (via TSIG) between primary an

servers. The security strength of

6. Authoritative servers shall be configured to generate and use a s

string for dynamic update message authentication (via TSIG). The

of t

servers. 

75
 be configured to send DNS queries to a DNSSEC-enabled 

2. Client systems should be configured to use DNSSEC-enabled applications, if they are 

available. 

stem Administrators 

The System Administrator is the individual who runs the DNS application on a day-tors (Authoritative Server) 

 policy regarding the Authoritative servers shall be enforced. 

ords before the 

ed if the private key associated 

 DNS zone leaves 

ity policy. 

inistrators shall utilize methods for handling and protecting the private key (e.g., 

using a smart card that requires appropriate user authentication). 

T Special 

nt Guide [SP 800-

8.5.2 Recommendations for System Administrators (Caching Recursive Servers) 

tion security policy for 

shall be adequately protected (see Part 1). 

 kept up to date. 

8.5.3 Recommendations for System Administrators (Client Systems) 

1. Server administrators shall ensure that there is an organization security policy for 

using the client systems. 

2. Server administrators shall ensure that users are properly trained. 

8.4.3 Recommendations for System Installers (Client Systems) 

1. Client systems shall

caching recursive server. 

8.5 Recommendations for Sy

day basis and interacts with the end user. 

8.5.1 Recommendations for System Administrato

1. Organization security

2. Cryptographic keys shall be protected as specified in Part 1. 

3. System administrators shall replace zone data signature Resource Rec

end of their validity period. 

4. Zone data signature Resource Records shall be replac

with the public key is compromised, when the administrator of the

the organization, and for other reasons listed in the organization’s secur

5. Adm

6. Administrators shall follow the key lifecycle procedures found in NIS

Publication 800-81 Secure Domain Name System (DNS) Deployme

81] 

1. Server administrators shall ensure that there is an organiza

using the Caching Recursive Server. 

2. Cryptographic keys

3. The trust anchors for DNS validating caches should be

76
1. End users shall operate their client systems as instructed by their organization and 

system administrator. 

8.6 Recommendations for End Users 

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

77
9 Encrypted File Systems (EFS) 

what different set 

cated data. 

ntegrity of 

y and integrity of 

ata and the secure sharing of this data. The key management guidance 

 been thoroughly 

s for file encryption 

g keys. Due to this 

velop 

p (TCG). 

• How are keys used in the system, and what protection are they afforded? 

ored on the system? 

e upward for numerous user communities (without requiring 

f files. The 

crypt a set of files 

y to provide access to a 

s way, only that 

 any of the 

 for each 

ile and must be provided to the sharing user. 

stribution 

process. However, when a sharing user requires access to a single file, giving access to 

aring 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. One option to limit access in this second system is for the 

 

9.1 Description 

The encryption of data files and complete disk volumes presents a some

of key management issues than those for encryption of network-communi

While network communications security focuses on the privacy and i

information in transit, storage (e.g., file) security focuses on the privac

persistent d

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

studied by the network security community, the commercial solution

utilize a wide variety of security schemes and methods for storin

range of solutions, this section will not be comprehensive, but will cover a variety of

m t e hods used for file encryption. One group that is currently working to de

standards for encrypted file systems is the Trusted Computing Grou

The most important questions that designers of a file encryption system must answer are: 

• Where are the keys st

• Does the method scal

an impractical number of keys to be stored)? 

9.1.1 Number of Keys Required 

For an Encrypted File System, keys are used to encrypt a file or group o

system can either encrypt each file with a distinct symmetric key or en

using the same symmetric key. In the first case, it is very eas

sharing user, for example, by simply giving the key to that user. In thi

single file can be accessed by the sharing user without providing access to

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

encrypted f

In the second case, many fewer keys are required, which eases the key di

that user is more problematic. By simply sending a key to the sh

51

51 An owner could be an individual or a group of individuals or processes that share the key. 

78
owner or system to decrypt the file and re-encrypt it using a new key f

the sharing user (e.g., using network security mechanisms and session ke

increasingly rare case of both users sharing a common file server, the dec

encrypted file would be placed in the sharing user’s file space. This woul

significant processing overhead and a key management protocol for exch

the owner and the sharing user or between the file system management process and the 

or transmission to 

ys). In the 

rypted and red require 

anges between 

sharing user. This process requires proper protection for these new keys, at the same 

nd the owner’s 

ing the one 

protect the key from third party administrators, but it is unlikely that the owner would 

der the common 

lowing is a 

 has an 

domly generated 

d using the public key 

a file wants to share 

ivate key) and 

file and readvantages. First, the owner needs to manage only a single asymmetric key pair. 

t because 

tem need not 

d by the owners, and 

r sets of files. The 

ore keys and 

idual 

sidered is 

covery 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 

rds, be included.52 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. 

 

security level as the original key protecting that file. 

Another option is for the sharing user to be provided the encrypted file a

decryption key that could be used to decrypt all of the owner’s files, includ

provided to the sharing user. System overhead is reduced, and it may be possible to 

agree that the requester should be granted access to all files protected un

key. 

Having provided more extreme examples in the previous two cases, the fol

more common approach that is used. In this case, each user on the system

asymmetric key pair. Each owner’s file is encrypted under different ran

symmetric File Encrypting Key (FEK). The FEK is then encrypte

of the owner and stored with the encrypted file. When the owner of 

it with another user, the owner decrypts the encrypted FEK (using her pr

then encrypts the FEK using the sharing user’s public key. The encrypted 

encrypted FEK can then be provided to the requester. This system has several 

Second, it permits easier file sharing between users. Third, it is very efficien

files do not have to be re-encrypted in order to be shared. Finally, the sys

manage any keys separately, since the asymmetric keys are manage

the FEKs are stored in encrypted form with the files. 

The owner can, of course, use different keys to encrypt different files o

fewer files that the owner chooses to encrypt with a given key results in m

associations (e.g., associations of keys with file identities, file groups, indiv

identities, or access groups) that would need to be maintained. 

Another important concept within an encrypted file system that must be con

how data re

some form of data recovery, such as master administrator passwo

52 The specifics of how data recovery is accomplished are beyond the scope of this document. 

79
When the scope of the system expands from a pair of individuals to a large n

internet-work, the factors associated with the management of keys ca

etwork or 

n become unwieldy. 

ata placement (many owners and large 

FS, that site provides 

 large domain. 

ho have left an 

should not be 

al or 

d encrypted 

o has left the organization 

and cannot be found). 

ber of the owner’s files, 

d with a single 

ric key, key management questions can be considered. How does the File 

Encryption System generate the encryption keys? How will the keys be stored and 

ons, as well as 

nal techniques 

 considered 

 how do file 

e the key from 

 depends on 

h randomness 

t is preferable 

. Good random 

 [SP 800-90]. 

r the question of how to protect the keys. When the key is derived from a 

password, the security of the key is dependent upon the strength (i.e., the randomness and 

secrecy) of the password used. A standard dictionary attack can often recover weak 

passwords, so a strong password is vital for the security of this type of system. 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. 

Key management challenges associated with large systems include the following: 

• Maintaining context in the face of global d

quantities of data) 

• Very large numbers of keys to manage and distribute 

• If numerous keys are stored in a single location within an E

an attractive target for an adversary, a single point of trust for a

• Difficulty in accounting for revoked users (individuals w

organization, whose subscriptions have expired, or otherwise 

authorized to access the file any longer). 

• Reassignment of ownership of protected data to another individu

organization. 

• Recovery of data in the event of lost keys (e.g., the case of archive

data that is encrypted and stored by an individual wh

• A sharing user who has been provided the keys to a num

then provides the keys, and the owner’s data, to additional users. 

9.1.2 Access to Symmetric Keys used in File Encryption 

After the decision has been made about the number of files to be protecte

symmet

protected? This section identifies common ways of answering these questi

discussing their strengths and weaknesses. As technology advances, additio

will be developed, and as such, the list below is not complete nor should be

mandatory. 

Consider common answers to the three important questions above. First,

encryption systems generate symmetric keys? A simple method is to deriv

a password as described in [PKCS-5]. In this case, the security of the system

the randomness of the password; normally, passwords do not contain enoug

to be used for generating keys (i.e., they can be guessed relatively easily). I

to utilize a good random bit generator within the system to generate keys

bit generation schemes can be found in NIST Special Publication 800-90

Next, conside

80
Next, consider where these keys will be stored. If random keys need to be 

could simply be stored on the computer itself or on a hardware token. Alte

key could be split into two (or more) key components with, for example, on

stored on a hardware token and the other key component stored on the co

a split key is employed, the method used to combine the key components

performing an XOR operation on equal length key components is be

concatenating the components. Common hardware tokens include PCMC

smartcards. The advantage to using a hardware token is that if the user

hardware token away from the computer, and the key is split between th

comput

stored, they 

rnatively, the 

e component 

mputer itself. If 

 is important; 

tter than simply 

IA cards and 

 stores the 

e token and the 

er, an adversary needs to recover both pieces of hardware to recover the key. 

 by using a 

ples of how 

 be answered will be considered, along with the pros and cons of each 

e File Encryption 

m that is 

s a single 

rated using 

h are stored on 

 (which is also 

d drive (e.g., using 

odule [TPM]). 

 are split into two 

omponent stored 

r component derived from a password (e.g., using 

PKCS-5 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 more 

clearly the pros and cons of the systems. 

Additional security may be provided by encrypting the key splits, perhaps

password. 

There are many permutations of answers to the questions above. Four exam

these questions can

system. It is important to consider the specific environment in which th

System will be used, as that will usually point to a specific type of syste

preferable for that case. 

The first example that will be considered is a file encryption system that use

symmetric key to encrypt every file on the system. This single key is gene

PKCS #5 from a user’s password. 

The second example is a system that utilizes per-file encryption keys, whic

the hard disk, encrypted by a key encryption key. The key encryption key

used to decrypt each file encryption key) is securely stored on the har

the Trusted Platform M

The third example is a system that utilizes per-file encryption keys that

key components that will be XORed to recreate the key, with one key c

on a hardware token and the othe

81
Method Pros Cons 

Example 1: 

PKCS #5 

lutio

lizing a strong password 

b

rity. 

ause the 

security is dependent only on 

f the password. 

- Least expensive so

- Uti

n. - Less secure bec

can result in reasona

secu

le the strength o

Example 2: 

Key Encryption 

ectl

re from external 

nd ph

ely new technology. 

- Keys are stored on the same 

Key ter as the file. 

- Secure storage dir

computer. 

y in the - Relativ

- Secu

software attack a

threat. 

ysical 

compu

Example 3: 

Hardware Token ware 

l

token ar

y secur

- More expensive. 

- If the token is lost, the files 

cannot be decrypted. 

- Splits key. 

- Requires two hard

pieces to decrypt. 

- Highly secure if imp

correctly. 

emented 

- If the files or e lost, 

the files will sta e. 

Example 4: 

Asymmetric use

owned Key 

Encryption Key 

s stored in the 

ring. 

- Highly secure if token is 

used. 

-Requires the user to manage 

their own RSA key pair. 

- Requires either a user 

password or a user token. 

r 

o plaintext key

computer. 

- Efficient file sha

-N

- Compromise of a user’s 

private key compromises 

only the user’s files.

9.2 Security and Compliance Issues 

roved cryptography if it is to be used for 

ation. 

mize the difficulty 

of an off-line exhaustion attack [SP 800-118] 39

9.3 Recommendations for Procurement Officials 

The following recommendations are for any individual(s) that make a purchasing 

decision for acquiring an EFS component. 

1. An encrypted file system shall include a data recovery capability (e.g., master 

administrator password) so that the data is not lost in the event that a user forgets his 

password or the user is unavailable. Data recovery is vital in this type of system. 

1. Any encrypted file system shall employ app

the protection of Federal government inform

2. Keys derived from passwords shall use strong passwords to maxi

82
2. Any EFS system that derives keys from passwords should have the capability of 

se a hardware 

en for storage of the key or the Trusted Platform Module (TPM) for storage of the 

keys. 

d performs the 

talled, the installer 

ark not defined. 

2. The system installer should ensure that the database of keys is protected by 

. In addition, if the key is split by the 

ardware token should be protected. 

 administrator is the individual that manages the EFS on a day-to-day basis 

 recover their data 

 A method 

ace prior to the 

3. f the EFS includes a master administrator password for use in data recovery by the 

ystem administrator, the system administrator shall utilize a strong password. 

ide training and security guidance to the end users of 

 procedures, and 

user configuration of their system to utilize the authentication features within the 

5.

9.6 Recommendations for End Users 

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

1. If user-selected passwords are used within the product, end users shall utilize strong 

passwords to maximize the difficulty of an off-line exhaustion attack. 

enforcing the use of strong passwords.Error! Bookmark not defined.

3. To increase the security of encrypted file systems, the system should u

tok

9.4 Recommendations for System Installers 

The system installer is the individual(s) that installs EFS components an

initial configuration of the components. 

1. When an EFS system that utilizes passwords for security is ins

shall require that strong passwords be enforced by the EFS.Error! Bookm

This maximizes the difficulty of an off-line exhaustion attack. 

encryption to ensure the security of the system

EFS system, the key component stored on a h

9.5 Recommendations for System Administrators 

The system

and interacts with the end user. 

1. The system administrator shall ensure that the organization’s security policy is 

enforced. 

2. Key recovery procedures shall be in place to ensure that users can

if they lose their authentication information (password, token data, etc).

for data recovery personnel to authenticate these users should be in pl

recovery of the user’s keys or files. 

I

s

4. System administrators shall prov

the system that, at a minimum, focuses on passwords, data recovery

system. 

83
2. End users shall follow guidance provided by the system administrator regarding the 

 a system administrator if they have lost their hardware token 

or forgotten their password. 

use of an Encrypted File System product. 

3. End users shall inform

84
10 Secure Shell (SSH) 

sideration) 

(Topic under consideration) 

(Topic under con

11 IEEE 802.1x 

85
Appendix A: Glossary 

as they are used in this document. The same terms 

y be defined differently in other documents. 

The terms provided below are defined 

ma

Term Definition 

Access control 

 Control 

Mechanism 

e. 

Approved n algorithm or 

at is either 1) specified in a FIPS or NIST 

 2) adopted in a FIPS or NIST 

 in a list of NIST approved 

Asymmetric key 

algorithm 

graphic algorithm. 

tion 

entication co

ation ; conveys an “official” 

 a given security function or activity. 

ity authorized entities. 

p cessary. 

AC ms. 

Certificate key certificate. 

ation lic Key Infrastructure (PKI) that is 

ompliance to 

Checksum A method used to protect the integrity of data by detecting 

errors in that data. 

Ciphertext Data in its encrypted form. 

Compromise The unauthorized disclosure, modification, substitution or use 

of sensitive data (e.g., keying material and other security related 

information). 

Restricts access to resources only to privileged entities. 

Access A method for restricting access to some resourc

FIPS-approved and/or NIST-recommended. A

technique th

Recommendation, or

Recommendation or 3) specified

security functions.

Archive See Key management archive. 

See Public key crypto

Authentica A process that establishes the origin of information, or 

determines an entity’s identity. 

Auth de See Message Authentication Code. 

Authoriz Access privileges granted to an entity

sanction to perform

Availabil

Backu

Timely, reliable access to information by

A copy of information to facilitate recovery, if ne

CBC-M A mode of operation for block cipher algorith

See public

Certific

authority 

The entity in a Pub

responsible for issuing certificates, and exacting c

a PKI policy. 

86
Confidentiality that sensitive information is not disclosed to 

Contingency plan ckup 

e availability 

nd to facilitate the continuity of operations 

Cryptographic 

Boundary s of a cryptographic module and contains all 

oftware, and/or firmware components of a 

cryptographic module. 

 Ha

ction 

Cryptographic key

(key) 

phic algorithm 

t an entity with 

 the operation, 

e key can ot. Examples 

ciphertext data, 

aintext data, 

 data, 

 data and a 

Cryptographic f hardware, software, and/or firmware in which 

ented; a cryptographic 

dary. 

Cryptoperiod orized for use 

en system or application may 

Data integrity 

ted or stored. 

ommendation, the statement that a cryptographic 

algorithm "provides data integrity" means that the algorithm is 

used to detect unauthorized alterations. 

Decryption The process of changing ciphertext into plaintext using a 

cryptographic algorithm and key. 

DES The Data Encryption Standard that was specified in FIPS 46 

(now withdrawn). 

The property 

unauthorized entities. 

A plan that is maintained for disaster response, ba

operations, and post-disaster recovery to ensure th

of critical resources a

in an emergency situation. 

An explicitly defined continuous perimeter that establishes the 

physical bound

hardware, s

Cryptographic

Fun

sh See Hash function. 

A parameter used in conjunction with a cryptogra

that determines its operation in such a way tha

knowledge of the key can reproduce or reverse

while an entity without knowledge of th n

include: 

1. the transformation of plaintext data into 

2. the transformation of ciphertext data into pl

3. the computation of a digital signature from

4. the verification of a digital signature, 

5. the computation of an authentication code from data, 

6. the verification of an authentication code from

received authentication code, 

7. the computation of a shared secret that is used to derive 

keying material. 

The set o

module approved security functions are implem

module is contained within a cryptographic boun

The time span during which a specific key is auth

or in which the keys for a giv

remain in effect. 

A property whereby data has not been altered in an 

unauthorized manner since it was created, transmit

In this Rec

87
Digital signature rmation of data that, when 

des the services of: 

cation, 

and 

n-repudiation. 

tion 

ryption ciphertext using a 

rocess. 

Hash algorithm 

Hash function h to a fixed 

 infeasible to find any input 

 

ind any 

tinct inputs that map to the same output. 

ation. 

Hash-based messa

authentication cod

(HMAC) 

 approved keyedce or 

e, or may be 

g consisting of an 

lication. 

Initialization vect

(IV) 

cryptographic 

c algorithm. 

r. In this 

phic algorithm 

tect 

Key cryptographic key. 

Key agreement A key establishment scheme whose resultant keying material is 

a function of information contributed by two or more 

participants, so that no party can predetermine the value of the 

keying material. 

Key Bundle A set of keys used during one operation, typically a TDEA 

operation. 

The result of a cryptographic transfo

properly implemented, provi

1. origin authenti

2. data integrity, 

3. signer no

Distribu See key distribution. 

Enc The process of changing plaintext into

cryptographic algorithm and key. 

Entity An individual (person), organization, device or p

See Hash function. 

A function that maps a bit string of arbitrary lengt

length bit string. Approved hash functions satisfy the following 

properties: 

1. (One-way) It is computationally

that maps to any pre-specified output, and

2. (Collision free) It is computationally infeasible to f

two dis

Hash value The result of applying a hash function to inform

ge 

e 

A message authentication code that uses an

hash function. 

Identifier A bit string that is associated with a person, devi

organization. It may be an identifying nam

something more abstract (for example, a strin

IP address and timestamp), depending on the app

or A vector used in defining the starting point of a 

process within a cryptographi

Integrity The property that sensitive data has not been modified or 

deleted in an unauthorized and undetected manne

Recommendation, the statement that a cryptogra

"provides integrity" means that the algorithm is used to de

unauthorized modifications or deletions. 

See

88
Key component omponents in 

to form a plaintext cryptographic 

Key distribution l from an entity 

rates the key to another entity that is 

g ke ion or 

Key establishmen process by 

 among 

phic modules using manual transport methods (e.g., 

ort and/or key 

ated and 

Key management 

ing their 

ntry and output, and 

gement a repository 

st. 

ey; a key pair is 

Key recovery d processes that allow authorized entities to 

ve. 

Key revocation to affected 

emoved from 

ished cryptoperiod 

. 

ort ity (the sender) 

Key update graphic key in order to 

compute a new, but related, key. 

Key wrapping A method of encrypting keys (along with associated integrity 

information) that provides both confidentiality and integrity 

protection using a symmetric key. 

Keying material The data (e.g., keys and IVs) necessary to establish and 

maintain cryptographic keying relationships. 

A parameter used in conjunction with other key c

an approved security function 

key or perform a cryptographic function. 

The transport of a key and other keying materia

that either owns or gene

intended to use the key. 

Key encryptin y A cryptographic key that is used for the encrypt

decryption of other keys. 

t A function in the lifecycle of keying material; the 

which cryptographic keys are securely distributed

cryptogra

key loaders), automated methods (e.g., key transp

agreement protocols), or a combination of autom

manual methods. 

The activities involving the handling of cryptographic keys and 

other related security parameters (e.g., IVs and passwords) 

during the entire life cycle of the keys, includ

generation, storage, establishment, e

destruction. 

Key mana

archive 

A function in the lifecycle of keying material;

containing keying material of historical intere

Key pair A public key and its corresponding private k

used with a public key algorithm. 

Mechanisms an

retrieve keying material from key backup or archi

A process whereby a notice is made available

entities that keying material should be r

operational use prior to the end of the establ

of that keying material

Key transp A key establishment procedure whereby one ent

selects a value for secret keying material and then securely 

distributes that value to another party (the receiver). 

A function performed on a crypto

89
Message 

Authentication Code 

C) 

symmetric key to 

detect both accidental and intentional modifications of data. 

Nonce e chance of 

dom value that is 

estamp, a 

Non-repudiation integrity and 

origin can be 

rom a specific 

ed signatory. 

Owner For an asymmetric key pair, the entity that owns the private 

r a trusted party 

s, the file owner has control over the 

may have one 

ndividual or a group of 

Password ters, numbers and other symbols) that 

ify access 

 information and 

Plaintext derstood 

ption. 

Private key ryptographic 

ly associated with an entity and is not 

em, the 

ding on the 

pute the corresponding public key, 

d by the 

as encrypted by the corresponding public 

key, or 

4. Compute a piece of common shared data, together with other 

information. 

Protocol A special set of rules used by two or more entities that describe 

the message order and data structures for information 

exchanged between the entities. 

(MA

A cryptographic checksum on data that uses a 

A time-varying value that has, at most, a negligibl

repeating. For example, a nonce could be a ran

generated anew for each instance of a nonce, a tim

sequence number, or some combination of these.

A service that is used to provide assurance of the

origin of data in such a way that the integrity and 

verified by a third party as having originated f

entity in possession of the private key of the claim

key, whether that entity generated the key pair o

generated the key pair for the entity. 

In Encrypted File System

file and grants access of the file to others. A file 

or more owners. An owner could be an i

individuals or processes 

A string of characters (let

are used to authenticate an identity or to ver

authorization. 

Payload A part of the data stream representing the user

user overhead in a communication. 

Intelligible data that has meaning and can be un

without the application of decry

A cryptographic key, used with a public key c

algorithm, that is unique

made public. In an asymmetric (public) cryptosyst

private key is associated with a public key. Depen

algorithm, the private key may be used to: 

1. Com

2. Compute a digital signature that may be verifie

corresponding public key, 

3. Decrypt data that w

90
Public key yptographic 

ity and that 

yptosystem, 

e public key 

algorithm, may 

ed to: 

he corresponding 

key, 

e decrypted by the corresponding 

key 

algorithm 

lgorithm that uses two related keys, a public 

property that 

ey is 

Public key certific ata that uniquely identifies an entity, contains the 

n, and is 

 by a trusted party, thereby binding the public 

Public Key 

Infrastructure (PK

 and revoke 

lic key certificates. 

onstitute erent 

security information 

 a service from 

Rekey e” of the new key is 

nt of the “value” of the old key. 

 party rtificate and 

ntity of the 

rithms and 

ssion of the 

Secret key a secret key (symmetric) 

 uniquely associated with one or 

of the term 

“secret” in this context does not imply a classification level, but 

rather implies the need to protect the key from disclosure. 

Security association A relationship between two network entities in which security 

information is shared and used to support secure 

communication between the two entities. 

Security services Mechanisms used to provide confidentiality, data integrity, 

A cryptographic key used with a public key cr

algorithm that is uniquely associated with an ent

may be made public. In an asymmetric (public) cr

the public key is associated with a private key. Th

may be known by anyone and, depending on the 

be us

1. Verify a digital signature that is signed by t

private 

2. Encrypt data that can b

private key, or 

3. Compute a piece of shared data. 

Public A cryptographic a

(asymmetric) 

cryptographic 

key and a private key. The two keys have the 

determining the private key from the public k

computationally infeasible. 

ate A set of d

entity's public key and possibly other informatio

digitally signed

key to the entity. 

I) 

A framework that is established to issue, maintain

pub

Rec Rebuilding a service provider (possibly with a diff

infrastructure) using previously saved 

and/or key material rather than simply restarting

a backup. 

A new key replaces another key; the “valu

entirely independe

Relying An individual or organization that relies on the ce

the CA that issued the certificate to verify the ide

user; the validity of the public key, associated algo

any relevant parameters; and the user’s posse

corresponding private key. 

A cryptographic key that is used with

cryptographic algorithm that is

more entities and is not made public. The use 

91
authentication or non-repudiation of information. 

A public key certificate whose digital signature m

by the public key contained within the certificate. 

signature on a self-signed certificate protects th

data, but does not guarantee authenticity of the infor

Self-signed 

certificate 

ay be verified 

 The 

e integrity of the 

mation. 

Shall deral 

uirement that 

lfilled to claim conformance to this 

ed with not to 

ed secret ent scheme; the 

material for a 

ent. 

ignoring the 

nt could result in undesirable results. Note that 

me should not. 

erifica key to verify a 

metric key a secret 

t the potential to adversely 

impact a system through unauthorized access, destruction, 

ice. 

ES/Triple orithm [specified in SP 800-67] 

Unauthorized 

disclosure 

n to entities not 

authorized access to the information. 

User name (in a 

certificate) 

The name of the party authorized to use the private key 

associated with the public key in the certificate; the subject of 

the certificate. 

User registration A function in the lifecycle of keying material; a process 

whereby an entity becomes a member of a security domain. 

The trust of self-signed certificates is based on the secure 

procedures used to distribute them. 

This term is used to indicate a requirement of a Fe

Information Processing Standard (FIPS) or a req

must be fu

Recommendation. Note that shall may be coupl

become shall not. 

Shar A value that is generated during a key agreem

shared secret is typically used to derive keying 

symmetric key algorithm. 

Should This term is used to indicate a very important requirem

While the “requirement” is not stated in a FIPS, 

requireme

should may be coupled with not to beco

Signature v tion Uses a digital signature algorithm and a public 

digital signature. 

Sym A single cryptographic key that is used with 

(symmetric) key algorithm. 

Symmetric key 

algorithm 

A cryptographic algorithm that uses one shared key, a secret 

key. 

Threa Any circumstance or event with 

disclosure, modification of data or denial of serv

Triple D Triple Data Encryption Alg

DEA (TDEA) 

3-TDEA Three key TDEA as specified in SP 800-67. 

An event involving the exposure of informatio

92
X.509 public key 

certificate 

 for the user 

n, rendered union authority 

ificate, encoded in the format defined in the 

ISO/ITU-T X.509 standard.

 The public key for a user (or device) and a name

(or device), together with some other informatio

forgeable by the digital signature of the certificat

that issued the cert

93
Appendix B: Acronyms 

ES yption Standard 

H Header 

CBC Chaining 

-MA ethod 

e 

VP ule Validation 

TS e-Shelf 

R 

S ndard 

P ration Protocol 

SA e Algorithm 

DH llman 

DSA l Signature 

ocol 

CM Mode 

AC tication Code 

MAC sage Authentication 

TP er Protocol 

lue 

F Task Force 

E y Exchange 

KDC Key Distribution Center 

KMF Key Management Facility 

KMM Key Management Message 

KSK Key Signing Key 

KWK Key Wrapping Key 

LDAP Lightweight Directory Access Protocol 

A Advanced Encr

A Authentication

AS Authentication Server 

CA Certificate Authority 

Cipher Block 

CBC C Cipher Block Chaining M

Authentication Cod

CM Cryptographic Mod

Program

CO Commercial Off-th

CRL Certificate Revocation List 

CT Counter Mode 

DE Data Encryption Sta

DHC Dynamic Host Configu

DNS Domain Name System 

D Digital Signatur

EC Elliptic Curve Diffie-He

EC Elliptic Curve Digita

Algorithm 

EFS Encrypted File System 

ESP Encapsulating Security Prot

FEK File Encryption Key

G Galois Counter

GM Galois Message Authen

H Hash-based Mes

Code 

HT Hypertext Transf

ICV Integrity Check Va

IET Internet Engineering

IK Internet Ke

IP Internet Protocol 

IV Initialization Vector 

94
MAC ion Code 

5 e-Digest Algorithm 5 

EC 

T dards and 

P rotocol 

MB and Budget 

N tion Number 

CS#1 ography Standard #1 

I structure 

F Function 

VM tion Module 

FC omment 

cord 

dleman. 

SEP e Entry Point 

A lgorithm 

P tocol 

IME nternet Mail 

L er 

EA ption Algorithm 

ncryption Key 

G ting Group 

S rvice 

S Security 

M Module 

TSIG Transaction Signature 

URL Uniform Resource Locator 

VPN Virtual Private Network 

XOR Exclusive-Or operation 

ZSK Zone Signing Key 

Message Authenticat

MD Messag

NS Next Secure 

NIS National Institute of Stan

Technology 

OCS Online Certificate Status P

O Office of Management 

OTAR Over The Air Rekeying 

PI Personal Identifica

PK Public Key Crypt

PK Public Key Infra

PR Pseudorandom 

P Path Valida

RA Registration Authority

R Request for C

RR Resource Re

RSA Rivest, Shamir, and A

SA Security Association 

Secur

SH Secure Hash A

SMT Simple Mail Transfer Pro

S/M Secure/Multipart I

Extensions 

SS Secure Socket Lay

TD Triple Data Encry

TEK Traffic E

TC Trusted Compu

TG Ticket Granting Se

TL Transport Layer 

TP

TS Target 

Trusted Pla

Server 

tform

95
Appendix C: A Word to Novice End Users 

ed with, the 

 used. Keys 

etric and used 

: a private key

et. In general, the 

e public key 

n the case of 

lue and use the same 

 decryption. 

ers are 

ey of a static 

n ephemeral 

ephemeral also applies to symmetric 

n ephemeral 

n application or 

used in many 

as other 

I and public 

curity protocols or 

y. A long-term, or “static” public key is generally combined with the 

ey certificate. 

ted the key pair 

ost 

 a 

ifferent 

 to web sites. 

nd contractors, 

re personal 

y require “soft” 

mmercial CAs. 

afari, typically 

implement a mechanism to generate key pairs, send the public keys to a CA and return a 

public key certificate for that key to the browser. The certificates are then kept in a user 

certificate store on the user’s computer, which can be managed in a manner similar to a 

root certificate store (see Section 2). The process and interfaces for generating keys, and 

for requesting, downloading and installing certificates are specific to both the individual 

user client product and, sometimes, to the CA itself; however, the websites of CAs often 

have pages that “walk” the user through the key generation and certificate issuance 

Cryptographic keys are frequently categorized by the algorithms they are us

operations they are used to perform and by the number of times they can be

will either be asymmetric and used with an asymmetric algorithm, or symm

with a symmetric algorithm. Asymmetric keys are generated as key pairs

that must be kept secret, and a related public key, that may not be a secr

private key performs one operation, for example, a digital signature, and th

does the complementary operation, in this case, signature verification. I

symmetric keys, end users need to treat the key as a shared secret va

value for complementary cryptographic functions, such as encryption and

Some asymmetric keys are static and intended for long-term use, while oth

ephemeral and expire after use with one message or session. The public k

asymmetric key pair is often provided in a public key certificate, while a

public key is not. Although the concept of static vs. 

keys, a short term symmetric key is often called a session key, rather than a

key. No specific terminology is used for a long-term symmetric key. A

protocol may be supported by some combination of such keys. 

A PKI is the foundation of many current key management processes and is 

of the protocols or applications described in this Recommendation, as well 

security protocols and applications. Some understanding of the role of a PK

key certificates in key management is very helpful to setting up se

applications properl

name of the key’s “owner” in an electronic document called a public k

While certificates can be self-issued and signed (that is, the party that crea

can sign his name and the public key with the corresponding private key), m

certificates are digitally signed with the private key of a trusted entity called

Certification Authority. 

An end user may typically has one or more certificates, and may have d

certificates for different applications, e.g., for e-mail and for authentication

As Federal Personal Identity (PIV) cards are issued to Federal employees a

most Federal users will have a personal smart card that contains one or mo

certificates issued to them by their agency. Other specific applications ma

certificates, usually kept on the user’s computer, and possibly issued by co

For example, browser products, such as Internet Explorer, Firefox or S

96
process for the common browser products. Users can share certificates via email or 

public key infrastructures, smart cards or other memory tokens. 

n specific 

ather than SSL, 

). The 

n name of the 

al CAs sell SSL 

-government 

ot certificate 

indows, 

t users to verify 

. However, it is important to review the certificate policy and 

choices that may be available from the CAs selling SSL certificates for use on Federal 

agency web servers in order to ensure that the certificates meet the requirements stated 

herein and in SP 800-57. 

Similarly, secure web servers have TLS/SSL server certificates, with certai

characteristics; note that, although Federal users are required to use TLS r

SSL is really just an earlier version of TLS, and the certificates are identical

Subject Name in these certificates follows specific rules so that the domai

server is included in the Subject Name field of the certificate. Commerci

certificates, and, where it is important to reach a general population of non

users, it may be desirable to get an SSL certificate from a CA that has its ro

widely distributed “out of the box” in the certificate stores of Microsoft W

Macintosh OS X, and the various Mozilla browsers. This will allow mos

the server certificate

97
Appendix D: References 

COMMON I Common Policy 

COMMON 

PROF 

RL) Extensions 

Profile for the Shared Secret Providers (SSP) Program” Federal PKI 

p, January 

NN 

“X.509 Certification Policy for the U.S. Federal PK

Framework”, Federal Public Key Infrastructure Policy Authority, 

Version 3647-1.3, December 2007. 

“X.509 Certificate and Certificate Revocation List (C

Policy Authority Shared Service Provider Working Grou

2008 

DE Dorothy E. Denning and Giovanni Maria Sacco, “Time-stamps in Key 

Distribution Protocols,” Communications of the ACM, Vol. 24 (8), p. 

533-536, August 1981. 

DES ANSI X3.106, "American National Standard for Infor

Data Link Encryption," American 

mation SystemsNational Standards Institute, 1983. 

-3 ation Processing 

hnology, U.S. 

FIPS 180-2 ion Processing 

f Standards and Technology, US 

FIPS 180-3 

FIPS 186-3 Processing 

FIPS 197 ES)”, Federal 

essing Standard, National Institute of Standards and 

FIPS 201 PIV) of Federal Employees and 

Contractors”, Federal Information Processing Standard, National 

Institute of Standards and Technology, U.S. Department of 

Commerce, March 2006. 

FPKI PROF “Federal Public Key Infrastructure (PKI) X.509 Certificate and CRL 

Extensions Profile” Booz-Allen & Hamilton and National Institute of 

Standards and Technology, October 2005. 

FIPS 46 “Data Encryption Standard (DES)”, Federal Inform

Standard, National Institute of Standards and Tec

Department of Commerce, October 25, 1999. 

“Secure Hash Standard (SHS)”, Federal Informat

Standard, National Institute o

Department of Commerce, August 2002. 

“Secure Hash Standard (SHS)”, Federal Information Processing 

Standard, National Institute of Standards and Technology, US 

Department of Commerce, June 2007. 

“Digital Signature Standard”, Federal Information

Standard, National Institute of Standards and Technology, U.S. 

Department of Commerce, March 2006. 

FIPS 197, “Advanced Encryption Standard (A

Information Proc

Technology, U.S. Department of Commerce, November 2001. 

“Personal Identity Verification (

98
KEA gorithm Specifications", Version 2.0, 

NEED 

"SKIPJACK and KEA Al

Department of Defense, June 1998. 

Roger M. Needham and Michael D. Schroeder, “Using Large 

Networks of Computers,” Communications of the ACM, Vol. 21 (12), 

pp. 993-999, December 1978. 

NEUM B. Clifford Neuman and Theodore Y. Ts’o, “An Authentication 

Service for Computer Networks,” IEEE Communications Magazine, 

Vol. 32 (9), p. 33-38, September 1994. 

OMB 04-04 “MEMORANDUM TO THE HEADS OF ALL DEPARTMENTS 

ederal 

er 16, 2003 

R AR) Protocol”, 

OTAR1 “Project 25 Digital Radio Over The Air Rekeying Protocol: 

ments for Type 3 

orithms”, TIA/EIA 102.AACA-1, November 

PKCS-5 ord-Based Cryptography Standard", RSA 

PKCS-7 Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", 

RFC 791 RFC 791, September 1981. 

acilities” RFC 1034 

RFC 1035 d Specification” 

 November 1987 

RFC 1510 d C. Neuman “The Kerberos Network Authentication 

Service (V5)”, RFC 1510, September 1993. 

RFC 2045 N. Freed and N. Borenstein, “Multipurpose Internet Mail Extensions 

(MIME) Part One:Format of Internet Message Bodies” RFC 2045, 

November 1996. 

RFC 2046 N. Freed and N. Borenstein, “MIME Part 2: Media Types” RFC 2046, 

November 1996. 

AND AGENCIES RE: E-Authentication Guidance for F

Agencies”, M-04-04, Decemb

OTA “Project 25 Digital Radio Over The Air Rekeying (OT

TIA/EIA-102.AACA-2001, April 2001. 

Addendum 1 - Key Management Security Require

Block Encryption Alg

2002. 

"PKCS #5 v2.0: Passw

Laboratories, March 25, 1999. 

RFC 2315, IETF, March 1998. 

PKCS-10 “PKCS #10 v1.7: Certification Request Syntax Standard” RSA 

Laboratories May 2000 

“Internet Protocol”

RFC 1034 P. Mockapetris “Domain Names – Concepts and F

November 1987. 

P. Mockapetris “Domain Names – Implementation an

RFC 1035

J. Kohl an

99
RFC 2047 or NonRFC 2048 “MIME Part Four: Registration 

RFC 2049 N. Freed and N. Borenstein, “MIME Part Five: Conformance Criteria 

46 n 1.0”, RFC 2246, 

01 the Internet 

 RFC 2401, November 1998. 

02 FC 2402, 

RFC 2404 -SHA-1-96 within ESP 

and AH", RFC 2404, November 1998. 

RFC 2405 oraswamy, "The ESP DES-CBC Cipher 

Algorithm with Explicit IV", RFC 2405, November 1998. 

RFC 2406, November 1998. 

RFC 2407 pretation for 

ISAKMP", RFC 2407, November 1998. 

RFC 2408 D. Maughan, et. al., "The Internet Security Association and Key 

ber 1998. 

09 E)”, RFC 

RFC 2410 R. Glenn and S. Kent, “The NULL Encryption Algorithm and its Use 

with IPsesc”, RFC 2410, November 1998. 

RFC 2451 R. Pereira, and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 

Internet Advisory Board, Internet Engineering Task Force, RFC 2451, 

November 1998. 

K. Moore, “MIME Part Three: Message Header Extensions f

ASCII Text” RFC 2047, November 1996. 

N. Freed, J. Klensin , J. Postel,

Procedures” RFC 2048, November 1996.

and Examples” RFC 2049, November 1996 

RFC 22 T. Dierks and C. Allen, “The TLS Protocol Versio

January 1999. 

RFC 24 S. Kent and R. Atkinson, "Security Architecture for 

Protocol",

RFC 24 S. Kent and R. Atkinson, "IP Authentication Header", R

November 1998. 

C. Madson and R. Glenn, "The Use of HMAC

C. Madson and N. D

RFC 2406 S. Kent, and R. Atkinson, "IP Encapsulating Security Payload (ESP)", 

D. Piper, "The Internet IP Security Domain of Inter

Management Protocol (ISAKMP)", RFC 2408, Novem

RFC 24 Harkins, D., Carrel, D., “The Internet Key Exchange (IK

2409, November 1998. 

100
RFC 2460 rnet Protocol, Version 6 (IPv6) 

RFC 2560 dams, “X.509 

tatus Protocol – 

31 ”, RFC 2631, 

1999. 

34 FC 2634, 

94 andard (AES) Key 

47 tandards 

 and 

RFC 3602 

RFC 3686 ousley, “Using Advanced Encryption Standard (AES) Counter 

, RFC 3686, 

51 ion”, RFC 3851, 

RFC 3852 , RFC 3852, July 

RFC 3962 Encryption for 

os 5”, RFC 3962, February 2005. 

33 ose, “DNS 

March 2005. 

34 S. Rose, 

”, RFC 4034, 

35 d S. Rose, “Protocol 

 RFC 4035, March 

06 ode (GCM) 

 4106, June 

RFC 4109 P. Hoffman, “Algorithms for Internet Key Exchange version 1 

(IKEv1), RFC 4109, May 2005. 

RFC 4120 Neuman, C., Yu, T., Hartman, S., Raeburn, K., “The Kerberos 

Network Authentication Service (V5)”, RFC 4120, July 2005. 

RFC 4210 Adams, C., Farrell, S., Kause, T., Mononen, T., “Internet X.509 Public 

Key Infrastructure Certificate Management Protocol (CMP)”, RFC 

4210, September 2005. 

S. Deering and R. Hinden. “Inte

Specification” RFC 2460 December 1998. 

M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. A

Internet Public Key Infrastructure Online Certificate S

OCSP”, RFC 2560, June 1999. 

RFC 26 E. Rescorla, “Diffie-Hellman Key Agreement Method

June 

RFC 26 P. Hoffman “Enhanced Security Services for S/MIME” R

June 1999. 

R. Housley and J. Schaad, “Advanced Encryption St

Wrap Algorithm”, RFC 3394, September 2002. 

RFC 33

RFC 34 J. Jonsson, and B. Kaliski, “Public-Key Cryptography S

(PKCS) #1: RSA Cryptography Specifications Version 2.1”, RFC 

3447, February 2003. 

RFC 3566 S. Frankel and H. Herbert, “The AES-XCBC-MAC-96 Algorithm

its Use with IPsec”, RFC 3566, September 2003. 

S. Frankel, R. Glenn, and S. Kelly, “The AES-CBC Cipher Algorithm

and its Use with IPsec”, RFC 3602, September 2003. 

R. H

Mode with IPsec Encapsulating Security Payload (ESP)”

January 2004. 

RFC 38 B. Ramsdell, “S/MIME Version 3 Message Specificat

June 1999. 

R. Housley, “Cryptographic Message Syntax (CMS)”

2004. 

K. Raeburn, “Advanced Encryption Standard (AES)

Kerber

RFC 40 R. Arends, R. Austein, M. Larson, D. Massey, and S. R

Security Introduction and Requirements”, RFC 4033, 

RFC 40 R. Arends, R. Austein, M. Larson, D. Massey, D., and 

“Resource Records for the DNS Security Extensions

March 2005. 

RFC 40 R. Arends, R. Austein, M. Larson, D. Massey, an

Modifications for the DNS Security Extensions”,

2005. 

RFC 41 J. Viega and D. McGrew, “The Use of Galois/Counter M

in IPsec Encapsulating Security Payload (ESP)”, RFC

2005. 

101
RFC 4301 “Security Architecture for the Internet Protocol", 

02 ecember 2005. 

03 RFC 4303, 

06 rotocol”, RFC 

07 ternet Key 

08 , December 

09 ES) CCM Mode 

P)”, RFC 4309, 

hm for the Internet 

ary 2006. 

43 Authentication 

and AH”, RFC 4543, May 2006. 

56 itial 

ication in Kerberos (PKINIT)”, RFC 4556, June 2006. 

18 Implementation 

53 ”, RFC 4753, 

RFC 4754 IKE and IKEv2 Authentication Using the 

RFC 4754, 

35 equirements 

ication Header 

68 AC-SHA-384, 

7. 

RFC 5008 cure/Mulitpurpose Internet 

2007. 

19 Certificate Status 

ents”, RFC 5019, 

September 2007. 

RFC 5035 P. Hoffman, “Enhanced Security Services (ESS) Update: Adding 

CertID Algorithm Agility”, RFC 5035, August 2007. 

RFC 5155 B. Laurie, G. Sisson, R. Arends and D. Blacka. “DNSSEC Hashed 

Authenticated Denial of Existence”. RFC 5155, March 2008. 

RFC 5246 T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) 

Protocol Version 1.2", RFC 5246, August 2008. 

S. Kent and K. Seo,

RFC 4301, December 2005. 

RFC 43 S. Kent, "IP Authentication Header", RFC 4302, D

RFC 43 S. Kent, "IP Encapsulating Security Payload (ESP)", 

December 2005. 

RFC 43 C. Kaufman, ed., “Internet Key Exchange (IKEv2) P

4306, December 2005. 

RFC 43 J. Schiller, "Cryptographic Algorithms for use in the In

Exchange Version 2 (IKEv2)" RFC 4307, December 2005. 

P. Hoffman, "Cryptographic Suites for IPsec", RFC 4308

2005. 

RFC 43

RFC 43 R. Housley, “Using Advanced Encryption Standard (A

with IPsec Encapsulating Security Payload (ES

December 2005. 

RFC 4434 P. Hoffman, “The AES-XCBC-PRF-128 Algorit

Key Exchange Protocol (IKE)”, RFC 4434, Febru

RFC 45 D. McGrew, and J. Viega, “The Use of Galois Message

Code (GMAC) in IPsec ESP 

RFC 45 L. Zhu and B. Tung, “Public Key Cryptography for In

Authent

RFC 47 P. Eronen and P. Hoffman, “IKEv2 Clarification and

Guidelines”, RFC 4718, October 2006. 

RFC 47 D. Fu and J. Solinas, “ECP Groups for IKE and IKEv2

January 2007. 

D. Fu and J. Solinas, “

Elliptic Curve Digital Signature Algorithm (ECDSA)”, 

January 2007. 

RFC 48 V. Manral, “Cryptographic Algorithm Implementation R

for Encapsulating Security Payload (ESP) and Authent

(AH)”, RFC 4835, April 2007. 

RFC 48 S. Kelly and S. Frankel, "Using HMAC-SHA-256, HM

and HMAC-SHA-512 with IPsec", RFC 4868, May 200

RFC 4869 L. Law and J. Solinas, “Suite B Cryptographic Suites for IPsec”, RFC 

4869, May 2007. 

R. Housley, and J. Solinas, “Suite B in Se

Mail Extensions (S/MIME) “, RFC 5008, September 

RFC 50 A. Deacon and R. Hurst, “ The Lightweight Online

Protocol (OCSP) Profile for High-Volume Environm

102
103

RFC 5272 ad, “Certificate Management Messages over 

RFC 5280 ousley, and W. 

ificate and 

May 2008. 

Curve 

lateral/sec1.pdf.] 

SP 800-15 ISPC Minimum 

ion 1”, 

pecial 

SP 800-32 V. Hu, W. Polk, and S. Chang, “Introduction to Public Key 

 National Institute of 

n 800-32, 

8A s of 

ogy, NIST 

cember 2001 

-56A dations for Pair-Wise 

ryptography 

gy, NIST 

SP 800-67 Encryption 

, te of Standards and 

4. 

SP 800-78-1 rithms and Key 

tion” National Institute of 

n 800-78-1, 

SP 800-81 ure Domain Name System (DNS) 

d Technology, 

2006. 

800-90 dom Number 

vised)”, 

TPM TCG TPM Specification Version 1.2 Revision 103 including Design 

Principles, Structures of the TPM, and Commands. 

X9.62 ANSI X9.62, "Public key cryptography for the financial services 

industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", 

November 2005. 

M. Myers and J. Scha

CMS “, RFC 5272, June 2008. 

D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. H

Polk, “Internet X.509 Public Key Infrastructure Cert

Certificate Revocation List (CRL) Profile”,RFC 5280, 

SEC1 Standards for Efficient Cryptography Group, “Elliptic 

Cryptography”, 2000. [See http://www.secg.org/col

W. Burr, D. Dodson, N Nazario, and W. Polk, “M

Interoperability Specifications for PKI Components, Vers

National Institute of Standards and Technology, NIST S

Publication 800-15, September 1997. 

D. Kuhn,

Technology and the Federal PKI Infrastructure”,

Standards and Technology, NIST Special Publicatio

February 2001. 

SP 800-3 M. Dworkin, “Recommendations for Block Cipher Mode

Operation” National Institute of Standards and Technol

Special Publication 800-38A De

SP 800 E. Barker, D. Johnson and M. Smid, “Recommen

Key Establishment Schemes Using Discrete Logarithm C

(Revised)” National Institute of Standards and Technolo

Special Publication 800-56A March 2007. 

W. Barker, “Recommendation for the Triple Data 

Algorithm (TDEA) Block Cipher” National Institu

Technology, NIST Special Publication 800-67, May 200

W. Polk, D. Dodson and W. Burr, “Cryptographic Algo

Sizes for Personal Identity Verifica

Standards and Technology, NIST Special Publicatio

August 2007. 

R. Chandramouli and S. Rose, “Sec

Deployment Guide”, National Institute of Standards an

NIST Special Publication 800-81, May 

SP E. Barker and J. Kelsey, “Recommendation for Ran

Generation Using Deterministic Random Bit Generators (Re

NIST Special Publication 800-90, March 2007.