Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Since “digest” is the official term for output of a cryptographic hashing function, that makes it sound like a hash of a hash.  But, I think the Microsoft description and reference to digest is getting at the HMAC-SHA1 which is the 20 octet digest output based on the NTLM one-way-function (most commonly referred to as the NT hash).

 

HMAC-SHA1 looks like an approved algorithm.  SHA1 is not being used for digital signature generation, and thus pure hashing, so it should be OK.

 

This probably goes back to RC4-HMAC and RFC 4757 which is why it may be foggy.

 

I think there could be a problem with HMAC-MD5 since the message digest #5 algorithm (MD5) is not an approved hashing function.  MD5 has a smaller digest output than SHA1.  (128 bits v. 160 bits) or 16 bytes v. 20 bytes.  That would make the nominal security strength only 64 bits.

 

While it may be true that “The digest of the password hash cannot be used to access resources in the customer's on-premises environment”, I think our concern was whether or not the digest could be used in offline cracking attacks (as a result of eavesdropping to capture the hash) in a manner that could be considered “practical”.

 

Per the IAP v1.2, password sync falls under communications between systems which would require protected channels. (4.2.8.2.1).  Here’s wording from the IAAF v1.2:

 

The security of communications between system components (IdP, IdMS, Verifier, etc.) is

important. A Protected Channel uses cryptographic methods that implement an Approved

Algorithm to provide integrity and confidentiality protection, resistance to replay and manin-

the-middle attacks, and mutual authentication. For example, typical SSL/TLS

implementations provide these protections.

 

Although this doesn’t require SSL/TLS, it may be the easiest way to be sure a protected channel is implemented.  Would an approved algorithm encryption of the specific data being sent over the network meet this requirement?  If so, maybe the HMAC-SHA1 would be sufficient protection.

 

Jeff C.

 

From: [mailto:] On Behalf Of Brian Arkills
Sent: Tuesday, June 04, 2013 10:10 AM
To:
Subject: [AD-Assurance] Azure AD DirSync password sync

 

Yesterday, Microsoft released a new version of their DirSync tool. This new version supports password synchronization from your on-premise AD. This allows enterprises that don't want to use federated authentication nor manage two sets of passwords to have a single password for their users.

 

I think we've talked briefly about this possibility in the past, but my recollection is foggy. In any event, there's some detail at http://technet.microsoft.com/en-us/library/dn246918.aspx, where a key phrase is:

 

"When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment."

 

I don't think we should include this scenario in the core portion of the revised cookbook document, but I do think we should mention it and note that those who choose to use this option should consider the implications.

 

-B