Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

Ann,

Looping them in on electronic mail is probably the most effective thing.  It might also help us to resolve some of our questions prior to the call, so we could focus on the knottier issues during the call.  It may be hard to have a single spokesperson during the call, but we should certainly have a lead spokesperson with authority to get us out of rat holes.

I've edited some thoughts on MS's questions below.

David

On Tue, 2013-07-23 at 15:02 +0000, Ann West wrote:
>     Hi All,
>     
>     
>     Below is a list of questions from Microsoft about our questions in preparation for Friday's call. How would you like us to respond to them?
>     
>     
>     We could have a quick call this week or just loop them in on a thread and discuss via email. It strikes me that we should have a technical spokesperson to lead the discussion as opposed to everyone pitching in…but I'm easy on this. 
>     
>     
>     Thoughts?
>     
>     
>     A
>     
>     
>     
>     
>     -------------

For the Question List, I think our team has some questions on INTENT and RATIONALE that might help us to understand the predicament facing your customer groups.  Maybe we use the time to discuss the answers that I do have, plus gaining more knowledge on the other points that are still outstanding?

 

Regarding your AD-DS question list, here’s the current list (from https://spaces.internet2.edu/display/InCAssurance/Questions+for+Microsoft)  – with commentary and intended discussion points:

 

1. Protected Channels - IAP 4.2.3.6.1b - Gaps
   1. RC4 HMAC encryption is not NIST or FIPS approved, and we would like to determine if it's comparable to those methodologies that are.  Can you help with this? (See http://www.incommon.org/assurance/alternativemeans.html for the criteria we will consider.) RC4 HMAC is not considered a suitable encryption method moving forward, and its use within future deliverables is not practical.  Per Microsoft Crypto Standard Procedures, stream ciphers such as RC4 HMAC should be replaced with block ciphers such as AES with a minimum key length of 128 bits.

Hmmm...  Sounds like a "no," which could put us between a rock and a hard place.  We've been assuming that it is not practical to stop using RC4 HMAC in common ADDS deployments in higher ed.  Are the Microsoft Crypto Standard Procedures more practical to deploy than we have thought?

1. Currently, it is not very practical to crack RC4 HMAC, even though it has long-known vulnerabilities.  If that were to change (e.g., a simple crack program posted on the Internet), does Microsoft have a response procedure for such compromises? How will this procedure protect Microsoft's customers that may be operating at LoA-2 via an alternate means exception? Microsoft operates a vulnerability reporting mechanism via the Microsoft Security Response Center (MSRC).  This website documents the methodology of reporting, tracking and responding to any such vulnerability.
2. What encryption algorithms does Windows Secure Channel use? Based upon the user’s settings, the ALG_ID can be assigned to include settings such as 3DES, two-key 3DES @ 112bits, AES, AES @ 128bits, AES @ 192bits, AES @ 256bits, mutually-agreed algorithm via Diffie-Hellman, etc.  More details on algorithm choices @ http://msdn.microsoft.com/en-us/library/windows/desktop/aa375549(v=vs.85).aspx.Note that of these, only AES is considered strong and is approved. Also, if your definition of “encryption” for this question extends to asymmetric encryption/key exchange, SChannel also supports RSA, DH and ECDH. All of these are SDL-approved.
3. What's the impact of turning on the FIPS setting on all Domain Clients? What's the impact on Domain Controllers? [INVESTIGATING]
4. As NIST has observed, the initial key used by Kerberos is typically encrypted only by the user's password, which enables brute force attacks against the password.  Does AD have mitigation for this?  Does NTLMv2 also have this vulnerability?  [NEWLY ADDED QUESTION, INVESTIGATING]
   1. For reference to this issue see NIST 800-63-1, the following sections: 
      1. Section 3: The definition of Kerberos on page 10, calling out known vulnerabilities against offline attacks
      2. Section 8.2.2, Footnote #26, which defines criteria for "impractical" eavesdropping attacks
      3. Section 9.3.2.2, describing that "...the use of Kerberos keys derived from user generated passwords is not permitted at Level 2 or above."
1. What should one do to enable distinguishing between NTLM v1 and v2 in the logs? We would like to downgrade a user's assurance level if they access a service that employs NTLM v1.  To generalize, we're looking to detect the overall technical context of the authentication event: protocol, encryption algorithm, tunnel, client platform options, etc.  Is this information available?  [Escalated to Windows Security Product Team]
2. When BitLocker full disk encryption is used are disk sectors decrypted only as they are read? What is the recommended/supported BitLocker configuration for use with AD-DS?  Need to understand further details on the background of this question, but – as a prescriptive aid, sectors are decrypted in memory as they are accessed via the BitLocker layer, and encrypted as they are written back to disk.  There is no wholesale decryption in practice.  Reference for BL and AD: http://technet.microsoft.com/en-us/library/cc766015(v=ws.10).aspx
3. Does Syskey use NIST/FIPS Approved Algorithms for encryption? SYSKEY used a 128-bit RC4 key.  I have escalated this question to Windows Security to get an up-to-date answer regarding the underlying algorithms used.  [INVESTIGATING]
4. Are AD-DS password credentials replicated and stored by other Microsoft identity management components, such as ADFS or Azure services?  If so, what are those components? Is this question relative to using the DirSync routine to replicate on-premises data to the cloud?  If so, then DirSync does replicate newly-created identities and credentials for use by services such as Office 365.

We're more interested in whether credentials are stored by other Microsoft identity management components, than how they are stored, as that puts those other components into the scope of the institute's assurance assessment, if out of scope for this ADDS "cookbook."  For the purposes of the cookbook, we would probably just observe that other credential stores like Office 365, if used, would require further assessment by the institution.

1. Does Microsoft have a strategy for supporting compliance with the Federal Identity, Credential, and Access Management (FICAM) requirements at LoA-2, perhaps through Microsoft's partnership with the Kantara Initiative? If so, what is the time frame?  [INVESTIGATING]
2. Does Microsoft have a strategy for AD integration of non-Windows and old-Windows client platforms that will use NIST/FIPS approved algorithms for transport of passwords over a network? If so, what is the time frame?  [INVESTIGATING]  Note:  many questions about older editions of Windows must be escalated to the Support team, as the Engineering teams no longer work on these releases.
3. Is it possible to configure AD so that the NetUserChangePassword and NetUserSetInfo protocols require NIST approved algorithms for encrypting the session over which the password data is passed? [INVESTIGATING]
4. Reviewing "IAP Requirements and Gaps for Active Directory Domain Services" overall, are there other issues we should address? [INVESTIGATING]

 

 

Many of these topics cover different pieces of Microsoft technology – so there are a large number of teams that provide pieces of the answers.

 

This list represents the current status, and I hope to have additional details by Friday.

 

 

So – let us know about the call length and call-in details.

 

Thanks!

-Phil

 

 

 

 

 

 

>     From: Ann West [] 
>     Sent: Tuesday, July 23, 2013 9:52 AM
>     To: Phil West; John Krienke; Ken Klingenstein; Nate Klingenstein; Khalil Yazdi
>     Cc: David Turner; Adrian Wilson; Lamont Harrington; Chris Irwin; Chris Niehaus; Bill Hagen
>     Subject: Re: Internet2 A/D Call on Fri July 26th
>     
>     
>      
>     
>     Hi Phil,
>     
>     
>      
>     
>     
>     My apologies, but I thought the call on Friday was specifically about working through the issues around AD-DS being certified for the InCommon Assurance Program  (and Federal ICAM Program) and addressing the questions I sent earlier. Exploring broader priority list for identity and InCommon needs to be discussed for sure, but we would need to get together a different group to do that. Currently, I have the AD Assurance Community working group scheduled to meet with us.
>     
>     
>      
>     
>     
>     So thinking about your agenda further, do you see Friday's schedule breaking down to, say, discussing AD-DS certification first, seeing how far we get, and then using the remaining time on the bigger identity issues? The AD-DS issue is time critical for us: a number of schools have stopped working on Assurance certification until we can provide guidance on how AD-DS can be made to comply. I think the bigger picture can wait for our next call together.
>     
>     
>      
>     
>     
>     Thoughts?
>     
>     
>      
>     
>     
>     Thanks,
>     
>     
>     Ann
>     
>     
>      
>     
>     
>     -------
>     
>     
>     Ann West
>     
>     
>     Assistant Director,
>     
>     
>     InCommon Assurance and Community
>     
>     
>     Internet2 based at Michigan Tech
>     
>     
>      
>     
>     
>     office: +1.906.487.1726 
>     
>     
>      
>     
>     
>     From: Phil West <>
>     Date: Monday, July 22, 2013 12:59 PM
>     To: Ann West <>, John Krienke <>, Ken Klingenstein <>, Nate Klingenstein <>, Khalil Yazdi <>
>     Cc: David Turner <>, Adrian Wilson <>, Lamont Harrington <>, Chris Irwin <>, Chris Niehaus <>, Bill Hagen <>
>     Subject: Internet2 A/D Call on Fri July 26th
>     
>     
>      
>     
>     
>     Ann and Crew…
>     
>      
>     
>     I wanted to confirm that our team will be joining the call on this Friday (7/26) at Noon Eastern time (9am Pacific).
>     
>      
>     
>     I have invited David Turner, who is a Standards PM on the Azure AD Team to join us.
>     
>      
>     
>     For this initial call with your team, I would like to maximize David’s time by allowing him to explain our current direction on SAML interop testing and support.  In addition, with your team and other Internet2 members on the line – it would be great for David to garner feedback and discussion about your priority list for any extensions needed for the InCommon identity platform.  David is familiar with the www.incommonfederation.org website, but he is really looking for your input and guidance relative to a prioritization and rationale for items that might lie outside of the SAML standard.
>     
>      
>     
>     Is it possible to get some “pre-work” data from you regarding the priority list and rationale for the InCommon unique requirements?  Also, would it be possible to know who will be attending the call from the Internet2 side?
>     
>      
>     
>      
>     
>     With regards to the list of questions from the AD and O365 fronts, I am working those in parallel, so I will be able to address some of those (we can discuss some and I can forward details via email on others).  I am getting help from the Windows Active Directory team, as well as Windows Security.
>     
>      
>     
>      
>     
>     I did want to take advantage of the “LIVE” time with David to really dig into the strategic SAML topic and understand the history and roadmap from the InCommon perspective.
>     
>      
>     
>     Also – please send us the call logistics (phone numbers, codes, etc.) for the call.
>     
>      
>     
>     THANKS!!
>     
>     -Phil
>     
>      
>     
>      
>     
>      
>     
>      
>     
>     phil west : : director of solutions development : : office of civic innovation : :  u.s. public sector : :  microsoft : :  425.538.1179
>

 

                 

 

This communication may contain privileged and confidential information. Use, disclosure, or retention of this information is prohibited if you are not the intended recipient. If you have received this message in error, please delete the message from your system.  Thank you.