ad-assurance - [AD-Assurance] RE: AAC Response: Clarification on Authentication Secrets
Subject: Meeting the InCommon Assurance profile criteria using Active Directory
List archive
- From: "Capehart,Jeffrey D" <>
- To: "" <>
- Subject: [AD-Assurance] RE: AAC Response: Clarification on Authentication Secrets
- Date: Fri, 30 Aug 2013 15:26:24 +0000
- Accept-language: en-US
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: [mailto:]
On Behalf Of Ann West 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. 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 |
- [AD-Assurance] AAC Response: Clarification on Authentication Secrets, Ann West, 08/27/2013
- [AD-Assurance] RE: AAC Response: Clarification on Authentication Secrets, Capehart,Jeffrey D, 08/30/2013
- Re: [AD-Assurance] RE: AAC Response: Clarification on Authentication Secrets, Ann West, 08/30/2013
- [AD-Assurance] RE: AAC Response: Clarification on Authentication Secrets, Capehart,Jeffrey D, 08/30/2013
Archive powered by MHonArc 2.6.16.