These notes are derived from Wikipedia entries, and as such are licenced under the GNU Free Documentation License, see http://en.wikipedia.org/wiki/Wikipedia:Copyrights for details.
So far we have looked at how passwords are managed on a single stand-alone system. Clearly it's more efficient and effective for users to be able to login to everything at an organisation using the same userid and password.
The problem Kerberos solves is the multiplication of effort, insecurity and inefficiency within a large organisation resulting from the decentralised authentication of:
This isn't an easy problem to solve. It had to be solved because all sorts of interesting and devastating attacks became possible once large networks started being developed, for example:
Universities were the first place where a lot of these issues were actively explored. Corporate employees are much less likely to test or want to study the security of a large network involving many machines than students and researchers studying technical disciplines.
This and other sections on Kerberos were copied from http://en.wikipedia.org/wiki/Security_protocol_notation on 30 Oct 2006 with permission.
The Massachusetts Institute of Technology (MIT) developed Kerberos to protect network services provided by Project Athena. The protocol was named after the Greek mythological character Kerberos (or Cerberus), known in Greek mythology as being the monstrous three-headed guard dog of Hades. Several versions of the protocol exist; versions 1-3 occurred only internally at MIT.
Steve Miller and Clifford Neuman, the primary designers of Kerberos version 4, published that version in the late 1980s, although they had targeted it primarily for Project Athena.
Version 5, designed by John Kohl and Clifford Neuman, appeared as RFC 1510 in 1993 (made obsolete by RFC 4120 in 2005), with the intention of overcoming the limitations and security problems of version 4.
Windows 2000, Windows XP and Windows Server 2003 use a variant of Kerberos as their default authentication method. Some Microsoft additions to the Kerberos suite of protocols are documented in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". Apple's Mac OS X also uses Kerberos in both its client and server versions.
(Note by RK: While standard Kerberos is an open-source product, the Windows version of Kerberos has been reverse engineered so that the open-source product, SAMBA version 4 will implement full server and client functionality compatible with the Windows Domain Controller Kerberos implementation.)
This section were copied from http://en.wikipedia.org/wiki/Security_protocol_notation on 30 Oct 2006 with permission.
Security (engineering) protocol notation is a way of expressing a protocol of correspondence between entities of a dynamic system, such as a computer network. In the context of a formal model, it allows reasoning about the properties of such a system.
The standard notation consists of a set of individuals (traditionally named Alice, Bob, Charlie and so on) who wish to communicate. They may have access to a server S, shared keys K, timestamps T, and can generate nonces N for authentication purposes.
A simple example might be the following:
A->B:{X1}KAB
This states that Alice intends a message for Bob consisting of a plain text X1 encrypted under shared key KAB.
Another example might be the following:
B->A:{NB}PK(A)
This states that Bob intends a message for Alice consisting of a Nonce encrypted using public key of Alice.
A key with two subscripts is a symmetric key shared by the two corresponding individuals. A key with one subscript is the public key of the corresponding individual. A private key is represented as the inverse of the public key.
The notation specifies only the operation and not its semantics - for instance, public key encryption and signature are represented identically.
We can express more complicated protocols in such a fashion, see Kerberos as an example.
Several models exist to reason about security protocols in this way, one of which is BAN logic.
This section were copied from http://en.wikipedia.org/wiki/Security_protocol_notation on 30 Oct 2006 with permission.
BAN logic, and logics in the same family, are decidable. There exists an algorithm taking BAN hypotheses and a purported conclusion, and that answers whether or not the conclusion is derivable from the hypotheses. The proposed algorithms use a variant of magic sets (Monniaux, 1999).
BAN logic inspired many other similar formalisms, such as GNY logic. Some of these try to repair one weakness of BAN logic: the lack of a good semantics with a clear meaning in terms of knowledge and possible universes.
The definitions and their implications are below (P and Q are network agents, X is a message, and K is an Encryption key):
The meaning of these definitions is captured in a series of postulates:
P must believe that X is fresh here. If X is not known to be fresh, then it might be an obsolete message, replayed by an attacker.
Using this notation, the assumptions behind an authentication protocol can be formalized. Using the postulates, one can prove that certain agents believe that they can communicate using certain keys. If the proof fails, the point of failure usually suggests an attack which compromises the protocol.
A very simple protocol - the Wide Mouth Frog protocol - allows two agents, A and B, to establish secure communications, using a trusted authentication server, S, and synchronized clocks all around. Agents A and B are equipped with keys Kas and Kbs, respectively, for communicating securely with S. So we have assumptions:
Agent A wants to initiate a secure conversation with B. It therefore invents a key, Kab, which it will use to communicate with B. A believes that this key is secure, since it made up the key itself:
B is willing to accept this key, as long as it is sure that it came from A:
Moreover, B is willing to trust S to accurately relay keys from A:
That is, if B believes that S believes that A wants to use a particular key to communicate with B, then B will trust S and believe it also.
The goal is to have
A reads the clock, obtaining the current time t, and sends the following message:
That is, it sends its chosen session key and the current time to S, encrypted with its private authentication server key Kas.
Since S believes that key(Kas, A<->S), and S sees {t, key(Kab, A<->B)}Kas, then S concludes that A actually said {t, key(Kab, A<->B)}. (In particular, S believes that the message was not manufactured out of whole cloth by some attacker.)
Since the clocks are synchronized, we can assume
Since S believes fresh(t) and S believes A said {t, key(Kab, A<->B)}, S believes that A actually believes that key(Kab, A<->B). (In particular, S believes that the message was not replayed by some attacker who captured it at some time in the past.)
S then forwards the key to B:
Because message 2 is encrypted with Kbs, and B believes key(Kbs, B<->S), B now believes that S said {t, A, A believes key(Kab, A<->B)}. Because the clocks are synchronized, B believes fresh(t), and so fresh(A believes key(Kab, A<->B)). Because B believes that S's statement is fresh, B believes that S believes that (A believes key(Kab, A<->B)). Because B believes that S is authoritative about what A believes, B believes that (A believes key(Kab, A<->B)). Because B believes that A is authoritative about session keys between A and B, B believes key(Kab, A<->B). B can now contact A directly, using Kab as a secret session key.
Now let's suppose that we abandon the assumption that the clocks are synchronized. In that case, S gets message 1 from A with {t, key(Kab, A<->B)}, but it can no longer conclude that t is fresh. It knows that A sent this message at some time in the past (because it is encrypted with Kas) but not that this is a recent message, so S doesn't believe that A necessarily wants to continue to use the key Kab. This points directly at an attack on the protocol: An attacker who can capture messages can guess one of the old session keys Kab. (This might take a long time.) The attacker then replays the old {t, key(Kab, A<->B)} message, sending it to S. If the clocks aren't synchronized (perhaps as part of the same attack), S might believe this old message and request that B use the old, compromised key over again.
Kerberos uses as its basis the Needham-Schroeder protocol. It makes use of a trusted third party, termed a Key Distribution Center (KDC), which consists of two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server (TGS). Kerberos works on the basis of "tickets" which serve to prove the identity of users.
Kerberos maintains a database of secret keys; each entity on the network - whether a client or a server - shares a secret key known only to itself and to Kerberos. Knowledge of this key serves to prove an entity's identity. For communication between two entities, Kerberos generates a session key which they can use to secure their interactions.
One can specify the protocol as follows in security protocol notation, where Alice (A) authenticates herself to Bob (B) using a server S. Here,
We see here that the security of the protocol relies heavily on timestamps T and lifespans L as reliable indicators of the freshness of a communication .
In relation to the following Kerberos operation, it is helpful to note that the server S here stands for both authentication service (AS), and ticket granting service (TGS). In 
, 
is the client to server ticket, 
is the authenticator, and 
confirms B's true identity and its recognition of A. This is required for mutual authentication.
What follows is a simplified description of the protocol. The following shortcuts will be used: AS = Authentication Server, TGS = Ticket Granting Server, SS = Service Server.
In one sentence: the client authenticates itself to AS, then demonstrates to the TGS that it's authorized to receive a ticket for a service (and receives it), then demonstrates to the SS that it has been approved to receive the service.
In more detail:
| term | definition |
|---|---|
| Kerberos | A family of protocols for centrally-controlled and networked authentication of multiple users and services to each other. |
| KDC | Key Distribution Centre, the centralised Kerberos key distribution server, normally a combination of a TGS and an AS. |
| AS | Authentication Server. The component of the centralised Kerberos service responsible for authenticating principals. |
| TGS | Ticket Granting Server, the component of the centralised Kerberos service responsible for granting tickets. |
| TGT | Ticket Granting Ticket, a token issued by the AS to the client for subsequent ticket requests to the TGS. |
| Session Key |
|
| Realm | The set of services and clients authenticated by a KDC. |
| Cross Realm Authentication | This is what administrators need to setup if there are too many client and service requests creating scalability problems on the AS and TGS servers. This makes things more complicated with one realm having a RTGS (Remote Ticket Granting Server) within another realm and vice-versa. Things get worse if you want to have very many realms and they don't all trust each other. |
| CA | Certificate Authority, as used with asymmetric encryption. Kerberos 5 supports this approach, which avoids many of weaknesses resulting from use of shared secrets in authentication and allowing greater scalability. Ultimately for 2 principals to communicate securely, there needs to be a trusted third party. |
| Symmetric Cryptography | Cryptography in which single keys are used as shared secrets between 2 parties to enable these to communicate securely. |
| Asymmetric Cryptography | Cryptography in which each party maintains a secret key known only to them, and publishes a related public key which others can use to communicate securely with the party holding the secret key. Use of asymetric cryptography is limited to establishing session keys usable for symmetric cryptography. |
"Under the rubric of security, Microsoft harms interoperability by manipulating the encryption, signing or tagging of calls made between its operating systems and middleware. Encrypted or signed calls made by Microsoft's operating systems can be seen by competing middleware, but either cannot be read by them or the calls cannot be executed properly and with full function. Calls made by competing server operating systems are rejected by Microsoft's products because they are not encrypted or signed in the Microsoft way.
Microsoft, for example, now encrypts information exchanged between its directory service (Active Directory) and its operating systems. The effect of such "security" is to prevent Novell's eDirectory or other directory services from replacing Active Directory in a network. Even if Novell discovers, or is provided with, the interfaces between Active Directory and Windows, Microsoft's encryption of the information exchanges will effectively prevent the use of an alternative directory service. This tactic, moreover, could be replicated wherever middleware exchanges information, or calls, with Windows.
Although encryption or signing of calls may, in fact, promote security, there is no legitimate reason for such security methods to harm interoperability. In simplest terms, information security is generally afforded by encrypting or "locking up" sensitive information and safeguarding the "keys" to those locks. Rather then relying on well established technologies to protect the "keys" to sensitive information, Microsoft routinely prevents competitors from using the same types of locks that its uses for its own products. This tactic unnecessarily inhibits interoperability, because information security invariably depends not on the type of lock that is used (since a variety of tamper-proof locks have been developed), but solely on protection of the keys.(14) Microsoft routine ignores such distinctions to enable it to harm interoperability under the rubric of security.
In sum, the "security" exception to the RPFJ harms, rather than protects, the public interest. As interpreted by Microsoft, the exception will enable it to withhold information that is irrelevant to securing networks from hacking, viruses and the like, but highly relevant to securing networks from meaningful competition. "
SAMBA is an open source file and print server providing integration between Linux/Unix and Microsoft environments. The current version (3) allows non Windows servers to participate within Windows networks and to authenticate to Microsoft Domain Controllers with some difficulties. It is also possible to use a SAMBA server to authenticate Windows clients, but currently (Nov 2006) only to obsolete versions of the Windows login (i.e. NTLM) protocol.
The implementation of Microsoft Domain Controller functionality has been announced as a primary development goal for SAMBA 4.