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

Compare with Current View Page History

« Previous Version 4 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
"LMhash" is the output from encrypting a constant with
the password and DES. 

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.

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 specifies IAPs.
  • Protected Channel - A Protected Channel uses cryptogrphic methods that implement and Approved Algorithm to provide integrity and confidentiality protection, resistance to replay and man-in-the-middle attacks, and mtual authentication.
  • No labels