On Thursday, Feb 20, 2003, at 00:15 US/Pacific, John Rudd wrote:
(nothing Ken said contradicts what I have asserted)
I want to clarify this one claim of mine. Nothing I had asserted up to that point in the message was a contradiction to what Ken was saying. What I said right after that does disagree with some things Ken's faq says. Ken's faq, in other places, does say that the KDC stores passwords, but I believe Ken is saying so because he's not being rigorously detailed (it's just a faq, not a formal spec, after all). Ken's assertion of "KDC stores passwords" contradicts what I was directly told by several of the kerberos maintainers (I used to work with several of them at Cygnus).

(the following is my cloudy memory from when they described it all to me; the KDC definitely doesn't store anything unencrypted -- the thing I'm cloudy on is what encrypted datum it does store, an encrypted password or an encrypted ticket)

When you create the kerberos database, you have to create the master key, which is used to encrypt the database. Then you create your admin instances.

When you create a user (principle), you do so in a kadmin session. That session is being encrypted using the session/service ticket (tgs) you got via your admin instance. Your kadmin program creates a ticket granting ticket (tgt) for the principle and encrypts it with the password you give. It then sends that encrypted tgt to the KDC for storage (and that transfer is encrypted with your kadmin tgs). Then your kadmin program throws away its local copy of that tgt.

When the user runs kinit, it requests a copy of the encrypted tgt for their principle. If the user can supply the right pass phrase for that encrypted tgt, then they have an unencrypted tgt (except that it has time time encoding to it, as well, insuring that it expires after some number of hours). The tgt is now your shared secret with the KDC, until it expires. The user can then use the tgt to request tgs's for other services (and those tgs will arrive encrypted with the tgt).


Host tickets (which every application server needs) are created the same way, except that kadmin doesn't throw them away after it sends them off to the KDC. It stores them in the host's keytab (usually, for kerberos 5, /etc/krb5.keytab, which should only be readable by root). These host tickets are then used between the KDC and host as part of the process for setting up tgs's.

(I'm more vague on this latter part, I think it works in that when a service request happens, the KDC creates a tgs and sends it to the application server and the user's client application. The tgs copy sent to the application server is encrypted using the host's ticket and the copy sent to the user's client is encrypted with its copy of the user's encrypted tgt ... so if the application server is authentic and the client is authentic, then they'll both be able to decrypt the tgs into something THEY can use as a shared secret.)





-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users


Reply via email to