Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

A significant emphasis on the part of the alternative means statement should be towards “Strong Protection of Authentication Secrets”.  The interpretation being used as it applies to these specific authentication methods is helpful.  (See Eric’s 2^nd email with interpretation for 4.2.3.6.2)

 

One problem to consider is that Bronze 4.2.3.5 says “don’t transmit plain-text passwords.”  Silver says “use a protected channel.”  LM Hash, NT Hash, NTLMv2 and Kerberos RC4-HMAC don’t meet protected channel, but they aren’t plain text either.  However, LM hash is so weak it might as well be plain text.  NTLM (V1) is stronger, and NTLMv2 & RC4-HMAC are better.

 

Ultimately, the minimum bar for Windows AD would need to be set at NTLMv2 & RC4 (RC4-HMAC) which although not being “approved algorithms” would be much better than a plain text password and better than the older weaker protocols.

 

I suppose it may not make much difference, but if the IdP <-> Verifier channel on the Shibboleth side uses a protected channel (such as LDAPS SSL/TLS), then for InCommon’s touching point with an IdP (with HTTPS), the spirit and letter of Silver is met.  The other protocols (NTLMv2, RC4-HMAC) would be used by the verifier only for other authentications that aren’t Shibboleth such as logging in to a Windows workstation, file share, server, database, etc.  The point here is that the non-approved algorithms would not be used when doing the Shibboleth/InCommon Profile verifications/authentications.  Therefore, if the risk of having a credential/authentication secret ‘learned’ from the internal side can be argued to be low, that could help support the alternative means statement.  For example, learning the secret may require network eavesdropping which could limit the risk to the IdP’s internal network rather than those protocols going across the whole Internet. Having switched networks and encrypted WiFi might help limit exposure on the internal network.

 

--Jeff C.

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Friday, August 23, 2013 3:55 PM
To:
Subject: [AD-Assurance] RE: Definitions for Authentication Secrets

 

Thanks for finding these (I never found the one in the IAAF).

 

The NIST definition is arguably broader than the IAAF’s, the IAAF sounds like it really means “the password” not “a session key”.

 

I was just getting ready to send my suggested text, but it is written assuming that an encrypted session key or a response message (to am NTLMv2 challenge) would be considered an “Authentication Secret”. The IAAF definition implies to me that it is not, and to me shifts the argument back over to “we’re not sending the authentication secret, we’re sending something encrypted with the authentication secret” although part of me feels like “sending my password encrypted” and “sending data encrypted with my password” are roughly equivalent.

 

--- Eric

 

 

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Friday, August 23, 2013 10:49 AM
To:
Subject: [AD-Assurance] Definitions for Authentication Secrets

 

Following up from today’s call on the discussion surrounding “Authentication Secrets” and whether a hash versus the plaintext password would be considered to be included…

 

Note the slight variations and differences in the definitions for “Authentication Secret”:

 

NIST SP800-63

A generic term for any secret value that could be used by an Attacker to impersonate the Subscriber in an authentication protocol.

These are further divided into short-term authentication secrets, which are only useful to an Attacker for a limited period of time, and long-term authentication secrets, which allow an Attacker to impersonate the Subscriber until they are manually reset. The token secret is the canonical example of a long term authentication secret, while the token authenticator, if it is different from the token secret, is usually a short term authentication secret.

 

IAAF v1.2

The term Authentication Secret is used generically for passwords, passphrases, PINs,

symmetric keys and other forms of secrets used for authentication. An Authentication

Secret may also be generated by a Token, which is a physical device (or specialized

software on a device such as a mobile phone) used in authentication. Authentication

Secrets are vulnerable to guessing attacks, so resistance to guessing is an important IAP

requirement. Requirements for protection of Secrets in transit and storage also may be

needed.

 

NOTE: Another key point to reference for the Alternative Means statements:

3.1.3 CREDENTIAL TECHNOLOGY

For shared secret Credentials, e.g., userID/password, the IAP might address how the

Authentication Secret must be sufficiently difficult for a person other than the Subject to

determine through trial and error, or other means and must be protected from illicit capture

or replay.

 

Appendix C:

Authentication Secret

Used generically for passwords, passphrases, PINs, symmetric keys and other forms of secrets used for authentication

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu