| Minkyu Kim, mk13@cec.wustl.edu (A project report written under the guidance of Prof. Raj Jain) |
Download |
Kerberos was initially designed at MIT as a part of Project Athena [Neuman06] . It has been successfully deployed as a single sign-on protocol that is designed to authenticate clients to multiple different network services. There have been two different versions of the protocol in widely used, known as Kerberos 4 and 5. Kerberos 5 is the most recently proposed and is a trusted third-party authentication mechanism designed for TCP/IP networks. It uses strong symmetric cryptography to enable secure authentication in an insecure network. Currently it is available for all major operating systems, e.g., Linux, Microsoft Windows as well as Apple's OS X. Furthermore, Kerberos 5 has been improved as new functionalities are added to the basic protocol and one of these results is known as PKINIT [Zhu05] (Public-Key Cryptography for Initial Authentication) which modifies the basic protocol to allow public-key authentication and it causes considerable complexity to the protocol.
Regarding the security issues of Kerberos, it has been discussed in several papers which represents possible weak points including replay attacks, password attack against Ticket-Granting tickets or pre-authentication data, attacks against network time protocols (Kerberos requires time synchronization) and malicious client software. Furthermore, a guessing attack and particularly man-in-the-middle attack in PKINIT have been discovered. Before discussing flaws and weakness of Kerberos, in Section 2-4, an analysis of the structure of Kerberos 5, intra- and cross-realm authentication as well as a detailed description of PKINIT will be reviewed.
In Section 5-7, I discuss the flaws and attacks on Kerberos. In Section 5, I focus on the attacks on the basic protocol, Kerberos 5 without PKINIT, such as the password attack, reply attack and guessing attack. Firstly, regarding the reply attack, I reason that it is feasible by presenting attacks on both SMB and LDAPv3. An attacker will be able to access file shares and modify directory entries with the victim's credentials. Some server implementations have actual weaknesses, while others have default configurations that make the attack possible. Secondly, I show that a password attack is feasible, thus allowing the attacker to discover weak user passwords. Pre-authentication data are used for this attack. A replay attack is presented with the SMB protocol. This allows an attacker to access file shares with the victim's credentials without actually knowing the password. Lastly, in many computer systems, users are authenticated via passwords which they choose. Unfortunately, people tend to choose easy-to-remember passwords, which are vulnerable to guessing attacks. A malicious attacker can guess such passwords using the words in a machine-readable dictionary. I show that Kerberos is one of many existing authentication protocols which are vulnerable to so-called off-line guessing attacks, and In Section 8, I will discuss some useful guidelines to be secure against guessing attack as well as other attacks. Based on these guidelines, I will discuss a possible solution to enhance Kerberos protocol so that it can resist the each of attacks.
In Section 6, I discuss the attack on PKINIT, particularly man-in-the-middle attack, which allows an attacker to impersonate Kerberos administrative principals Key Distribution Center(KDC) and end-servers to a client, therefore breaching the authentication guarantees of Kerberos. It also gives the attacker the keys that the KDC would normally generate to encrypt the service requests of this client, hence defeating confidentiality as well, In Section 7, I will discuss about the possible enhancement for scalability and reliability issues in Kerberos cross-realm operation, followed by in Section 9, I provide some concluding remarks.
Networked computer systems provide a great number of shared resources at a user's fingertips; without leaving one's desk, remote hosts, file servers, printers, and many other networked services are readily at hand. Authentication and other security mechanisms are needed so that this convenience is not abused, especially where one's personal computer or organization network is at the risk of dangerous backdoors when connected to the Internet. A simple solution to this problem, requiring users to authenticate to each service they use (for example using a password) is not only inconvenient, but also insecure in practice as people are poor at dealing with a large number of different passwords.
The Kerberos protocol was designed to provide transparent access to all the networked resources a legitimate user needed for a typical day once he/she logs on his/her terminal [Neuman06] . For example, each time the user needs to retrieve a file from a remote server, the required authentication will be handled by Kerberos securely behind the scene, with no user's intervention needed.
This section will review how the latest verion of this protocol, Kerberos 5 [Neuman06] , achieves secure authentication based on a single logon, and for the time being on situations where all the authentications take place within the same administrative domain (or realm) without PKINIT.
The informal example above has described three of principals, that form a typical Kerberos exchange: the human user at his/her terminal, the client process that recognizes the user's password and transparently handles the authentication of each request on the user's behalf, and the requested services, or servers in Kerberos terminology. Kerberos relies on two additional administrative principals together, namely the KDC: the Kerberos Authentication Server (KAS) which authenticates the user and provides the corresponding client with credentials to use the network for a typical day, and the Ticket Granting Server (TGS) which authenticates the client to each requested server based on those credentials. The high-level picture is given in Figure 1.
The top of the figure represents the daily authentication process to Kerberos: as the user (U) logs on, the KAS authenticates the client process representing the user and provides credentials to use the system for that day. These credentials from the KAS are called the Ticket Granting Ticket (TGT). Whenever the user wants to use a networked service, the client on his/her behalf will seek authentication to the process S managing this service. This is done in two steps: the first time U attempts to access S, C presents the TGT from the KAS to the ticket granting server (TGS) who will in turn provide credentials for S. These credentials are called the Service Ticket (ST). Every subsequent time U wants to access this particular service, C forwards ST to S, without involving the TGS. The line at the bottom of the figure represents the actual use of the desired service: this is all the user sees as the client process handles the authentication overhead.
The above mode of interaction represents a typical single organization, or realm in Kerberos terminology. Each realm is regulated by a single KDC, although there may be synchronized replicas for performance and fault tolerance reasons. Within a realm, there will be generally multiple clients and multiple servers. Intra-realm authentication, as this modality is known, is widely deployed and has been extensively studied. Kerberos also supports cross-realm authentication [Bella07] [Butler01] [Mitcell08] , a scheme by which a client in a realm R1 can access a service in a different realm Rn. The rest of this paper will explore how Kerberos achieves cross-realm authentication. Firstly, let's recall how the basic intra-realm protocol works.
This section focuses on the messages exchanged during a typical intra-realm authentication session between a client C and a server S, as shown in the box of Figure 1 [Cervesato09] . Sufficient detail is provided to support their formal specification in the next section. However, it is important to notice that Kerberos is far more complex than the abstract view given here. The simplified version of the Kerberos 5 exchanges is given in Figure 2: the top part relies on the traditional "Alice-and-Bob" notation, with the standard name [Figure 2] for each message given on the left. I will now explain each of the three roundtrips between a client (C) and the KAS (K), the TGS (T), and a server (S), respectively.
Authentication Service Exchange (C <—@gt; K):
Ticket Granting Exchange (C <—@gt; T ):
Client/Server Exchange (C <—@gt; S):
One weakness of the standard Kerberos protocol lies in that the key kC used to encrypt the client's credentials is derived from a password, and passwords are undoubtedly vulnerable to dictionary attacks [Newman01]. In addition, since the initial request is completely plaintext, an active attacker can repeatedly make requests for an honest client's credentials and accrue a large number of plaintext-ciphertext pairs, the latter component being encrypted with the client's long-term key kC (which is derived from a password). While the attacker is unable to use these credentials to authenticate to the system, he is given considerable opportunity to perform an active dictionary attack against the key.
Kerberos can optionally use pre-authentication, a feature designed to prevent an attacker from actively requesting and obtaining credentials for an honest user. Pre-authentication functions by requiring the client to include a timestamp encrypted with his/her long-term key in the initial request. The authentication server will only return credentials if the decrypted timestamp is recent enough. This method successfully prevents an attacker from actively obtaining ciphertext encrypted with the long-term key; however, it does not prevent passive dictionary attacks, i.e., a passive attacker could eavesdrop on network communications, record credentials as the honest client requests them, and attempt off-line dictionary decryption. Hence, pre-authentication makes it slower for an attacker to perform cryptanalysis against the user's long-term key, but it does not prevent the attack. PKINIT, along with a number of other methods, aims at eliminating this dictionary attack vulnerability. In Section 4, I will introduce PKINIT and concentrate on the PKINT attack in Section 6.
Kerberos supports authentication across organizational boundaries by permitting clients and servers to reside on different realms. A realm consists of a group of clients, a KDC, and application servers. For example, the Network Security group in the CSE Department of Washington University in Saint Louis may create an independent realm RNS with its own users, services and administrators. Similarly, the CSE department may organize a Kerberos realm RCSE to allow CSE members to access shared resources, and the University may as well have a realm RW to operate university-wide resources such as printers and scanners in computer labs. Cross-realm authentication enables a student at her workstation in the Network Security group to transparently access a file on the common CSE server, and even to smoothly print it on a printer in any computer lab. Without cross-realm authentication this student would need a separate account in each realm, log onto each of them, and transfer files from account to account in order to achieve the same goals. This is inconvenient, not scalable, and less secure as several passwords would be needed, one for each realm.
In the simplest case, the cross-realm authentication of a client C in realm R1 to a server S in Rn is accomplished by registering the KDC of Rn as a deginated server in R1 and using a variant of the intra-realm protocol to first acquire a TGT for C in R1. And then, a ST for Rn's KDC seen as a local service in R1 [Cervesato09] . This ST has the same format as a TGT for C in Rn, and as such it is submitted to the KDC of Rn to obtain a service ticket for accessing S. The key used by R1's KDC to encrypt the ticket for the special service corresponding to Rn's KDC is called a cross-realm key. This is all Kerberos 4 allows. In Kerberos 5, C's access to S may require traversing intermediate realms R2, ... , Rn-1 if there is no cross-realm key between R1 and Rn, but R1 has such a partnership with R2, R2 with R3, etc. up to Rn. C then needs to obtain a TGT for each of these realms in succession before accessing S. The list of traversed KDC's [R1, ... ,Rn] is called the authentication path of C's access to S. This highlevel description [Cervesato09] is schematically shown in Figure 3.
Inter-realm trust management:
Reliability and Forward Secrecy:
Client centralized exchanges:
PKINIT is known as an extension to Kerberos 5, which uses public key cryptography to avoid shared secrets between a client and KAS [Zhu05] ; it modifies the AS exchange. However, other parts of the basic Kerberos 5 protocol are the same. The long-term shared key (kC) in the traditional AS exchange is typically derived from a password, which limits the strength of the authentication to the user's ability to design and memorize good passwords; PKINIT does not use kC and thus solves this issue. Also, PKINIT allows network administrators to use an existing public key infrastructure (PKI) rather than expend additional effort on managing users' long-term keys needed for traditional Kerberos. This protocol extension adds complexity to Kerberos as it retains symmetric encryption in the later rounds but relies on asymmetric encryption, digital signatures, and corresponding certificates in the first round [Tsay03] .
In PKINIT, the client C and the KAS has independent public/secret key pairs, e.g.,(pkC, skC) and (pkK, skK). Certificate sets CertC CertK issued by a PKI independent from Kerberos are used to testify the binding between each principal and its purported public key [Tsay03] . This simplifies administration as authentication decisions can now be reached based on the trust the KDC holds in just a few known certification authorities within the PKI, rather than keys individually shared with each client. Dictionary attacks are defeated as user-chosen passwords are replaced with automatically generated asymmetric keys. The login process changes as very few users would be able to remember a random public/secret key pair. In Microsoft Windows, keys and certificate chains are stored in a smartcard that the user swipes in a reader at login time. A passphrase is generally required as an additional security measure [Clercq10] . Other possibilities including keeping these credentials on the user's hard drive, are again protected by a passphrase.
In RFC 4556 [Zhu05] , as the PKINIT extension to Kerberos has recently been defined after a sequence of Internet Draft found in [IETFSeq04] , Cervesato et al. use "PKINIT-n" to refer to the protocol as specified in the nth draft revision and "PKINIT" for the protocol more generally and these drafts and the RFC can be found at [IETFSeq04] .
There are two operation modes in PKINIT. First, in public-key encryption mode, the key pairs,e.g.,(pkC, skC) and (pkK, skK), are used for both signature and encryption. The latter is designed to protect the confidentiality of AK, while the former ensures its integrity. Another mode is known as Diffie-Hellman (DH) mode, the key pairs are used to provide digital signature support for an authenticated Diffie-Hellman key agreement which is used to protect the fresh key AK shared between the client and KAS. A variant of this mode allows the reuse of previously generated shared secrets. In the following section, I will take a look more detail about these two modes.
In PKINIT-26, the AS exchange is illustrated in Figure 2. In discussing this and other descriptions of the protocol, Cerversato et al. write [m]sk for the digital signature of message m with secret key sk. (PKINIT realizes digital signatures by concatenating the message and a keyed hash for it, occasionally with other data in between). Cerversato et al. make the standard assumption that digital signatures are unforgeable [Goldwasser11] . Denote that the encryption of m with public key pk is {{m}}pk because, as earlier, I indicated that {m}k is for the encryption of m with symmetric key k.
First line in Public-key Encryption mode:
Second line in Public-key Encryption mode:
I will briefly describe the Diffie-Hellman (DH) mode of PKINIT in this section, although Cervesato's preliminary investigation did not reveal any flaw in this mode [Butler02] . It should be noted that this mode appears not to have been included in any of the major operating systems. The only support can be found is within the PacketCable system [CTL12] , developed by CableLabs, a cable television research consortium.
In the DH moed, except that k is generated by a Diffie-Hellman key exchange instead of the KDC using some key generation algorithm, it is very simliar to the public-key encryption mode. Figure 5 shows the messages involved. The first message is the same except the signature contains, in addition to a timestamp and nonce, Diffie-Hellman parameters and C's public Diffie-Hellman value.
This will perform the same verification actions as in the public-key mode and K will also check that the parameters for the Diffie-Hellman key generation are acceptable when K receives this message. For instance, the system administrator may configure a minimum key length. If everything is valid then K will send a reply as in the second message of Figure 5. K's reply is again similar to the public-key encryption method, except that now it is unnecessary to encrypt the information used to obtain k. This is because k is derived from a Diffie-Hellman key exchange and, under the common assumption that discrete logarithms cannot be computed in polynomial time, learning the public values gives an attacker no information about the actual derived key. K sends n2 and its public Diffie-Hellman value DHpubK signed to C. The signature is necessary for ensuring that DHpubK was created and sent by K.
C receives K's reply and validates it by checking K's certificate and the signature across DHpubK, n2. If everything is valid then C computes the Diffie-Hellman shared secret using DHpubK and its own private Diffie-Hellman value, and then can use the shared secret to derive k. C will then decrypt the authenticator and the protocol proceeds as per the standard Kerberos protocol. Since Diffie-Hellman key generation is expensive, it is desirable to reduce the load on the KDC by reusing Diffie-Hellman shared secrets.
For this reason a variant of the DH mode exists which reuses previously generated Diffie-Hellman shared secrets to derive new keys. In this mode the first message is identical to that of the DH mode except C also includes an extra nonce nC in the signed data. This nonce will be used to compute the new key from the existing Diffie-Hellman secret.
Kerberos V implicitly relies on the servers being secure and software being nonmalicious. However, the most interesting assumptions are the ones about password guessing and replay attacks. Both attacks are non-trivial but could be carried out over the local network. Password guessing attacks can be based on any text encrypted with the key derived from the victim's password, and will result in exposure of the plaintext password. Replay attacks will usually result in the attacker assuming the victim's identity without actually recovering the password. We will discuss both attacks in the next chapter.
In the following sections, I discuss how an attacker might hijack a network connection allowing active monitoring and modification of the victim's network traffic.
According to Kasslin and Tikkanen [Kasslin14] , to hijack a network connection of the target machine we have to be able to direct the flow of network traffic from the target machine to our machine. The rest is accomplished by redirecting the packets in the kernel level. This problem can be solved by the weaknesses of the ARP (address resolution protocol). The ARP is a stateless protocol so it is completely legal by the protocol to send ARP reply packets to the target machine even if it has not send any ARP requests yet.
This makes it possible for the attacker to send forged ARP reply packets continuously to the victim where the MAC address is forged to correspond to the one of the attacker's machines. Usually when you want to sniff the traffic originating from a machine, you need to spoof the gateway of the network.
The tool required for this attack are already implemented. We only need one tool from this package: arpspoof. Iptables is available on most Linux distributions by default.
The ARP spoof is carried out as follows [Kasslin14] :
The hijacking attack allows the network traffic from the victim to be easily monitored and controlled by the attacker on a switched network. As a result of the ARP spoofing attack all the traffic from the victim can be routed to the client through the attacking machine. This situation allowed us to launch the replay attack on Kerberos 5 and SMB
.Network connection hijacking can be done in many ways. Here I take the solutions against ARP spoofing for discussion [Kasslin14] . There are two well known ways to detect ARP spoofing attempts monitoring the local ARP cache and monitoring the network traffic on the wire. ARP cache monitoring on a local machine can be accomplished with the arpcommand. This can be done automatically with a tool called arpwatch. Network traffic monitoring can be implemented with certain Intrusion Detection Systems. The Open Source IDS called Snort is able to do this in real time.
One of the best ways to protect machines against ARP spoofing attacks is to enforce static ARP entries on the local machines, especially the entry for the local gateway should be static.
The Microsoft Windows implementation of Kerberos 5 protocol requires the use of the pre-authentication data in the KRB_AS_REQ message by default, which makes it harder to implement offline password attacks [Kasslin15] . If pre-authentication is not used, anyone can make a request for a TGT from the KDC (Key Distribution Center) and launch an offline password attack against it. The default implementation of pre-authentication data in Windows consists of an encrypted Kerberos timestamp created with a key derived from the user's password and a cryptographic checksum.
If an attacker is able to monitor the network traffic between the victim and the KDC server, a password attack becomes possible. This is based on the fact that before encryption the Kerberos timestamp is an ASCII-encoded string with the syntax "YYYYMMDDHHMMSSZ". This information makes it possible to find a valid password by running a dictionary or brute force attack against the encrypted timestamp. The correctness of the result can be verified by calculating the checksum. The detailed descriptions of the cryptographic operations are provided in [Song16] .
This attack shows that the pre-authentication scheme based on the symmetrically encrypted timestamp is very vulnerable to the dictionary and brute force attacks [Kasslin15] . It was trivial to gather pre-authentication data between the victim and the KDC server by passively monitoring the network traffic. Dictionary attacks were successfully launched against weak passwords. It can be concluded that the feasibility of this attack depends mainly on the strength of the used passwords.
To make it easier to perform this attack Kasslin and Tikkanen created two new tools. The first tool [Kasslin17] is a network sniffer which monitors the network traffic in promiscuous mode and collects pre-authentication data from the KRB_AS_REQ messages. The second tool [Kasslin18] performs a dictionary attack against the data collected by the first tool.
This attack is accomplished by passively listening to the network traffic between the victim and the Kerberos KDC server. The only way to detect this is by monitoring the network for symptoms which might show a hint that someone is running a sniffer on the network.
This attack will become infeasible if a strong password policy is implemented. The Windows implementation of Kerberos 5 also supports another pre-authentication method in addition to the password-based. As discussed, PKINIT does not suffer from the weakness described here. Another effective way to prevent this attack is to encrypt the network traffic, for example by using IPSEC.
Replay attacks against Kerberos 5 are targeted on the final message transferred from the client to the server, called the KRB_AP_REQ message [Kasslin19] . An attacker will attempt to capture this message and reuse its data to authenticate himself as the victim. If successful, the attacker will have full access to the same service the victim accessed. However, He will not be able to recover the victim's actual password. This attack requires that traffic from the victim to the server is subverted to the attacker's network address. This can be achieved with a hijacking attack described in Section 5.1. In SMB case, there are two questions we need to answer regarding this issue.
We can conclude from the results of Kasslin and Tikkanen's research that replay attacks against SMB and Kerberos 5 on a Windows domain are feasible. An attacker will be able to use the victim's credentials to access file shares. Kasslin and Tikkanen's research shows that the Windows Server SP3 does actually cache used authenticators. the attempt to replaying used authenticators failed, because the server refused to accept them. This indicates that an attacker must use an active man-in-the-middle attack to listen on the SMB session setup and prevent the server from seeing the credentials the victim sends. As such, when the attacker replays the security blob, and the server has not seen the authenticator, the attack succeeds. Kasslin and Tikkanen's research shows that the Windows Server SP3 acting as a file server either does not verify the address field or the Windows KDC does not include it in the tickets it issues. This means that an attacker, once he has captured the victim's security blob, may reuse it from his own network address. This makes replay attacks easier.
A tool to perform such an attack, [Kasslin21] is a proxy that listens to connections on the attacker's machine, forwards session negotiations between the real server and the victim and captures the security blob inside the Session Setup AndX message.
To detect a replay attack, one option would be to attempt detecting ARP spoofing altogether. This is described in more detail in section 6.1. If this is successful, the attack becomes infeasible. The victim can also detect a possible attack if attempted connections seem to fail. When an attack is under way, the victim will see an error message stating that the service is not available. This is because the attacker will stop proxying traffic to the server after capturing the security blob. However, this is not an efficient solution, since such errors are also possible in normal circumstances [Kasslin19] . Also, counting on users in such problems is probably not the best choice. The detection of this attack is very difficult. More effort should be made on preventing it from happening. This is possible in a number of ways, among which, the most efficient is to use some form of encryption on the IP layer. The use of IPSEC would be a sufficient protective action. However, using it to encrypt all client-to-server traffic is very difficult. SMB signing, which is available on some implementations, can be used to prevent replay attacks.
In brief, when signing is enabled, packets will include a cryptographic MD5 checksum created with a session key to ensure their integrity. There is a significant pitfall. Servers usually support SMB signing, but do not require that clients always use it. If the victim is using SMB signing, the connection can still be attacked. The security blob is easily extracted, since no encryption is used. If the attacker is then allowed to connect to the server with the stolen credentials without signing, the attack will succeed.
The server must require SMB signing for all connections for the attack to fail. In this case, the attacker will not know the key to create the checksums, and therefore cannot create a connection. If SMB connections have to be made in an unsafe network, other authentication methods such as NTLMv2 are highly possibly safer than Kerberos [Kasslin19] [Kasslin20] . Replay attacks on such challenge-response mechanisms are not possible, but dictionary attacks on weak passwords surely are.
In this section, I discuss a dangerous attack against PKINIT in public-key encryption mode [Cervesato13] . I start with a detailed description of the attacker's actions in the AS exchange, the key to the attack, followed by an explanation of the conditions required for the attack. Then I close this section with a discussion on how the attacker may propagate the effects of his AS exchange actions throughout the rest of a protocol run.
Figure illustrate "man-in-middle-attack". As a consequence of this attack, C believed to be talking to KAS, is talking to I instead and this causes a failure of authentication problem. Also, regarding a failure of confidentiality, I knows AK and k, then C believes that KAS produced AK and k just for her. Note for this attack is as the following:
Attacker observes traffic and learns keys in replies:
Attacker impersonates servers:
What's wrong with PKINIT-26:
Solution adopted in PKINIT version 27:
As discussed in Section 3, the Kerberos has some issues related to the cross-realm operations. These issues are related to the inter-realm trust management and client centricity of the proto col exchanges. The inter-realm trust in the current specification is managed through shared secret keys. This method is not scalable when the number of realms increases. The client centricity of the Kerberos protocol exchanges on the other hand puts all the load of cross-realm operation on the client side. For devices such as PDAs and sensors, this processing could result in unacceptable delays. In order to solve these issues, recently, the Extensible Key Distribution Center Protocol(XKDCP) is new proposed for the cross-realm operations in Kerberos [Zrelli23]
Acquiring TGT in visited realm:
Acquiring tickets for remote services:
In summary, I reviewed and analyzed the structure of Kerberos recently proposed and the cross-realm authentication model of Kerberos as well as an extension version of Kerberos, PKINIT, modifies the basic protocol to allow public-key authentication. As discussed, even though Kerberos has been proven its strengths so far, we could spot several security weakness on Kerberos V and PKINIT. Overall, we look at the recent discovery of attacks against Kerveros V and PKINIT. Regarding attacks on Kerveros V, we discuss about Hijacking a Network Connection on a Switched Network, password attack and reply attack. Particularly for PKINIT, we concentrate on man-in-middle attack and currently, the solution adopted in PKINIT-27 and current candidates for H include hmac-sha1-96-aes128. Lastly, based on the recent published papers, I introduce several feasible solution to prevnet other possible attacks and way to protect your envionment.
[Butler01] F. Butler, I. Cervesato, A. D. Jaggard, A. Scedrov, C. Walstad, Formal Analysis of Kerberos 5, Theoretical Computer Science 367 (1-2), 2006.
http://eprints.kfupm.edu.sa/17429/
[Butler02] M. Backes, I. Cervesato, A. D. Jaggard, A. Scedrov, J. K. Tsay, Cryptographically Sound Security Proofs for Basic and Public-key Kerberos, ESORICS¡¯06, 2006.
http://www.springerlink.com/index/432558h2046mh722.pdf
[Tsay03] JK Tsay, Formal analysis of the Kerberos authentication protocol, Univ. of Pennsylvania Electronic Dissertations, 2008.
http://repository.upenn.edu/dissertations/AAI3328667
[IETFSeq04] JIETF, Public Key Cryptography for Initial Authentication in Kerberos, RFC 4556. Preliminary versions available as a sequence of Internet Drafts, 1996-2006
http://tools.ietf.org/wg/krb-wg/draft-ietf-cat-kerberos-pk-init/
[Zhu05] L. Zhu, B. Tung, IETF RFC 4556, Public Key Cryptography for Initial Authentication in Kerberos, June, 2006,
http://www.ietf.org/rfc/rfc4556.txt
[Neuman06] C. Neuman, T. Yu, S. Hartman, K. Raeburn, IETF RFC4120, The Kerberos Network Authentication Service (V5), July 2005,
http://www.ietf.org/rfc/rfc4120.txt
[Bella07] G. Bella, Inductive Verification of Cryptographic Protocols, Ph.D. thesis, University of Cambridge, March 2000,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.2215&rep=rep1&type=pdf
[Mitcell08] J. C. Mitchell, M. Mitchell, and U. Stern, Automated Analysis of Cryptographic Protocols Using Mur, Proc. of the IEEE Symposium on Security and Privacy, IEEE Computer Society Press, 1997, pp. 141-153,
http://ieeexplore.ieee.org/document/601329
[Cervesato09] I. Cervesato, A. D. Jaggard, A. Scedrov, and C. Walstad, Specifying kerberos 5 cross realm authentication, pp. 12-26, 10-11 January 2005.
http://portal.acm.org/citation.cfm?id=1045405.1045408
[Clercq10] J. De Clercq, M. Balladelli, Windows 2000 authentication, digital Press, 2001
http://www.windowsitlibrary.com/Content/617/06/6
[Goldwasser11] S. Goldwasser, S. Micali, R. L. Rivest, A Digital Signature Scheme Secure Against Adaptive Chosen Message Attacks, SIAM J. Computing 17 (1988) 281-308.
http://eprints.kfupm.edu.sa/17429/
[CTL12] Cable Television Laboratories, Inc., PacketCable Security Specification, technical document PKT-SP-SEC-I11-040730 (2004).
http://www.cablelabs.com/
[Cervesato13] Iliano Cervesato, "Breaking and Fixing Public Key Kerberos", 2007.
http://linkinghub.elsevier.com/retrieve/pii/S089054010700123X/
[Kasslin14] K. Kasslin, A. Tikkanen. Hijacking a Network Connection on a Switched Network, March 2003.
http://users.tkk.fi/autikkan/kerberos/docs/phase1/pdf/LATEST_hijacking_attack.pdf
[Kasslin15] K. Kasslin, A. Tikkanen. Password Attack on Kerberos V and Windows 2000, March 2003.
http://users.tkk.fi/autikkan/kerberos/docs/phase1/pdf/LATEST_password_attack.pdf
[Song16] D. Song. Toolset dsniff.
http://naughty.monkey.org/~dugsong/dsniff/
[Kasslin17] K. Kasslin, A. Tikkanen. sniff_krb5_asreq_packet.c
[Kasslin18] K. Kasslin, A. Tikkanen. crack_krb5_preauth_data.c.
[Kasslin19] K. Kasslin, A. Tikkanen. Replay Attack on Kerberos V and SMB, March 2003.
http://users.tkk.fi/autikkan/kerberos/docs/phase1/pdf/LATEST_replay_attack.pdf
[Kasslin20] K. Kasslin, A. Tikkanen. Replay Attack against Kerberos V and LDAPv3, April 2003.
http://users.tkk.fi/autikkan/kerberos/docs/phase1/pdf/LATEST_ldap_replay.pdf
[Kasslin21] K. Kasslin, A. Tikkanen. smb_catchblob.c
[Zrelli22] S. Zrelli, Y Shinoda, S. Sakane, K. Kamada, and M. Ishiyama, Xkdcp, the inter kdc protocol for cross realm operations in kerberos, IETF, Internet Draft, July 2006
http://tools.ietf.org/html/?draft=draft-zrelli-krb-xkdcp-00
[Zrelli23] S. Zrelli, Tunc Medeni and Yoichi Shinoda, Improving Kerberos Security System for Cross Realm Collaborative Interactions:An Innovative Example of Knowledge Technology for Evolving & Verifiable E Society, 2007
http://ieeexplore.ieee.org/document/4223076/
| AS | Authentication Server |
| CS | Client-Server |
| CSE | Computer Science and Engineering |
| EAP | Extensible Authentication Protocol |
| IETF | Internet Engineering Task Force |
| KAS | Kerberos Authentication Server |
| KDC | Key Distribution Center |
| LDAPv3 | Lightweight Directory Access Protocol |
| MIT | Massachusetts Institute of Technology |
| NTLMv2 | NT LAN Manager Version 2 |
| PKI | Public Key Infrastructure |
| PKINIT | Public Key Cryptography for Initial Authentication in Kerberos, |
| RADIUS | Remote Authentication Dial In User Service |
| RFC | Request For Comments |
| SMB | Server Message Block |
| ST | Service Ticket |
| TGT | Ticket granting ticket |
| TGS | Ticket granting Server |
| XASP | Inter Authentication Service Protocol |
| XKDCP | Extensible Key Distribution Center Protocol |
| XTGST | Inter Ticket Granting Service Protocol |