Skip to Content.
Sympa Menu

ad-assurance - Re: [AD-Assurance] FW: Internet2 A/D Call on Fri July 26th

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

Re: [AD-Assurance] FW: Internet2 A/D Call on Fri July 26th

Chronological Thread 
  • From: Eric Goodman <>
  • To: "<>" <>
  • Subject: Re: [AD-Assurance] FW: Internet2 A/D Call on Fri July 26th
  • Date: Thu, 25 Jul 2013 15:10:16 +0000
  • Accept-language: en-US

Still on vacation but saw this thread an thought I'd throw in a comment or two. 

I suspect Brian's question is more about getting an indication of how real Microsoft's advice is in this case. If RC4 is recently on the list, then maybe there will be action. If it's been on a do not use list for years, then the advice is really theoretical. I.e., the question is more of a litmus test of the practicality of the comment than anything else. 

I agree that the preview answers imply "use only current OS releases", which is disappointing but something we are not too surprise to hear. 

In any case, sounds like the questions, follow ups and clarifications are well in hand and I look forward to seeing the summary when I get back Monday. 

Good luck!

--- Eric

Eric Goodman

On Jul 24, 2013, at 12:19 PM, "Capehart,Jeffrey D" <> wrote:

Does it matter how long RC4 has been in if the problem is that it is still supported in the current products… regardless if it has an approved exception to the SDL?


Maybe we are expecting that Microsoft would have some knowledge of the impact of removing available ciphers, turning NTLM off, switching on FIPS mode, and what the downstream effects would be and what needs to be done to minimize impact while keeping operations supported.


Who wants to turn those features off/on and just “see what happens”?  Test environment??  How about the whole campus?  While there now exist some printer/scanner/multi-function machines that can speak Kerberos, and some older ones can speak NTLMv2, and Mac OSX Lion can do NTLMv2, there are a myriad of other devices out there and IT gets to be the one saying that hardware you bought that worked OK last week is now no good and you need to buy a newer/better more expensive unit.


Jeff C.

From: [] On Behalf Of Rank, Mark
Sent: Wednesday, July 24, 2013 11:55 AM
Subject: RE: [AD-Assurance] FW: Internet2 A/D Call on Fri July 26th




Just want to give a big +1 to your response. I don't know that I can add much productive to the discussion and may not even join the call on the 26th to "protect" the discussion ;)






Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)



From: [] on behalf of Brian Arkills []
Sent: Wednesday, July 24, 2013 8:45 AM
Subject: RE: [AD-Assurance] FW: Internet2 A/D Call on Fri July 26th

I think the most important question to focus on is 1a, and perhaps a follow-up we didn't state which is:

If you don't consider it suitable, then what are your customers supposed to do to mitigate this while waiting for Microsoft to replace it in the product?


I was a little disappointed with the response on this question because it seems to focus on an ideal world, instead of the real world. My immediate internal response was to wonder just how long RC4 had been in this state in their Crypto Standard Procedures, and for how many releases that guidance has gotten an exception. I recognize that response as not particularly constructive, so don't want to raise it, but do want to help Microsoft be focused on reality not some hypothetical future. It's in the product today, and what are we supposed to do about it? :)



From: [] On Behalf Of Capehart,Jeffrey D
Sent: Tuesday, July 23, 2013 12:52 PM
Subject: RE: [AD-Assurance] FW: Internet2 A/D Call on Fri July 26th




Thanks for sending Microsoft the questions and concerns in advance, and sharing their responses.  If anyone else hasn’t seen them yet, scroll down farther because there is a lot of information contained within the email.


My observations…


On Q1a, the answer seems to imply “don’t use RC4 HMAC”.  Well, there must be some reason why people are still using it, for compatibility, integration, or maybe just because it has always been there.  Is it only in the Kerberos?  Is it related or tied to NTLM?  Is it needed for compatibility with legacy non-Microsoft systems?  Plus, RC4 HMAC is already in Windows Server 2008 and that is the target we’re considering.


On Q1b, regarding if RC4 were to be cracked, the response was to report the vulnerability to the MSRC.  I don’t think we’re likely to be the ones reporting this to Microsoft.  Even if it gets reported and added to something like [Mitre CWE-327: Use of a Broken or Risky Cryptographic Algorithm], the detection method is manual so you wouldn’t know unless you looked.  I’m not sure what we’re asking Microsoft to do here because in Q1a they basically have said that they have moved past RC4 and banned its use in the SDL (Security Development Lifecycle).  If an end user has the cipher configured to use, what more can Microsoft do?  Maybe they would send out a notice to say to remove it as a supported cipher.  The complete list of “banned” ciphers is MD4, MD5, RC4, DES, and SHA1.


On Q3, the Bitlocker question, Microsoft’s response was “Need to understand further details on the background of this question“.  We should make it clear that we are talking about ‘Bitlockering’ the Domain Controller with AD DS to meet the specifics of the requirement to only unencrypt passwords when needed.  It might be worth mentioning that we consider the password hashes to be the passwords since per the alternative option, the passwords are not stored using a salted hash with an approved algorithm.

There are many questions they are still investigating, and a common theme seems to be: “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.

Jeff C.


From: [] On Behalf Of David Walker
Sent: Tuesday, July 23, 2013 11:59 AM
Subject: Re: [AD-Assurance] FW: Internet2 A/D Call on Fri July 26th



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.


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. 








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  – with commentary and intended discussion points:


  1. Protected Channels - IAP - 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 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.
    1. 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 @ 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.
    1. What's the impact of turning on the FIPS setting on all Domain Clients? What's the impact on Domain Controllers? [INVESTIGATING]
    1. 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
        1. Section 8.2.2, Footnote #26, which defines criteria for "impractical" eavesdropping attacks
        1. Section, 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]
  1. 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:
  1. 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]
  1. 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]
  1. 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.
  1. 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]
  1. 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.










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.








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 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.








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.




JPEG image

PNG image

Archive powered by MHonArc 2.6.16.

Top of Page