Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections


Chronological Thread 
  • From: "Capehart,Jeffrey D" <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections
  • Date: Wed, 23 Oct 2013 21:05:54 +0000
  • Accept-language: en-US

Regarding:
"Back to defining what's in scope, the definition in this cookbook section
appears to be: if it's used to authenticate to the IdP, or if it's used to
authenticate to a change my password app. I think the definition of in-scope
authentication secrets is not related solely to specific technologies. They
are in scope if they meet a whole variety of criteria that underpin the
design of the overall Silver implementation."

OK -- Perhaps we can be clearer about what we specifically want. If the
actual password is sent over the network, then it is in scope. The IDP uses
a protected channel and meets criteria. All web-based apps would need to use
a protected channel too if they ask for username and password.

If some other non-web based application prompts for the user's AD DS
username/password, then we think it should not be considered in scope if it
doesn't send the password itself over the network, regardless of the channel.
For example, if an application takes the user-input password and converts it
in-memory such as by hashing the password like NT Hash, using NTLM
authentication or a Kerberos ticket, and then sends it over the network in
that modified form by using AD as the verifier, then those methods do not
send the actual password itself over the network. We think those
authentications could be considered out-of-scope authentication methods,
specific to 4.2.3.6.2. This is where the disagreement is.

I think the reason it gets complicated is because Bronze already says no
plain text transmission over the network. Silver only allows approved
algorithm/protected channel methods. Doing something more than plaintext but
less than "approved algorithm/protected channel" may not cut it.

We seem to think the risk is higher dealing with the plain text password, and
lower when dealing with the hash or a ticket.

It may just be easier if the AAC could grant an exception for AD DS under the
conditions that match our requirements that you can't configure your IDP and
AD DS for single sign-on such that a user could authenticate to the IDP using
an existing Kerberos ticket or an NTLM hash. The requirement would be for
the IDP to get the credentials (username/password) directly from the user
when the IDP is operating in only username and passwords for Silver. That
could be the basis for an alternative means proposal and may be the route to
go if trying to set up interpretations to match our desired outcome is not
working.

The IDP would not accept the types of credentials that could be intercepted
or replayed from AD DS, even though the IDP might use AD DS behind the scenes
on the server side, such as with LDAPS, because it would need the user's
username and password to authenticate that user. This would be the
compensating control needed for an alternative means proposal.

Jeff C.



Archive powered by MHonArc 2.6.16.

Top of Page