Assurance

["Roy, Nicholas S" <>]

See table 5 on page 40.  You’ll notice that at level 1, challenge-response password is allowed, but at level 2, “zero knowledge” password is required.

 

Nick

 

From: [mailto:] On Behalf Of Russell J Yount
Sent: Friday, November 18, 2011 12:53 PM
To:
Cc: Russell J Yount
Subject: [Assurance] RE: InCommon Silver/AD cookbook updated

 

I think that is fine..

 

Kerberos has really been designed to eliminate the possibility of disclosing password information on the wire. It does however permit one to see who is authenticating with whom.

 

In what section do see NIST SP 800-63 disallow challenge handshake for level 2?

 

-Russ

 

From: [mailto:] On Behalf Of Roy, Nicholas S
Sent: Friday, November 18, 2011 1:33 PM
To:
Subject: [Assurance] RE: InCommon Silver/AD cookbook updated

 

OK- thanks, Russell.  It’s just that parts of this exchange look like a challenge handshake authentication protocol, which is explicitly dis-allowed in NIST SP 800-63 at level 2, so that’s where my concern comes from.

 

I’ve updated the cookbook with this information:

 

“Basic LDAP binds using SSPI for security that require Kerberos V are acceptable, because it is not possible to gain useful knowledge of the subject's secret from the messages exchanged during a Kerberos V authentication event.”

 

Is that acceptable?

 

Thanks,

 

Nick

 

From: [] On Behalf Of Russell J Yount
Sent: Friday, November 18, 2011 11:50 AM
To:
Cc: Russell J Yount
Subject: [Assurance] RE: InCommon Silver/AD cookbook updated

 

>The second item of note says that Kerberos is acceptable for preventing eavesdropper attacks, but the language of the IAP >requires that nothing that the attacker did not already know about the password can be gained by analyzing the messages >passing between subject and verifier.  With Kerberos, this isn’t the case, to the best of my knowledge.

 

 

Kerberos V5 does not pass the password in messages.

 

The password is converted to a key via a hash function using a salt.

 

The key derived from the password is  not pass via messages either. (Except in the case of password changes of course.)

 

·         The key is used to decrypt a message send from the KDC to the client to obtain a ticket granting ticket. (login)

·         In some cases of pre-authentication the key as an encryption key also in the initial exchange of messages.

 

In either case knowledge about the password is not disclosed on the wire with Kerberos V5.

 

-Russ

 

 

 

From: [] On Behalf Of Roy, Nicholas S
Sent: Friday, November 18, 2011 12:06 PM
To:
Subject: [Assurance] InCommon Silver/AD cookbook updated

 

Hello, InCommon Assurance folk.  If you are interested in Active Directory and InCommon Silver, please read on.  If not, please disregard this message.

 

I’ve made some updates to the Silver/AD cookbook:

 

https://spaces.internet2.edu/display/cicincsilver/InCommon+Silver+with+Active+Directory+Cookbook+-+DRAFT

 

Some of the less minor updates that I did were to insert notes in places where we are missing things, in some cases these might have gotten changed or deleted during edits that removed references to locations in the text that previously existed.  These are mostly in section 4.2.5.2’s Management Assertions subsection.  They are bold, italicized, and begin with “NOTE”

 

The first item of note refers to section 4.2.3.2 and 4.2.3.3 which are sections that cover password entropy, so I’m not sure how a management assertion about an eavesdropper attack would be relevant.

 

The second item of note says that Kerberos is acceptable for preventing eavesdropper attacks, but the language of the IAP requires that nothing that the attacker did not already know about the password can be gained by analyzing the messages passing between subject and verifier.  With Kerberos, this isn’t the case, to the best of my knowledge.  The text that existed in this section before my edit contained a reference to a paragraph that no longer seems to exist in the assertions (“Basic LDAP binds using SSPI for security that require Kerberos are acceptable because they use Kerberos for authentication, covered under the first paragraph of this assertion.”) – If you edited these assertions and recall where this paragraph went, or know of a reason why Kerberos is acceptable for this section of the IAP, please edit the wiki or let me know and I can add it.

 

The third note is in Appendix B and is a place holder for Alex or Warren or anyone else who has experience with signed LDAP binds and OS X to put their information on how well or otherwise this works.  If you have any experience with OS X or other clients and requiring signed binds in AD, please let me know and I can help to get that information added to the appendix.

 

Thanks,

 

Nick

 

------------

Nicholas Roy – Identity Architect

The University of Iowa / ITS - Administrative Information Systems / Directory and Authentication