SRC Technical Note 1998 - 007 March 18, 1998 Two Facets of Authentication Mart´ın Abadi d i g i t a l Systems Research Center 130 Lytton Avenue Palo Alto, California 94301 http://www.research.digital.com/SRC/ Copyright c IEEE 1998. All rights reserved. Republished by permission. Two Facets of Authentication Mart´ın Abadi Digital Equipment Corporation Systems Research Center [email protected] March 18, 1998 Abstract Authentication can serve both for assigning responsibility and for giving credit. Some authentication protocols are adequate for one pur- pose but not the other. This paper explains the distinction between responsibility and credit, through several examples, and discusses the role of this distinction in the design and analysis of protocols. Contents 1 Responsibility and Credit 1 2FourExamples 2 2.1SigningaPublicKey....................... 2 2.2EncryptingaSessionKey.................... 4 2.3 Making a Session Key from Encrypted Shares . 5 2.4TheStation-to-StationProtocol................. 7 3 Discussion 8 3.1Design............................... 8 3.2Analysis.............................. 9 Acknowledgements 10 References 11 1 Responsibility and Credit Authentication can serve both for assigning responsibility and for giving credit. An “authenticated” message M from a principal A toaprincipalB may be used in at least two distinct ways: • B may believe that the message M is being supported by A’s authority. For example, suppose that B is a file server, A a client, and M a request to delete a file f.ThenBmay use A’s identity as an argument to the access control decision of whether to delete f. • B may attribute credit for the message M to A. For example, suppose that B is running a contest, offering a prize to the principal that mails the factors for a large number. When B receives the message M as an entry, B may give credit for the entry to A. These two uses are sharply different, and require different concepts of au- thentication. Furthermore, some natural protocols are adequate for assign- ing responsibility but not for giving credit, and vice versa. We consider some of those protocols in this paper. When a new authentication protocol is designed, it is therefore prudent to state whether the protocol is intended to establish responsibility, credit, or both. Similarly, when an authentication protocol is analyzed, it is prudent to clarify whether its properties suffice for establishing responsibility or credit. However, a quick look at the literature (discussed below) suggests that this clarification is not often present. This paper explains the distinction between responsibility and credit, through several examples, and discusses the role of this distinction in the design and analysis of protocols. Papers by Gollman, Lowe, and others have shed light on several possible definitions of authentication [Gol96, Low97]. This paper does not attempt to review those studies, but aims to comple- ment them. The two facets of authentication are most clearly separate in proto- cols that rely on asymmetric cryptosystems, such as the RSA cryptosys- tem [RSA78]. We therefore take public-key protocols as examples. Al- though our list of examples is not meant to be comprehensive, we illustrate the distinction between responsibility and credit through several protocols of different styles. Our emphasis is not on classifying cryptographic techniques. (See [MvOV96, Chapter 12] for a helpful classification.) Rather, we focus on the higher-level guarantees that protocols provide to the applications that mayrelyonthem. 1 The direct author of a message need not always be held responsible for the message or be given credit for it. In particular, a principal may delegate some part of its authority to another principal, taking responsibility for messages sent by the delegate (much like one can let a friend withdraw from one’s bank account). Similarly, a principal may legitimately divert credit for its messages to another principal (much like one can deposit into a friend’s bank account). Therefore, even when it is proved beyond a reasonable doubt that a principal sent a message, responsibility and credit may not follow. Responsibility and credit are thus distinct from non-repudiation of origin and other related concepts [ZG96, Roe]. 2 Four Examples This section discusses four examples that illustrate the concepts of respon- sibility and credit, and their applications. The examples concern techniques that are common in published, useful protocols. In all four examples, re- sponsibility and credit for the messages between two parties is assigned by the parties themselves. For simplicity, we do not consider scenarios where a third party (for example, a judge) may assign responsibility or credit, but such scenarios could be interesting too. 2.1 Signing a Public Key As a first example, we consider a simple protocol where a principal A creates a short-term key pair, sends the short-term public key to a principal B, signing it with its long-term secret key, then uses the short-term secret key for signing further messages: Message 1 A → B : A, B, {K, A, B, T} −1 KA → {{ } − } Message 2 A B : A, B, M K 1 KB Here M is an arbitrary message, T is a timestamp, KA is A’s long-term −1 public key, KA is the corresponding secret key, K is A’s short-term public key, and K −1 is the corresponding secret key. We use braces for signatures, { } − {{ } − } as in M K 1 , and for encryptions, as in M K 1 KB . Message 1 is the core of the protocol; Message 2 appears only as an example of the use of K. In one interpretation of this protocol, Message 1 conveys that A takes responsibility for the key K,soBcan blame A for any message signed with K−1. Thus, the protocol fits applications that require responsibility for a message (or for a connection). For example, the protocol seems adequate 2 for the situation where B is a file server, A a client, and M a request to delete a particular file. It seems adequate even if A gives K−1 to a delegate, allowing the delegate to make requests on A’s behalf (although delegation mechanisms where B knows the identity of the delegate may be preferable [LABW92]). In a second interpretation of this protocol, B would assign credit to A for every message that is signed with K−1. This interpretation is not justified, as the following would constitute an attack: Message 1 A → B : A, B, {K, A, B, T} −1 (intercepted by C) KA Message 1’ C → B : C, B, {K, C, B, T} −1 KC → {{ } − } Message 2 A B : A, B, M K 1 KB (intercepted by C) → {{ } − } Message 2’ C B : C, B, M K 1 KB Here C is an attacker who signs the public key generated by A. On receipt of M, we would have B give credit for M to C rather than to A.This sequence of messages constitutes an attack with the second interpretation, since it may result in erroneous credit to C. On the other hand, with the first interpretation, this sequence of messages may result in erroneous blame to C; it may also result in denial of service to A and B, but has no other direct negative impact on them. The protocol can be strengthened in a variety of ways. In particular, A may sign its own name with the secret key K−1, for example as in: Message 1 A → B : A, B, {K, A, B, T} −1 , {A}K−1 KA → {{ } − } Message 2 A B : A, B, M K 1 KB or Message 1 A → B : A, B, {K, A, B, T} −1 KA → {{ } − } Message 2 A B : A, B, A, M K 1 KB These modification do not prevent an attacker C from signing the key K −1 −1 with its key KC ; however, C cannot sign its own name with K ,sinceC does not have K−1. Therefore, the protocol becomes adequate for giving credit for M to A. We may say that, with these modifications, A proves possession of the secret key K−1 [MvOV96, Definition 12.7]. However, this statement should not be taken literally. For example, suppose that A is a user with a smart- card and that B is a server. The smart-card may sign a short-term key K generated by the workstation to which the smart-card is connected, and the workstation may sign the name A, while the user and the smart-card may never have access to the secret key K−1. 3 Protocols similar to this one may be used for registering public keys. In this application, B is a certification authority and A is a client that enters a new public key K into B’s registry. It has been argued that, whenever a client is associated with a public key K, the client should prove possession of the corresponding secret key K−1 [MvOV96, Remark 13.23]. However, this view is not universal—it is not shared, in particular, in some recent public-key-infrastructure designs [Ell97]. 2.2 Encrypting a Session Key While the first example shows that a signature may lead to responsibility, the second example shows that an encryption may lead to credit, and that a decryption may lead to responsibility. We consider the situation where a principal A transmits a session key K (say, a DES key [DES77]) to another principal B, encrypting K under B’s public key KB, and including the name A along with K: → { } Message 1 A B : A, K KB Message 2 A → B : {M}K 0 Message 3 B → A : {M }K Messages 2 and 3 simply illustrate the use of the session key K for sending some messages, M and M 0.