home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-petke-serv-deity-protocol-00.txt
< prev
next >
Wrap
Text File
|
1996-11-16
|
27KB
|
688 lines
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]