Excerpts from Firewalls: 28-Oct-93 Re: System Security "Perry E.
> (Tokens are DES
> > encrypted).
> No they aren't. You don't understand how Kerberos works. The ticket is
> SENT to you encrypted -- your password is used to DECRYPT it. Were it
> not for that, you would have to type in your password to decrypt the
> ticket every time you wanted to perform the smallest operation, or the
> key to decrypt it would have to be stored on the machine (which would
> effectively mean that there was no point in storing the ticket
> encrypted in the first place).
I understand how kerberos works. Do you understand how AFS works?
A "ticket" is proof of mutual authentication between the client and
server. It is encrypted by the ticket granter with the server
encryption key -- the client cannot decrypt the ticket. A "session key"
is also encrypted by the server, using a second encryption key. This is
a shared secret between the client and server, and involves mutual
authentication. The ticket, the session key, a time stamp, and other
information are all sealed in a package known as a "token". The token
is encrypted on the server by a third encryption key, and sent back to
the client. The token encryption key is derived from the user's
password, among other things.
> Please learn how Kerberos works before embarassing yourself with more
> pronouncements. You are confusing the way that AFS deals with
> kerbersos with the way that kerberos itself works. A remote entity
> cannot know which process is using a ticket -- it can only know that
> the remote entity has the ticket and thus appears to be a legitimate
> user of services. Once you have the ticket, you can masquerade at
AFS authentication servers don't understand kerberos tickets -- only AFS
PS: You should learn how spell words like "embarrassing", if you're
tempted to use that kind of language in a public forum.