Prudent Engineering Practice
for Cryptographic Protocols
Mart'in Abadi and Roger Needham
November 1, 1995

Mart'in Abadi is at the Systems Research Center, Digital Equipment Cor-
poration, 130 Lytton Avenue, Palo Alto, CA 94301, USA.
Roger Needham is at the University of Cambridge Computer Laboratory,
Pembroke Street, Cambridge CB2 3QG, UK.
A preliminary version of this paper has appeared in the Proceedings of
the 1994 IEEE Computer Society Symposium on Research in Security and
Privacy.
c
flDigital Equipment Corporation 1995
This work may not be copied or reproduced in whole or in part for any com-
mercial purpose. Permission to copy in whole or in part without payment
of fee is granted for nonprofit educational and research purposes provided
that all such whole or partial copies include the following: a notice that
such copying is by permission of the Systems Research Center of Digital
Equipment Corporation in Palo Alto, California; an acknowledgment of the
authors and individual contributors to the work; and all applicable portions
of the copyright notice. Copying, reproducing, or republishing for any other
purpose shall require a license with payment of fee to the Systems Research
Center. All rights reserved.

Authors' Abstract
We present principles for designing cryptographic protocols. The principles
are neither necessary nor sufficient for correctness. They are however helpful,
in that adherence to them would have prevented a number of published
errors.
Our principles are informal guidelines; they complement formal methods,
but do not assume them. In order to demonstrate the actual applicability of
these guidelines, we discuss some instructive examples from the literature.

Index Terms
Cryptography, authentication, cryptographic protocols, authentication pro-
tocols, security.


Contents
1 Introduction 1
2 Basics 2
2.1 Explicit communication . . . . . . . . . . . . . . . . . . . . . 2
2.2 Appropriate action . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Examples and other principles . . . . . . . . . . . . . . . . . . 4
3 Notation 4
4 Naming 5
5 Encryption 8
5.1 The uses of encryption . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Signing encrypted data . . . . . . . . . . . . . . . . . . . . . . 11
6 Timeliness 12
6.1 Timestamps, sequence numbers, and other nonces . . . . . . 12
6.2 What is fresh: use vs. generation . . . . . . . . . . . . . . . . 16
7 Recognizing messages and encodings 17
8 Trust 19
9 Conclusion 21
Acknowledgments 22
References 23


1 Introduction
Cryptographic protocols, as used in distributed systems for authentication
and related purposes, are prone to design errors of every kind. Over time,
various formalisms have been proposed for investigating and analyzing proto-
cols to see whether they contain blunders. (Liebl's bibliography [13] includes
references to protocols and formalisms.) Although sometimes useful, these
formalisms do not of themselves suggest design rules; they are not directly
beneficial in preventing trouble.
We present principles for the design of cryptographic protocols. The
principles are not necessary for correctness, nor are they sufficient. They are
however helpful, in that adherence to them would have simplified protocols,
and prevented a number of published confusions and mistakes.
We arrived at our principles by noticing some common features among
protocols that are difficult to analyze. If these features are avoided, it be-
comes less necessary to resort to formal tools---and also easier to do so if
there is good reason to. The principles themselves are informal guidelines,
and useful independently of any logic.
We illustrate the principles with examples. In order to demonstrate
the actual applicability of our guidelines, we draw these examples from the
literature. Some of the oddities and errors that we analyze have been docu-
mented previously (in particular, in [4]). Other examples are new: protocols
by Denning and Sacco [6], Hickman (Netscape) [11, 10], Lu and Sundare-
shan [14], Varadharajan, Allen, and Black [31], and Woo and Lam [34]. We
believe they are all instructive.
Generally, we pick examples from the authentication literature, but the
principles are applicable elsewhere, for example to electronic-cash protocols
(e.g., [17]). We focus on traditional cryptography, and on protocols of the
sort commonly implemented with the DES [20] and the RSA [28] algorithms.
In particular, we do not consider the subtleties of interactive schemes for sig-
natures (e.g, [7]). Moreover, we do not discuss the choice of cryptographic
mechanisms with adequate protection properties, the correct implementa-
tion of cryptographic primitives, or their appropriate use; these subjects are
discussed elsewhere (e.g., [32, 19]).
Throughout, we concentrate on the simple principles with the largest
potential applicability and payoff. Admittedly, the literature is full of inge-
nious protocols and attacks. We do not attempt to formulate the laws that
underly this ingenuity, and perhaps it is not necessary to do so. We hope
that our simple principles and examples will contribute to the engineering
of robust cryptographic protocols.
1

2 Basics
A protocol, for present purposes, is a set of rules or conventions defining an
exchange of messages between a set of two or more partners. These part-
ners are users, processes, or machines, which we will generically refer to as
principals. In the cryptographic protocols we consider here, the whole or
part of some or all of the messages is encrypted. We interpret the term en-
cryption fairly broadly, applying it for example to signature operations. For
present purposes, encryption and decryption are defined as key-dependent
transformations of a message which may be inverted only by using a definite
key; the keys used for encryption and decryption are the same or different,
depending on the cryptographic algorithm used.
We find two basic, overarching principles for the design of secure crypto-
graphic protocols. One principle is concerned with the content of a message
and the other with the circumstances in which it will be acted upon:
1. Every message should say what it means---its interpretation should
depend only on its content.
2. The conditions for a message to be acted upon should be clearly set
out so that someone reviewing a design may see whether they are
acceptable or not.
Next we explain these principles. They lead to other, more specific recom-
mendations, which we discuss in the subsequent sections.
2.1 Explicit communication
In full, our first basic principle is:
Principle 1
Every message should say what it means: the interpretation of
the message should depend only on its content. It should be pos-
sible to write down a straightforward English sentence describ-
ing the content---though if there is a suitable formalism available
that is good too.
For example, an authentication server S might send a message whose
meaning may be expressed thus: ``After receiving bit-pattern P , S sends
to A a session key K intended to be good for conversation with B''. All
elements of this meaning should be explicitly represented in the message, so
that a recipient can recover the meaning without any context. In particular,
2

if any of P , S, A, B, or K are left to be inferred from context, it may be
possible for one message to be used deceitfully in place of another.
This principle is not completely original. In [4], we recommend the
use of a logical notation in generating and describing protocols---essentially
proposing a method to follow the principle. Establishing the correspon-
dence between the logical protocol and its concrete implementation can be
a simple matter of parsing, as for example in [33, Section 4.3.2]. Although
a precise comparison of informal ideas is difficult, we also find an affinity
with Boyd and Mao's proposal that protocols should be robust in the sense
that ``authentication of any message in the protocol depends only on infor-
mation contained in the message itself or already in the possession of the
recipient'' [3]. An operational variant on this theme appears in the work of
Woo and Lam, who say that a protocol is a full information protocol if ``its
initiator and responder always include in their outgoing encrypted messages
all the information they have gathered'' [35].
2.2 Appropriate action
For a message to be acted upon, it does not suffice that the message be
understood; a variety of other conditions have to hold too. These conditions
often consist of what may be regarded informally as statements of trust,
though this anthropomorphic notion should be used with care.
Statements of trust cannot be wrong though they may be considered
inappropriate. For example, if someone believes that choosing session keys
should be done by a suitably trusted server rather than by one of the par-
ticipants in a session, then he will not wish to use a protocol such as the
Wide-mouthed-frog protocol [4].
In general, we have:
Principle 2
The conditions for a message to be acted upon should be clearly
set out so that someone reviewing a design may see whether they
are acceptable or not.
2.3 Secrecy
The secrecy of certain pieces of information is essential to the functioning
of cryptographic protocols. Obviously, a protocol should not publicize the
cryptographic keys used for communicating sensitive data. Further, it is
important to know how long a piece of information needs to remain secret,
and to protect it accordingly.
3

None of our principles makes these points explicitly. Rather, all of our
principles warn against mistakes that often imply the loss of secrecy, in-
tegrity, and authenticity. Some of the examples clarify how the principles
relate to the need for secrecy.
There may be more to say about secrecy guidelines for cryptographic
protocols, but these are outside the scope of the present paper.
2.4 Examples and other principles
Below we discuss many concrete examples where errors would have been
avoided by using our two basic principles. We also introduce other principles,
some of them corollaries of the basic ones. In particular, we recommend:
ffl Be clear on how encryption is used, and on the meaning of encryption.
ffl Be clear on how the timeliness of messages is proved, and on the
meaning of temporal information in messages.
Hopefully, the two basic principles will encourage a certain lucidity in the
design of cryptographic protocols, and thereby make it easier to follow the
other principles.
3 Notation
We adopt notation common in the literature. That notation is not quite
uniform and, in the examples, we make compromises between uniformity of
this paper and faithfulness to the original notation.
In this paper, the symbols A and B often represent arbitrary principals,
S represents a server, T a timestamp, N a nonce (a quantity generated for
the purpose of being recent), K a key, and K \Gamma1 its inverse. In symmetric
cryptosystems such as DES, K and K \Gamma1 are always equal. For asymmetric
cryptosystems such as RSA, we assume for simplicity that the inversion
operation is an involution (so K \Gamma1 \Gamma1 equals K); we tend to use K \Gamma1 for
the secret part and K for the public part of a key pair (K; K \Gamma1 ). We write
fXgK to represent X encrypted under K; anyone who knows fXgK and
the inverse of K can obtain X. If K is secret, we may refer to fXgK as a
signed message, and to the encryption operation as a signature.
For example,
Message 4 B ! A : fT a + 1g K ab
describes the fourth message in a protocol; in this message, B sends to A
the timestamp T a incremented by 1, under the key K ab . In this example,
4

the subscript a in T a is a hint that A first generated T a ; the subscript ab
in K ab is a hint that K ab is intended for communication between A and B.
Similarly, we may write K a for A's public key.
The typical notation ``Message 4 B ! A : X '' needs to be interpreted
with some care. The messages constituting a cryptographic protocol are not
sent in a benign environment (in which they would frequently be unneces-
sary) but in one with error, corruption, loss, and delay. Accordingly we may
read ``Message 4 B ! A : X '' only as ``the protocol designer intended X
to be originated by B as the fourth message in the protocol, and for it to
be received by A''. There is nothing in the environment to guarantee that
messages are made in numerical order by the principals indicated, received
in numerical order or at all by the principals indicated, or received solely by
the principals indicated. If assurance is needed about any of these matters
it must be provided as part of the function of the protocol.
4 Naming
The most immediate instance of Principle 1 prescribes being explicit about
the names of principals:
Principle 3
If the identity of a principal is essential to the meaning of a
message, it is prudent to mention the principal's name explicitly
in the message.
The names relevant for a message can sometimes be deduced from other
data and from what encryption keys have been applied. However, when
this information cannot be deduced, its omission is a blunder with serious
consequences.
The principle is obvious and simple, yet it is commonly ignored. We give
several examples of fairly different natures.
Example 3.1 In [6, p. 535], Denning and Sacco propose a protocol for key
exchange based on an asymmetric cryptosystem. In the first two messages
of this protocol, A obtains certificates CA and CB that connect A and B
with their public keys K a and K b , respectively. The exact form of CA and
CB is not important for our purposes. The interesting part of the protocol
is Message 3. There, A sends to B a key K ab for subsequent encrypted
communication between A and B, with a timestamp T a . The protocol is:
Message 1 A ! S : A; B
Message 2 S ! A : CA; CB
Message 3 A ! B : CA; CB; ffK ab ; T a g K \Gamma1
a
g K b
5

This third message is encrypted for both secrecy and authenticity. When
A sends this message to B, it is important that no other principal obtain
K ab ; the use of K b provides this guarantee. Furthermore, the intent is that,
when B receives the message, B should know that A sent it (because of the
signature with K \Gamma1
a ). Finally, B should know that the message was intended
for B (because of the use of K b ).
Unfortunately nothing provides this final guarantee, with dramatic con-
sequences. Any principal B with which A opens communication can pretend
to a third party C that it actually is A, for the duration of validity of the
timestamp. For simplicity, we omit the exchanges which yield the public
certificates CA, CB, and CC. When A opens communication with B,
Message 3 A ! B : CA; CB; ffK ab ; T a g K \Gamma1
a
g K b
B removes the outer encryption, re-encrypts with K c , sends:
Message 3' B ! C : CA; CC; ffK ab ; T a g K \Gamma1
a
g Kc
and C will believe that the message is from A. In particular, C might send
sensitive information under K ab , and B may see it when perhaps only A
should.
The intended meaning of Message 3 is roughly ``At time T a , A says that
K ab is a good key for communication between A and B''. Any adequate
format for Message 3 should contain all of these elements expressly or by
implication. The obvious one is:
Message 3 A ! B : CA; CB; ffA; B; K ab ; T a g K \Gamma1
a
g K b
although the name A might be deducible from K \Gamma1
a . It is important that
this format must not be used for anything else; we return to this point in
Section 7. 2
Example 3.2 In [34, pp. 42--43], Woo and Lam present an authentication
protocol based on symmetric-key cryptography. When B wants to check
that it is in A's presence, it runs:
Message 1 A ! B : A
Message 2 B ! A : N b
Message 3 A ! B : fN b g Kas
Message 4 B ! S : fA; fN b g Kas g K bs
Message 5 S ! B : fN b g K bs
Here N b is a nonce, S is a server, and K as and K bs are keys that A and
B share with S. Basically, A claims his identity (Message 1); B provides
6

a nonce challenge (Message 2); A returns this challenge encrypted under
K as (Message 3); B passes this message on to S for verification, bound with
A's name under K bs (Message 4); S decrypts using A's key and re-encrypts
under B's (Message 5). If S replies fN b g K bs
, then B should be convinced
that A has responded to the challenge N b .
The protocol is flawed. The connection between the messages is not
sufficient. In particular, nothing connects B's query to S with S's reply.
The protocol is therefore vulnerable to an attack, as follows. Suppose that
B is willing to talk to A and to C roughly at the same time; A may be
off-line. Then C can impersonate A:
Message 1 C ! B : A
Message 1' C ! B : C
Message 2 B ! A : N b
Message 2' B ! C : N 0
b
Message 3 C ! B : fN b g Kcs
Message 3' C ! B : fN b g Kcs
Message 4 B ! S : fA; fN b g Kcs g K bs
Message 4' B ! S : fC; fN b g Kcs g K bs
Message 5 S ! B : fN 00
b g K bs
Message 5' S ! B : fN b g K bs
where N 00
b is the result of decrypting fN b g Kcs using K as . In Messages 1
and 1', C tells B that both A and C want to establish a connection. In
Messages 2 and 2', B replies with two challenges; C receives one normally,
and captures the other one, which was destined to A's address. In Messages
3 and 3', C replies to both challenges. On A's behalf, it can send anything.
On its own behalf, C responds to the challenge intended for A. In Messages 4
and 4', B consults S about the two responses. Messages 5 and 5' are the
replies from S. One of these replies matches nothing, while the other one
contains the challenge intended for A. On the basis of these replies, then,
B must believe that A is present.
The existence of this attack demonstrates that the messages in the proto-
col are not sufficiently explicit about the identity of the principals in ques-
tion. (After we contacted them, Woo and Lam came to the same con-
clusion [35].) Reasoning as in Example 3.1, we may remove the flaw, by
changing the last message of the protocol to
Message 5 S ! B : fA; N b g K bs
A further change is discussed in Example 6.2. 2
Example 3.3 A more dramatic example is provided by the basic Internet
protocol of Lu and Sundareshan [14, pp. 1016--1017]. This protocol is rather
7

complicated for a detailed description. Its intent is to allow two principals
A and B to obtain a session key, with the mediation of local servers and
gateways.
On the other hand, the fundamental flaw of the protocol is rather simple.
One immediately sees that neither A nor B ever receives a message that
contains the other's name. Obviously, this opens the door for confusions
between different connections. It also allows some easy attacks to defeat the
protocol. After we contacted them, the authors published a correction [15],
where names appear in messages explicitly. 2
Example 3.4 The SSL protocol [10] from Netscape allows a Web server and
a client to exchange session keys. An early version of the SSL protocol [11]
includes the following messages:
Message 1 A ! B : fK ab g K b
Message 2 B ! A : fN b g K ab
Message 3 A ! B : fCA; fN b g K \Gamma1
a
g K ab
In the first message, the client A sends a session key K ab to the server B,
under B's public key. Then B produces a challenge N b , which A signs and
returns along with a certificate CA. These three messages are the ones
relevant for client authentication; we omit other messages.
This version of the SSL protocol does not in fact provide client authenti-
cation as was intended. We leave the construction of an attack as an exercise
for the reader. This flaw can be repaired by making the third message more
explicit:
Message 3 A ! B : fCA; fA; B; K ab ; N b g K \Gamma1
a
g K ab
The current version of the SSL protocol corrects this and other flaws that
we found. 2
5 Encryption
The next group of principles and examples concern encryption. They are
generally related to Principle 1, since they concern what encryption means
and what it does not mean.
5.1 The uses of encryption
As the examples below illustrate, encryption is used for a variety of purposes
in the present context [21].
8

ffl Encryption is sometimes used for the preservation of confidentiality.
In such cases it is assumed that only intended recipients know the key
needed to recover a message. When a principal knows K \Gamma1 and sees
fXgK , it may deduce that X was intended for a principal who knows
K \Gamma1 ; and it may even deduce that X was intended for itself, given
additional information.
ffl Encryption is sometimes used to guarantee authenticity. In such cases
it is assumed that only the proper sender knows the key used to encrypt
a message. The encryption clearly contributes to the overall meaning
of the message. The extreme situation is that where a principal shows
that a key is known by encrypting a null message or a timestamp.
ffl While encryption guarantees confidentiality and authenticity, it also
serves in binding together the parts of a message: receiving fX; Y g K is
not always the same as receiving fXgK and fY g K . When encryption
is used only to bind parts of a message, signature is sufficient. The
meaning attached to this binding is rather protocol-dependent, and
often subtle.
ffl Finally, encryption can serve in producing random numbers. There
is a vast theory that explains the relation between one-way functions
and random-number generators. At the level of abstraction that we
consider, one typically assumes that random numbers are available
without examining how they are constructed (but see Example 7.1).
There is considerable confusion about the uses and meanings of encryp-
tion. If the cryptography is asymmetric it may be obvious what is intended;
if the cryptography is symmetric, it is generally not.
Principle 4
Be clear about why encryption is being done. Encryption is not
wholly cheap, and not asking precisely why it is being done can
lead to redundancy. Encryption is not synonymous with security,
and its improper use can lead to errors.
Example 4.1 The Kerberos protocol [18] is based on the original Needham-
Schroeder protocol [22], but makes use of timestamps as nonces in order
to remove flaws demonstrated by Denning and Sacco [6] and in order to
reduce the total number of messages required. Like the Needham-Schroeder
protocol on which it is based, the Kerberos protocol relies on symmetric-key
9

cryptography. A slightly simplified version of the protocol goes:
Message 1 A ! S : A; B
Message 2 S ! A : fT s ; L; K ab ; B; fT s ; L; K ab ; AgK bs
g Kas
Message 3 A ! B : fT s ; L; K ab ; AgK bs
; fA; T a g K ab
Message 4 B ! A : fT a + 1g K ab
Here, T s and T a are timestamps, and L is a lifetime. Initially the server S
shares the keys K as and K bs with the principals A and B; after execution,
A and B share K ab . This protocol serves to illustrate different uses of
encryption; we describe the protocol step by step:
ffl Encryption is not essential for Message 1. Without encryption, though,
an attacker can flood S with requests for keys, by falsifying instances
of Message 1. It is common for designers not to focus on this sort of
vulnerability.
ffl Message 2 requires encryption: K ab should remain confidential, and S
should sign the message as a proof of authenticity.
ffl We may however question why double encryption is used in Mes-
sage 2. Most probably, this use of double encryption is simply in-
herited from the Needham-Schroeder protocol (see Example 9.1). As
in the Needham-Schroeder protocol, double encryption does not add
anything from the points of view of confidentiality or authenticity, and
it is not entirely free of cost.
It does provide a guarantee: when B receives the first part of Mes-
sage 3, it knows that A must have extracted it from Message 2, and
hence that A must have looked at Message 2. (Heintze and Tygar [9]
discuss a similar use of encryption in a variant of the Otway-Rees pro-
tocol [25].) This interpretation of encryption is sound, but slightly
unusual, and probably not what the protocol designers had in mind.
The double encryption has been eliminated in recent versions of Ker-
beros.
ffl In the second part of Message 3, encryption is used for an entirely
different purpose: A encrypts T a with K ab in order to prove knowledge
of K ab near time T a .
In general, T a may be a few hours newer than T s . However, if T a is not
much different from T s , the encryption is redundant: the use of double
encryption in Message 2 gives adequate proof of knowledge of K ab . In
this case, the second part of Message 3 could be omitted altogether,
and B could use T s in Message 4.
10

ffl The encryption in Message 4 serves an analogous purpose.
2
Examples 6.1 and 6.2, below, illustrate the interaction of encryption
and nonces. In short, encryption is often used for binding when a nonce
provides an association between a message and an implicit name. Following
Principle 3, we make this missing name explicit. The use of both encryption
and nonces is then much simpler and economical.
5.2 Signing encrypted data
Signature is used, as the name suggests, to indicate which principal last
encrypted a message. It is frequently taken as also guaranteeing that the
signing principal knew the message content. It is hard, but fortunately
unnecessary to be precise about what knowing is. An informal notion is
sufficient for stating the next principle:
Principle 5
When a principal signs material that has already been encrypted,
it should not be inferred that the principal knows the content of
the message. On the other hand, it is proper to infer that the
principal that signs a message and then encrypts it for privacy
knows the content of the message.
Failure to follow this principle can lead to errors, as in the next example.
Example 5.1 The CCITT X.509 standard contains a set of three protocols
using between one and three messages [5]. The protocols are intended for
signed, secure communication between two principals, assuming that each
knows the public key of the other.
The CCITT proposal has problems. We discuss one problem described
in [4]; it appears already in the one-message protocol:
Message 1 A ! B : A; fT a ; N a ; B; X a ; fY a g K b
g K \Gamma1
a
Here, T a is a timestamps, N a is a nonce (not used), and X a and Y a are user
data. The X.509 protocol actually uses hashing to reduce the amount of
encryption. We do not show this because it does not affect our argument
about X.509.
The protocol is intended to ensure the integrity of X a and Y a , assuring
the recipient of their origin, and to guarantee the privacy of Y a . However,
although Y a is transferred in a signed message, there is no evidence to suggest
that the sender is actually aware of the data sent in the private part of the
11

message. This corresponds to a scenario where some third party intercepts
a message and removes the existing signature while adding his own, blindly
copying the encrypted section within the signed message. This problem can
be avoided by several means, the simplest of which is to sign the secret data
before it is encrypted for privacy. 2
A particular case of the principle concerns hash functions:
Example 5.2 It is common to use hash functions in order to save on encryp-
tion with asymmetric-key systems (see for example [27, 12]). In particular,
A can send a signed, confidential message to B as follows:
Message 1 A ! B : fXgK b
; fH(X)g K \Gamma1
a
where H is a one-way hash function. When A sends this message, only B
discovers X, and B knows that A signed the hash of X. For example, if
X is a request for an operation, B may then infer that A supports X. We
should think of one-way hashing as encryption, and then Principle 5 applies.
In this instance, it means that B cannot be certain that A knew X. For
example, if X is a secret such as a password, B cannot be certain that A
knew the secret; A may have received H(X) from a friend. 2
In general, we recommend careful examination of those protocols that
require a principal to sign material that is both already encrypted and such
that the principal cannot decrypt it. On the other hand, signing before
encrypting is not a bill of health; see Example 3.1.
6 Timeliness
An important part of the meaning of a message is made up of temporal
information. Further, one common precondition for acting upon a message
is that there is reason to believe that the message is fresh, and hence not a
replay of an old one. This freshness has to be inferred from some compo-
nent of the message. Whatever this talisman, it should be bound together
with the rest of the message so that it cannot be attached to a message
being replayed. It is important to understand properly how the freshness
component works, and what is being assumed about it.
The next group of principles and examples concern time. They all ad-
dress what must be assumed about proofs of timeliness, and what they
actually prove.
6.1 Timestamps, sequence numbers, and other nonces
When guarding against replay of messages from an earlier run of the same
protocol it is common to use nonces as part of a challenge-response exchange.
12

A message is sent which leads to a reply which could only have been produced
in knowledge of the first message. The objective is to guarantee that the
second message is made after the first was sent, and sometimes to bind
the two together. There is sometimes confusion about nonces---are they
guaranteed new, random, unpredictable? Whence we propose:
Principle 6
Be clear what properties you are assuming about nonces. What
may do for ensuring temporal succession may not do for ensuring
association---and perhaps association is best established by other
means.
Example 6.1 In [25], Otway and Rees describe the following protocol. It
allows two parties A and B to establish a shared key K ab , with the help of
a server S with whom they share keys K as and K bs , respectively, using the
nonces M , N a , and N b :
Message 1 A ! B : M; A; B; fN a ; M; A; BgKas
Message 2 B ! S : M; A; B; fN a ; M; A; BgKas ; fN b ; M; A; BgK bs
Message 3 S ! B : M; fN a ; K ab g Kas ; fN b ; K ab g K bs
Message 4 B ! A : M; fN a ; K ab g Kas
This is the first protocol analyzed in [4]. Perhaps because of our relative
inexperience, we were rather bold in the idealization of this protocol---in
assigning meanings to these messages. As a consequence, we suggested in
passing that the encryption of N b in Message 2 is unnecessary. As Mao
and Boyd have since explained in detail [16], the encryption of N a and N b
is essential: because N a and N b are bound with the names A and B by
encryption in Messages 1 and 2, they can serve as secure references to A
and B in Messages 3 and 4. Encryption is being used not for secrecy, but
for binding; nonces are exploited not only as proofs of timeliness but also as
substitutes for names.
Much encryption can be avoided when names are included in S's reply:
Message 1 A ! B : A; B; N a
Message 2 B ! S : A; B; N a ; N b
Message 3 S ! B : fN a ; A; B; K ab g Kas ; fN b ; A; B; K ab g K bs
Message 4 B ! A : fN a ; A; B; K ab g Kas
The protocol is not only more efficient but also conceptually simpler after
this modification. 2
Example 6.2 Example 3.2 describes a protocol due to Woo and Lam. Look-
ing back at the use of encryption in that protocol, we notice that the purpose
13

of encryption in Message 4 is to bind two parts of a message. Looking back
at the use of nonces, we notice that N b provides only a proof of freshness,
but not an association to the name A as was intended.
As we argue in Example 3.2, Message 5 should mention the name A
explicitly for the sake of security. With that change, the binding of Message 4
becomes unnecessary. Further, N b needs to be viewed only as a proof of
freshness. The protocol is now simply:
Message 1 A ! B : A
Message 2 B ! A : N b
Message 3 A ! B : fN b g Kas
Message 4 B ! S : A; B; fN b g Kas
Message 5 S ! B : fA; N b g K bs
2
It is not essential for nonces to be unpredictable. In fact, the value of a
counter makes a proper nonce. However, predictable nonces should be used
with caution:
Principle 7
The use of a predictable quantity (such as the value of a counter)
can serve in guaranteeing newness, through a challenge-response
exchange. But if a predictable quantity is to be effective, it
should be protected so that an intruder cannot simulate a chal-
lenge and later replay a response.
Example 7.1 Protocols that rely on synchronized clocks must be accompa-
nied by protocols to access time servers. These protocols cannot themselves
rely on synchronized clocks, but they can rely either on random nonces or
on predictable nonces.
Using random nonces, we may have:
Message 1 A ! S : A; N a
Message 2 S ! A : fT s ; N a g Kas
where T s is the current time and N a is a random nonce, used as a challenge.
After this exchange, A accepts T s as the current time if the response arrived
reasonably soon after the challenge. Reiter exploits random nonces roughly
in this manner [26].
This protocol would not work if N a were predictable. An attacker C
could make A set its clock back: early on, C makes a request for the current
time using a future value of the nonce, saves S's response, and then forwards
the response to A when A uses this value in a challenge.
14

When N a is predictable, it should be protected:
Message 1 A ! S : A; fN a g Kas
Message 2 S ! A : fT s ; fN a g Kas g Kas
The attack is no longer possible. Note that it is not important for N a
to remain secret (and after all we have assumed it is predictable). The
encryption in Message 1 serves to construct a quantity fN a g Kas that only
A and S can predict from a quantity that anyone can predict.
A similar exchange arises in the context of Kerberos. Neuman and
Stubblebine suggest using Kerberos itself to obtain the time from a time
server [24]. The quantity used as a nonce is roughly predictable: it is an
incorrect timestamp; since it is encrypted, we expect no difficulties. 2
Freshness can also be proved by the use of timestamps. Timestamps are
appealing because they seem easier to use than random numbers. However,
their use is not always correct. There are a number of aspects of prudent
practice in the use of timestamps, and they are often misunderstood. One
use of timestamps is as a kind of nonce. In this case the ultimate user of
the timestamp, as part of a response, is the same as the originator of the
challenge of which the timestamp was part. This style of use does not depend
on clock synchronization at all, but does need care because the timestamp
may be to a large extent predictable. Another style of use does depend on
clock synchronization. The recipient of a message looks at a timestamp in
it, and accepts the message only if the timestamp is within a reasonable
interval of the recipient's local time. In this case we have:
Principle 8
If timestamps are used as freshness guarantees by reference to
absolute time, then the difference between local clocks at various
machines must be much less than the allowable age of a message
deemed to be valid. Furthermore, the time maintenance mecha-
nism everywhere becomes part of the trusted computing base.
Example 8.1 Timestamps have received abundant attention in the authen-
tication literature. Gong, in particular, has described problems arising from
the use of incorrect timestamps [8]. Therefore, we keep this example brief,
summarizing Gong's example for the Kerberos system.
In Kerberos, as elsewhere, a principal with a slow clock is exposed to
all sorts of difficulties, since the principal may mistake expired certificates
for current ones. It is more interesting that a fast clock can also be an
opportunity for attackers. If a principal A signs a request at time T 0
using a
timestamp T , with T 0
! T , an attacker C can replay this request near time
15

T . The effect of the request at time T may benefit C, for example if C is
using A's workstation at time T .
Bellovin and Merritt have discussed further problems in the use of times-
tamps in Kerberos [2]. 2
6.2 What is fresh: use vs. generation
Roughly, a bit-pattern is fresh if any message that contains it must be recent.
Clearly, it does not suffice that the bit-pattern participate in one recent
message, if it may also participate in old ones. This observation is most
important for keys:
Principle 9
A key may have been used recently, for example to encrypt a
nonce, yet be quite old, and possibly compromised. Recent use
does not make the key look any better than it would otherwise.
Example 9.1 The Needham-Schroeder protocol and the Kerberos protocol
are similar in structure and in goal; the Needham-Schroeder protocol reads:
Message 1 A ! S : A; B; N a
Message 2 S ! A : fN a ; B; K ab ; fK ab ; AgK bs
g Kas
Message 3 A ! B : fK ab ; AgK bs
Message 4 B ! A : fN b g K ab
Message 5 A ! B : fN b + 1g K ab
As in Kerberos, only A makes contact with S, who provides A with the
session key, K ab , and a certificate encrypted with B's key K bs conveying
the session key to B. Then B decrypts this certificate and carries out a
nonce handshake with A to be assured that A is present currently, since the
certificate might have been a replay. As explained in Section 7, Message 5
contains N b + 1 rather than N b in order to distinguish this message from
Message 4.
Messages 4 and 5 of the Needham-Schroeder protocol were intended to
convince B that A is present and active. They do not (and in fact were
not intended to) convince B that K ab is fresh, and it was pointed out by
Denning and Sacco that compromise of a session key could allow an intruder
to deceive B [6]. Once the importance of freshness of K ab is recognized, a
solution may be found by using timestamps, as suggested by Denning and
Sacco. In another solution, described in [23], B sends a nonce to S, and
then S includes it in its certificate. 2
16

Example 9.2 In [31], Varadharajan, Allen, and Black present several pro-
tocols for delegation in distributed systems. We take as an example the
one for delegation in a Kerberos environment [31, p. 273]. In this protocol,
client B shares the key K bt with the authentication server; B has generated
a timestamp T b and wants a key K bs to communicate with another server S.
The authentication server gives K bs and fK bs g K bt
to S. Then S constructs
fT b + 1g K bs
, and sends:
Message 5 S ! B : S; B; fT b + 1g K bs
; fK bs g K bt
The authors reason:
Having obtained K bs , B is able to verify using T b that S has
replied to a fresh message, so that the session key is indeed fresh.
However, B obtains no proof that K bs is fresh. All that B can deduce is that
K bs has been used recently---but it may be an old, compromised key. 2
7 Recognizing messages and encodings
It seems important that principals recognize messages for what they are,
and can associate them correctly with the current step of whatever protocol
they are executing. There are two possible forms of confusion (which could
happen together): first, between the current message and a message of sim-
ilar purpose from a previous run of the protocol, and second, between the
current message and a message belonging either elsewhere in the protocol,
or to another protocol. Snekkenes [29] and Syverson [30] have constructed
examples of protocols where these confusions can arise.
We believe that these confusions are less important when all our princi-
ples are correctly followed. If a message says what it means then we have
no reason to be concerned with its context. The message is meaningful (or
meaningless) on its own, whether we know that it belongs in a particular
protocol instance or not.
Still, mapping a message to the appropriate protocol instance is con-
venient when it contributes to the compact encoding of the message. For
example, Message 1 of the Wide-mouthed-frog protocol always means some-
thing of the form: ``the signer (with key K as ) says at time T a that K ab is
a good key to talk to B'' (see Example 11.2). If the principal who receives
a message can be certain that it is Message 1 of this protocol, then the
message can be encoded compactly: fT a ; B; K ab g Kas .
We arrive at the following recommendation:
17

Principle 10
If an encoding is used to present the meaning of a message, then
it should be possible to tell which encoding is being used. In
the common case where the encoding is protocol dependent, it
should be possible to deduce that the message belongs to this
protocol, and in fact to a particular run of the protocol, and to
know its number in the protocol.
Mapping a message to the appropriate protocol instance is often trivial
if the message obeys our other principles. If the message contains sufficient
timeliness guarantees and sufficient names, then the current instance cannot
be confused with an old instance, or an instance for other principals. It could
be confused with a concurrent instance for the same principals.
Next we give an example where this principle is relevant, but where other
more important principles apply as well.
Example 10.1 If signature or confidentiality are mediated by symmetric-
key encryption, then a particular form of confusion is associated with the
direction in which a message is intended to pass.
In the Needham-Schroeder protocol, a participant sends a challenge N b
and receives N b + 1 as a response (see Example 9.1):
Message 4 B ! A : fN b g K ab
Message 5 A ! B : fN b + 1g K ab
The purpose of incrementing N b is to distinguish the challenge from the
response. Without this increment, an attacker could send B's message back
to B, who could mistake it for A's reply. The purpose of incrementing
a nonce has often been misunderstood. For example, a ``+1'' operation
appears in Kerberos, where it is unnecessary.
The messages would be clearer if they were rewritten:
Message 4 B ! A : fN-S Message 4: N b g K ab
Message 5 A ! B : fN-S Message 5: N b g K ab
though in fact any way of making the two messages different will do. (This
is an instance of our suggestion to Syverson mentioned in [30].)
Guided by the principle that messages should say what they mean, how-
ever, we ought to rewrite the messages:
Message 4 B ! A : fB says that K ab is a good key to talk to A;
sometime after receiving K ab g K ab
; N b
Message 5 A ! B : fA says that K ab is a good key to talk to B,
sometime after receiving N b g K ab
18

Of course, shorter encodings of these meanings can be constructed. Not
only is there no risk of confusion between these two messages, but also each
of them is self-contained. It is not important to know that they are part of
a particular instance of the Needham-Schroeder exchange. 2
8 Trust
The use of timestamps makes explicit for the first time a question of trust.
When can a principal A rely on another principal B putting a correct times-
tamp in a message? The answer usually given is that this is acceptable if A
trusts B in relation to timestamps.
The idea of trust is pervasive and a little elusive. A careful classification
of types of trust is given in [36] and is taken further by Klein in her doctoral
thesis. There are questions both of practice and philosophy to do with trust
relations---for example whether they are transitive or not---which it would
not be appropriate to pursue here. We may simply say that A trusts B in
regard to some function if a loss of security to A could follow from B not
behaving in the specified way; it is usually difficult or impossible for A to
verify B's good behavior.
There is some measure of trust involved whenever one principal acts on
the content of a message from another. It is essential that this trust be
properly understood.
Principle 11
The protocol designer should know which trust relations his pro-
tocol depends on, and why the dependence is necessary. The
reasons for particular trust relations being acceptable should be
explicit though they will be founded on judgment and policy
rather than on logic.
Example 11.1 Complete loss of security could follow from a Kerberos server
issuing wrong timestamps. The server, and its source of time, must be
trusted by all concerned. This, it may be pointed out, is a case in which
clients can to some extent monitor the good behavior of the trusted server
because the correct time is public and global. If a client reads GPS time
it will have reason for suspicion if Kerberos' time varies from this time
significantly. 2
Example 11.2 The Wide-mouthed-frog protocol uses symmetric-key cryp-
tography and an authentication server. It transfers a key from A to B via
19

S in only two messages:
Message 1 A ! S : A; fT a ; B; K ab g Kas
Message 2 S ! B : fT s ; A; K ab g K bs
First, A sends a session key K ab to S, including a timestamp T a . Then S
checks T a and forwards the message to B, together with its own timestamp
T s . Finally, B checks T s and accepts the session key K ab for communication
with A. Thus, A is trusted to choose a session key. This kind of trust is often
thought unacceptable because of the quality requirements placed on key
generation such as secrecy, non-repetition, unpredictability, and doubtless
more. 2
Example 11.3 Principals associate public keys with other principals by
consulting public-key certificates. These certificates can be issued by certifi-
cation authorities (CAs). CAs are trusted to certify a key only after proper
steps have been taken to identify the principal that owns it. Since there is
no global source of authority, it is not surprising that this is an area where
questions of transitivity of trust come up. It may happen that the only way
A can find out B's public key is by accepting a certificate from CA 1
for
CA 2 's public key which is used to sign a certificate for CA 3 's public key : : :
which is used to sign a certificate for B's public key, for example. In this
case A knows and trusts CA 1 but has never heard of the other certification
authorities---and maybe even distrusts them. 2
Example 11.4 It is usually taken for granted that the two principals in
an authentication dialogue are honestly working to the common end of es-
tablishing a secure communication channel for subsequent use. This is not
always the case, as may be seen in communication between potential ene-
mies or between security forces and terrorists. Possible sorts of bad behavior
are disclosure of keys and forgery of messages. Therefore, if this assumption
is made in a particular case then it should be explicit. 2
Example 11.5 An access control list (ACL) is a statement of trust [1]: if
principal A appears on the ACL for an operation then A is trusted when
it says that the operation should be performed (that is, when it makes a
request). It can be a complex matter to determine whether the statement of
trust that the ACL represents is appropriate. Often, the question of whether
it is appropriate makes little sense, particularly in the context of completely
discretionary access control policies. Nonetheless, understanding ACL's and
their consequences is essential to security. 2
In practice, it is not very common for complicated inferences about trust
to be necessary. With the exception of the chains of trust of Example 11.3,
which are likely to be simpler in practice than they might be in theory,
20

it is usually not difficult to isolate the trust relations being relied on in a
particular circumstance. It is valuable to do so explicitly, because this may
lead to useful debate about the appropriateness of these trust relations.
9 Conclusion
We have found the principles and examples described in this paper useful
in our own work. Perhaps it is because of this that they bear a certain
subjective character. We do however believe that they respond to an im-
mediate general need, in a discipline where some basic mistakes appear in
print several times.
Many of our suggestions can be embodied in development methods and
in formalisms. While these are helpful, we tried to emphasize an informal
understanding of some issues essential for security. We hope that our guide-
lines will help improve the practice of designing cryptographic protocols.
21

Acknowledgments
We have benefited from discussions with Mike Burrows and Butler Lamp-
son. In particular, we discovered many of the examples in this paper in
collaboration with Mike Burrows. Bob Morris pointed out the importance
of clarifying the meaning of the ! notation, and Mark Lomas helped us
do it. Raphael Yahalom, Michael Reiter, and anonymous referees all made
useful comments on earlier versions of this paper. The authors of the papers
from which we drew our examples have also been helpful. Finally, Cynthia
Hibbard suggested improvements in the exposition.
22

References
[1] M. Abadi, M. Burrows, B. Lampson, and G. Plotkin. ``A Calculus for
Access Control in Distributed Systems''. ACM Transactions on Pro-
gramming Languages and Systems Vol. 15, No. 4, September 1993,
pp. 706--734.
[2] S.M. Bellovin and M. Merritt. ``Limitations of the Kerberos Authen-
tication System''. Computer Communication Review Vol. 20, No. 5,
October 1990, pp. 119--132.
[3] C. Boyd and W. Mao. ``On a Limitation of BAN Logic''. Advances in
Cryptology: Eurocrypt '93, Springer-Verlag, 1993, pp. 240--247.
[4] M. Burrows, M. Abadi, and R.M. Needham. ``A Logic of Authenti-
cation''. Proceedings of the Royal Society of London A Vol. 426, 1989,
pp. 233--271. A preliminary version appeared as Digital Equipment Cor-
poration Systems Research Center report No. 39, February 1989.
[5] CCITT. CCITT Blue Book, Recommendation X.509 and ISO 9594-8:
The Directory-Authentication Framework. Geneva, March 1988.
[6] D.E. Denning and G.M. Sacco. ``Timestamps in Key Distribution Pro-
tocols''. CACM Vol. 24, No. 8, August 1981, pp. 533--536.
[7] U. Feige, A. Fiat, A. Shamir. ``Zero Knowledge Proofs of Identity''.
Proceedings of the Nineteenth Annual ACM Symposium on Theory of
Computing, 1987, pp. 210--217.
[8] L. Gong. ``A Security Risk of Depending on Synchronized Clocks''. Op-
erating Systems Review Vol. 26, No. 1, January 1992, pp. 49--54.
[9] N. Heintze and J.D. Tygar. ``Timed Models for Protocol Security''.
CMU Technical Report CMU-CS-92-100, January 1992.
[10] K.E.B. Hickman and T. Elgamal. ``The SSL Protocol''. Internet Draft,
Netscape Communications Corp., version of June, 1995. Currently
available from http://home.netscape.com/newsref/std/SSL.html.
[11] K.E.B. Hickman. ``The SSL Protocol''. RFC, Netscape Communications
Corp., version of October 31, 1994.
[12] B. Lampson, M. Abadi, M. Burrows, and E. Wobber. ``Authentication
in Distributed Systems: Theory and Practice''. ACM Transactions on
Computer Systems Vol. 10, No. 4, November 1992, pp. 265--310.
23

[13] A. Liebl. ``Authentication in Distributed Systems: A Bibliography''.
Operating Systems Review Vol. 27, No. 4, October 1993, pp. 31--41.
[14] W.P. Lu and M.K. Sundareshan. ``Secure Communication in Inter-
net Environments: A Hierarchical Key Management Scheme for End-
To-End Encryption''. IEEE Transactions on Communications Vol. 37,
No. 10, October 1989, pp. 1014--1023.
[15] W.P. Lu and M.K. Sundareshan. ``Enhanced Protocols for Hierarchical
Encryption Key Management for Secure Communication in Internet
Environments''. IEEE Transactions on Communications Vol. 40, No. 4,
April 1992, pp. 658--660.
[16] W. Mao and C. Boyd. ``Towards Formal Analysis of Security Protocols''.
Proceedings of the Computer Security Foundations Workshop VII, 1993,
pp. 147--158.
[17] G. Medvinsky and B.C. Neuman. ``NetCash: A Design for Practical
Electronic Currency on the Internet''. Proceedings of the 1993 ACM
Conference on Computer and Communications Security, pp. 102--106.
[18] S.P. Miller, B.C. Neuman, J.I. Schiller, and J.H. Saltzer. ``Kerberos
Authentication and Authorization System''. Project Athena Technical
Plan Section E.2.1, MIT, July 1987.
[19] J.H. Moore. ``Protocol Failures in Cryptosystems''. Proceedings of the
IEEE Vol. 76, No. 5, May 1988, pp. 594--602.
[20] National Bureau of Standards. ``Data Encryption Standard''. FIPS Pub.
46, January 1977.
[21] R.M. Needham. ``Cryptography and Secure Channels''. Distributed Sys-
tems, 2nd Ed., S. Mullender (editor), ACM Press, 1993, pp. 231--241.
[22] R.M. Needham and M.D. Schroeder. ``Using Encryption for Authen-
tication in Large Networks of Computers''. CACM Vol. 21, No. 12,
December 1978, pp. 993--999.
[23] R.M. Needham and M.D. Schroeder. ``Authentication Revisited''. Op-
erating Systems Review Vol. 21, No. 1, January 1987, p. 7.
[24] B.C. Neuman and S.G. Stubblebine. ``A Note on the Use of Times-
tamps as Nonces''. Operating Systems Review Vol. 27, No. 2, April
1993, pp. 10--14.
24

[25] D. Otway and O. Rees. Efficient and Timely ``Mutual Authentication''.
Operating Systems Review Vol. 21, No. 1, January 1987, pp. 8--10.
[26] M.K. Reiter. ``A Security Architecture for Fault-Tolerant Systems''.
Ph.D. Thesis, Cornell University. Available as Technical Report 93-
1367, Department of Computer Science, Cornell University, July 1993.
[27] R. Rivest. ``The MD4 Message Digest Algorithm''. Advances in Cryp-
tology: Crypto '90, Springer-Verlag, 1991, pp. 303--311.
[28] R.L. Rivest, A. Shamir, and L. Adleman. ``A Method for Obtaining
Digital Signatures and Public-key Cryptosystems''. Communications of
the ACM Vol. 21, No. 2, February 1978, pp. 120-126.
[29] E. Snekkenes. ``Roles in Cryptographic Protocols''. Proceedings of the
1992 IEEE Symposium on Security and Privacy, pp. 105--119.
[30] P. Syverson. ``On Key Distribution Protocols for Repeated Authentica-
tion''. Operating Systems Review Vol. 27, No. 4, October 1993, pp. 24--
30.
[31] V. Varadharajan, P. Allen, S. Black. ``An Analysis of the Proxy Problem
in Distributed Systems''. Proceedings of the 1991 IEEE Symposium on
Security and Privacy, pp. 255--275.
[32] V.L. Voydock and S.T. Kent. ``Security Mechanisms in High-Level Net-
work Protocols''. Computing Surveys Vol. 15, No. 2, 1983, pp. 135--171.
[33] E. Wobber, M. Abadi, M. Burrows, and B. Lampson. ``Authentication
in the Taos Operating System''. ACM Transactions on Computer Sys-
tems Vol. 12, No. 1, February 1994, pp. 3--32.
[34] T.Y.C. Woo and S.S. Lam. ``Authentication for Distributed Systems''.
Computer Vol. 25, No. 1, January 1992, pp. 39--52.
[35] T.Y.C. Woo and S.S. Lam. ``A Lesson on Authentication Protocol De-
sign''. Operating Systems Review Vol. 28, No. 3, July 1994, pp.24-37.
[36] R. Yahalom, B. Klein, T. Beth. ``Trust Relations in Secure Systems---A
Distributed Authentication Perspective''. Proceedings of the 1993 IEEE
Symposium on Security and Privacy, pp. 150--164.
25