As per Relevance of the word messages, we have this rfc below:
Network Working Group D.L.
Request for Comments: 1004 University of
April 1987
A Distributed-Protocol Authentication
Status of this
The purpose of this RFC is to focus discussion on
problems in the Internet and possible methods of solution.
proposed solutions this document are not intended as standards
the Internet at this time. Rather, it is hoped that a
consensus will emerge as to the appropriate solution
authentication problems, leading eventually to the adoption
standards. Distribution of this memo is unlimited
1. Introduction and
This document suggests mediated access-control and
procedures suitable for those cases when an association is to be
up between multiple users belonging to different trust environments
but running distributed protocols like the existing Exterior
Protocol (EGP) [2], proposed Dissimilar Gateway Protocol (DGP) [3]
and similar protocols. The proposed prcedures are evolved from
described by Needham and Shroeder [5], but specialized to
distributed, multiple-user model typical of these protocols
The trust model and threat environment are identical to that used
Kent and others [1]. An association is defined as the end-to-
network path between two users, where the users themselves
secured, but the path between them is not. The network may drop
duplicate or deliver messages with errors. In addition, it
possible that a hostile user (host or gateway) might intercept
modify and retransmit messages. An association is similar to
traditional connection, but without the usual connection
for error-free delivery. The users of the association are
called associates
The proposed procedures require each association to be assigned
random session key, which is provided by an authentication
called the Cookie Jar. The procedures are designed to permit
those associations sanctioned by the Cookie Jar while operating
arbitrary network topologies, including non-secured networks
broadcast-media networks, and in the presence of hostile attackers
However, it is not the intent of these procedures to hide the
Mills [Page 1]
RFC 1004 April 1987
(except for private keys) transmitted via these networks, but only
authenticate messages to avoid spoofing and replay attacks
The procedures are intended for distributed systems where each user
runs a common protocol automaton using private state variables
each of possibly several associations simultaneously, one for
user j. An association is initiated by interrogating the Cookie
for a one-time key K(i,j), which is used to encrypt the
which authenticates messages exchanged between the users.
initiator then communicates the key to its associate as part of
connection establishment procedure such as described in [3].
The information being exchanged in this protocol model is
intended to converge a distributed data base to specified (as far
practical) contents, and does not ordinarily require a
distribution of event occurances, other than to speed the
process. Thus, the model is intrinsically resistant to message
or duplication. Where important, sequence numbers are used to
the impact of message reordering. The model assumes that
between peers, once having been sanctioned, are
indefinitely. The exception when an association is broken may be
to a crash, loss of connectivity or administrative action such
reconfiguration or rekeying. Finally, the rate of
exchange is specifically designed to be much less than the
capabilities of the network, in order to keep overheads low
2.
Each user i is assigned a public address A(i) and private key K(i)
an out-of-band procedure beyond the scope of this discussion.
address can take many forms: an autonomous system identifier [2],
Internet address [6] or simply an arbitrary name. However, no
what form it takes, every message is presumed to carry both
sender and receiver addresses in its header. Each address and
access-control list is presumed available in a public
accessable to all users, but the private key is known only to
user and Cookie Jar and is not disclosed in messages
between users or between users and the Cookie Jar
An association between i and j is identified by the
consisting of the catenation of the addresses A(i) and A(j),
with a one-time key K(i,j), in the form [A(i),A(j),K(i,j)]. Note
the reciprocal association [A(j),A(i),K(j,i)] is distinguished
by which associate calls the Cookie Jar first. It is the intent
the protocol model that all state variables and keys relevant to
previous association be erased when a new association is
and no caching (as suggested in [5]) is allowed
Mills [Page 2]
RFC 1004 April 1987
The one-time key K(i,j) is generated by the Cookie Jar upon
of a request from user i to associate with user j. The Cookie Jar
access to a private table of entries in the form [A(i),K(i)], where
ranges over the set of sanctioned users. The public
includes for each A(i) a list L(i) = {j1, j2, ...} of
associates for i, which can be updated only by the Cookie Jar.
Cookie Jar first checks that the requested user j is in L(i),
rolls a random number for K(i,j) and returns this to the requestor
which saves it and passes it along to its associate during
connection establishment procedure
In the diagrams that follow all fields not specifically mentioned
unencrypted. While the natural implementation would include
address fields of the message header in the checksum, this
significant difficulties, since they may be necessary to
the route through the network itself. As will be evident below,
if a perpetrator could successfully tamper with the address fields
order to cause messages to be misdelivered, the result would not be
useful association
The checksum field is computed by a algorithm using all the bits
the message including the address fields in the message header,
is ordinarily encrypted along with the sequence-number field by
appropriate algorithm using the specified key, so that the
receiver is assured only the intended sender could have generated it
In the Internet system, the natural choice for checksum is the 16-
bit, ones-complement algorithm [6], while the natural choice
encryption is the DES algorithm [4] (see the discussion following
further consideration on these points). The detailed procedures
as follows
1. The requestor i rolls a random message ID I and sends it
the association specifier [A(i),A(j)] as a request to the
Jar. The message header includes the addresses [A(i),A(C)],
A(C) is the address of the Cookie Jar. The following
illustrates the result
+-----------+-----------+
| A(i) | A(C) | message
+-----------+-----------+
| I | checksum | message
+-----------+-----------+
| A(i) | A(j) | assoc
+-----------+-----------+
2. The Cookie Jar checks the access list to determine if
association [A(i),A(j)] is valid. If so, it rolls a random
K(i,j) and constructs the reply below. It checksums the message
Mills [Page 3]
RFC 1004 April 1987
encrypts the j cookie field with K(j), then encrypts it and
other fields indicated with K(i) and finally sends the reply
+-----------+-----------+
| A(C) | A(i) | message
+-----------+-----------+
| I | checksum | message ID (encrypt K(i))
+-----------+-----------+
| K(i,j) | i cookie (encrypt K(i))
+-----------+
| K(i,j) | j cookie (encrypt K(j)K(i))
+-----------+
3. Upon receipt of the reply the requestor i decrypts
indicated fields, saves the (encrypted) j cookie field and
the i cookie field to the j cookie field, so that both
fields are now the original K(i,j) provided by the Cookie Jar
Then it verifies the checksum and matches the message ID with
list of outstanding requests, retaining K(i,j) for its own use.
then rolls a random number X for the j cookie field (to
wiretappers) and another I' for the (initial) message ID,
recomputes the checksum. Finally, it inserts the saved j
field in the i cookie field, encrypts the message ID fields
K(i,j) and sends the following message to its associate
+-----------+-----------+
| A(i) | A(j) | message
+-----------+-----------+
| I' | checksum | message ID (encrypt K(i,j))
+-----------+-----------+
| K(i,j) | i cookie (encrypt K(j))
+-----------+
| X | j cookie (noise
+-----------+
4. Upon receipt of the above message the associate j decrypts
i cookie field, uses it to decrypt the message ID fields
verifies the checksum, retaining the I' and K(i,j) for later use
Finally, it rolls a random number J' as its own initial
ID, inserts it and the checksum in the confirm message,
the message ID fields with K(i,j) and sends the message
+-----------+-----------+
| A(j) | A(i) | message
+-----------+-----------+
| J' | checksum | message ID (encrypt K(i,j))
+-----------+-----------+
Mills [Page 4]
RFC 1004 April 1987
5. Subsequent messages are all coded in the same way. As new
are generated the message ID is incremented, a new
computed and the message ID fields encrypted with K(i,j).
receiver decrypts the message ID fields with K(i,j) and
the message in case of incorrect checksum or sequence number
3.
Since the access lists are considered public read-only, there is
need to validate Cookie Jar requests. A perpetrator might intercept
modify and replay portions of Cookie Jar replies or
messages exchanged between the associates. However, presuming
perpetrator does not know the keys involved, tampered messages
fail the checksum test and be discarded
The "natural" selection of Internet checksum algorithm and
encryption should be reconsidered. The Internet checksum has
well-known vulnerabilities, including invariance to word order
byte swap. In addition, the checksum field itself is only
bits wide, so a determined perpetrator might be able to discover
key simply by examining all possible permutations of the
field. However, the procedures proposed herein are not intended
compensate for weaknesses of the checksum algorithm, since
vulnerability exists whether authentication is used or not. Also
that the encrypted fields include the sequence number as well as
checksum. In EGP and the proposed DGP the sequence number is
sixteen-bit quantity and increments for each successive message
which makes tampering even more difficult
In the intended application to EGP, DGP and similar
associations may have an indefinite lifetime, although messages
be sent between associates on a relatively infrequent basis
Therefore, every association should be rekeyed occasionally,
can be done by either associate simply by sending a new request
the Cookie Jar and following the above procedure. To protect
stockpiling private user keys, each user should be
occasionally, which is equivalent to changing passwords.
mechanisms for doing this are beyond the scope of this proposal
It is a feature of this scheme that the private user keys are
disclosed, except to the Cookie Jar. This is why two cookies
used, one for i, which only it can decrypt, and the other for j
decrypted first by i and then by j, which only then is valid.
interceptor posing as i and playing back the Cookie Jar reply to
will be caught, since the message will fail the checksum test.
perpetrator with access to both the Cookie Jar reply to i and
subsequent message to j will see essentially a random permutation
Mills [Page 5]
RFC 1004 April 1987
all fields. In all except the first message to the Cookie Jar,
checksum field is encrypted, which makes it difficult to recover
original contents of the cookie fields before encryption
exploiting the properties of the checksum algorithm itself
The fact that the addresses in the message headers are included
the checksum protects against playbacks with modified addresses
However, it may still be possible to destabilize an association
playing back unmodified messages from prior associations. There
several possibilities
1. Replays of the Cookie Jar messages 1 and 2 are unlikely
cause damage, since the requestor matches both the addresses
once-only sequence number with its list of pending requests
2. Replays of message 3 may cause user j to falsely assume a
association. User j will return message 4 encrypted with
assumed session key, which might be an old one or even a
valid one, but with invalid sequence number. Either way, user
will ignore message 4.
3. Replays of message 4 or subsequent messages are unlikely
cause damage, since the sequence check will eliminate them
The second point above represents an issue of legitimate concern
since a determined attacker may stockpile message 3 interceptions
replay them at speed. While the attack is unlikely to succeed
establishing a working association, it might produce
timeouts and result in denial of service. In the Needham-
scheme this problem is avoided by requiring an additional
involving a message sent by user j and a reply sent by user i,
amounts to a three-way handshake
However, even if a three-way handshake were used, the
protocol overhead induced by a determined attacker may still
in denial of service; moreover, the protocol model is
resistant to poor network performance, which has the same
signature as the attacker. The conclusion is that the
expense and overhead of a three-way handshake is unjustified
4. Application to EGP and
This scheme can be incorporated in the Exterior Gateway
(EGP) [2] and Dissimilar Gateway Protocol (DGP) [3] models by
the fields above to the Request and Confirm messages in
straightforward way. An example of how this might be done is given
[3]. In order to retain the correctness of the state machine, it
Mills [Page 6]
RFC 1004 April 1987
convenient to treat the Cookie Jar reply as a Start event, with
understanding that the Cookie Jar request represents an
event which evokes that response
The neighbor-acquisition strategy intended in the Dissimilar
Protocol DGP follows the strategy in EGP. The stability of the
state machine, used with minor modifications by DGP, was verified
state simulation and discussed in an appendix to [2].
associate can send a Request command at any time, which causes
the sender and the receiver to reinitialize all state information
send a Confirm response. In DGP the Request operation involves
Cookie Jar transaction (messages 1 and 2) and then the
command itself (message 3). In DGP the keys are reinitialized as
and each retransmission of a Request command is
authenticated
In DGP the Request command (message 3) and all subsequent
exchanges assume the keys provided by the Cookie Jar. Use of
other keys results in checksum discrepancies and discarded messages
Thus the sender knows its command has been effected, at least at
time the response was sent. If either associate lost its
variables after that time, it would ignore subsequent messages and
(or its associate) would eventually time out and reinitiate the
procedure
If both associates attempt to authenticate at the same time, they
wind up with the authentication sequences crossing in the network
Note that the Request message is self-authenticating, so that if
Request command is received by an associate before the
response to an earlier Request command sent by that associate,
keys would be reset. Thus when the subsequent Confirm response
arrive, it will be disregarded and the Request command
following timeout. The race that results can only be broken when,
to staggered timeouts, the sequences do not cross in the network
This is a little more complicated than EGP and does imply that
attention must be paid to the timeouts
A reliable dis-association is a slippery concept, as example TCP
its closing sequences. However, the protocol model here is much
demanding. The usual way an EGP association is dissolved is when
associate sends a Cease command to the other, which then sends
Cease-ack response; however, this is specifically assumed a non
reliable transaction, with timeouts specified to break retry loops
In any case, a new Request command will erase all history and
in a new association as described above
Other than the above, the only way to reliably dis-associate is
timeout. In this protocol model the associates engage in
Mills [Page 7]
RFC 1004 April 1987
reachability protocol, which requires each to send a message to
other from time to time. Each associate individually times out
a period when no messages are heard from the other
5.
Dan Nessett and Phil Karn both provided valuable ideas and
on early drafts of this report. Steve Kent and Dennis Perry
provided valuable advice on its review strategy
6.
[1] Kent, S.T., "Encryption-Based Protection for
User/Computer Communication", Proc. Fifth Data
Symposium, September 1977.
[2] Mills, D.L., "Exterior Gateway Protocol Formal Specification",
DARPA Network Working Group Report RFC-904, M/A-COM Linkabit
April 1984.
[3] Mills, D.L., "Dissimilar Gateway Protocol Draft Specification",
in preparation, University of Delaware
[4] National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standards Publication 46,
1977.
[5] Needham, R.M., and M.D. Schroeder, "Using Encryption
Authentication in Large Networks of Computers",
of the ACM, Vol. 21, No. 12, pp. 993-999, December 1978.
[6] Postel, J., "Internet Protocol", DARPA Network Working
Report RFC-791, USC Information Sciences Institute,
1981.
Mills [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
