new Inet Auth Guidelines draft
Ran Atkinson <atkinson@itd.nrl.navy.mil> Sun, 20 March 1994 20:56 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16497; 20 Mar 94 15:56 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16489; 20 Mar 94 15:56 EST
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa27673; 20 Mar 94 15:56 EST
Received: by bitsy.MIT.EDU id AA16765; Sun, 20 Mar 94 15:41:05 EST
Received: from itd.nrl.navy.mil by bitsy.MIT.EDU with SMTP id AA16757; Sun, 20 Mar 94 15:41:02 EST
Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14933; Sun, 20 Mar 94 15:40:53 EST
Date: Sun, 20 Mar 1994 15:40:53 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ran Atkinson <atkinson@itd.nrl.navy.mil>
Message-Id: <9403202040.AA14933@itd.nrl.navy.mil>
To: cat-ietf@bitsy.mit.edu
Subject: new Inet Auth Guidelines draft
I've sent the revised draft below off to the Internet Drafts folks for more general release. Neil and I think that this is probably ready to go out as an Informational RFC now (well, as soon as I fix a reference or two that was TBD). We'd really appreciate it if folks would take a look at it and point out any remaining problem areas and suggest any improvements that you all can make. Thanks, Ran atkinson@itd.nrl.navy.mil --- cut here --- INTERNET DRAFT Neil Haller, draft-haller-auth-requirements-03.txt Bellcore 20 March 1994 Randall Atkinson, Naval Research Laboratory Internet Authentication Guidelines 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 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. Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. The distribution of this Internet Draft is unlimited. It is filed as <draft-haller-auth-requirements-03.txt>, and it replaces an earlier Internet Draft "Internet Authentication Requirements". It expires on 20 August 1994. 1. ABSTRACT The authentication requirements of computing systems and network protocols vary greatly with their intended use, accessibility, and their network connectivity. This document describes a spectrum of authentication technologies and provides guidance to protocol developers on what kinds of authentication might be suitable for what kinds of protocols and applications used in the Internet. Disclosing passwords, which are vulnerable to passive attack, are not strong enough to be appropriate in the current Internet. [CERT94] Further, there is ample evidence that both passive and active attacks are not uncommon in the current Internet. [Bellovin89, Bellovin92, Bellovin93, Cheswick, Stoll90] The authors of this paper believe that many protocols used in the Internet should have stronger authentication mechanisms so that they are at least protected from passive attacks. Support for authentication mechanisms secure against active attack is clearly desirable in internetworking protocols. There are a number of dimensions to the internetwork authentication problem and, in the interest of brevity and readability, this document Haller & Atkinson [Page 1] Internet-Draft 20 March 1994 only describes some of them. However, factors that a protocol designer should consider include whether authentication is between machines or between a human and a machine, whether the authentication is local only or distributed across a network, strength of the authentication mechanism, and how keys are managed. 2. DEFINITION OF TERMS This section briefly defines some of the terms used in this paper to aid the reader in understanding the draft. 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 the information 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: TBD 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 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 Haller & Atkinson [Page 2] Internet-Draft 20 March 1994 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.0 AUTHENTICATION TECHNOLOGIES There are a number of different classes of authentication, ranging from no authentication to very strong authentication. Different authentication mechanisms are appropriate for addressing different kinds of authentication problems, so this is not a strict hierarchical ordering. The CCITT's Recommendation X.509 provides one definition of the difference between "strong" and "weak" authentication, but different user communities have different views on this. [X.509] 3.1 No Authentication For completeness, the simplest authentication system is not to have any. A non-networked PC in a private (secure) location is an example of where no authentication is acceptable. Another case is a stand-alone public workstation, such as "mail reading" workstations provided at some conferences, on which the data is not 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. Simple authentication checks come in many forms: the key may be a password memorized by the user, it may be a physical or electronic item possessed by the user, or it may be a unique biological feature. Simple authentication systems are said to be "disclosing" because if the key is transmitted over a network it is disclosed to eavesdroppers. There have been widespread reports of successful passive attacks in the current Internet using already compromised machines to engage in passive attacks against additional machines. [CERT94] Disclosing authentication mechanisms are vulnerable to replay attacks. Access keys may be stored on the target system, in which case a single breach in system security may gain access to all passwords. Alternatively, as on most systems, the data stored on the system can be enough to verify passwords but not to generate them. 3.3 Authentication Mechanisms Vulnerable to Active Attacks Non-disclosing password systems have been designed to prevent replay attacks. Several systems have been invented to generate non-disclosing passwords. For example, the SecurID Card from Security Dynamics uses synchronized clocks for authentication information. The card generates a visual display and thus must be in the possession of the person Haller & Atkinson [Page 3] Internet-Draft 20 March 1994 seeking authentication. The S/KEY authentication system developed at Bellcore generates multiple single use passwords from a single secret key. [Haller94] It does not use a physical token, so it is also suitable for machine-machine authentication. In addition there are challenge- response systems in which a device or computer program is used to generate a verifiable response from a non-repeating challenge. S/Key doesn't store the user's secret key anyplace, which is an advantage when dealing with current untrustworthy computing systems. However, in its current form, S/Key is vulnerable to a dictionary attack. The Point- to-Point Protocol's CHAP challenge-response system is non-disclosing but only useful locally. [LS92, Simpson93] These systems vary in the sensitivity of the information stored in the authenticating host, and thus vary in the security requirements that must be placed on that host. 3.4 Authentication Mechanisms Not Vulnerable to Active Attacks The growing use of networked computing environments has led to the need for stronger authentication. In open networks, many users can gain access to any information flowing over the network, and with additional effort, a user can send information that appears to come from another user. More powerful authentication systems make use of the computation capability of the two authenticating parties. Authentication may be unidirectional, for example authenticating users to a host computer system, or it may be mutual in which case the entity logging in is assured of the identity of the host. Some authentication systems use cryptographic techniques and establish (as a part of the authentication process) a shared secret (e.g. session key) that can be used for further exchanges. For example, a user, after completion of the authentication process, might be granted an authorization ticket that can be used to obtain other services without further authentication. These authentication systems might also provide confidentiality (using encryption) over insecure networks when required. 4.0 CRYPTOGRAPHY Cryptographic mechanisms are widely used to provide authentication, either with or without confidentiality, in computer networks and internetworks. There are two basic kinds of cryptography and these are described in this section. A fundamental and recurring problem with cryptographic mechanisms is how to securely distribute keys to the communicating parties. Key distribution is addressed in Section 6 of this document. 4.1 Symmetric Cryptography Symmetric Cryptography includes all systems that use the same key for encryption and decryption. Thus if anyone improperly obtains the key, they can both decrypt and read data encrypted using that key and also encrypt false data and make it appear to be valid. This means that knowledge of the key by an undesired third party fully compromises the confidentiality of the system. Therefore, the keys used need to be distributed securely, either by courier or perhaps by use of a key Haller & Atkinson [Page 4] Internet-Draft 20 March 1994 distribution protocol, of which the best known is perhaps that proposed by Needham and Schroeder. [NS78, NS87] The widely used Data Encryption Standard (DES) algorithm, that has been standardized for use to protect unclassified civilian US Government information, is perhaps the best known symmetric encryption algorithm. [NBS77] A well known system that addresses insecure open networks as a part of a computing environment is the Kerberos Authentication Service that was developed as part of Project Athena at MIT. [SNS88, BM91, KN93] Kerberos is based on Data Encryption Standard (DES) symmetric key encryption and uses a trusted (third party) host that knows the secret keys of all users and services, and thus can generate credentials that can be used by users and servers to prove their identities to other systems. As with any distributed authentication scheme, these credentials will be believed by any computer within the local administrative domain or realm. Hence, if a user's password is disclosed, an attacker would be able to masquerade as that user on any system which trusts Kerberos. As the Kerberos server knows all secret keys, it must be physically secure. Kerberos session keys can be used to provide confidentiality between any entities that trust the key server. 4.2 Asymmetric Cryptography In the late 1970s, a major breakthrough in cryptology led to the availability of Asymmetric Cryptography. This is different from Symmetric Cryptography because different keys are used for encryption and decryption, which greatly simplifies the key distribution problem. The best known asymmetric system is based on work by Rivest, Shamir, and Adleman and is often referred to as "RSA" after the authors' initials. [RSA78] SPX is an experimental system that overcomes the limitations of the trusted key distribution center of Kerberos by using RSA Public Key Cryptography. [TA91] SPX assumes a global hierarchy of certifying authorities at least one of which is trusted by each party. It uses digital signatures that consist of a token encrypted in the private key of the signing entity and that are validated using the appropriate public key. The public keys are known to be correct as they are obtained under the signature of the trusted certification authority. Critical parts of the authentication exchange are encrypted in the public keys of the receivers, thus preventing a replay attack. 4.3 Cryptographic Checksums Cryptographic checksums are one of the most useful near term tools for protocol designers. A cryptographic checksum or message integrity checksum (MIC) provides data integrity and authentication but not non- repudiation. For example, Secure SNMP and SNMPv2 both calculate a MD5 cryptographic checksum over a shared secret item of data and the information to be authenticated. [Rivest92, GM93] This serves to authenticate the data origin and is believed to be very difficult to forge. It does not authenticate that the data being sent is itself valid, only that it was actually sent by the party that claims to have Haller & Atkinson [Page 5] Internet-Draft 20 March 1994 sent it. Crytographic checksums can be used to provide relatively strong authentication and are particularly useful in host-to-host communications. The main implementation difficulty with cryptographic checksums is key distribution. 4.4 Digital Signatures A digital signature is a cryptographic mechanism which is the electronic equivalent of a written signature. It serves to authenticate a piece of data as to the sender. Digital signatures provide not only origin authentication and data integrity, but also non-repudiation. A digital signature using asymmetric cryptology (public key) can also be useful in proving that data in fact originated with a party even if the party denies having sent it, a property called non-repudiation. A digital signature provides authentication without confidentiality and without incurring some of the difficulties in full encryption. Digital signatures are being used with key certificates for Privacy Enhanced Mail. 5.0 USER TO HOST AUTHENTICATION There are a number of different approaches to authenticating users to remote or networked hosts. Two types of hazard are created by remote or networked access: First an intruder can eavesdrop on the network and obtain user ids and passwords for a later replay attack. Even the form of existing passwords provides a potential intruder with a head start in guessing new ones. Attacks based on eavesdropping are called "passive attacks". Second, an intruder can "take over" a connection after authentication; this is an example of an "active attack". Currently, most systems use plain-text disclosing passwords sent over the network (typically using telnet or rlogin) from the user to the remote host. [Anderson84 , Kantor91] This system does not provide adequate protection from replay attacks where an eavesdropper gains remote user ids and remote passwords. 5.1 Protection Against Passive Attack Is Necessary Failure to use at least a non-disclosing password system means that unlimited access is unintentionally granted to anyone with physical access to the network. For example, anyone with physical access to the Ethernet cable can impersonate any user on that portion of the network. Thus, when one has plain-text disclosing passwords on an Ethernet, the primary security system is the guard at the door (if any exist). The same problem exists in other LAN technologies such as Token-Ring or FDDI. In some small internal Local Area Networks (LANs) it may be acceptable to take this risk, but it is an unacceptable risk in an Internet.[CERT94] The minimal defense against passive attacks, such as eavesdropping, is to use a non-disclosing password system. Such a system can be run from a dumb terminal or a simple communications program (e.g. Versaterm or PROCOMM) that emulates a dumb terminal on a PC class computer. Using a stronger authentication system would certainly defend against passive Haller & Atkinson [Page 6] Internet-Draft 20 March 1994 attacks against remotely accessed systems, but at the cost of not being able to use simple terminals. It is reasonable to expect that the vendors of communications programs and non user-programmable terminals (such as X-Terminals) would build in non-disclosing password or stronger authentication systems if they were standardized or if a large market were offered. One of the advantages of Kerberos is that, if used properly, the user's password never leaves his/her workstation. Instead they are used to decrypt his/her Kerberos tickets, which are themselves encrypted information which are sent over the network to application servers. 5.2 Perimeter Defenses as Short Term Tool Perimeter defenses are becoming more common. In these systems, the user first authenticates to an entity on an externally accessible portion of the network, possibly a "firewall" host on the Internet, using a non- disclosing password system. The user then uses a second system to authenticate to each host, or group of hosts, from which service is desired. This decouples the problem into two more easily handled situations. There are several disadvantages to the perimeter defense, so it should be thought of as a short term solution. The gateway is not transparent at the IP level, so it must treat every service independently. The use of double authentication is, in general, difficult or impossible for computer-computer communication. End to end protocols, which are common on the connectionless Internet, could easily break. The perimeter defense must be tight and complete, because if it is broken, the inner defenses tend to be too weak to stop a potential intruder. For example, if disclosing passwords are used internally, these passwords can be learned by an external intruder (eavesdropping). If that intruder is able to penetrate 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. As these relays are protocol specific, the IP connectivity of the hosts inside the perimeter with the outside world is broken and part of the power of the Internet is lost. An administrative advantage of the perimeter defense is that the number of machines that are on the perimeter and thus vulnerable to attack is small. These machines may be carefully checked for security hazards, but it is difficult (or impossible) to guarantee that the perimeter is leak-proof. The security of a perimeter defense is complicated as the gateway machines must pass some types of traffic such as 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] Furthermore the perimeter gateway system must be able to pass without bottleneck the entire traffic load for its security domain. Haller & Atkinson [Page 7] Internet-Draft 20 March 1994 5.3 Protection Against Active Attacks Highly Desirable In the foreseeable future, the use of stronger techniques will be required to protect against active attacks. Many corporate networks based on broadcast technology such as Ethernet probably need such techniques. To defend against an active attack, or to provide privacy, it is necessary to use a protocol with session encryption, for example Kerberos, or use an authentication mechanism that protects against replay attacks, perhaps using time stamps. In Kerberos, users obtain credentials from the Kerberos server and use them for authentication to obtain services from other computers on the network. The computing power of the local workstation can be used to decrypt credentials (using a key derived from the user-provided password) and store them until needed. If the security protocol relies on synchronized clocks, then NTPv3 will be useful because it distributes time amongst a large number of computers and is one of the few existing Internet protocols that includes solid 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. This shared secret can then be used encrypt all communication between the two machines enabling the accessible workstation to relay authentication information to the KDC in a secure way. Finally, workstations that are remotely accessible 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 the public key to encrypt a simple password and the remote system can decrypt the password to authenticate the user without risking disclosure of the password while it is in transit. A limitation of this workstation-oriented security is that it 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 is also needed. 6. KEY DISTRIBUTION & MANAGEMENT The discussion thus 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 seeking to provide authentication in large internetworks. Hence this section provides 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 key server 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 are not impossible problems, but this approach clearly involves significant Haller & Atkinson [Page 8] Internet-Draft 20 March 1994 infrastructure changes. Most public-key encryption algorithms are computationally expensive and so are not ideal for encrypting packets in a network. However, the asymmetric property makes them very useful for setup and exchange of 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 using 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 certificates which contains the public key of some party and authentication that the public key in fact belongs to that party. Key certificates can be distributed in many ways. One way to distribute key certificates might be to add them to existing directory services, for example by extending the existing Domain Name System to hold each host's the 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. Thus there is a serious scaling problem with current published multicast key management techniques. If one considers existing symmetric algorithms to be 1-key techniques, and existing asymmetric algorithms such as RSA to be 2-key techniques, one might wonder whether N-key techniques will be developed in the future (i.e. for values of N larger than 2). If such N-key technology existed, it might be useful in creating scalable multicast key distribution protocols. Finally, key management mechanisms described in the public literature have a long history of subtle flaws. There is ample evidence of this, even for well-known techniques such as the Needham & Schroeder protocol [NS78, NS87]. In some cases, subtle flaws have only become known after formal methods techniques were used in an attempt to verify the protocol. Hence, it is highly desirable that key management mechanisms be kept separate from authentication or encryption mechanisms as much as is possible. For example, it is probably better to have a key management protocol that is distinct from and does not depend upon another security protocol. 7. AUTHENTICATION OF NETWORK SERVICES In addition to needing to authenticate users and hosts to each other, many network services need or could benefit from authentication. This section describes some approaches to authentication in protocols that are primarily host to host in orientation. As in the user to host authentication case, there are several techniques that might be considered. The most common case at present is to not have any authentication support in the protocol. Bellovin and others have documented a number Haller & Atkinson [Page 9] Internet-Draft 20 March 1994 of cases where existing protocols can be used to attack a remote machine because there is no authentication in the protocols. [Bellovin89] Some protocols provide for disclosing passwords to be passed along with the protocol information. The original SNMP protocols used this method and a number of the routing protocols continue to use this method. [Moy91, LR91, CFSD88] This method is useful as a transitional aid to slightly increase security and might be appropriate when there is little risk in having a completely insecure protocol. There are many protocols that need to support stronger authentication mechanisms. For example, there was widespread concern that SNMP needed stronger authentication than it originally had. This 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 used in Secure SNMP are based on appending a cryptographic checksum to the SNMP information. The cryptographic checksum is computed using the MD5 algorithm and a secret shared between the communicating parties so is believed to be difficult to forge or invert. Digital signature technology has evolved in recent years and should be considered for applications requiring authentication but not confidentiality. Digital signatures may use a single secret shared among two or more communicating parties or it might be based on asymmetric encryption technology. The former case would require the use of predetermined keys or the use of a secure key distribution protocol, such as that devised by Needham and Schroeder. In the latter case, 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 little additional expense. Each protocol could address the key exchange and setup problem, but that might make adding support for digital signatures more complicated and effectively discourage protocol designers from adding digital signature support. For cases where both authentication and confidentiality are required on a host-to-host basis, session encryption could be employed using symmetric cryptography, asymmetric cryptography, or a combination of both. Use of the asymmetric cryptography simplifies key management. Each host would encrypt the information while 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 was truly user-to-user rather than being host-to-host. The Privacy Enhanced Mail (PEM) work is employing this approach. [Linn93, Kent93, Balenson93, Kaliski93] The recent IETF work on Common Authentication Technology might make it easier to implement a secure distributed or networked application through use of standard security programming interfaces. [Linn93a] Haller & Atkinson [Page 10] Internet-Draft 20 March 1994 8. FUTURE DIRECTIONS Systems are moving towards the cryptographically stronger authentication mechanisms described earlier. This move has two implications for future systems. We can expect to see the introduction of non-disclosing authentication systems in the near term and eventually see more widespread use of public key crypto-systems. Session authentication, integrity, and privacy issues are growing in importance. As computer- to-computer communication becomes more important, protocols that provide simple human interfaces will become less important. This is not to say that human interfaces are unimportant; they are very important. It means that these interfaces are the responsibility of the applications, not the underlying protocol. Human interface design is beyond the scope of this memo. The use of public key crypto-systems for user-to-host authentication simplifies many 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. It is likely that larger key sizes will be used in the future. Thus, users might have to carry their private keys in some electrically readable form. The use of read-only storage, such as a floppy disk or a magnetic stripe card provides such storage, but it might require the user to trust their private keys to the reading device. Use of a smart card, 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. The use of public key crypto-systems for host-to-host authentication appears not 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 and obviate that problem. Single user inherently insecure systems, such as PCs and Macintoshes, remain difficult to handle but the smart card approach should also work for them. The implications of this taxonomy 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 vulnerable to passive attack should be phased out in favour of stronger authentication mechanisms. Additional research is needed to develop improved key management technology and scalable multicast security mechanisms. SECURITY CONSIDERATIONS The entire Internet Draft discusses Security Considerations in that it discusses authentication technologies and needs. Haller & Atkinson [Page 11] Internet-Draft 20 March 1994 ACKNOWLEDGEMENTS This draft has benefited from review by and suggestions from the IETF's Common Authentication Technology (CAT) working group which is chaired by John Linn, from Marcus J. Ranum, and from other members of the Internet community. REFERENCES [Anderson84] B. Anderson, TACACS User Identification Telnet Option, RFC-927, DDN Network Information Center, December 1984. [Balenson93] D. Balenson, Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, RFC-1423, DDN Network Information Center, February 1993. [Bellovin89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [Bellovin92] Steven M. Bellovin, "There Be Dragons", Proceedings of the 3rd Usenix UNIX Security Symposium, Baltimore, MD, September 1992. [Bellovin93] Steven M. Bellovin, "Packets Found on an Internet", ACM Computer Communications Review, Vol. 23, No. 3, July 1993, pp. 26-31. [BM91] Steven M. Bellovin & Michael Merritt, "Limitations of the Kerberos Authentication System", ACM Computer Communications Review, October 1990. [Bishop] Matt Bishop, "A Security Analysis of the NTP Protocol", unpublished draft report to the PSRG, available by anonymous ftp from louie.udel.edu. (A better reference is pending). [Cheswick] W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is Lured, Endured, & Studied", unpublished paper, available by anonymous ftp from research.att.com. [CCITT88] X.509 reference is TBD... [CERT94] Computer Emergency Response Team, "Ongoing Network Monitoring Attacks", CERT Advisory CA-94:01, 3 February 1994. [CFSD88] J. Case, M. Fedor, M. Schoffstall, & J. Davin, "Simple Network Management Protocol", RFC-1067, DDN Network Information Center, August 1988. [DH76] W. Diffie & M.E. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Volume IT-11, November 1976, pp. 644-654. [GM93] J. Galvin & K. McCloghrie, Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. Haller & Atkinson [Page 12] Internet-Draft 20 March 1994 [Haller94] N. Haller, "The S/Key One-time Password System", Proceedings of the Symposium on Network & Distributed Systems Security, Internet Society, February 1994, San Diego, CA. [Kaufman93] C. Kaufman, Distributed Authentication Security Service (DASS), RFC-1507, DDN Network Information Center, September 1993. [Kaliski93] B. Kaliski, Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services, RFC-1424, DDN Network Information Center, February 1993. [Kantor91] B. Kantor, BSD Rlogin, RFC-1258, DDN Network Information Center, September 1991. [Kent93] S. Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, RFC-1422, DDN Network Information Center, February 1993. [KN93] J.Kohl & C. Neuman, The Kerberos Network Authentication Service (V5), RFC-1510, DDN Network Information Center, September 1993. [Linn93] J. Linn, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, RFC-1421, DDN Network Information Center, February 1993. [Linn93a] J. Linn, Common Authentication Technology Overview, RFC-1511, DDN Network Information Center, September 1993. [LS92] B. Lloyd & W. Simpson, "PPP Authentication Protocols", RFC-1334, DDN Network Information Center, October 1992. [LR91] K. Lougheed & Y. Rekhter, "A Border Gateway protocol 3 (BGP-3)", RFC-1267, DDN Network Information Center, October 1991. [Mills92] D. Mills, Network Time Protocol (Version 3) Specification, Implementation, and Analysis, RFC-1305, DDN Network Information Center, March 1992. [NBS77] National Bureau of Standards, "Data Encryption Standard", _F_e_d_e_r_a_l _I_n_f_o_r_m_a_t_i_o_n _P_r_o_c_e_s_s_i_n_g _S_t_a_n_d_a_r_d_s _P_u_b_l_i_c_a_t_i_o_n _4_6, Government Printing Office, Washington, DC, 1977. [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978. [NS87] R.M. Needham & M.D. Schroeder, "Authentication Revisited", ACM Operating Systems Review, Vol. 21, No. 1, 1987. [PR85] J. Postel & J. Reynolds, File Transfer Protocol, RFC-959, DDN Network Information Center, October 1985. [Moy91] J. Moy, "OSPF Routing Protocol, Version 2", RFC-1247, DDN Network Information Center, July 1991. Haller & Atkinson [Page 13] Internet-Draft 20 March 1994 [RSA78] R.L. Rivest, A. Shamir, & L. Adleman, "A Method for Obtaining Digital Signatures and Public Key Crypto-systems", Communications of the ACM, Vol. 21, No. 2, February 1978. [Simpson93] W. Simpson, "The Point to Point Protocol", RFC-1548, DDN Network Information Center, December 1993. [SNS88] J.G. Steiner, C. Neuman, & J.I. Schiller, Kerberos: "An Authentication Service for Open Network Systems", USENIX Conference Proceedings, Dallas, Texas, February 1988. [Stoll90] Clifford Stoll, _T_h_e _C_u_c_k_o_o'_s _E_g_g: _T_r_a_c_k_i_n_g _a _S_p_y _T_h_r_o_u_g_h _t_h_e _M_a_z_e _o_f _C_o_m_p_u_t_e_r _E_s_p_i_o_n_a_g_e, Pocket Books, New York, NY, 1990. [TA91] J. Tardo & 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. EXPIRATION This Internet Draft expires on 20 August 1994. AUTHORS' ADDRESSES Neil Haller <nmh@thumper.bellcore.com> Bell Communications Research 445 South Street -- MRE 2Q-280 Morristown, NJ 07962-1910 Randall Atkinson <atkinson@itd.nrl.navy.mil> Information Technology Division Naval Research Laboratory Washington, DC 20375-5337 Haller & Atkinson [Page 14]
- Re: new Inet Auth Guidelines draft Ran Atkinson
- Re: new Inet Auth Guidelines draft Robert W. Shirey
- Re: new Inet Auth Guidelines draft Robert W. Shirey
- new Inet Auth Guidelines draft Ran Atkinson