INTERNET-DRAFT G Brown draft-petke-serv-deity-protocol-00.txt CompuServe Expires: 15-May-97 15 November 1996 Remote Passphrase Authentication Part Four: Service-to-Deity Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. In addition, the service need not know and does not learn the user's pass phrase, making this scheme useful in distributed environments where it would be difficult or inappropriate to trust a service with a pass phrase database or to allow the server to learn enough to masquerade as the user in a future authentication attempt. This draft is part four of a four part series and explains the protocol between the service and the deity. Part one of this series (draft-petke-ext-intro-00.txt) provides an extended introduction to the problems of authentication over insecure networks. Part two (draft-petke-mech-00.txt) explains the RPA mechanism. Part three (draft-petke-http-auth-scheme-00.txt) explains how to incorporate the mechanism into HTTP. This scheme was inspired by Dave Raggett's Mediated Digest Authentication paper. G Brown [Page 1]
INTERNET-DRAFT RPA - Part Four 15 November 1996 Table of Contents 1. INTRODUCTION 2. OBJECT FORMATS 3. THE BLOB 4. MESSAGE OBJECT TYPES 4.1 AUTHENTICATION REQUEST 4.2 AUTHENTICATION RESPONSE, AFFIRMATIVE 4.3 AUTHENTICATION RESPONSE, NO SERVICE 4.4 AUTHENTICATION RESPONSE, NEGATIVE 4.5 AUTHENTICATION RESPONSE, INVALID SERVICE 4.6 AUTHENTICATION RESPONSE, PROBLEM 5. OBJECT TYPES 6. THE BLOB 7. SECURITY CONSIDERATIONS 8. AUTHOR'S ADDRESS 1. Introduction The service sends a request to the authentication deity and receives a reply. The requests and replies may be packaged in UDP datagrams, or as byte streams over a TCP connection. The tradeoff is primarily that opening a TCP connection requires multiple round trip delays, where UDP doesn't; but TCP avoids the "I wonder whether it's actually running" issue. How to find the deity is a service configuration issue. The service must know the IP addresses, TCP or UDP port numbers, etc., for the deities for a particular realm; it must also know its name and pass phrase in that realm. 2. Object formats Every message is an object composed of other objects. Every object consists of a type-length-value encoded structure: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length MSB | Length LSB | Value octet 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value octet 2 | Value octet 3 | Value octet 4 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G Brown [Page 2]
INTERNET-DRAFT RPA - Part Four 15 November 1996 In this picture, each box represents one octet. Octets are transmitted in order from left to right, top to bottom. "Type" is a single octet that identifies the type of the object. "Length" indicates the number of octets following the length field, as a 16-bit, big-endian value. The appropriate number of value octets--possibly none--follow the length field. Their meaning is determined by the type of the object; in some cases, the value octets contain a sequence of other objects. Here is an example of an object that contains 4 value octets: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0| Value octet 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value octet 2 | Value octet 3 | Value octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And here is an example of an object that contains 1,000 value octets: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |0 0 0 0 0 0 1 1|1 1 1 0 1 0 0 0| Value octet 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value octet 2 | Value octet 3 | Value octet 4 | Value octet 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Value octet 996|Value octet 997|Value octet 998|Value octet 999| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Value octet1000| +-+-+-+-+-+-+-+-+ No padding or alignment is used; if an object contains sub-objects, they follow one another with no padding. For example, an object whose value consists of three sub-objects might look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object type | 00000000 | 00001111 |Sub-obj 1 type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000000 | 00000101 | Value octet 1 | Value octet 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value octet 3 | Value octet 4 | Value octet 5 |Sub-obj 2 type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000000 | 00000000 |Sub-obj 3 type | 00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000001 | Value octet 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G Brown [Page 3]
INTERNET-DRAFT RPA - Part Four 15 November 1996 In this example, we have a single object whose value contains 15 octets. In this example, the value is a sequence of three objects, the first of which contains five octets, the second of which is zero length, and third of which contains one octet. The meaning of each object depends on its type; we'll describe all object types in detail after describing the message objects. We'll sometimes use the term "sub-object" to refer to an object when it is a part of another object, but this is merely a matter of terminology. There is no difference in encoding nor in the meaning of the type field, regardless of whether the object is contained in some other object or not. 3. The blob All messages may contain a "blob" that conveys information defined by a particular deity. The blob is used in three contexts. * In a request, a service may use the blob to tell the deity the nature of the action for which authentication is being performed, if there's some reason to do so. In addition, the service might ask the deity for particular information about the username being authenticated, although, in the general case, the deity will already know what additional information to return to a particular service. * In an affirmative response, the deity may return additional information about the username. * In other responses, the blob might indicate something about the nature of the problem. In general, different deities and services will have different information that's appropriate for inclusion in the blob, so it is difficult to conceive of a truly "standard" set of information. Thus, the definition of the blob's contents is left to each deity, but we define one format for inclusion of attribute/value pairs. Should information in the blob be encrypted? That's a deity configuration issue. Beware, though, of naively encrypting the blob by XOR'ing it with the session key. That would reveal parts of the key because, in general, portions of the plaintext are known. G Brown [Page 4]
INTERNET-DRAFT RPA - Part Four 15 November 1996 4. Message object types There are six message object types, one for a request and five kinds of replies. * Authentication request * Authentication response, affirmative * Authentication response, no service * Authentication response, negative * Authentication response, invalid service * Authentication response, problem The various response flavors indicate various conditions of the account as described below. Remember, a message is simply an object that contains other objects. The message itself is encoded as a type, length, and value, as described above, where the value consists of the concatenation of the component objects of that message; each component object consists of its own type, length, and value. Unless stated to the contrary, all messages must contain exactly the objects indicated in the order shown. Optional components, such as the blob, may be omitted. [When appropriate, it is possible to add extensions, or make a sub-object optional, yet parse the containing object successfully. But in a security protocol, it is best to stick to well-defined formats, rather than adopting a "construct them any way you wish" attitude.] Contents of the component objects are explained in more detail following the descriptions of the message objects. 4.1 Authentication request An authentication request contains the following sub-objects. Request identifier Nr (Realm name) Ns (Service name) Nu (User name) Cu (Challenge from user) Cs (Challenge from service) Ts (Timestamp from service) Ru (Response from user) Blob (optional) Rs (Response from service) The value contained in most of the sub-objects matches the value described in part two of this specification (draft-petke-mech-00.txt). G Brown [Page 5]
INTERNET-DRAFT RPA - Part Four 15 November 1996 The request identifier contains arbitrary data that is not interpreted by the deity; it is simply echoed in a response to provide a way for the requesting service to match requests and responses. The blob contains additional information about the request, and is described below. Usually, it will be omitted or null, i.e., zero-length. Rs is calculated as MD5(Ps + Z + M + Ps), where M is the request shown above, octet by octet, from the type octet for the message object itself through the last length octet of the length field of the Rs object. Thus, it serves to protect the entire request, including its structure, length, etc., and is a different calculation from that shown in the authentication document. 4.2 Authentication response, affirmative An affirmative response indicates that the username is recognized, and is indeed the user you're talking to. Request identifier Canonical Nu (User name, case corrected) Kuss (Key obscured for service) Kusu (Key obscured for user) Au (Authentication value for user) Blob (optional) As (Authentication value for service) The response contains the canonical username in the desired case; this is not the same object type as Nu in the request. In an environment that is not case sensitive, this is the preferred form of the name, which might differ from the name in the request. The blob may contain additional information about the username; see below. As is calculated as MD5(Ps + Z + Ns + Nu + Nr + Kuss + Cs + Cu + Ts + Kus + M + Ps) where M is the request shown above, octet by octet, from the type octet for the containing object through the last octet of the length field of the As object, inclusive. This serves to protect the entire request, and differs from the calculation in the authentication document by the addition of the message contents as shown. Note that the Nu mentioned as the third component in the formula is the originally specified username, not the altered-case version in the response message. G Brown [Page 6]
INTERNET-DRAFT RPA - Part Four 15 November 1996 Beware that an affirmative response does not necessarily mean that it is reasonable to provide service to the user. Often, there are criteria beyond a "yes" answer, which could mean anything from "it's a valid user" to "it's a valid user but not billable" to "it's an account that was signed up five minutes ago and we haven't had a chance to look at it yet." Typically, the authentication deity applies criteria appropriate to the requesting service. For example, if the service doesn't want to allow "free" users, the authentication deity would be configured to return a no-service response for such a user. Alternatively, the deity could be configured to provide an affirmative response but include information in the blob that would permit the service to distinguish "free" from "paying" users and treat them differently. 4.3 Authentication response, no service The no-service response is an indication that the user is whom he claims to be, but you should not provide service to him for one reason or another. For example, he might be a "free" user but your service is provided only to paying accounts; his billing choices might not include your service; or Customer Service might be waiting for him to provide a new credit card number. The authentication deity's configuration for this particular service determines the criteria applied by the deity when making the decision to reply affirmative or no service. Request identifier Canonical Nu (User name, case corrected) Kuss (Key obscured for service) Kusu (Key obscured for user) Au (Authentication value for user) Blob (optional) As (Authentication value for service) The contents of this object are identical to those for an affirmative response, but the service would not normally use the keys or Au values. The blob might include information useful in distinguishing the reason for the no service response, if appropriate for this service. 4.4 Authentication response, negative A negative response means the user is not who he says he is. Whether there is such a username, but that's not who you're talking to; there is such a username, but it is not an enabled account; or there is no such username, is not specified. G Brown [Page 7]
INTERNET-DRAFT RPA - Part Four 15 November 1996 Request identifier Blob (optional) As (Authentication value for service) As is calculated as MD5(Ps + Z + M + Ps). The message may contain a blob if there is additional information about the problem, e.g., for logging, but it may be omitted. 4.5 Authentication response, invalid service An invalid request response means the request could not be processed because you (the service) are not whom you claim to be, based on your apparently not knowing the service's pass phrase or based on any other kind of authentication checking done by the deity. Request identifier Blob (optional) The blob, if present, contains information that allows the deity administrators to trace the problem. There is no As field, because there is no shared secret to authenticate the response. This presents some obvious denial of service issues. 4.6 Authentication response, problem A "problem" response indicates that the request could not be processed for some reason. This could indicate a failure in the system, an unparsable request, or a request for a realm that isn't handled by this deity. Request identifier Blob (optional) As (optional) The blob may contain information that allows the deity administrators to trace the problem. As might or might not be present, depending on the nature of the problem, i.e., whether there is a known shared secret with the server; if present, it is calculated as MD5(Ps + Z + M + Ps). 5. Object types The following types of objects are defined in this protocol. These object types apply to the messages themselves and objects contained in messages. These types do not apply to the contents of the blob. G Brown [Page 8]
INTERNET-DRAFT RPA - Part Four 15 November 1996 [Numbers for the object type field are indicated for each type, but are not necessarily accurate in this draft of the document.] Authentication request--type 1--The request to the authentication deity. Its contents consist of a sequence of other objects as described elsewhere in this document. Authentication response, affirmative--type 2 Authentication response, no service--type 3 Authentication response, negative--type 4 Authentication response, invalid service--type 5 Authentication response, problem--type 6 Request identifier--type 128--A request must contain an identifier to assist in matching replies to requests. This identifier is opaque to the deity, and is simply echoed in the reply, so its value is defined only by the requesting entity. The value should, of course, be unique for each request, but it is otherwise meaningless. It may be of any length. Realm name--type 129--The name of the realm in which the user's and service's identities exist. This is included in the request to allow a deity to serve more than one realm. The value consists of the name in Unicode, in big-endian order. There is no terminating null character, and the realm is generally treated as being case insensitive. For example, the realm aol.com might look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10000001 | 00000000 | 00001110 | 00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01100001 | 00000000 | 01101111 | 00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01101100 | 00000000 | 00101110 | 00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01100011 | 00000000 | 01101111 | 00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 01101101 | +-+-+-+-+-+-+-+-+ That's type 129, fourteen octets follow, and the big-endian Unicode representation of the seven characters aol.com. Service name--type 130--The name of the service in big-endian Unicode. G Brown [Page 9]
INTERNET-DRAFT RPA - Part Four 15 November 1996 User name--type 131--The name of the user in big-endian Unicode, e.g., gsb. User challenge--type 132--The user's challenge, a sequence of random octets. The length is not bounded by the protocol, but the deity will impose length restrictions, e.g., a minimum and maximum length. All bit patterns are legal in the challenge. Service challenge--type 133--The service's challenge, a sequence of random octets. The length is not bounded by the protocol, but the deity will impose length restrictions, e.g., a minimum and maximum length. All bit patterns are legal in the challenge. Time stamp--type 134--The time stamp, containing 14 octets with the value specified in part two of this specification (draft-petke-mech-00.txt). User's response--type 135--The user's response, containing 16 octets with the value specified in part two of this specification (draft-petke-mech-00.txt). This is a binary value, so any bit pattern is possible in this value. Service's response--type 136--The service's response, calculated as described elsewhere in this document. This is a binary value, so any bit pattern is possible in this value. Key obscured for user--type 137--The key for the user, containing 16 octets as described in part two of this specification (draft-petke-mech-00.txt). This is a binary value, so any bit pattern is possible in this value. Key obscured for service--type 138--The key for the service, containing 16 octets as described in part two of this specification (draft-petke-mech-00.txt). This is a binary value, so any bit pattern is possible in this value. Authentication proof for user--type 139--The authentication proof, Au, for the user, containing 16 octets as described in part two of this specification (draft-petke-mech-00.txt). This is a binary value, so any bit pattern is possible in this value. Authentication proof for service--type 140--The authentication proof, As, for the service, containing 16 octets calculated as described elsewhere in this document (not as described in part two of this specification). This is a binary value, so any bit pattern is possible in this value. Canonical user name--type 141--The username adjusted to canonical case, in big-endian Unicode. Blob--type 142--Deity-specific request and response information. G Brown [Page 10]
INTERNET-DRAFT RPA - Part Four 15 November 1996 6. The blob The blob consists of a sequence of objects that contain information about the user's account, or indicate, by their presence or absence, some characteristic of the user's account. Note that the use of any particular object is a function of the deity's configuration for a particular service. Consider, for example, a "free" account in an environment where services are normally provided for a price. There are three most-likely possibilities for how the deity would handle a free account when a particular service asks the deity to authenticate a user: * If the account is free, return an affirmative response. * If the account is free, return an affirmative response and include a "free" indicator in the blob. * If the account is free, return a no-service response. The first alternative would be appropriate for a service that should provide service to free users, when it's none of the service's business whether the user is paying or not. The second alternative would be appropriate for a service that should provide service to free users, but should know that it's doing so, e.g., to provide a different class of service to free users than not-free users. The third alternative would be appropriate for a service that should not provide service to free users. In that case, the deity might include a free indicator in the blob, to note the reason why. It's difficult to conceive of a truly general, standard blob format; that's why we called it a "blob." Therefor, a service-deity pair may define the blob in any way they wish. However, we define one type of sub-object that contains textual attribute/value pairs, to provide a standard encoding for one common need. Type 1--Attribute/value pairs If the blob contains a type-1 object, that object is composed of a sequence of textual attribute/value pairs, where the value is optional: sometimes, the presence or absence of an attribute is significant, with no need for a corresponding value. An attribute consists of a sequence of Unicode characters in the syntax attribute ["=" value] G Brown [Page 11]
INTERNET-DRAFT RPA - Part Four 15 November 1996 i.e., the attribute name optionally followed by an '=' character (code 003D) and a value. All characters are taken from the Unicode character set and stored in big-endian byte order. The attribute name may consist of any characters except a null or equals sign; the value may consist of any characters except a null. To include more than one attribute, use a null character (code 0000) as a separator. A null character following the last attribute is optional, and may be omitted. L"free\0language=en" is a C-syntax example of a pair of attributes, the first with no value. Attribute names are meaningful only in the context of a particular service-deity pair. They may be case sensitive or not as appropriate. [Perhaps there should be two blocks of named attributes, one with standard-defined attributes and one with deity-specific attributes?] 7. Security Considerations This entire document is about security. 8. Author's Address Gary S. Brown CompuServe Incorporated 5000 Britton Rd P.O. Box 5000 Hilliard OH 43026-5000 USA +1 614 723 1127 <gsb@csi.compuserve.com> G Brown [Page 12]