Talk:Kerberos
I just changed the definition to reflect what I think are the key points about this protocol. I'm not an expert in Kerberos, but it looks to me like it has no advantage over a public-key system, and a few serious disadvantages. I'm thinking of adding to the article something like the following paragraph, but I would like to get some feedback first.
- Kerberos has largely been replaced by public-key systems. Both have the objective of providing a secret session key to allow encrypted communications between two clients. Both need a central server, one to distribute public keys for each client, the other to hold secret keys for each client. The server with secret keys for all clients must be very secure, much more than is required for the server holding only the public keys of all clients.
See http://en.wikipedia.org/wiki/Kerberos_(protocol)#Drawbacks for more on the disadvantages of Kerberos.
"Authentication Protocols", section 8.3 in Peterson & Davie, Computer Networks, 4th ed. (Morgan Kaufmann, 2007).
"Authentication Protocols", section 8.7 in Tanenbaum, Computer Networks, 4th ed. (Prentice Hall, 2003).
"Authentication and Authorization Controls", R. Bragg, chapter 6 in Network Security: The Complete Reference (McGraw-Hill, 2004).
--David MacQuigg 17:12, 25 November 2009 (UTC)
- I think the suggested text above is wrong. For one thing, newer versions of Kerberos do use public key techniques, see for example RFC 4556. For another, it has not "largely been replaced"; it is still extremely widely deployed. As far as I know it is still the basic mechanism used in Windows network authentication.
- That said, you are raising valid points. Kerberos has limitations and there are alternatives; both need to be covered. Sandy Harris 10:07, 26 November 2009 (UTC)
- I read the introduction to RFC-4556, and it is not clear to me why anyone would want to add a public-key step to an already too-complex protocol. The goal is to provide a secure session key to two parties using an insecure network. That can be done directly, using public keys only, without requiring either party to reveal its secret key. PGP does it this way.
- "Largely replaced" may be the wrong choice of words. Microsoft alone would qualify it as "widely deployed". I see that it is not included in Thunderbird (the most popular email client in the open-source community) or in Apple's mail client. Are there any major deployments outside of the Microsoft world?
- Maybe we should just say Kerberos has no fundamental advantage over a public-key system, and a few serious disadvantages (listed in the Wikipedia article). This is the kind of fundamental summary information we need in a CZ article, information that is *not* in the textbooks or RFCs. --David MacQuigg 12:49, 26 November 2009 (UTC)
- Kerberos has very different functions than PGP. Including PGP support in a mail client is useful, arguably essential; including Kerberos is not.
- However, what if you want a network login — I can log in at any end-user machine (X terminal, desktop PC, ...) with the same ID and get the same access to server resources — printers, shared files, ...? PGP cannot give you that; Kerberos can. Its goal is not just to provide secure session keys but to provide mechanisms for managing identities and privileges. Given that goal, you must have some sort of central server to manage IDs so they are visible across the network and to manage privileges — keep the engineers out of the personnel data, allow teachers access to some things students cannot see, etc.
- It is widely used. Here are links for Sun, Apple, HP and IBM. Sandy Harris 13:48, 26 November 2009 (UTC)
- I wouldn't compare PGP to Kerberos. We've got to distinguish products from protocols. PGP is a product that uses a public key protocol to establish a session key, the way other products use Kerberos to establish a session key. The other features provided by these products (email encryption, identity management, text compression, digital signatures, etc.) are independent of the protocol used to establish a session key. I would say the purpose of the Kerberos protocol is simply to establish a session key, and comparisons with other protocols should ignore whatever features are "bundled" in products that use these protocols.
- Perhaps I'm missing something essential in Kerberos, but this is all I get from reading the introductions to RFC-4120 and RFC-4556. The two best explanations I have found are in Peterson & Davie and in Tanenbaum. Niether text, unfortunately, does a simple comparison of Kerberos with a public-key protocol. We are still left with the fundamental question - Why would one use Kerberos instead of a simpler and more secure public-key protocol?
- What I would like to see in all these articles on authentication protocols is a simple summary of what the protocol does, how it works, and what are its fundamental advantages and limitations. We might also include some ancillary information on popularity of the protocols (what companies and major products use them, etc.) and also some history, if there is something interesting to say. --David MacQuigg 19:38, 28 November 2009 (UTC)
Kerberos separates authentication and credentialing
If one looks at its actual functionality, Kerberos does more than many pure authentication protocols. Whether or not the additional functionality is needed, however, is a separate matter. Separate credentialing probably isn't needed in email.
Separate credentialing, however, makes sense in such things as multilevel security, especially under Red Book/Rainbow Book criteria for things such as mandatory access control. It's especially relevant when you have both hierarchical and nonhierarchical access criteria; see compartmented control system for military examples: just because you have TOP SECRET clearance (perhaps a primitive granted by authentication), and access to the SAP-PSALM/SI-DINAR compartment (real example of operational planning for the Cuban Missile Crisis combined with access to the highest then-current category of signals intelligence) doesn't give you access to RD-CNWDI-Sigma 1 (not used at the time, but would have been the access control for the internal design of thermonuclear weapons that might have been used in PSALM). Howard C. Berkowitz 15:18, 16 December 2009 (UTC)