Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

I thought we were pretty clear here. If the secret that is transmitted is one 
that can be used to authenticate to the IdP, then it's in scope; otherwise 
it's not. 

I don't disagree with your statements here, Jeff, I just think we were clear 
about our meaning. I'm not opposed to restating it to make it more 
understandable, I'm just concerned that they may actually be disagreeing with 
the assertion. (I guess we'll get to talk with them about that tomorrow.)

I was going to try to say more in response to the AAC comments, but I didn't 
have much time yesterday or today. I'll be on the call tomorrow, so can 
hopefully get some notes together before then.

--- Eric

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Capehart,Jeffrey D
Sent: Wednesday, October 23, 2013 2:06 PM
To: 

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

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.