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