Information about http://www.eecis.udel.edu/~mills/database/papers/dimacs.pdf
Cryptographic Authentication for Real-Time Network Protocols1,2 …
Tags: authentication scheme, autokey, computer time, conventional cryptography, cryptographic authentication, data encryption, data structures, hash functions, network protocols, network time protocol, new security, ntp version, phy, protocol operations, random sequence, real time network, security model, time synchronization, transition documents, udel edu,Pages: 7
Language: english
Created: Wed Dec 2 22:00:17 1998
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Cryptographic Authentication for Real-Time Network Protocols1,2
David L. Mills3
Abstract
This paper describes a new security model and authentication scheme for distributed, real-time network
protocols used in time synchronization and event scheduling applications. It outlines the design require-
ments of these protocols and why these requirements cannot be met using conventional cryptography and
algorithms. It proposes a new design called autokey, which uses a combination of public-key cryptogra-
phy and a psuedo-random sequence of one-way hash functions. Autokey has been implemented for the
Network Time Protocol (NTP), but it can be adapted to other similar protocols. The paper describes the
protocol operations, data structures and resources required for autokey, as well as a preliminary vulnera-
bility assessment.
AMS keywords: cryptography 94A60, data encryption ification is not yet complete, but transition documents
68P25 are available [7] which describe the new features. The
NTP Version 4 reference implementation now under test
1. Introduction supports most of these features, including the authenti-
cation scheme described in this paper. Additional infor-
The Network Time Protocol (NTP) [5] is widely mation can be found at the NTP home page http://
deployed in the Internet to synchronize computer time to www.eecis.udel.edu/~ntp and the author's home page
national standards. The current NTP population includes http://www.eecis.udel.edu/~mills.
over 230 primary servers and well over 100,000 second-
ary servers and clients. It provides comprehensive The NTP security model is common to many other ubiq-
mechanisms to access national time and frequency dis- uitous, distributed applications, such as directory ser-
semination services, organize the hierarchical network vices, web servers and archive repositories.
server-client topology and adjust the clock of each par- Conventional authentication models are based on pub-
ticipant. It uses redundant servers, diverse network paths lic-key cryptography and digital signatures; however,
and crafted algorithms which cast out incorrect servers the known public-key algorithms drastically degrade
and minimize errors due to network latencies and clock timekeeping accuracy and require significant computing
frequency variations. The protocol can operate in peer- resource commitments. Current key-agreement schemes
peer, client-server, and multicast modes, where the iden- based on Diffie-Hellman [11] do not scale well in a large
tity of the servers can be cryptographically authenti- network with thousands of servers and clients. Further-
cated. In most places of the Internet of today, NTP more, a time-sensitive protocol such as NTP places
provides accuracies of 1-50 ms, depending on the char- severe requirements on latency and available resources
acteristics of the synchronization source and network which cannot be satisfied using conventional
paths. approaches. With NTP, cryptographic media lifetimes
and time synchronization interact in complicated ways
Most NTP servers and clients use the NTP Version 3 ref- that can affect the security of all authenticated network
erence implementation for Unix, VMS and Windows, services.
which is a relatively complex, real-time, distributed
application. The architecture, protocol and algorithms This paper presents a new security model and authenti-
are specified in RFC-1305 [6]. The NTP Version 4 spec- cation scheme for NTP and similar real-time protocols.
1. Sponsored by: DARPA Information Technology Office Contract DABT 63-95-C-0046, NSF Division of Network
and Communications Research and Infrastructure Grant NCR 93-01002, Northeastern Center for Electrical Engi-
neering Education Contract A303 276-93, Army Research Laboratories Cooperative Agreement DAA L01-96-2-
002, and Digital Equipment Corporation Research Agreement 1417.
2. Reprinted from: Mills, D.L. Cryptographic authentication for real-time network protocols, in: AMS DIMACS
Series in Discrete Mathematics and Theoretical Computer Science, Vol 45 (1999), 135-144.
3. Author's address: Electrical and Computer Engineering Department, University of Delaware, Newark, DE
19716, mills@udel.edu, http://www.eecis.udel.edu/~mills.
1
It begins with an overview of the NTP protocol opera- the designated address and send no requests. Some mul-
tions, in order to provide a context for the remainder of ticast servers can also respond to client-server requests,
the paper. Following this is a description of the new so that clients can calibrate the network propagation
authentication scheme, called autokey, which provides delay before continuing operation in listen-only mode.
public-key based authentication of servers where the
cryptographic keys are randomly generated and used The NTP security model recognizes that individual serv-
only once. The paper concludes with a discussion of ers can fail or operate incorrectly or even attempt to dis-
possible weakness in the scheme and an assessment of rupt other servers and clients in one way or another. In
its vulnerability to specific attacks. addition, network links can fail, routes can change or
become congested, and cryptographic keys and even
2. NTP Version 3 Security Model and security policies can change while in regular, continuous
Authentication Scheme operation. However, at any one time, synchronization
flows from the primary time servers at the root of the
The existing NTP security model and authentication NTP tree graph or subnet to all secondary servers and
scheme described in the NTP Version 3 specification clients at increasing stratum levels toward the leaves.
RFC-1305 were developed some years ago in response The model requires the authentication tree to follow the
to what were then considered likely directions in the same subnet paths. Thus, if the primary servers are cor-
evolution of generic Internet security models and rectly synchronized and authenticated (by outside
authentication schemes. Since then, there have been sig- means) and, if each secondary server and client is syn-
nificant developments in the field of cryptographic algo- chronized and authenticated to each server at the next
rithms and security models. In order to understand how lower stratum level, the subnet is considered secure.
the current authentication scheme works and how it has
evolved to the autokey scheme, it is necessary to under- The authentication scheme described in RFC-1305 is
stand the various modes of operation and how previ- designed to support this security model. This scheme
ously unknown servers are discovered. has since been augmented to include provisions for the
MD5 message digest algorithm [12], in addition to the
It is important to point out at the outset that the NTP DES-CBC [8], [9] algorithm. The scheme contains pro-
security model is intended only to verify that a server is visions to cryptographically authenticate individual
in fact authentic and not an intruder attempting acci- servers operating in any mode using a symmetric-key
dently or on purpose to impersonate a legitimate server. cryptosystem and private keys.
It is not necessary, nor would it be politically expedient,
to encrypt the timestamps or otherwise hide the data in In RFC-1305, an association is distinguished by source
NTP messages, since these are public values. It is not and destination network addresses and assigned a secret
the intent in the model to include access controls; other cryptographic key, which is stored in a secure database.
mechanisms based on network address and port filtering The key is accessed by a unique key identifier, which
are available for that. It is not necessarily the case that serves a purpose similar to the security parameter identi-
the model includes protections from message loss, fier (SPI) described in recent internet drafts [2], [3]. The
duplication or corruption, since these are provided by key is used to construct a message digest (one-way hash
the NTP protocol itself. function) of the message using either keyed MD5 [4] or
DES-CBC. The key identifier and message digest
A NTP client normally operates with several servers, in together form the message authentication code (MAC),
order to provide redundancy and insure correctness. It which is transmitted following the NTP packet header.
discovers these servers by indexing directory services or The recipient uses the key identifier included in the
by intercepting multicast messages they send. The state MAC to retrieve the secret key from its own secure data-
variables for each server belong to a client process, or base and verifies the authenticity of the message by
association, which can operate in various modes using computing the message digest and comparing it with the
point-to-point and point-to-multipoint communications corresponding value included in the MAC.
paradigms. In peer-peer and client-server modes, a cli-
ent sends a request to a designated server address and The authentication function itself is reasonably fast,
expects a reply from which it can determine the relative even with thousands of clients and in servers providing
clock offset and roundtrip delay. Synchronization flow other functions, such as file sharing, name resolution
is strictly from server to client in client-server modes, and security services. The busiest Internet servers have
but can flow either way in peer-peer modes. In multicast well over 750 clients producing an average (input plus
mode, a server sends a message to a designated multi- output) of over ten packets per second. For a Sun IPC
cast group address. Multicast clients normally listen on workstation, which is slow by today's standards, the
2
average time to service a non-authenticated packet is sage is verified using mechanisms described in the next
about 1.5 ms; authentication adds about 0.28 ms to this section.
figure. However, even the busiest servers spend not
more than about 1.6 percent of the available processing 3.1 Conventional Approaches
resources for all NTP operations.
In a perfect world with inexhaustible processor and
It is possible to engineer some interesting and useful memory resources, a public-key cryptosystem such as
security topologies by sharing a single key among a set RSA public-key infrastructure (PKI) [10] would be a
of servers and clients. For example, a closely cooperat- good foundation on which to build the authentication
ing clique of primary servers operating in peer-peer scheme. In a typical scheme such as RSA or El Gamal
modes can share a single key, in order to provide backup digital signatures, each server or clique of servers is
for each other if a radio clock source fails. This avoids assigned a public/private key pair along with public val-
having to distribute a different key to every server in the ues such as the algorithm modulus, server name, and
clique. In another example, a set of servers can operate network addresses. The private key is held by the server
in multicast mode with a single key, so that a client pop- and never divulged. The public values are stored in
ulation can synchronize to any of them without requir- directory service databases, together with one or more
ing separate keys for each one. digitally signed certificates which bind the public values
to a trusted agent serving as a notary.
3. Autokey Authentication Scheme The power of public-key cryptography lies in the fact
While the current NTP security model and authentica- that a message encrypted with a given private key can be
tion scheme have been in use for well over a decade, correctly decrypted only using the corresponding public
there are several drawbacks, the most serious being the values. In order to minimize the vulnerability to crypto-
requirement that keys must be securely distributed in graphic attack, every message must be individually
advance for all server-client pairs. There are no provi- signed using the server private key. In order to minimize
sions in the NTP protocol specification for key distribu- the processor requirements, the usual practice is to con-
tion or management on the assumption these functions struct the message digest using a one-way hash function
can be provided by standard network security services. such as MD5, then encrypt it using RSA and the server
Even if such services were available, the large number private key. The result is stored in the MAC and trans-
of associations, well over 250,000 in the current NTP mitted with the message.
subnet, would make the operations to securely manufac- To verify the signature, the client decrypts the MAC
ture and distribute keys and enforce their lifetimes very using the server public values, then compares the result
difficult to sustain. In addition, the recent addition of with its own message hash. If the two values agree, the
multicast modes raises new issues where the identity of message must be authentic, since only the designated
servers is not known in advance and their credentials server has the corresponding private key. In practice, the
must be determined using only public values. public values must be cryptographically bound to the
server name and address, as verified by a trusted certifi-
The autokey scheme described in following sections is
cate authority. A certificate including these values is
specifically tailored to the needs of time-sensitive proto-
then installed in a public directory service such as the
cols where the keys are randomly generated and used
DNS.
only once, as in the S/KEY scheme [1]. It involves three
stages of operation for each potential server. In the first Constructing the MD5 message digest is a relatively fast
stage, the server network address is determined, either operation involving only standard arithmetic and logical
directly from directory services or from an intercepted functions. For instance, the time to construct the NTP
multicast message, and an association mobilized to message digest on a Sun SPARC 20 is 54 us and 291 us
communicate with the server. In the second stage, time on a SPARC IPC. However, even when the encrypted
synchronization and server authentication functions pro- data are a relatively small 16-octet MD5 hash, the RSA
ceed independently. encryption operation is expensive. For instance, the pro-
cessor time to generate a NTP MAC using MD5 and
As each function proceeds, potential servers that fail the RSA ranges from 80.4 ms on a Digital Alpha to 2.1 s on
authentication test are discarded and keys that fail the a Sun SPARC 1.
lifetime test are discarded. The third stage begins when
the time-sensitive server credentials are verified and the In principle, the encryption times can be measured in
server joins the population used to discipline the system advance and used to correct time values. However, there
clock. Subsequently, the authenticity of each NTP mes- is a large variance in running times, depending on the
3
population of one bits in the key and other factors. For and before the local clock has been reliably set. Thus,
example, with random bit strings as keys, the Alpha any protocols used by NTP itself to initiate crypto-
requires a mean time of 80.4 ms; however the actual graphic associations must not depend on prior key
times range from 53.3 ms to 104.4 ms. Since time values exchanges that are themselves dependent on synchro-
must be obtained before encryption, these variations nized clocks.
translate directly to timekeeping errors. While there are
other schemes based on public-key cryptography, all are A public-key cryptosystem requires reliable directory
based on computation-intense algorithms and are likely services to obtain the server public values, including the
to behave in a way similar to RSA. For these reasons, server name, network address, public key, modulus and
the autokey scheme does not require each message to be optional certificates. In principle, these services are
individually signed. required to be synchronized to trusted sources only if
they support encryption or decryption operations, since
An alternative to authenticating each message is a key these operations require keys with enforced lifetimes.
distribution scheme, in which the server generates a ses- Presumably, the availability and authenticity of the pub-
sion key and transmits it to the client using public-key lic values depend on databases accessible via inband or
cryptography, or a key agreement scheme, in which the outband mechanisms; however, the ultimate decision on
server and client jointly agree on a joint session key whether the data are authentic rests with the clients of
using a variant of Diffie-Hellman. Either way requires these services, not the server itself.
servers to hold a distinct key for each client and for cli-
ents to hold a distinct key for each server. Either of these In general, server public values are obtained during the
schemes requires the server and client to maintain per- initial configuration process when the client is first
sistent state variables, but this may not be possible for a started. This is done for each server separately while at
server with hundreds or thousands of clients. For this the same time provisional time values are collected.
reason, the autokey scheme must not depend on pair- Since reliable encryption and decryption operations can-
wise private keys. not be done unless the clock is synchronized and the
lifetimes verified, this requires the client to fetch all
3.2 Interactions Between Synchronization and cryptographic values first, then perform the decryptions
Key Lifetimes on a tentative basis. When sufficient time values have
accumulated to reliably synchronize the clock, the life-
A basic rule in all key distribution and management times can be checked against the tentative time. If all
schemes is that cryptographic key and certificate media checks agree, the server is considered authentic. There-
must have enforced lifetimes. Specific keys must be after, the authenticity of its messages must be deter-
destroyed and replaced from time to time, in order to mined by other means as described below.
frustrate potential cryptanalysis. New keys must not
work with old data and old keys must never be used 3.3 Cryptographic Operations
again. Obviously, reliable lifetime enforcement requires
reliable time synchronization. If secure timekeeping is Certain extensions to the existing NTP security model
dependent on lifetime-enforced cryptographic media, an and authentication scheme are required for autokey to
interesting circularity results. In principle, this circular- support additional cryptographic data in the packet
ity can be resolved through the use of special timekeep- header and to enforce key lifetime. The packet format
ing hardware present in some drop-in security devices, has been revised to include an optional extension field,
such as the Fortezza card; however, this hardware is which is inserted between the end of the NTP header
politically unacceptable in some contexts and does not and the beginning of the MAC. The cryptographic mes-
work for all computers manufactured today. sage digest is constructed using all the data between the
beginning of the NTP header to the beginning of the
If trusted hardware is not available, the autokey scheme MAC, including the extension field, if present.
treats clock synchronization and server authentication as
separate functions. These considerations require that A cryptographic key consists of a 4-octet key identifier,
these functions may have to operate when reliable net- a variable length key, a key type indicator (DES or
work timekeeping has not yet been established or when MD5), a validity indicator, and a remaining lifetime
the keys have not yet been certificated. The most com- counter. In the NTP reference implementation, these
mon case occurs when a client is first started after reboot values are stored in a key cache, with the most recently
or when the server configuration is changed. In these used key saved in a special location for quick access. A
cases, the key distribution and management functions miss on the key identifier causes the new key to replace
must operate even when key lifetimes are not enforced the old key, which is stored in the key cache. The key
4
cache itself uses a hash table for quick lookup. Routines Continuing in this way, the server completes the key list,
are provided to create an entry, mark it valid and specify which may have from a few to several hundred entries,
its lifetime. The validity indicator provides a mechanism depending on the interval between master key regenera-
to create a block of keys in advance and enable them as tions and the interval between NTP messages. Finally,
a block at a given time. the server encrypts the last session key using its RSA
private key, and saves the result for later.
In order to preserve backwards compatibility, there are
two ranges of key identifier values. Private keys have The server uses the key list in inverse order; that is, the
identifiers less than 65,536 and are assigned specific last entry is used first and is assigned sequence number
values with indefinite lifetimes. Random keys have zero, then the next before that, which is assigned
identifiers greater than 65,536 and are assigned random sequence number one, and so on until all entries have
values or hashes of a random values with designated been used. At this point, the server generates a new ran-
lifetimes. During normal operation, the remaining life- dom seed and computes a new key list as before. Each
time of each random key is decremented once each sec- time the server uses an entry, it stores the low order four
ond. When this value decrements to zero, the entry is octets of the next session key (not yet used) in the key
automatically expunged from the cache. While the asso- identifier field of the packet and the sequence number
ciation of key identifier and key is arbitrary in this and encrypted last session key in the extension field.
design, an important consequence is that each key iden- Formulated in this way, the server does not need to
tifier must be unique and never replicated in the cache recalculate session keys as they are needed and can
during its lifetime. expunge them immediately after use.
A client authenticates each message relative to the mes-
3.4 Protocol Operations sage that immediately precedes it. It computes the ses-
sion key and message digest as described above, then
As each autokey server is registered with directory ser- extracts the low order four octets of the session key and
vices, it generates a RSA public/private key pair and compares them with the key identifier of the previous
constructs a certificate trail which clients can use to ver- message, which has been saved for this purpose. If the
ify the authenticity of the public values. Registering the values agree, the current message is considered valid. If
server can be a lengthy process involving interactions not, a message might have been discarded in transit, so
with many other services, so this is done only on rare the client hashes again. This procedure may continue for
occasions during the server lifetime. Each server main- a maximum number of hashes equal to the current
tains a private random value used as a master key-gener- sequence number. To complete the procedure, the client
ating key. This value is refreshed at intervals of about decrypts the last session key, which is included in the
one day using a good random generator, which is a rela- extension field, and verifies it matches the final hash.
tively expensive operation taking up to several seconds
on modern workstations. The random keys in the key
4. Security Vulnerabilities
cache must be expunged when the RSA key pair or mas-
ter key are changed. In the NTP security model, the first line of defense is
access control based on an address value bounds check.
Clients may operate several simultaneous server associ- This is followed by the authentication scheme, and a set
ations, each identified by a unique source and destina- of sanity checks which deflect old duplicates or mes-
tion address. At intervals on the order of a thousand sages with format errors or data range errors. The
seconds, the server generates a 4-octet random seed crafted NTP filtering, selection, clustering and combin-
using a fast algorithm and computes the 16-octet MD5 ing algorithms are designed to distinguish between
hash of this value concatenated with the current master truechimers that are correctly synchronized to UTC, and
key. This is the first entry in a pseudo-random sequence falsetickers that are not. The bottom line is that an attack
or key list of 16-octet session keys The least significant succeeds if the intruder can fool all of these algorithms
four octets of the hash is used as the key identifier for into accepting a real falseticker as a truechimer or reject-
the second entry, which is constructed as the MD5 hash ing a real truechimer as a falseticker.
of the concatenated source and destination network
addresses and the key identifier of the first entry. Note An intruder can try to break the various cryptographic
that the autokey scheme in effect includes all significant keys used by the autokey scheme, including the RSA
fields of the NTP message, not just the NTP header as in private key, master key, random seed used to generate
the original scheme, and thus provides additional secu- the session key list, or an individual session key. For all
rity. practical purposes, the RSA private key and the master
5
key are cryptographically unassailable. However, the In a clogging attack, the intruder attempts to deny ser-
attacker may choose as target an individual session key. vice by overwhelming the resources of the client, server
Since the source and destination network addresses are or network by generating large volumes of traffic, either
known, only the 4-octet key identifier for a session key replay or bogus. Clogging attacks to not require the
not yet used needs to be known in order to predict the intruder to pry open legitimate NTP messages, just the
remaining session keys on the list. capability to clone a valid NTP message. By its very
nature, NTP operating in client-server or multicast
The attacker might start by intercepting a legitimate modes is designed as a ubiquitous service; that is, a
message, then try to guess a key identifier that results server will ordinarily respond to any client request with-
after one or more hashes to match the key identifier in out necessarily authenticating the request or checking to
the message. This might not be as hard as it seems. The see if it contains valid data. As the processor cycles nec-
work function for a successful attack is O(231) MD5 essary to reply to a client request are only modest and no
hashes. If each hash takes one microsecond, which additional state persists after the reply has been gener-
might be possible with future hardware, the intruder ated, the vulnerability of a server to a clogging attack is
succeeds on average after only 2000 seconds, so the minimal. However, an intruder can manufacture an oth-
scheme would be classed as cryptographically weak. erwise correct NTP message, but substitute a bogus key
While it would be simple to extend the key length by identifier with correct session key and MAC. The victim
changing the packet header format, this would create an can discover the message is bogus, but only after
incompatibility with older versions of the protocol. The repeated hashes and a significant resource investment to
difficulties this would create outweigh the advantages of validate the RSA signature.
a longer key.
In the old authentication scheme, an intruder can disable
Depending on the network configuration and location of a properly authenticated source by a contrived jamming
the intruder, it may be able to intercept, delay and attack. It can simply send a stream of bogus messages to
retransmit messages (replay attack), modify these mes- the victim, which will cause it to expunge all time val-
sages (modification attack), or prevent onward transmis- ues, legitimate or not. This lesson having been learned,
sion and attack in either of these ways (middleman in the autokey scheme bogus messages are discarded
attack), or even clog the network, server or client with before any damage can result.
spurious traffic (clogging attack).
5. Summary and Conclusions
A middleman can intercept, delay and replay selected
messages from the client to the server or from the server The design of a robust security model and authentication
to the client. These messages will be properly authenti- scheme for a time-sensitive protocol such as NTP is not
cated so will be believed correct. The middleman can a straightforward application of current cryptographic
delay the message or pass on only certain messages technology. The scheme must be scalable, non-invasive
while discarding all others. The effect would be to intro- of processor resources and continue support for legacy
duce a statistical bias in the timekeeping data or to cause protocol versions. It must allow server authentication
the client to believe the server is unstable. Such attacks and time synchronization to proceed independently to
may be hard to detect, since much the same thing hap- avoid circular dependencies that might lead to deadlock.
pens as the result of normal network behavior. There is The autokey scheme described in this paper has been
no intrinsic protection against this attack, other than the devised to comply with these requirements. It uses a
NTP mitigation algorithms, which rely on the inherent combination of public-key cryptography with one-way
redundancy and diversity of the synchronization subnet hash algorithms where keys are randomly generated and
to resist attack. used only once.
The session key applies only to the current message and The alpha distribution of the reference implementation
is not useful for any subsequent message. However, an for NTP Version 4, which includes the autokey scheme,
middleman could intercept a legitimate server message has been in regular operation for several months. While
and learn the current session key before clients have it includes all the protocol mechanisms described in this
received the message. The intruder is then free to manu- paper, the mechanisms to retrieve public values from
facture a bogus message which will be accepted by these secure directory services have yet to be implemented. It
clients. There appears to be no defense against this is anticipated that these mechanisms will be incorpo-
attack other than using public-key cryptographic signa- rated in the form of application libraries made available
tures on every message. from other sources.
6
6. References 5. Mills, D.L. Internet time synchronization: the Net-
work Time Protocol. IEEE Trans. Communications
Note: Internet Drafts are perishable memoranda describ- COM-39, 10 (October 1991), 1482-1493.
ing works in progress and may change in substantial
6. Mills, D.L. Network Time Protocol (Version 3)
ways before final publication as research reports. They
specification, implementation and analysis. Net-
are cited here only when no other source of the material
work Working Group Paper RFC-1305, University
is available.
of Delaware, March 1992, 113 pp.
1. Haller, N. The S/KEY one-time password system. 7. Mills, D.L, and A. Thyagarajan. Network time pro-
Network Working Group Report RFC-1760. tocol version 4 proposed changes. Electrical Engi-
Bellcore, February 1995, 12 pp. neering Department Paper 94-10-2, University of
Delaware, October 1994, 32 pp.
2. Karn, P., and W.A. Simpson. The Photuris session
key management protocol. Network Working 8. DES modes of operation. FIPS Publication 81,
Group Internet Draft, Qualcomm, November 1995, National Bureau of Standards, December 1980.
66 pp. 9. Data encryption standard. FIPS Publication 46-1,
National Bureau of Standards, January 1988.
3. Maughan, D., M. Schertler. Internet security associ-
ation and key management protocol (ISAKMP). 10. PKCS #1: RSA encryption standard, Version 1.5.
Internet Draft, National Security Agency, Novem- RSA Laboratories, November 1993.
ber 1995, 59 pp.
11. PKCS #3: Diffie-Hellman key-agreement standard,
version 1.4. RSA Laboratories, November 1993.
4. Metzger, P., and W. Simpson. IP authentication
using keyed MD5. Network Working Group Paper 12. Rivest, R. The MD5 message-digest algorithm.
RFC-1828, Piermont and Daydreamer, August Network Working Group Paper RFC-1321, MIT
1995, 5 pp. and RSA, April 1992, 21 pp.
7