You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

IAP v1.2 Section 

Requirements (paraphrased)

AD-DS

Gaps

4.2.3.4 - Stored Authentication Secrets (S)

Do not store passwords as plaintext. Limit access to admins and apps that require access.

Protect stored passwords with one of the following alternatives:

1. Concatenate a variable salt to the password and hash with an Approved Algorithm.

2. Encrypt the password with an Approved Algorithm and decrypt only when immediately needed for authentication.

3. Any method allowed for NIST 800-63 Level 3 or 4.

Passwords are stored in the ntds.dit file. They are not stored as plaintext. The operating system normally prevents access to the file.

1. The "NT hash" is an unsalted MD4 hash. The "LM hash" isn't a cryptographic hash.


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. 

No gaps.

1. MD4 is not an Approved Algorithm and a variable salt is not employed.

2. DES and RC4 are not Approved Algorithms.

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.

2. Do not transmit plaintext passwords over the network

1. Passwords are stored in the ntds.dit file. They are not stored as plaintext. The operating system normally prevents access to the file.

2. Authentication using Kerberos, NTLM, or LDAP over SSL does not transmit cleartext passwords.

1. No gaps

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.

1b. Use Protected Channels when passwords are sent from one credential store to another.

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.

1a. See the relevant sections in this table.

1b. This is an issue concerning the provisioning of passwords into or out of AD-DS.

2.

3.

1a. See the relevant sections in this table.

1b. There may be implementation specific issues based on local technology choices.

4.2.5.1 - Resist Replay Attack (B, S)

Ensure it's impractical to achieve authentication by recording and replaying a previous authentication message.

Can support low str methods (LDAP bind, LM) Kerb replay concerns

 

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.

Can support low str methods (LDAP bind, 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.
  • No labels