Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

I agree with everyone's comments.  It's a good response.  The only thing I would say is to emphasize Jeff's point of the Cookbook being focused on compliance.  I think we agree with much of what Joe says; it's just not needed for compliance with Silver.

David

On Mon, 2013-10-07 at 17:42 +0000, Capehart,Jeffrey D wrote:
> Thank you for putting the response together, Brian.  Nice work!
>
> In general, I am thinking maybe we could say there are certain configurations and choices that an IDPO could make to provide a higher level of security than the basic/minimum recommendations in the cookbook.  (For example, turn off NTLM and use Kerberos only, go to DFL 2012, eliminate Windows XP workstations, or automate monitor & mitigate for 24 hour processing instead of 72.  However, the recommendations are made for basic compliance not best security config.)
>
> A couple comments on BitLocker & NTLMv2:
>
> >BitLocker decrypts data on a sector by sector basis *when* that data is needed. It does *NOT* decrypt the entire disk at boot time. This is well-documented >and we took the extra step of verifying this with Microsoft.
>
> The "decrypt the entire disk at boot time" is where I think some people get hung-up.  Yes, a key is read in at boot time to be able to decrypt the data on-the-fly as it is read from disk, but it is not used to decrypt and then store the data unencrypted back out on the disk (i.e. remove encryption from the disk).  Therefore, BitLocker is in compliance, regardless of the fact that once booted up, the disk appears to be "decrypted" from the perspective of the logged-on user or server operating system.  If the system had its plug pulled, the data on the disk would still be encrypted.  Maybe if we explain this 5 different ways, one of them will eventually work for everyone.
>
> >Therefore, NTLMv2 use is not in violation of the Silver IAP (assuming NTLM cannot be used to authenticate to the IdP).
> >If AD-DS is the verifier for your IdP, then your concerns are warranted.
>
> As Eric also mentioned, the AD/verifier/IdP/IDPO relations can be confusing if not explicitly pointed out.  While an IDPO can operate an AD DS, which can be used as a verifier for the IdP, the verification needs to be performed over LDAPS to AD DS with username/password collected from the IdP over a protected channel.  In other words, the IDPO can use AD DS (Kerberos Tickets, NTLMv1, v2) as long as the IDP (Shibboleth) does not use those same authentication methods when authenticating the Subject.  (This may need some work to make it more clear and distinguish between IdP/IDPO and what is OK.)
>
> -Jeff C.