IAP v1.2 Section |
Requirements (paraphrased) |
AD-DS Baseline Controls |
Baseline Gaps |
AM Proposal |
Remaining Gaps |
4.2.3.4 - Stored Authentication Secrets (S) |
Do not store passwords as plaintext. Limit access to admins and apps that require access. |
Passwords are stored in the ntds.dit file. They are not stored as plaintext. The operating system normally prevents access to the file. |
No gaps. |
|
|
|
Protect stored passwords with one of the following alternatives: |
1. The "NT hash" is an unsalted MD4 hash. The "LM hash" isn't a cryptographic hash. |
1. MD4 is not an Approved Algorithm and a variable salt is not employed. |
|
|
|
2. Encrypt the password with an Approved Algorithm and decrypt only when immediately needed for authentication. |
2. Encrypts the "NT hash" with DES and the users RID, then encrypts again with RC4 and the PEK. The "LM hash" is the output from encrypting a constant with the password and DES. |
2. DES and RC4 are not Approved Algorithms. |
|
|
|
3. Any method allowed for NIST 800-63 Level 3 or 4. |
|
|
|
|
4.2.3.5 - Basic Protection of Authentication Secrets (B) |
1. Do not store passwords as plaintext. Limit access to admins and apps that require access. |
1. Passwords are stored in the ntds.dit file. They are not stored as plaintext. The operating system normally prevents access to the file. |
1. No gaps |
|
|
|
2. Do not transmit plaintext passwords over the network |
2. Authentication using Kerberos, LM, NTLM, or LDAP over SSL does not transmit cleartext passwords. |
2. LDAP without SSL transmits plaintext passwords. |
|
|
4.2.3.6 - Strong Protection of Authentication Secrets (S) |
1a. Any credential store with passwords used by the IdP or verifier is subject to 4.2.3.4 and 4.2.8. |
1a. See the relevant sections in this table. |
1a. See the relevant sections in this table. |
|
|
|
1b. Use Protected Channels when passwords are sent from one credential store to another. |
1b. This is an issue concerning the provisioning of passwords into or out of AD-DS. |
1b. There may be implementation specific issues based on local technology choices. |
|
|
|
2. Use Protected Channels when passwords are sent between services for verification purposes. |
|
|
|
|
|
3. Have policies and procedures to minimize the risk of transient password exposure to non-IdP apps. |
|
|
|
|
4.2.5.1 - Resist Replay Attack (B, S) |
Ensure it's impractical to achieve authentication by recording and replaying a previous authentication message. |
LM - |
|
|
|
4.2.5.2 - Resist Eavesdropper Attack (B, S) |
Ensure it's impractical to learn the password or otherwise obtain information that would allow impersonation of a subject by network eavesdropping. |
LM - |
|
|
|
4.2.8.2.1 - Network Security (S) |
Protected Channels should be used for communication between IdMS systems. |
|
|
|
|
Definitions from the Identity Assurance Assessment Framework:
- Approved Algorithm - Any implementation of an algorithm or technique specified in a FIPS standard or NIST recommendation, or any algorithm or technique that conforms to an alternative means identitified by InCommon as approved for specified IAPs.
- Protected Channel - A Protected Channel uses cryptographic methods that implement an Approved Algorithm to provide integrity and confidentiality protection, resistance to replay and man-in-the-middle attacks, and mtual authentication.