Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Great documentation resources, Jeff.

 

Yes, for the average reader, just understanding that there is a difference between SHA-1 and HMAC-SHA-1 is non-trivial. Perhaps this should all go into an appendix (to keep “TLS” discussions out of the main body) and perhaps it should be headed with a brief summary (or claim #1) along the lines of “while SHA-1 and HMAC-SHA-1 use mathematically similar operations, they are distinct encryption/hashing algorithms”

 

--- Eric

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Friday, October 04, 2013 12:02 PM
To:
Subject: RE: [AD-Assurance] 5.2.1 HMAC-SHA1 comment

 

Please add these NIST references if it will help clarify the issues surrounding HMAC-SHA-1 and TLS with (SHA-1/MD5).   It’s a good thing I had local copies.  NIST website is closed due to gov’t shutdown.  While these are not specific to AD, the questions are likely to come up anyway when someone reads the document.  This is somewhat long, but it is my best attempt to walk through the inter-connected NIST documents that cover FIPS, approved algorithms, keys, hash functions, and protocols. 

 

As for the problem with the Microsoft document, it probably has to do with Windows TLS implementations using schannel and having the FIPS setting turned on to ensure approved algorithms.  Is there any way to configure schannel to use only approved algorithms when communicating with the IdP/Verifier, but not force all workstations to have the FIPS setting turned on?  Could it be configured at the other end (IdP/Verifier) to only accept approved protocols? –Jeff C.

 

Claims to make:

·         HMAC-SHA-1 is approved after 12/31/2013 even though SHA-1 for digital signature is not.

·         HMAC-SHA-1 is capable of security strengths of 80, 112, and 128 bits. (112 is required after 12/31/2013).

·         SHA-1 is 160 bits and provides at least 112 bits of preimage resistance that is needed to achieve the 112-bit security strength for HMAC.

·         TLS 1.0 – Approved only with non-govt systems

·         TLS 1.1 – Acceptable, but should migrate to TLS 1.2 by January 1, 2015

·         TLS 1.2 -  Approved

 

 

Recommendation for Applications Using Approved Hash Algorithms

Summary: HMAC-SHA-1 is approved even though SHA-1 for digital signature is not.

SP 800-107 Revision 1, page7:

In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance (see Table 1 in Section 4.2) needed to achieve the security strength.

 

On the other hand, SHA-1 does provide the 112 bits of preimage resistance that is needed to achieve the 112-bit security strength for HMAC. The security strengths of the approved hash functions for different applications can be found in SP 800-57, Part 1 [SP 800-57].

 

Recommendation for Key Management – Part 1: General (Revision 3)

SP800-57

Table 3 identifies HMAC/SHA1 being capable of security strengths of 80, 112, and 128 bits.

Table 3 [not included here] lists the hash functions that shall be used for providing the indicated security strength for the generation of digital signatures and HMAC values, for deriving keys using key derivation functions (i.e., KDFs) and for random number generation. For some applications, a cryptographic key is associated with the application and needs to be considered when determining the security strength actually afforded by the application. For example, for the generation of digital signatures, the minimum key length for the keys for a given security strength is provided in the FFC, IFC and ECC columns of Table 2; while for HMAC, the key lengths are discussed in [SP800-107].

 

Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths

SP800-131A

HMAC Generation: Any approved hash function may be used. (FYI: SHA-1 is an approved hash function)

 

From January 1, 2011 through December 31, 2013, the use of key lengths ≥ 80 bits, but < 112 bits is deprecated.

After December 31, 2013, key lengths < 112 bits shall not be used. The use of key lengths ≥ 112 bits is acceptable.

 

FIPS 140-2 Implementation Guide

Summary: TLS 1.0 / SSL3.1 are OK after 12/31/2013. 

See footnote on page 156 “TLS also uses MD5 in the key derivation process, but in a different manner, so that all of the master key depends on both MD5 and SHA-1; nothing in TLS actually depends on MD5 for its security. Therefore, TLS implementations can be validated under FIPS 140-2, while SSL 3.0 implementations cannot.”

 

Draft SP800-52-Revision 1

Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

TLS 1.0 – With non-govt systems

TLS 1.1 – Migrate to TLS 1.2 by January 1, 2015

TLS 1.2 -  Approved

TLS versions 1.1 and 1.2 are approved for the protection of Federal information, when properly configured. TLS version 1.0 is approved only when it is required for interoperability with non-government systems and is configured according to these guidelines.  

REFER TO PAGE 34 FOR SPECIFIC ALGORITHMS SUPPORTED--- 3.9.2 Recommendations for Server Installation and Configuration

In TLS versions 1.0 and 1.1, the hash function used in the PRF is a parallel application of MD5 and SHA-1, as defined in [RFC2246] and [RFC4346]. For TLS 1.2, the PRF hash function is SHA-256, unless otherwise stated.

In order to maximize interoperability, TLS server implementations shall support the following cipher suites: (Note: other “should support” cipher suites not included here.)

• TLS_RSA_WITH_3DES_EDE_CBC_SHA

• TLS_RSA_WITH_AES_128_CBC_SHA

 

 

GENERAL DISCLAIMER:  (SP 800-57 page 67, Table 4)

If the security life of information extends beyond one time period specified in the table into the next time period (the later time period), the algorithms and key sizes specified for the later time period shall be used for applying cryptographic protection (e.g., encryption). The following examples are provided to clarify the use of the table:

1. If information is cryptographically protected (e.g., digitally signed) in 2012, and the maximum-expected security life of that data is only one year, any of the approved digital-signature algorithms or key sizes that provide at least 80 bits of security strength may be used. However, if only 80 bits of protection is used, there is some risk that needs to be accepted. Note that a digital signature that provides 80 bits of security could be processed (i.e., verified) after 2013 as  indicated by the “legacy use” indication in the table.

2. If the information is to be digitally signed in 2012, and the expected security life of the data is six years, then an algorithm or key size that provides at least 112 bits of security strength is required.

 

> 

>-- "5.2.1 Transmission of Authentication Secrets Between Credential

>   Stores"

> 

>   In the bulleted item, the text current reads "select one of the AES

>   options"

> 

>   There are only two options: AES128_HMAC_SHA1 and AES256_HMAC_SHA1

> 

>   Of the two, AES256_HMAC_SHA1 would be preferable, but it still uses

>   SHA1 which is deprecated/will be deprecated as the document itself

>   notes at 2.3 in bold text.

> 

>   This section also requires use of LDAPS (TLS/SSL), but more

>   specificity is needed when it comes to explaining what constitutes

>   an acceptable version of TLS (e.g., is TLS 1.0 good enough? It

>   shouldn't be treated as such). Require TLS 1.2 with an appropriate

>   cipher suite (that should be a whole section of its own)

> 

>   The Microsoft references in document section 5.3.1 ("Section 4.2.3.6.2

>   requirements") really don't clear this up, either.

>