Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Brian,

 

If I understand you correctly, someone could still logon with a user-selected password.  The Kerberos protocol is only allowed at LOA1 with user password authentication.  At LOA2 and above, Kerberos is allowed as long as it is not user-selected password based.  I assume that with a hardware token (i.e. the “multi-factor”) that the Kerberos key is generated from the token itself.  I’m not really sure how you get your Kerberos Ticket from the hardware token, but it seems to involve public key encryption with the smart card.  There also seems to be a HW-AUTHENT flag indicating hardware was used for initial authentication. 

 

From SP800-63-1:

“All assertion protocols used at Level 2 and above require the use of Approved cryptographic techniques. As such, the use of Kerberos keys derived from user generated passwords is not permitted at Level 2 or above.”

 

AND

 

[LEVEL3] Kerberos tickets are acceptable for use as assertions at Level 3 as long as:

•                      All Verifiers (Kerberos Authentication Servers and Ticket Granting Servers) are under the control of a single management authority that ensures the correct operation of the Kerberos protocol;

•                      The Subscriber authenticates to the Verifier using a Level 3 token;

•                      All Level 3 requirements unrelated to non-repudiation are satisfied.

 

[LEVEL4] …based on the high degree of vetting conducted on the Kerberos protocol and its wide deployment, Kerberos tickets are acceptable for use as assertions at Level 4 as long as:

•                      All Verifiers (Kerberos Authentication Servers and Ticket Granting Servers) are under the control of a single management authority that ensures the correct operation of the Kerberos protocol;

•                      The Subscriber authenticates to the Verifier using a Level 4 token;

•                      All Level 4 requirements unrelated to non-repudiation are satisfied.

 

All Level 1-3 requirements for the protection of assertion data remain in force at Level 4.

 

From: [mailto:] On Behalf Of Brian Arkills
Sent: Thursday, April 25, 2013 1:53 PM
To:
Subject: RE: [AD-Assurance] Applying FISMA to 800-63

 

From what I've seen of the Microsoft 2 factor AD Support, you can't actually turn off password (single factor) based authentication for a given user account. You can enable 2 factor. You can require that 2 factor be used for all interactive logons, but that isn't the same as requiring it for *all* logons.

 

Maybe there's an angle here that I'm missing, but every time I hear someone suggest that you could use 2 factor authN to get the IAP requirements specific to passwords, I wonder if folks realize that passwords are still going to be in AD, and they will still be a valid way to get a logon token.

 

There are ways to mitigate some of that, and I've even initiated a thought exercise among a few folks here at the UW around how we might get creative in trying to prevent password based AD authentication on an account with 2 factor authN enabled. But I don't see anyone talking about that, and frankly, the results of our thought exercise suggested that it might be costly and prohibitive to mitigate. Because of this, I've been thinking that one ask we'd have to Microsoft is that they add a user control that requires 2 factor authN on all logons for that user.

 

Finally, I'd call attention to something relatively new in the Microsoft authentication technology space called virtual smart cards: http://www.microsoft.com/en-us/download/details.aspx?id=29076. Requires Win8 clients and leverages a computer TPM to store the virtual smart card. Definitely lowers the bar in terms of the cost of deploying 2 factor, but at the cost of using Win8.