Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

Yes, I think we have tomorrow's agenda.  Talk to you all then.

David

On Thu, 2013-10-24 at 23:08 +0000, Ron Thielen wrote:
>     What you said Eric.  I thought we were clear as well.  However, the call with the AAC is a week from tomorrow.  I presume we'll use the time tomorrow to prepare for 11-1.
>     
>     Ron
>     
>     -----Original Message-----
>     From:  [] On Behalf Of Eric Goodman
>     Sent: Thursday, October 24, 2013 6:04 PM
>     To: 
>     Subject: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections
>     
>     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:  [] 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.