Meeting the InCommon Assurance profile criteria using Active Directory

[Ann West <>]

Hi Jeff,

Yes we have having a call to finalize the cookbook  in light of the information from the AAC and look at next steps with community review. 

Ann

From: <Capehart>, Jeffrey D <>
Reply-To: "" <>
Date: Friday, August 30, 2013 11:26 AM
To: "" <>
Subject: [AD-Assurance] RE: AAC Response: Clarification on Authentication Secrets

Since everything seemed good with the AAC response and clarification, is there still going to be a conference call today?

 

For your consideration, I was wondering if this really is the answer we wanted.   Is it clear enough to disambiguate?  Read carefully these test cases.  See if you can come up with any test cases that may fail.

 

“Any other secrets, keys, etc that the Verifier verifies that are not used by Subjects to authenticate to the IdP are not in scope for 4.2.3.6.x.”

 

Case #1:

Subject authenticates to the IdP (InCommon IdP which is Shibboleth, right?) over HTTPS (SSL/TLS) using an approved algorithm (cipher) with their ID “Subject1” and Secret “MySecret”. 

 

Behind the scenes somewhere, the IdP may use LDAPS to talk to the Verifier (Active Directory Domain Services) which we’ll assume uses Kerberos and GSSAPI protocol with an approved algorithm over START TLS.

 

This would be in scope and meet Silver.  Case #1 part 1 meets 4.2.3.6.2 and 4.2.5 as well.

 

Case #2:

 

Subject logs on to their networked Windows 7 workstation connected to the Active Directory Domain Services using “Subject1” and their Secret “MySecret”.  This is a non-IdP application and the authentication secret sent to the verifier might be the NT-HASH using NTLMv2 or more likely a Kerberos authentication protocol with a ticket granting ticket, etc.  The Secret sent over the network for “MySecret” is then something like “79054025255fb1a26e4bc422aef54eb4” which would be a hash value which could not be used by the Subject to authenticate to the IdP.

 

Per the interpretation, this would be “out of scope” even though an approved algorithm/protected channel may not be in use. 

 

The key factor in the interpretation is that if the Authentication Secret is not, (within the context of these test cases), the literal string “MySecret”, then it isn’t an Authentication Secret in scope.  That would seem to be not much different than the Bronze requirement 4.2.3.5.2 “Plaintext passwords or Secrets shall not be transmitted across a network.” applied in a general sense to all network authentications.

 

---

For reference:

 

Authentication Secret / 4.2.3.6:

4.2.3.6.2. Whenever Authentication Secrets used by the IdP (or the IdP’s Verifier) are sent

between services for verification purposes (for example, an IdP to a Verifier, or

some non-IdP application to a Verifier), Protected Channels should be used, but

Protected Channels without client authentication may be used.

 

Definiton of IdP:

Just for clarification, the IdP is different from the IdP Operator.  I think the InCommon IdP (software, Shibboleth,) is what is being referred to as the IdP.  Don’t get caught up thinking that the IdP is the Institution operating as the identity provider, because that is the IdPO.  If the IdP is strictly limited to the software/program/service that is running, then that opens up a better interpretation as to what a “non-IdP application” refers to.

 

The definition in the Framework says that the IdP is “The IdMS system component that issues Assertions.”

 

This seems to be the key thinking in the Framework:

“An authentication event occurs when a Subject offers his or her Credential to an IdP’s Verifier. An IAP might define requirements to ensure this transaction is secure against interception or exposure of any Authentication Secret to any unauthorized party.”

 

--Jeff C.

 

From: [] On Behalf Of Ann West
Sent: Tuesday, August 27, 2013 12:47 PM
To:
Cc:
Subject: [AD-Assurance] AAC Response: Clarification on Authentication Secrets

 

Dear Colleagues,

 

The AAC agrees with the AD group that "Authentication Secrets" in the IAP refers to secrets shared by a Subject and the Verifier that are used in Subject's authentication to the IdP. Any other secrets, keys, etc that the Verifier verifies that are not used by Subjects to authenticate to the IdP are not in scope for 4.2.3.6.x. The set of Authentication Secrets in scope for the IAP is further restricted to just those belonging to Subjects that are in scope for the IAP.

4.2.5 addresses the integrity of authentication of a Subject to the IdP by requiring the existence of certain types of controls that reduce the chance that someone might impersonate a Subject when authenticating to the IdP. 

 

Best regards,

Ann on behalf of the AAC

 

----

Ann West

Assistant Director,

InCommon Assurance and Community

Internet2 based at Michigan Tech

 

office: +1.906.487.1726