RFC 1704

On Internet Authentication 🔐

okay so bestie, this is RFC 1704, and it's giving Informational 💅 Its authors are N. Haller from Bell Communications Research and R. Atkinson from the Naval Research Laboratory. It was published in October 1994 by the Network Working Group. There's no Obsoletes or Updates line in its header, so it doesn't replace or change any other RFC 🦋

Status of This Memo 📜

This document is here to give information to the Internet community 🌸 It does not specify an Internet standard of any kind, and distribution of this memo is unlimited ✨

1. Introduction ✨

Okay, authentication needs are wildly different depending on what a system is for, who can reach it, and how it's connected to the network 💖 This document covers a range of authentication technologies and gives protocol developers some tips on which kinds of authentication could fit which kinds of protocols and applications on the Internet 🧚 The hope is that it's useful info for anyone in the Internet community who wants it 🫶

Passwords can be captured by passive attack, and that's why they aren't strong enough for today's Internet [CERT94] 😭 And honestly? There's a LOT of evidence that both passive and active attacks happen all the time on the Internet [Bellovin89, Bellovin92, Bellovin93, CB94, Stoll90] 💀 The authors believe that lots of Internet protocols should have stronger authentication, so they're at least protected from passive attacks 🛡️ Being secure against active attack is clearly a must-have for internetworking protocols 👑

There are a bunch of dimensions to this internetwork authentication problem. To keep things brief and readable, this document only covers some of them 🙈 Still, a protocol designer should think about whether authentication is between machines or between a human and a machine, whether it's local only or spread across a network, how strong the mechanism is, and how the keys get managed 🔥

2. Definition of Terms 📖

This section gives quick definitions for some of the terms used in this paper, so you can follow the suggestions 🎀 Other references might use slightly different terms and definitions, because the security community hasn't fully agreed on every definition yet 🤷‍♀️ The definitions here are focused on what this particular document talks about 💜

• Active Attack: An attempt to improperly modify data, gain authentication, or gain authorization by inserting false packets into the data stream or by modifying packets transiting the data stream. (See passive attacks and replay attacks.) 😈
• Asymmetric Cryptography: An encryption system that uses different keys for encryption and decryption. The two keys have an intrinsic mathematical relationship to each other. Also called Public~Key~Cryptography. (See Symmetric Cryptography) 🔑
• Authentication: The verification of the identity of the source of information. 🪪
• Authorization: The granting of access rights based on an authenticated identity. 🎟️
• Confidentiality: The protection of information so that someone not authorized to access the information cannot read it, even though the unauthorized person might see the information's container (e.g., computer file or network packet). 🤫
• Encryption: A mechanism often used to provide confidentiality. 🔒
• Integrity: The protection of information from unauthorized modification. 🧱
• Key Certificate: A data structure consisting of a public key, the identity of the person, system, or role associated with that key, and information authenticating both the key and the association between that identity and that public key. The keys used by PEM are one example of a key certificate [Kent93]. 📜✨
• Passive Attack: An attack on an authentication system that inserts no data into the stream, but instead relies on being able to passively monitor information being sent between other parties. This information could be used at a later time in what appears to be a valid session. (See active attack and replay attack.) 👀
• Plain-text: Unencrypted text. 📝
• Replay Attack: An attack on an authentication system by recording and replaying previously sent valid messages (or parts of messages). Any constant authentication information, such as a password or electronically transmitted biometric data, can be recorded and used later to forge messages that appear to be authentic. 🔁😬
• Symmetric Cryptography: An encryption system that uses the same key for encryption and decryption. Sometimes referred to as Secret~Key~Cryptography. 🗝️

3. Authentication Technologies 🔑

Authentication comes in lots of classes, from no authentication at all up to very strong authentication 🌈 Different mechanisms fit different kinds of authentication problems, so this isn't a strict ladder where each step beats the one below it 🪜

3.1 No Authentication 🙈

For completeness, the simplest authentication system is not having any 🫠 A non-networked PC in a private (secure) location is one place where no authentication is fine. Another is a stand-alone public workstation, like the "mail reading" workstations some conferences set up, where the data isn't sensitive to disclosure or modification 🧋

3.2 Authentication Mechanisms Vulnerable to Passive Attacks 👂

The simple password check is by far the most common form of authentication, no cap 💯 Simple checks come in lots of forms. The key might be a password the user memorizes, a physical or electronic item the user carries, or a unique biological feature 🧬 These systems are called "disclosing" because if the key goes over a network, it's exposed to eavesdroppers 😱 There have been widespread reports of successful passive attacks on the current Internet, where already compromised machines were used to launch passive attacks against more machines [CERT94] 🚨 Disclosing mechanisms are vulnerable to replay attacks too 🔁 Access keys might be stored on the target system, so one breach in system security could give access to every password 💀 On the other hand, as on most systems, the data stored on the system can be enough to verify passwords but not enough to generate them 🛡️

3.3 Authentication Mechanisms Vulnerable to Active Attacks 🧩

Non-disclosing password systems were designed to stop replay attacks, and the vibes are immaculate ✨ Several systems have been invented to generate non-disclosing passwords. For example, the SecurID Card from Security Dynamics uses synchronized clocks for its authentication info. The card makes a visual display, so the person trying to authenticate has to physically have it 💳 The S/Key (TM) authentication system, developed at Bellcore, generates multiple single-use passwords from a single secret key [Haller94] 🔐 It doesn't use a physical token, so it's also suitable for machine-to-machine authentication 🤖 There are also challenge-response systems, where a device or computer program makes a verifiable response from a non-repeating challenge 🎯 S/Key authentication doesn't need the user's secret key to be stored, which is a big win when you're dealing with untrustworthy computing systems 🙌 In its current form, though, S/Key is vulnerable to a dictionary attack on the secret password (pass phrase), which might have been poorly chosen 😬 The Point-to-Point Protocol's CHAP challenge-response system is non-disclosing, but it's only useful locally [LS92, Simpson93] 📡 These systems differ in how sensitive the information stored on the authenticating host is, and so they differ in the security requirements that have to be placed on that host 🏠

3.4 Authentication Mechanisms Not Vulnerable to Active Attacks 🦾

Networked computing environments are growing, and that's why we need stronger authentication 📈 On open networks, lots of users can get access to any information flowing over the network. With extra effort, a user can also send information that looks like it came from someone else 👻

More powerful authentication systems use the computing power of the two authenticating parties 🧠 Authentication can be unidirectional, like authenticating users to a host computer system. Or it can be mutual, in which case the entity logging in is also assured of the host's identity 🤝 Some systems use cryptographic techniques and establish a shared secret (e.g., session key) as part of the authentication process, and that secret can be used for further exchanges 🗝️ For example, after authentication is complete, a user might get an authorization ticket that can be used to access other services without authenticating again 🎫 These systems might also provide confidentiality (using encryption) over insecure networks when it's needed 🔒✨

4. CRYPTOGRAPHY 🔐✨

Okay so cryptographic mechanisms are literally everywhere in computer networks and internetworks 😭 They're used to provide authentication, either with or without confidentiality. There are two basic kinds of cryptography, and we're gonna go through both of them here 🫶 The big recurring problem (lowkey the biggest 💀) is how to securely distribute keys to the communicating parties. Key distribution gets its own spotlight in Section 6 of this document, so stay tuned 🦋

---

4.1 Symmetric Cryptography 💜

Symmetric Cryptography covers all the systems that use the same key for encryption and decryption. So if someone improperly gets their hands on the key, they can both decrypt and read the data encrypted with it, and also encrypt false data and make it look legit 😱 If an unwanted third party knows the key, the confidentiality of the system is fully compromised, no cap.

So the keys have to be distributed securely, either by courier or by a key distribution protocol. The best known one is maybe the protocol proposed by Needham and Schroeder [NS78, NS87] 🍓 The super popular Data Encryption Standard (DES) algorithm, which got standardized to protect unclassified civilian US Government information, is maybe the most famous symmetric encryption algorithm around [NBS77] 🎀

Now let's talk about the Kerberos (TM) Authentication Service 👑 It's a well-known system for handling insecure open networks as part of a computing environment, and it was developed as part of Project Athena at MIT [SNS88, BM91, KN93]. Kerberos runs on Data Encryption Standard (DES) symmetric key encryption, and it uses a trusted (third party) host that knows the secret keys of all users and services. Because of that, it can generate credentials that users and servers use to prove their identities to other systems 🪄 Like any distributed authentication scheme, these credentials will be believed by any computer inside the local administrative domain or realm 🏰

🚨 So if a user's password gets disclosed, an attacker could masquerade as that user on any system that trusts Kerberos. Since the Kerberos server knows all the secret keys, it has to be physically secure 🔒

Kerberos session keys can be used to get confidentiality between any entities that trust the key server 💖

---

4.2 Asymmetric Cryptography 🌈

Okay plot twist: in the late 1970s, a major breakthrough in cryptology made Asymmetric Cryptography available 🤯 It's different from Symmetric Cryptography because different keys get used for encryption and decryption. That greatly simplifies the key distribution problem, which is honestly iconic 👑 The best known asymmetric system is based on work by Rivest, Shamir, and Adleman, and people often call it "RSA" after the authors' initials [RSA78] 🧚

SPX is an experimental system that overcomes the limitations of Kerberos' trusted key distribution center by using RSA Public Key Cryptography [TA91] 🦋 It assumes a global hierarchy of certifying authorities, with at least one of them trusted by each party. Its digital signatures are a token encrypted in the signing entity's private key, and they get validated using the matching public key. The public keys are believed to be correct because they come with a signature from the trusted certification authority. Critical parts of the authentication exchange get encrypted in the receivers' public keys, which prevents a replay attack 🙅‍♀️

---

4.3 Cryptographic Checksums 🎀

Cryptographic checksums are one of the most useful near-term tools for protocol designers ✨ A cryptographic checksum, also called a message integrity checksum (MIC), gives you data integrity and authentication, but not non-repudiation.

For example, Secure SNMP and SNMPv2 both calculate an MD5 cryptographic checksum over a shared secret item of data plus the information being authenticated [Rivest92, GM93] 🔐 This is how the data origin gets authenticated, and it's believed to be super hard to forge. It doesn't authenticate that the data itself is valid, only that it was actually sent by the party that claims to have sent it 💅

Cryptographic checksums can be used to provide relatively strong authentication, and they're especially handy for host-to-host communications 🫶 The main implementation headache with cryptographic checksums? Key distribution 😩

---

4.4 Digital Signatures 🌸

A digital signature is a cryptographic mechanism that's the electronic equivalent of a written signature ✍️ It serves to authenticate a piece of data as to the sender. A digital signature using asymmetric cryptography (Public Key) can also be useful in proving that data originated with a party, even if that party denies having sent it. This property is called non-repudiation 👑

A digital signature provides authentication without confidentiality, and it does that without some of the difficulties of full encryption ⭐ Digital signatures are being used with key certificates for Privacy Enhanced Mail [Linn93, Kent93, Balenson93, Kaliski93] 💜

5. USER TO HOST AUTHENTICATION ✨

Okay so there are a bunch of different ways to authenticate users to remote or networked hosts, and bestie, remote access comes with two kinds of hazard 😭. First, an intruder can eavesdrop on the network, grab user IDs and passwords, and replay them later (a replay attack). Even the shape of existing passwords gives a would-be intruder a head start on guessing new ones 👀.

Right now most systems send plain-text passwords over the network (usually with telnet or rlogin) from the user to the remote host [Anderson84, Kantor91]. That's giving no protection against replay attacks, where an eavesdropper picks up remote user IDs and remote passwords 💀.

5.1 Protection Against Passive Attack Is Necessary

Not having at least a non-disclosing password system means unlimited access is accidentally handed to anyone with physical access to the network 🚨. For example, anyone with physical access to the Ethernet cable can impersonate any user on that part of the network. So if you're sending plain-text passwords over Ethernet, your main security is the guard at the door (if there even is one) 🙃. The same problem shows up in other LAN technologies like Token-Ring or FDDI. In some small internal Local Area Networks (LANs) it might be okay to take that risk, but on the Internet it's an unacceptable risk [CERT94] 🛑.

The minimal defense against passive attacks, like eavesdropping, is to use a non-disclosing password system. It can run from a dumb terminal or a simple communications program (e.g., Crosstalk or PROCOMM) that emulates a dumb terminal on a PC class computer 💻. Using a stronger authentication system would definitely defend against passive attacks on remotely accessed systems, but then you can't use simple terminals anymore 😤. It's reasonable to expect that vendors of communications programs and non user-programmable terminals (like X-Terminals) would build in non-disclosing password or stronger authentication systems if they were standardized or if a big market showed up 🛍️.

One of the perks of Kerberos is that, if used properly, the user's password never leaves the user's workstation 🫶. Instead, it's used to decrypt the user's Kerberos tickets, which are themselves encrypted and get sent over the network to application servers 🎟️.

5.2 Perimeter Defenses as Short Term Tool

Perimeter defenses are getting more common, and they're iconic in their own way 🏰. The user first authenticates to something on an externally accessible part of the network (possibly a "firewall" host on the Internet) using a non-disclosing password system. Then the user uses a second system to authenticate to each host, or group of hosts, they want service from. This splits the problem into two more manageable situations 🧩.

Here's the tea though: there are several disadvantages, so it should be thought of as a short term solution ⏳. The gateway isn't transparent at the IP level, so it has to treat every service independently. Double authentication is, in general, difficult or impossible for computer-to-computer communication. End to end protocols, which are common on the connectionless Internet, could easily break 💔.

The perimeter defense has to be tight and complete. If it gets broken, the inner defenses tend to be too weak to stop a potential intruder 😱. For example, if disclosing passwords are used internally, those passwords can be learned by an external intruder through eavesdropping. If that intruder gets through the perimeter, the internal system is completely exposed.

Finally, a perimeter defense may be open to compromise by internal users looking for shortcuts 🙄.

A frequent form of perimeter defense is the application relay. Since these relays are protocol specific, the IP connectivity between hosts inside the perimeter and the outside world gets broken, and part of the power of the Internet is lost 😢.

The administrative advantage of a perimeter defense is that the number of machines on the perimeter (and so the number that are vulnerable to attack) is small 🎯. These machines can be carefully checked for security hazards, but it's difficult (or impossible) to guarantee the perimeter is leak-proof. Security gets complicated because the gateway machines have to pass some types of traffic, like electronic mail 📧. Other network services such as the Network Time Protocol (NTP) and the File Transfer Protocol (FTP) may also be desirable [Mills92, PR85, Bishop]. And the perimeter gateway has to pass the entire traffic load for its security domain without becoming a bottleneck 🚧.

5.3 Protection Against Active Attacks Highly Desirable

In the foreseeable future, stronger techniques will be required to protect against active attacks 🔥. Lots of corporate networks built on broadcast technology like Ethernet probably need these techniques. To defend against an active attack, or to provide privacy, it's necessary to use a protocol with session encryption (for example, Kerberos), or to use an authentication mechanism that protects against replay attacks, perhaps using time stamps ⏰.

In Kerberos, users get credentials from the Kerberos server and use them to authenticate for services on other computers on the network 🎫. The computing power of the local workstation can decrypt those credentials (using a key derived from the user-provided password) and store them until they're needed. If the security protocol relies on synchronized clocks, then NTPv3 might be useful, because it distributes time across a large number of computers and is one of the few existing Internet protocols that includes authentication mechanisms [Bishop, Mills92] ⌚.

Another approach to remotely accessible networks of computers is for all externally accessible machines to share a secret with the Kerberos KDC 🤫. In a sense, this makes these machines "servers" instead of general use workstations. That shared secret can then be used to encrypt all communication between the two machines, which lets the accessible workstation relay authentication information to the KDC in a secure way 🔐.

Finally, remotely accessible workstations could use asymmetric cryptographic technology to encrypt communications 🗝️. The workstation's public key would be published and well known to all clients. A user could use that public key to encrypt a simple password, and the remote system could decrypt it to authenticate the user without risking disclosure of the password while it's in transit. The limitation here is that this workstation-oriented security does not authenticate individual users, only individual workstations 🖥️. In some environments, for example government multi-level secure or compartmented mode workstations, user to user authentication and confidentiality are also needed 🕵️‍♀️.

6. KEY DISTRIBUTION & MANAGEMENT

The discussion so far has periodically mentioned keys, either for encryption or for authentication (e.g., as input to a digital signature function) 🔑. Key management is perhaps the hardest problem faced when trying to provide authentication in large internetworks 😵. So this section gives a very brief overview of key management technology that might be used.

The Needham & Schroeder protocol, which is used by Kerberos, relies on a central key server 🖧. In a large internetwork, there would need to be significant numbers of these key servers, at least one per administrative domain. There would also need to be mechanisms for separately administered key servers to cooperate in generating a session key for parties in different administrative domains. These aren't impossible problems, but this approach clearly involves significant infrastructure changes 🏗️.

Most public-key encryption algorithms are computationally expensive, so they aren't ideal for encrypting packets in a network 🐢. However, the asymmetric property makes them super useful for setting up and exchanging symmetric session keys ✨. In practice, the commercial sector probably uses asymmetric algorithms primarily for digital signatures and key exchange, but not for bulk data encryption. Both RSA and the Diffie-Hellman techniques can be used for this [DH76]. One advantage of asymmetric techniques is that the central key server can be eliminated 🙌. The difference in key management techniques is perhaps the primary difference between Kerberos and SPX.

Privacy Enhanced Mail has trusted key authorities use digital signatures to sign and authenticate the public keys of users [Kent93] 📜. The result of this operation is a key certificate, which contains the public key of some party and an authentication that the public key really does belong to that party. Key certificates can be distributed in many ways. One way might be to add them to existing directory services, for example by extending the existing Domain Name System to hold each host's key certificate in a new record type 🌐.

For multicast sessions, key management is harder, because the number of exchanges required by the widely used techniques is proportional to the number of participating parties 📈. So there's a serious scaling problem with current published multicast key management techniques 😩.

Finally, key management mechanisms described in the public literature have a long history of subtle flaws 🙈. There's ample evidence of this, even for well-known techniques like the Needham & Schroeder protocol [NS78, NS87]. In some cases, subtle flaws only became known after formal methods techniques were used in an attempt to verify the protocol 🔍. So it's highly desirable that key management mechanisms be kept separate from authentication or encryption mechanisms as much as possible. For example, it's probably better to have a key management protocol that's distinct from, and doesn't depend upon, another security protocol 💜.

7. AUTHENTICATION OF NETWORK SERVICES ✨

Okay so, besties, beyond users and hosts needing to prove who they are to each other 🫶, a lot of network services need authentication or could seriously benefit from it 💅. This section walks through some ways to do authentication in protocols that are mainly host to host 🖥️. Just like in the user to host situation, there are several techniques that might be considered 🎀.

The most common situation right now? No authentication support in the protocol at all 💀. Bellovin and friends have documented a bunch of cases where existing protocols can be used to attack a remote machine, because there is no authentication in those protocols [Bellovin89] 🙈.

Some protocols let passwords get disclosed and sent along with the protocol information 🔑. The original SNMP protocols did this, and a number of the routing protocols still do [Moy91, LR91, CFSD88]. It's a transitional aid that slightly boosts security, and it might be appropriate when there's little risk in having a completely insecure protocol 🍓.

There are so many protocols that need stronger authentication mechanisms 😭. For example, there was widespread concern that SNMP needed stronger authentication than it originally had. That led to the publication of the Secure SNMP protocols, which support optional authentication using a digital signature mechanism, and optional confidentiality using DES encryption 🔐. The digital signatures in Secure SNMP are based on appending a cryptographic checksum to the SNMP information. That checksum is computed using the MD5 algorithm and a secret shared between the communicating parties, so it is believed to be difficult to forge or invert 🧚.

Digital signature technology has evolved in recent years, and it should be considered for applications that require authentication but not confidentiality ✨. Digital signatures may use a single secret shared among two or more communicating parties, or they might be based on asymmetric encryption technology 🦋. The first option would require predetermined keys or a secure key distribution protocol, like the one devised by Needham and Schroeder. With asymmetric encryption, the public keys would need to be distributed in an authenticated manner 🌸. If a general key distribution mechanism were available, support for optional digital signatures could be added to most protocols with very little extra expense 👑. Each protocol could handle the key exchange and setup problem on its own, but that might make adding digital signature support way more complicated, and it would effectively discourage protocol designers from bothering 🙄.

For cases where both authentication and confidentiality are required on a host-to-host basis, session encryption could be used. That could be symmetric cryptography, asymmetric cryptography, or a combo of both 💜. Using asymmetric cryptography simplifies key management, which is iconic 🫧. Each host would encrypt the information while it's in transit between hosts, and the existing operating system mechanisms would provide protection within each host 🛡️.

In some cases, possibly including electronic mail, it might be desirable to provide the security properties within the application itself, in a manner that is truly user-to-user rather than host-to-host 💌. The Privacy Enhanced Mail (PEM) work is doing exactly this [Linn93, Kent93, Balenson93, Kaliski93]. The recent IETF work on Common Authentication Technology might make it easier to build a secure distributed or networked application through standard security programming interfaces [Linn93a] 🌈.

---

8. FUTURE DIRECTIONS 🔮

Systems are moving toward the cryptographically stronger authentication mechanisms we talked about earlier 🚀. This shift has two implications for future systems. In the near term, we can expect non-disclosing authentication systems to show up, and eventually public key crypto-systems will get way more widespread 🗝️. Session authentication, integrity, and privacy issues are becoming more and more important ⭐. As computer-to-computer communication becomes the main event, protocols that provide simple human interfaces will matter less 🤖. That doesn't mean human interfaces are unimportant, because they are very important 💖. It just means those interfaces are the responsibility of the applications, not the underlying protocol 🎀. Human interface design is beyond the scope of this memo 🙈.

Using public key crypto-systems for user-to-host authentication simplifies a lot of security issues, but unlike simple passwords, a public key cannot be memorized 🧠. As of this writing, public key sizes of at least 500 bits are commonly used in the commercial world 💼. Larger key sizes will likely be used in the future. So users might have to carry their private keys in some electrically readable form 🪪. Read-only storage, like a floppy disk or a magnetic stripe card, provides that, but it might require the user to trust their private keys to the reading device 😬. A smart card, which is a portable device containing both storage and program, might be preferable 💳. These devices have the potential to perform the authenticating operations without divulging the private key they contain 🔒. They can also interact with the user, requiring a simpler form of authentication to "unlock" the card 🔓.

Public key crypto-systems for host-to-host authentication don't seem to have the same key memorization problem as the user-to-host case does 🙌. A multiuser host can store its key(s) in space protected from users, which makes that problem disappear 🏰. Single user inherently insecure systems, like PCs and Macintoshes, remain difficult to handle, but the smart card approach should also work for them 🍎.

If you consider existing symmetric algorithms to be 1-key techniques, and existing asymmetric algorithms like RSA to be 2-key techniques, you might wonder whether N-key techniques will be developed in the future (i.e., for values of N larger than 2) 🤔. If N-key technology existed, it might be useful for creating scalable multicast key distribution protocols 🌐. There is work currently underway examining the possible use of the Core Based Tree (CBT) multicast routing technology to provide scalable multicast key distribution [BFC93] 🌳.

The implications here are clear 🫶. Strong cryptographic authentication is needed in the near future for many protocols. Public key technology should be used when it is practical and cost-effective 💅. In the short term, authentication mechanisms that are vulnerable to passive attack should be phased out in favour of stronger ones 🚫. Additional research is needed to develop improved key management technology and scalable multicast security mechanisms 🔬.

---

SECURITY CONSIDERATIONS 🚨

This entire memo is about security, since it discusses authentication technologies and needs. So yes, every single part of this is serious business 😤🔐.

---

ACKNOWLEDGEMENTS 🫶

This memo has benefited from review by and suggestions from the IETF's Common Authentication Technology (CAT) working group, chaired by John Linn, and from Marcus J. Ranum 🌸💜.

REFERENCES 📚

Okay bestie, this is the reading list 🤓📖 Every single one of these is cited earlier in the doc, so here they are in full, typos and all.

[Anderson84] Anderson, B., "TACACS User Identification Telnet Option", RFC 927, BBN, December 1984.

[Balenson93] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993.

[BFC93] Ballardie, A., Francis, P., and J. Crowcroft, "Core Based Trees (CBT) An Architecture for Scalable Inter-Domain Multicast Routing", Proceedings of ACM SIGCOMM93, ACM, San Franciso, CA, September 1993, pp. 85-95.

[Bellovin89] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989.

[Bellovin92] Bellovin, S., "There Be Dragons", Proceedings of the 3rd Usenix UNIX Security Symposium, Baltimore, MD, September 1992.

[Bellovin93] Bellovin, S., "Packets Found on an Internet", ACM Computer Communications Review, Vol. 23, No. 3, July 1993, pp. 26-31.

[BM91] Bellovin S., and M. Merritt, "Limitations of the Kerberos Authentication System", ACM Computer Communications Review, October 1990.

[Bishop] Bishop, M., "A Security Analysis of Version 2 of the Network Time Protocol NTP: A report to the Privacy & Security Research Group", Technical Report PCS-TR91-154, Department of Mathematics & Computer Science, Dartmouth College, Hanover, New Hampshire.

[CB94] Cheswick W., and S. Bellovin, "Chapter 10: An Evening with Berferd", Firewalls & Internet Security, Addison-Wesley, Reading, Massachusetts, 1994. ISBN 0-201-63357-4.

[CERT94] Computer Emergency Response Team, "Ongoing Network Monitoring Attacks", CERT Advisory CA-94:01, available by anonymous ftp from cert.sei.cmu.edu, 3 February 1994.

[CFSD88] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1067, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, Proteon, Inc., August 1988.

[DH76] Diffie W., and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Volume IT-11, November 1976, pp. 644-654.

[GM93] Galvin, J., and K. McCloghrie, "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993.

[Haller94] Haller, N., "The S/Key One-time Password System", Proceedings of the Symposium on Network & Distributed Systems Security, Internet Society, San Diego, CA, February 1994.

[Kaufman93] Kaufman, C., "Distributed Authentication Security Service (DASS)", RFC 1507, Digital Equipment Corporation, September 1993.

[Kaliski93] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, RSA Laboratories, February 1993.

[Kantor91] Kantor, B., "BSD Rlogin", RFC 1258, Univ. of Calif San Diego, September 1991.

[Kent93] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN, IAB IRTF PSRG, IETF PEM, February 1993.

[KN93] Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, Digital Equipment Corporation, USC/Information Sciences Institute, September 1993.

[Linn93] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.

[Linn93a] Linn, J., "Common Authentication Technology Overview", RFC 1511, Geer Zolot Associate, September 1993.

[LS92] Lloyd B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, L&A, Daydreamer, October 1992.

[LR91] Lougheed K., and Y. Rekhter, "A Border Gateway protocol 3 (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991.

[Mills92] Mills, D., "Network Time Protocol (Version 3) - Specification, Implementation, and Analysis", RFC 1305, UDEL, March 1992.

[NBS77] National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standards Publication 46, Government Printing Office, Washington, DC, 1977.

[NS78] Needham, R., and M. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978.

[NS87] Needham, R., and M. Schroeder, "Authentication Revisited", ACM Operating Systems Review, Vol. 21, No. 1, 1987.

[PR85] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.

[Moy91] Moy, J., "OSPF Routing Protocol, Version 2", RFC 1247, Proteon, Inc., July 1991.

[RSA78] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public Key Crypto-systems", Communications of the ACM, Vol. 21, No. 2, February 1978.

[Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992.

[Simpson93] Simpson, W., "The Point to Point Protocol", RFC 1548, Daydreamer, December 1993.

[SNS88] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: "An Authentication Service for Open Network Systems", USENIX Conference Proceedings, Dallas, Texas, February 1988.

[Stoll90] Stoll, C., "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage", Pocket Books, New York, NY, 1990.

[TA91] Tardo J., and K. Alagappan, "SPX: Global Authentication Using Public Key Certificates", Proceedings of the 1991 Symposium on Research in Security & Privacy, IEEE Computer Society, Los Amitos, California, 1991. pp.232-244.

---

AUTHORS' ADDRESSES 🎀

Meet the squad behind this doc 💜

Neil Haller
Bell Communications Research
445 South Street  -- MRE 2Q-280
Morristown, NJ 07962-1910

Phone: (201) 829-4478
EMail: nmh@thumper.bellcore.com

Randall Atkinson
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320

Phone: (DSN) 354-8590
EMail: atkinson@itd.nrl.navy.mil