Skip to Content.
Sympa Menu

ad-assurance - RE: [AD-Assurance] NIST Approved Encryption

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

RE: [AD-Assurance] NIST Approved Encryption


Chronological Thread 
  • From: "Capehart,Jeffrey D" <>
  • To: "" <>
  • Subject: RE: [AD-Assurance] NIST Approved Encryption
  • Date: Wed, 6 Mar 2013 14:34:53 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none

Eric,

 

Yes, I was just looking at FIPS 140-2 “Annex A” yesterday.  It is in draft from May 2012, but there continue to be new updates to algorithms that are approved.

 

The document SP800-131A has a much more definitive list that even includes terms such as Approved and Acceptable as well as Restricted.

 

I have taken the liberty of creating my own table from all these disparate resources, with appropriate references to the authoritative documents.  Even NIST themselves claim to have a difficult time keeping up with the latest approved algorithms and they disclaim their website as not being complete or up-to-date.  So, even if an algorithm isn’t mentioned on the list, if it is “adopted in a FIPS or NIST Recommendation” then it is also considered approved.  Take for instance XTS_AES which uses the AES encryption algorithm (approved) but in a block cipher mode.  There is a disclaimer that XTS_AES is only good for stored data, not for transmitting the data over the Internet.

 

Anyway, I don’t know if this list will take attachments so I will just post my table here in-line.  Also, I have included a couple encryption types not allowed since there is an extension through the end of 2013 on versions that are 80-111 bits of security strength.  After that, they are no longer acceptable for use.  So the algorithm has to both have been approved and been deemed acceptable to use.  See some of my notes below the table.

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu

 

 

 

Algorithm

Description

Type

Standard

Validation

Encrypt Status

AES-128

Advanced Encryption Standard

Symmetric

FIPS 197

Nov-01

Acceptable

AES-192

Advanced Encryption Standard

Symmetric

FIPS 197

Nov-01

Acceptable

AES-256

Advanced Encryption Standard

Symmetric

FIPS 197

Nov-01

Acceptable

DES

Data Encryption Standard

Symmetric

FIPS 46-3

Withdrawn

Not Allowed

2TDEA

Triple Data Encryption Algorithm (2-key)

Symmetric

SP800-67 Rev1

May-04

Restricted 2011-15

3TDEA

Triple Data Encryption Algorithm (3-key)

Symmetric

SP800-67 Rev1

May-04

Acceptable

EES

Escrowed Encryption Standard (Skipjack)

Symmetric

FIPS 185

Feb-94

Not Allowed

XTS_AES

XEX Tweakable Block Cipher with Stealing

Symmetric

SP800-38E

Jan-10

APPROVED

DSA

Digital Signature standard Algorithm

Asymmetric

FIPS 186-3

Jun-09

Acceptable

RSA

Rivest-Shamir-Adleman

Asymmetric

FIPS 186-3

Jun-09

Acceptable

ECDSA

Ellicptic Curve Digital Signature Algorithm

Asymmetric

FIPS 186-3

Jun-09

Acceptable

SHA-1

Secure Hash Standard (Algorithm)

Hash

FIPS 180-4

Mar-12

Acceptable

SHA-224

Secure Hash Standard (Algorithm)

Hash

FIPS 180-4

Mar-12

Acceptable

SHA-256

Secure Hash Standard (Algorithm)

Hash

FIPS 180-4

Mar-12

Acceptable

SHA-384

Secure Hash Standard (Algorithm)

Hash

FIPS 180-4

Mar-12

Acceptable

SHA-512

Secure Hash Standard (Algorithm)

Hash

FIPS 180-4

Mar-12

Acceptable

CMAC

Cipher-based Message Authentication Code

Message Authentication

SP800-38B

May-05

Acceptable

CCM

Counter with Cipher block chaining MAC

Message Authentication

SP800-38C

May-04

Acceptable

GCM

Galois/Counter Mode

Message Authentication

SP800-38D

Nov-07

Acceptable

GMAC

Galois Message Authentication Code

Message Authentication

SP800-38D

Nov-07

Acceptable

HMAC

keyed-Hash Message Authentication Code

Message Authentication

FIPS 198

Jul-08

Acceptable

AESKW

AES Key Wrap

Key Wrapping

SP800-57

 

Acceptable

TDKW

Three-key Triple DES Key Wrap

Key Wrapping

SP800-57

 

Acceptable

 

NOTE1:

After December 31, 2013, key lengths providing less than 112 bits of security strength shall not be used to generate digital signatures

NIST SP 800-131A

http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

NOTE2:

Through the year 2030, Triple DES (TDEA) and the FIPS 197 Advanced Encryption Standard (AES) will coexist as approved algorithms thus, allowing for a gradual transition to AES. (The AES is another symmetric-based encryption standard approved by NIST.)

NIST SP 800-67 Rev 1

http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf

NOTE3:

TDEA with Keying Option 2 (see Section 3) is approved for the protection of Federal government information only through the period of time specified in SP 800-131A. Recommendations regarding the use of Option 2 are contained in SP 800-57, Part 1.

NIST SP 800-67 Rev 1

http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf

NOTE4:

Future use of DES by Federal agencies is to be permitted only as a component function of the Triple Data Encryption Algorithm (TDEA or Triple-DES) (NIST Special Publication 800-67). Triple-DES may continue to be used for the foreseeable future for the protection of Federal information; however, NIST encourages agencies to implement the faster and stronger algorithm specified by FIPS 197, Advanced Encryption Standard (AES).

DES Transition Plan

http://csrc.nist.gov/groups/STM/common_documents/DESTranPlan.pdf

 

 

 

Reference

Link

FIPS 140-2 Annex A: Approved Security Functions for Cryptographic Modules

http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

NIST Cryptographic Algorithm Validation Program (CAVP)

http://csrc.nist.gov/groups/STM/cavp/index.html

NIST Cryptographic Module Validation Program (CMVP)

http://csrc.nist.gov/groups/STM/cmvp/index.html

NIST CMVP Module Validation Lists

http://csrc.nist.gov/groups/STM/cmvp/validation.html

NIST Special Publications

http://csrc.nist.gov/publications/PubsSPs.html

NIST SP 800-67-Rev1 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher

http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf

NIST SP 800-131 A - Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths

http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

NIST Cryptographic Toolkit - Block Ciphers - Approved Algorithms

http://csrc.nist.gov/groups/ST/toolkit/block_ciphers.html

NIST Cryptographic Toolkit - Message Authentication - Approved Algorithms

http://csrc.nist.gov/groups/ST/toolkit/message_auth.html

NIST The Galois/Counter Mode (GCM) and GMAC Validation System (GCMVS)

http://csrc.nist.gov/groups/STM/cavp/documents/mac/gcmvs.pdf

 

 

NIST Cryptographic Algorithm Validation Program (CAVP)

http://csrc.nist.gov/groups/STM/cavp/validation.html

 

Algorithm Validation

 

NIST maintains validation lists for each cryptographic standard testing program (past and present). As new algorithm implementations are validated by NIST and CSEC, they are added to the appropriate algorithm validation list.

 

AES Validation List

Triple-DES Validation List

Skipjack Validation List

DSA Validation List

RSA Validation List

ECDSA Validation List

SHS Validation List

RNG Validation List

DRBG Validation List

CCM Validation List

HMAC Validation List

KAS Validation List

KDF (SP800-108) Validation List

Component Validation List (CVL)

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Tuesday, March 05, 2013 3:05 PM
To:
Subject: RE: [AD-Assurance] RE: Various links of interest

 

Thanks for calling out that linkage, David.

 

Despite Jeff’s clear summary of when he was referring to FIPS 140-2 security levels vs. NIST 800-63 LoA levels, my brain was spinning trying to hook it all together. J (That’s a comment on the linkages in the source documents, not on Jeff’s summary!)

 

So if you are saying that all we need for InCommon/NIST 800-63 LoAs 1 and 2 are “Approved Algorithms”, and not the full FIPS profile, then that means the relevant link is actually “Annex A” of the FIPS document, correct?

 

The “Annex A” document itself seems very hard to find… FIPS 140-2 refers to

 

  http://csrc.nist.gov/groups/STM/cmvp/index.html

 

for the Annex, but I don’t see links to either “Annex A” or “Approved Algorithms” there. I did find the following draft version of Annex A in a more general Google search, last updated in mid 2012:

 

   http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

 

is that the document we’re looking for?

 

--- Eric

 

 

From: [] On Behalf Of David Walker
Sent: Monday, March 04, 2013 10:43 AM
To:
Subject: Re: [AD-Assurance] RE: Various links of interest

 

Hmmm...  I see that the draft I barely started in Friday actually got sent...

Anyway, as I started to say, the issue is how to map 800-63's levels of assurance to FIPS 140-2's levels of security for credential storage.  That can be found in section "7.3 Token and Credential Management Assurance Levels" of 800-63-1:

  • LoA 1:  No FIPS 140-2 requirement.
  • LoA 2:  No FIPS 140-2 requirement, although an Approved algorithm must be used to encrypt the password.
  • LoA 3: FIPS 140-2 Level 2 or higher is required.
  • LoA 4: FIPS 140-2 Level 2 or higher is required.


Not a lot of help for us here.  My quick reading of 140-2, however, tells me that all levels of FIPS 140-2 require an Approved algorithm, so any 140-2 certified password storage method should suffice for LoA-2.
David

On Fri, 2013-03-01 at 17:03 -0800, David Walker wrote:

Thanks, Jeff.  You've done a lot of my work for me.

The remaining issue is how we map NIST 800-63's levels of assurance to FIPS 140-2's levels of security.



On Fri, 2013-03-01 at 19:10 +0000, Capehart,Jeffrey D wrote:

There was also a question about which Level of Assurance mapped to which FIPS security level. 

 

My understanding is that all FIPS 140-2 Security Levels use Approved Algorithms so for the purposes of InCommon Silver IAP V1.2 that it does not matter whether the Approved Algorithms you use are Level 1,2,3, or 4.  Any should suffice.  The Security level is not related to the Assurance level.

 

Keep on reading if interested…

 

Refer to Special Publication SP 800-63-1Electronic Authentication Guideline

http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf

 

OMB M-04-04 defines four levels of assurance, Levels 1 to 4, in terms of the consequences of authentication errors and misuse of credentials. Level 1 is the lowest assurance level, and Level 4 is the highest.  To avoid confusion, refer to these specifically as  ASSURANCE LEVEL(s) 1-4.

 

Note that in general, BRONZE maps to Assurance Level 1 and SILVER to Assurance Level 2.

 

FIPS 140-2 says:This standard specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information (hereafter referred to as sensitive information). The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4.  Note that later they are referred to more specifically as SECURITY LEVEL(s) 1-4.   If interested in the differences, refer toTable 1: Summary of security requirementsin FIPS 140-2.

 

Here’s where assurance levels come in for Active Directory:

You will see by reading the IAP 1.2 Criteria #4.2.3.4 (Silver) Stored Authentication Secrets… there are three choices to select from.  The verbiage is quite similar to what you will see for Assurance Level 2 in SP-800-63-1.  You are also allowed to use Level 3 or 4.  Level 1 also is very similar to the #4.2.3.5 (Bronze) Basic Protection of Authentication Secrets.

 

At Level 1, the following shall be required:  (Compare to BRONZE #4.2.3.5)

•                     Credential storage– Files of shared secrets used by Verifiers at Level 1 authentication shall be protected by access controls that limit access to administrators and only to those applications that require access. Such shared secret files shall not contain the plaintext passwords; typically they contain a one-way hash or “inversion” of the password. In addition, any method allowed for the protection of long-term shared secrets at Level 2 or above may be used at Level 1.

 

At Level 2, the following shall be required:(Compare to SILVER #4.2.3.4)

Credential storage – Files of shared secrets used by CSPs at Level 2 shall be protected by access controls that limit access to administrators and only to those applications that require access. Such shared secret files shall not contain the plaintext passwords or secrets; two alternative methods may be used to protect the shared secret:

1.     Passwords may be concatenated to a variable salt (variable across a group of passwords that are stored together) and then hashed with an Approved algorithm so that the computations used to conduct a dictionary or exhaustion attack on a stolen password file are not useful to attack other similar password files. The hashed passwords are then stored in the password file. The variable salt may be composed using a global salt (common to a group of passwords) and the username (unique per password) or some other technique to ensure uniqueness of the salt within the group of passwords.

2.     Shared secrets may be encrypted and stored using Approved encryption algorithms and modes, and the needed secret decrypted only when immediately required for authentication. In addition, any method allowed to protect shared secrets at Level 3 or 4 may be used at Level 2.

 

Jeff

 

From: [] On Behalf Of Brian Arkills
Sent: Friday, March 01, 2013 1:01 PM
To:
Subject: [AD-Assurance] Various links of interest


 

Incommon IAP

http://www.incommon.org/docs/assurance/IAP.pdf

 

AD Silver cookbook

https://spaces.internet2.edu/display/InCAssurance/InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook

 

FIPS 140-2

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

 

Example of specific Microsoft library that is FIPS approved:

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2010.htm#1335

 

Note: All of these have at the end of the "Operational Environment:" the parenthetical "(single-user mode)".

 

Enabling FIPS approved mode on Windows:

http://support.microsoft.com/kb/811833

 

-B

 

 



  • RE: [AD-Assurance] NIST Approved Encryption, Capehart,Jeffrey D, 03/06/2013

Archive powered by MHonArc 2.6.16.

Top of Page