Assurance

[Russell J Yount <>]

>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: [mailto:] 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