Computationally Sound Mechanized Proof of PKINIT for Kerberos ∗

Here we report initial results on the formalization and analysis, using the CryptoVerif tool [4, 5, 6], of the public-key extension to the Kerberos protocol, PKINIT [10]. This protocol provides a good test case for analysis techniques because it incorporates many different protocol design elements: symmetric and asymmetric encryption, digital signatures, and keyed hash functions. We are able to prove, using CryptoVerif’s interactive mode, secrecy and authentication properties for PKINIT at the computational level. Because Kerberos appears to be more complex than the protocols previously analyzed using CryptoVerif, our work provides evidence of the suitability of CryptoVerif for the analysis of real-world industrial protocols. This work is part of an ongoing project to formalize and analyze the Kerberos protocol suite; earlier work has included symbolic proofs (by hand) of security properties of the basic protocol [7], the discovery of a flaw in a draft version of PKINIT (which led to a Windows Security Bulletin [12]) and the symbolic proof of its fixes [8], and by-hand computational proofs of the security of Kerberos with the fixed version of PKINIT using the BPW model [2]. The current work extends this project to include the use of a mechanized tool, Blanchet’s CryptoVerif (v. 1.06). Kerberos and PKINIT. Kerberos [14] is designed to allow a user to repeatedly authenticate herself to multiple servers based upon a single login. The client’s interactions with the servers partition the basic Kerberos protocol into three different rounds. Our focus here is on the first round, called the Authentication Service (AS) Exchange in the protocol specification [14]. The PKINIT extension [10] to Kerberos replaces the basic AS exchange, allowing the use of PKI in place of a long-term key shared between the client C and the KAS K. PKINIT does not change either of the later rounds in the Kerberos protocol. Figure 1 shows the AS exchange in the fixed version of PKINIT: The client C generates two nonces and a timestamp and sends these to K in a message that names the server T (in the second round of Kerberos) for which she wants a ticketgranting ticket (TGT); the other data in this message are discussed fully in [8]. (Here { } , {{ }} , and [ ] are symmetric encryption, asymmetric encryption, and a digital signature, respectively.) The KAS K generates the keys k and AK and a timestamp and then sends AK to C encrypted under ∗Jaggard was partially supported by NSF Grants DMS-0239996 and CNS-0429689 and by ONR Grant N0001405-1-0818. Scedrov was partially supported by OSD/ONR CIP/SW URI “Software Quality and Infrastructure Protection for Diffuse Computing” through ONR Grant N00014-01-1-0795 and OSD/ONR CIP/SW URI “Trustworthy Infrastructure, Mechanisms, and Experimentation for Diffuse Computing” through ONR Grant N00014-04-1-0725. Additional support from NSF Grants CNS-0429689 and CNS-0524059. Tsay was partially supported by ONR Grant N00014-01-1-0795 and NSF grant CNS-0429689. †Tulane University. Current address: Rutgers University, adj@dimacs.rutgers. edu ‡University of Pennsylvania, scedrov@math.upenn. edu §University of Pennsylvania, jetsay@math.upenn. edu