home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1704.txt < prev    next >
Text File  |  1996-09-11  |  43KB  |  956 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          N. Haller
  8. Request for Comments: 1704                  Bell Communications Research
  9. Category: Informational                                      R. Atkinson
  10.                                                Naval Research Laboratory
  11.                                                             October 1994
  12.  
  13.  
  14.                        On Internet Authentication
  15.  
  16. Status of this Memo
  17.  
  18.    This document provides information for the Internet community.  This
  19.    memo does not specify an Internet standard of any kind.  Distribution
  20.    of this memo is unlimited.
  21.  
  22. 1. INTRODUCTION
  23.  
  24.    The authentication requirements of computing systems and network
  25.    protocols vary greatly with their intended use, accessibility, and
  26.    their network connectivity.  This document describes a spectrum of
  27.    authentication technologies and provides suggestions to protocol
  28.    developers on what kinds of authentication might be suitable for some
  29.    kinds of protocols and applications used in the Internet.  It is
  30.    hoped that this document will provide useful information to
  31.    interested members of the Internet community.
  32.  
  33.    Passwords, which are vulnerable to passive attack, are not strong
  34.    enough to be appropriate in the current Internet [CERT94].  Further,
  35.    there is ample evidence that both passive and active attacks are not
  36.    uncommon in the current Internet [Bellovin89, Bellovin92, Bellovin93,
  37.    CB94, Stoll90].  The authors of this paper believe that many
  38.    protocols used in the Internet should have stronger authentication
  39.    mechanisms so that they are at least protected from passive attacks.
  40.    Support for authentication mechanisms secure against active attack is
  41.    clearly desirable in internetworking protocols.
  42.  
  43.    There are a number of dimensions to the internetwork authentication
  44.    problem and, in the interest of brevity and readability, this
  45.    document only describes some of them.  However, factors that a
  46.    protocol designer should consider include whether authentication is
  47.    between machines or between a human and a machine, whether the
  48.    authentication is local only or distributed across a network,
  49.    strength of the authentication mechanism, and how keys are managed.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Haller & Atkinson                                               [Page 1]
  59.  
  60. RFC 1704               On Internet Authentication           October 1994
  61.  
  62.  
  63. 2. DEFINITION OF TERMS
  64.  
  65.    This section briefly defines some of the terms used in this paper to
  66.    aid the reader in understanding these suggestions.  Other references
  67.    on this subject might be using slightly different terms and
  68.    definitions because the security community has not reached full
  69.    consensus on all definitions.  The definitions provided here are
  70.    specifically focused on the matters discussed in this particular
  71.    document.
  72.  
  73.    Active Attack:  An attempt to improperly modify data, gain
  74.           authentication, or gain authorization by inserting false
  75.           packets into the data stream or by modifying packets
  76.           transiting the data stream. (See passive attacks and replay
  77.           attacks.)
  78.  
  79.    Asymmetric Cryptography:  An encryption system that uses different
  80.           keys, for encryption and decryption.  The two keys have an
  81.           intrinsic mathematical relationship to each other.  Also
  82.           called Public~Key~Cryptography.  (See Symmetric Cryptography)
  83.  
  84.    Authentication:  The verification of the identity of the source of
  85.           information.
  86.  
  87.    Authorization:  The granting of access rights based on an
  88.           authenticated identity.
  89.  
  90.    Confidentiality: The protection of information so that someone not
  91.           authorized to access the information cannot read the
  92.           information even though the unauthorized person might see the
  93.           information's container (e.g., computer file or network
  94.           packet).
  95.  
  96.    Encryption: A mechanism often used to provide confidentiality.
  97.  
  98.    Integrity:  The protection of information from unauthorized
  99.           modification.
  100.  
  101.    Key Certificate: A data structure consisting of a public key, the
  102.           identity of the person, system, or role associated with that
  103.           key, and information authenticating both the key and the
  104.           association between that identity and that public key.  The
  105.           keys used by PEM are one example of a key certificate
  106.           [Kent93].
  107.  
  108.    Passive Attack:  An attack on an authentication system that inserts
  109.           no data into the stream, but instead relies on being able to
  110.           passively monitor information being sent between other
  111.  
  112.  
  113.  
  114. Haller & Atkinson                                               [Page 2]
  115.  
  116. RFC 1704               On Internet Authentication           October 1994
  117.  
  118.  
  119.           parties.  This information could be used a later time in what
  120.           appears to be a valid session.  (See active attack and replay
  121.           attack.)
  122.  
  123.    Plain-text:  Unencrypted text.
  124.  
  125.    Replay Attack:  An attack on an authentication system by recording
  126.           and replaying previously sent valid messages (or parts of
  127.           messages).  Any constant authentication information, such as a
  128.           password or electronically transmitted biometric data, can be
  129.           recorded and used later to forge messages that appear to be
  130.           authentic.
  131.  
  132.    Symmetric Cryptography: An encryption system that uses the same key
  133.           for encryption and decryption.  Sometimes referred to as
  134.           Secret~Key~Cryptography.
  135.  
  136. 3. AUTHENTICATION TECHNOLOGIES
  137.  
  138.    There are a number of different classes of authentication, ranging
  139.    from no authentication to very strong authentication.  Different
  140.    authentication mechanisms are appropriate for addressing different
  141.    kinds of authentication problems, so this is not a strict
  142.    hierarchical ordering.
  143.  
  144.    3.1 No Authentication
  145.  
  146.       For completeness, the simplest authentication system is not to
  147.       have any.  A non-networked PC in a private (secure) location is an
  148.       example of where no authentication is acceptable.  Another case is
  149.       a stand-alone public workstation, such as "mail reading"
  150.       workstations provided at some conferences,  on which the data is
  151.       not sensitive to disclosure or modification.
  152.  
  153.    3.2 Authentication Mechanisms Vulnerable to Passive Attacks
  154.  
  155.       The simple password check is by far the most common form of
  156.       authentication.  Simple authentication checks come in many forms:
  157.       the key may be a password memorized by the user, it may be a
  158.       physical or electronic item possessed by the user, or it may be a
  159.       unique biological feature.  Simple authentication systems are said
  160.       to be "disclosing" because if the key is transmitted over a
  161.       network it is disclosed to eavesdroppers.  There have been
  162.       widespread reports of successful passive attacks in the current
  163.       Internet using already compromised machines to engage in passive
  164.       attacks against additional machines [CERT94].  Disclosing
  165.       authentication mechanisms are vulnerable to replay attacks.
  166.       Access keys may be stored on the target system, in which case a
  167.  
  168.  
  169.  
  170. Haller & Atkinson                                               [Page 3]
  171.  
  172. RFC 1704               On Internet Authentication           October 1994
  173.  
  174.  
  175.       single breach in system security may gain access to all passwords.
  176.       Alternatively, as on most systems, the data stored on the system
  177.       can be enough to verify passwords but not to generate them.
  178.  
  179.    3.3 Authentication Mechanisms Vulnerable to Active Attacks
  180.  
  181.       Non-disclosing password systems have been designed to prevent
  182.       replay attacks.  Several systems have been invented to generate
  183.       non-disclosing passwords.  For example, the SecurID Card from
  184.       Security Dynamics uses synchronized clocks for authentication
  185.       information.  The card generates a visual display and thus must be
  186.       in the possession of the person seeking authentication.  The S/Key
  187.       (TM) authentication system developed at Bellcore generates
  188.       multiple single use passwords from a single secret key [Haller94].
  189.       It does not use a physical token, so it is also suitable for
  190.       machine-machine authentication.  In addition there are challenge-
  191.       response systems in which a device or computer program is used to
  192.       generate a verifiable response from a non-repeating challenge.
  193.       S/Key authentication does not require the storage of the user's
  194.       secret key, which is an advantage when dealing with current
  195.       untrustworthy computing systems.  In its current form, the S/Key
  196.       system is vulnerable to a dictionary attack on the secret password
  197.       (pass phrase) which might have been poorly chosen.  The Point-to-
  198.       Point Protocol's CHAP challenge-response system is non-disclosing
  199.       but only useful locally [LS92, Simpson93].  These systems vary in
  200.       the sensitivity of the information stored in the authenticating
  201.       host, and thus vary in the security requirements that must be
  202.       placed on that host.
  203.  
  204.    3.4 Authentication Mechanisms Not Vulnerable to Active Attacks
  205.  
  206.       The growing use of networked computing environments has led to the
  207.       need for stronger authentication.  In open networks, many users
  208.       can gain access to any information flowing over the network, and
  209.       with additional effort, a user can send information that appears
  210.       to come from another user.
  211.  
  212.       More powerful authentication systems make use of the computation
  213.       capability of the two authenticating parties.  Authentication may
  214.       be unidirectional, for example authenticating users to a host
  215.       computer system, or it may be mutual in which case the entity
  216.       logging in is assured of the identity of the host.  Some
  217.       authentication systems use cryptographic techniques and establish
  218.       (as a part of the authentication process) a shared secret (e.g.,
  219.       session key) that can be used for further exchanges.  For example,
  220.       a user, after completion of the authentication process, might be
  221.       granted an authorization ticket that can be used to obtain other
  222.       services without further authentication.  These authentication
  223.  
  224.  
  225.  
  226. Haller & Atkinson                                               [Page 4]
  227.  
  228. RFC 1704               On Internet Authentication           October 1994
  229.  
  230.  
  231.       systems might also provide confidentiality (using encryption) over
  232.       insecure networks when required.
  233.  
  234. 4. CRYPTOGRAPHY
  235.  
  236.    Cryptographic mechanisms are widely used to provide authentication,
  237.    either with or without confidentiality, in computer networks and
  238.    internetworks.  There are two basic kinds of cryptography and these
  239.    are described in this section.  A fundamental and recurring problem
  240.    with cryptographic mechanisms is how to securely distribute keys to
  241.    the communicating parties.  Key distribution is addressed in Section
  242.    6 of this document.
  243.  
  244.    4.1 Symmetric Cryptography
  245.  
  246.       Symmetric Cryptography includes all systems that use the same key
  247.       for encryption and decryption.  Thus if anyone improperly obtains
  248.       the key, they can both decrypt and read data encrypted using that
  249.       key and also encrypt false data and make it appear to be valid.
  250.       This means that knowledge of the key by an undesired third party
  251.       fully compromises the confidentiality of the system.  Therefore,
  252.       the keys used need to be distributed securely, either by courier
  253.       or perhaps by use of a key distribution protocol, of which the
  254.       best known is perhaps that proposed by Needham and Schroeder
  255.       [NS78, NS87].  The widely used Data Encryption Standard (DES)
  256.       algorithm, that has been standardized for use to protect
  257.       unclassified civilian US Government information, is perhaps the
  258.       best known symmetric encryption algorithm [NBS77].
  259.  
  260.       A well known system that addresses insecure open networks as a
  261.       part of a computing environment is the Kerberos (TM)
  262.       Authentication Service that was developed as part of Project
  263.       Athena at MIT [SNS88, BM91, KN93].  Kerberos is based on Data
  264.       Encryption Standard (DES) symmetric key encryption and uses a
  265.       trusted (third party) host that knows the secret keys of all users
  266.       and services, and thus can generate credentials that can be used
  267.       by users and servers to prove their identities to other systems.
  268.       As with any distributed authentication scheme, these credentials
  269.       will be believed by any computer within the local administrative
  270.       domain or realm.  Hence, if a user's password is disclosed, an
  271.       attacker would be able to masquerade as that user on any system
  272.       which trusts Kerberos.  As the Kerberos server knows all secret
  273.       keys, it must be physically secure.  Kerberos session keys can be
  274.       used to provide confidentiality between any entities that trust
  275.       the key server.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Haller & Atkinson                                               [Page 5]
  283.  
  284. RFC 1704               On Internet Authentication           October 1994
  285.  
  286.  
  287.    4.2 Asymmetric Cryptography
  288.  
  289.       In the late 1970s, a major breakthrough in cryptology led to the
  290.       availability of Asymmetric Cryptography.  This is different from
  291.       Symmetric Cryptography because different keys are used for
  292.       encryption and decryption, which greatly simplifies the key
  293.       distribution problem.  The best known asymmetric system is based
  294.       on work by Rivest, Shamir, and Adleman and is often referred to as
  295.       "RSA" after the authors' initials [RSA78].
  296.  
  297.       SPX is an experimental system that overcomes the limitations of
  298.       the trusted key distribution center of Kerberos by using RSA
  299.       Public Key Cryptography [TA91].  SPX assumes a global hierarchy of
  300.       certifying authorities at least one of which is trusted by each
  301.       party.  It uses digital signatures that consist of a token
  302.       encrypted in the private key of the signing entity and that are
  303.       validated using the appropriate public key.  The public keys are
  304.       believed to be correct as they are obtained under the signature of
  305.       the trusted certification authority.  Critical parts of the
  306.       authentication exchange are encrypted in the public keys of the
  307.       receivers, thus preventing a replay attack.
  308.  
  309.    4.3 Cryptographic Checksums
  310.  
  311.       Cryptographic checksums are one of the most useful near term tools
  312.       for protocol designers.  A cryptographic checksum or message
  313.       integrity checksum (MIC) provides data integrity and
  314.       authentication but not non-repudiation.  For example, Secure SNMP
  315.       and SNMPv2 both calculate a MD5 cryptographic checksum over a
  316.       shared secret item of data and the information to be authenticated
  317.       [Rivest92, GM93].  This serves to authenticate the data origin and
  318.       is believed to be very difficult to forge.  It does not
  319.       authenticate that the data being sent is itself valid, only that
  320.       it was actually sent by the party that claims to have sent it.
  321.       Crytographic checksums can be used to provide relatively strong
  322.       authentication and are particularly useful in host-to-host
  323.       communications.  The main implementation difficulty with
  324.       cryptographic checksums is key distribution.
  325.  
  326.    4.4 Digital Signatures
  327.  
  328.       A digital signature is a cryptographic mechanism which is the
  329.       electronic equivalent of a written signature.  It serves to
  330.       authenticate a piece of data as to the sender.  A digital
  331.       signature using asymmetric cryptography (Public Key) can also be
  332.       useful in proving that data originated with a party even if the
  333.       party denies having sent it; this property is called non-
  334.       repudiation.  A digital signature provides authentication without
  335.  
  336.  
  337.  
  338. Haller & Atkinson                                               [Page 6]
  339.  
  340. RFC 1704               On Internet Authentication           October 1994
  341.  
  342.  
  343.       confidentiality and without incurring some of the difficulties in
  344.       full encryption.  Digital signatures are being used with key
  345.       certificates for Privacy Enhanced Mail [Linn93, Kent93,
  346.       Balenson93, Kaliski93].
  347.  
  348. 5. USER TO HOST AUTHENTICATION
  349.  
  350.    There are a number of different approaches to authenticating users to
  351.    remote or networked hosts.  Two types of hazard are created by remote
  352.    or networked access: First an intruder can eavesdrop on the network
  353.    and obtain user ids and passwords for a later replay attack. Even the
  354.    form of existing passwords provides a potential intruder with a head
  355.    start in guessing new ones.
  356.  
  357.    Currently, most systems use plain-text disclosing passwords sent over
  358.    the network (typically using telnet or rlogin) from the user to the
  359.    remote host [Anderson84, Kantor91].  This system does not provide
  360.    adequate protection from replay attacks where an eavesdropper gains
  361.    remote user ids and remote passwords.
  362.  
  363.    5.1 Protection Against Passive Attack Is Necessary
  364.  
  365.       Failure to use at least a non-disclosing password system means
  366.       that unlimited access is unintentionally granted to anyone with
  367.       physical access to the network.  For example, anyone with physical
  368.       access to the Ethernet cable can impersonate any user on that
  369.       portion of the network.  Thus, when one has plain-text disclosing
  370.       passwords on an Ethernet, the primary security system is the guard
  371.       at the door (if any exist).  The same problem exists in other LAN
  372.       technologies such as Token-Ring or FDDI.  In some small internal
  373.       Local Area Networks (LANs) it may be acceptable to take this risk,
  374.       but it is an unacceptable risk in an Internet [CERT94].
  375.  
  376.       The minimal defense against passive attacks, such as
  377.       eavesdropping, is to use a non-disclosing password system.  Such a
  378.       system can be run from a dumb terminal or a simple communications
  379.       program (e.g., Crosstalk or PROCOMM) that emulates a dumb terminal
  380.       on a PC class computer.  Using a stronger authentication system
  381.       would certainly defend against passive attacks against remotely
  382.       accessed systems, but at the cost of not being able to use simple
  383.       terminals.  It is reasonable to expect that the vendors of
  384.       communications programs and non user-programmable terminals (such
  385.       as X-Terminals) would build in non-disclosing password or stronger
  386.       authentication systems if they were standardized or if a large
  387.       market were offered.  One of the advantages of Kerberos is that,
  388.       if used properly, the user's password never leaves the user's
  389.       workstation.  Instead they are used to decrypt the user's Kerberos
  390.       tickets, which are themselves encrypted information which are sent
  391.  
  392.  
  393.  
  394. Haller & Atkinson                                               [Page 7]
  395.  
  396. RFC 1704               On Internet Authentication           October 1994
  397.  
  398.  
  399.       over the network to application servers.
  400.  
  401.    5.2 Perimeter Defenses as Short Term Tool
  402.  
  403.       Perimeter defenses are becoming more common.  In these systems,
  404.       the user first authenticates to an entity on an externally
  405.       accessible portion of the network, possibly a "firewall" host on
  406.       the Internet, using a non-disclosing password system. The user
  407.       then uses a second system to authenticate to each host, or group
  408.       of hosts, from which service is desired.  This decouples the
  409.       problem into two more easily handled situations.
  410.  
  411.       There are several disadvantages to the perimeter defense, so it
  412.       should be thought of as a short term solution.  The gateway is not
  413.       transparent at the IP level, so it must treat every service
  414.       independently.  The use of  double authentication is, in general,
  415.       difficult or impossible for computer-computer communication.  End
  416.       to end protocols, which are common on the connectionless Internet,
  417.       could easily break.  The perimeter defense must be tight and
  418.       complete, because if it is broken, the inner defenses tend to be
  419.       too weak to stop a potential intruder.  For example, if disclosing
  420.       passwords are used internally, these passwords can be learned by
  421.       an external intruder (eavesdropping).  If that intruder is able to
  422.       penetrate the perimeter, the internal system is completely
  423.       exposed.  Finally, a perimeter defense may be open to compromise
  424.       by internal users looking for shortcuts.
  425.  
  426.       A frequent form of perimeter defense is the application relay.  As
  427.       these relays are protocol specific, the IP connectivity of the
  428.       hosts inside the perimeter with the outside world is broken and
  429.       part of the power of the Internet is lost.
  430.  
  431.       An administrative advantage of the perimeter defense is that the
  432.       number of machines that are on the perimeter and thus vulnerable
  433.       to attack is small.  These machines may be carefully checked for
  434.       security hazards, but it is difficult (or impossible) to guarantee
  435.       that the perimeter is leak-proof.  The security of a perimeter
  436.       defense is complicated as the gateway machines must pass some
  437.       types of traffic such as electronic mail.  Other network services
  438.       such as the Network Time Protocol (NTP) and the File Transfer
  439.       Protocol (FTP) may also be desirable [Mills92, PR85, Bishop].
  440.       Furthermore, the perimeter gateway system must be able to pass
  441.       without bottleneck the entire traffic load for its security
  442.       domain.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Haller & Atkinson                                               [Page 8]
  451.  
  452. RFC 1704               On Internet Authentication           October 1994
  453.  
  454.  
  455.    5.3 Protection Against Active Attacks Highly Desirable
  456.  
  457.       In the foreseeable future, the use of stronger techniques will be
  458.       required to protect against active attacks.  Many corporate
  459.       networks based on broadcast technology such as Ethernet probably
  460.       need such techniques.  To defend against an active attack, or to
  461.       provide privacy, it is necessary to use a protocol with session
  462.       encryption, for example Kerberos, or use an authentication
  463.       mechanism that protects against replay attacks, perhaps using time
  464.       stamps.  In Kerberos, users obtain credentials from the Kerberos
  465.       server and use them for authentication to obtain services from
  466.       other computers on the network.  The computing power of the local
  467.       workstation can be used to decrypt credentials (using a key
  468.       derived from the user-provided password) and store them until
  469.       needed.  If the security protocol relies on synchronized clocks,
  470.       then NTPv3 might be useful because it distributes time amongst a
  471.       large number of computers and is one of the few existing Internet
  472.       protocols that includes authentication mechanisms [Bishop,
  473.       Mills92].
  474.  
  475.       Another approach to remotely accessible networks of computers is
  476.       for all externally accessible machines to share a secret with the
  477.       Kerberos KDC.  In a sense, this makes these machines "servers"
  478.       instead of general use workstations.  This shared secret can then
  479.       be used encrypt all communication between the two machines
  480.       enabling the accessible workstation to relay authentication
  481.       information to the KDC in a secure way.
  482.  
  483.       Finally, workstations that are remotely accessible could use
  484.       asymmetric cryptographic technology to encrypt communications.
  485.       The workstation's public key would be published and well known to
  486.       all clients.  A user could use the public key to encrypt a simple
  487.       password and the remote system can decrypt the password to
  488.       authenticate the user without risking disclosure of the password
  489.       while it is in transit.  A limitation of this workstation-oriented
  490.       security is that it does not authenticate individual users only
  491.       individual workstations.  In some environments for example,
  492.       government multi-level secure or compartmented mode workstations,
  493.       user to user authentication and confidentiality is also needed.
  494.  
  495. 6. KEY DISTRIBUTION & MANAGEMENT
  496.  
  497.    The discussion thus far has periodically mentioned keys, either for
  498.    encryption or for authentication (e.g., as input to a digital
  499.    signature function).  Key management is perhaps the hardest problem
  500.    faced when seeking to provide authentication in large internetworks.
  501.    Hence this section provides a very brief overview of key management
  502.    technology that might be used.
  503.  
  504.  
  505.  
  506. Haller & Atkinson                                               [Page 9]
  507.  
  508. RFC 1704               On Internet Authentication           October 1994
  509.  
  510.  
  511.    The Needham & Schroeder protocol, which is used by Kerberos, relies
  512.    on a central key server.  In a large internetwork, there would need
  513.    to be significant numbers of these key servers, at least one key
  514.    server per administrative domain.  There would also need to be
  515.    mechanisms for separately administered key servers to cooperate in
  516.    generating a session key for parties in different administrative
  517.    domains.  These are not impossible problems, but this approach
  518.    clearly involves significant infrastructure changes.
  519.  
  520.    Most public-key encryption algorithms are computationally expensive
  521.    and so are not ideal for encrypting packets in a network.  However,
  522.    the asymmetric property makes them very useful for setup and exchange
  523.    of symmetric session keys.  In practice, the commercial sector
  524.    probably uses asymmetric algorithms primarily for digital signatures
  525.    and key exchange, but not for bulk data encryption.  Both RSA and the
  526.    Diffie-Hellman techniques can be used for this [DH76].  One advantage
  527.    of using asymmetric techniques is that the central key server can be
  528.    eliminated.  The difference in key management techniques is perhaps
  529.    the primary difference between Kerberos and SPX.  Privacy Enhanced
  530.    Mail has trusted key authorities use digital signatures to sign and
  531.    authenticate the public keys of users [Kent93].  The result of this
  532.    operation is a key certificates which contains the public key of some
  533.    party and authentication that the public key in fact belongs to that
  534.    party.  Key certificates can be distributed in many ways.  One way to
  535.    distribute key certificates might be to add them to existing
  536.    directory services, for example by extending the existing Domain Name
  537.    System to hold each host's the key certificate in a new record type.
  538.  
  539.    For multicast sessions, key management is harder because the number
  540.    of exchanges required by the widely used techniques is proportional
  541.    to the number of participating parties.  Thus there is a serious
  542.    scaling problem with current published multicast key management
  543.    techniques.
  544.  
  545.    Finally, key management mechanisms described in the public literature
  546.    have a long history of subtle flaws.  There is ample evidence of
  547.    this, even for well-known techniques such as the Needham & Schroeder
  548.    protocol [NS78, NS87].  In some cases, subtle flaws have only become
  549.    known after formal methods techniques were used in an attempt to
  550.    verify the protocol.  Hence, it is highly desirable that key
  551.    management mechanisms be kept separate from authentication or
  552.    encryption mechanisms as much as is possible.  For example, it is
  553.    probably better to have a key management protocol that is distinct
  554.    from and does not depend upon another security protocol.
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Haller & Atkinson                                              [Page 10]
  563.  
  564. RFC 1704               On Internet Authentication           October 1994
  565.  
  566.  
  567. 7. AUTHENTICATION OF NETWORK SERVICES
  568.  
  569.    In addition to needing to authenticate users and hosts to each other,
  570.    many network services need or could benefit from authentication.
  571.    This section describes some approaches to authentication in protocols
  572.    that are primarily host to host in orientation.  As in the user to
  573.    host authentication case, there are several techniques that might be
  574.    considered.
  575.  
  576.    The most common case at present is to not have any authentication
  577.    support in the protocol.  Bellovin and others have documented a
  578.    number of cases where existing protocols can be used to attack a
  579.    remote machine because there is no authentication in the protocols
  580.    [Bellovin89].
  581.  
  582.    Some protocols provide for disclosing passwords to be passed along
  583.    with the protocol information.  The original SNMP protocols used this
  584.    method and a number of the routing protocols continue to use this
  585.    method [Moy91, LR91, CFSD88].  This method is useful as a
  586.    transitional aid to slightly increase security and might be
  587.    appropriate when there is little risk in having a completely insecure
  588.    protocol.
  589.  
  590.    There are many protocols that need to support stronger authentication
  591.    mechanisms.  For example, there was widespread concern that SNMP
  592.    needed stronger authentication than it originally had.  This led to
  593.    the publication of the Secure SNMP protocols which support optional
  594.    authentication, using a digital signature mechanism, and optional
  595.    confidentiality, using DES encryption.  The digital signatures used
  596.    in Secure SNMP are based on appending a cryptographic checksum to the
  597.    SNMP information.  The cryptographic checksum is computed using the
  598.    MD5 algorithm and a secret shared between the communicating parties
  599.    so is believed to be difficult to forge or invert.
  600.  
  601.    Digital signature technology has evolved in recent years and should
  602.    be considered for applications requiring authentication but not
  603.    confidentiality.  Digital signatures may use a single secret shared
  604.    among two or more communicating parties or it might be based on
  605.    asymmetric encryption technology.  The former case would require the
  606.    use of predetermined keys or the use of a secure key distribution
  607.    protocol, such as that devised by Needham and Schroeder.  In the
  608.    latter case, the public keys would need to be distributed in an
  609.    authenticated manner.  If a general key distribution mechanism were
  610.    available, support for optional digital signatures could be added to
  611.    most protocols with little additional expense.  Each protocol could
  612.    address the key exchange and setup problem, but that might make
  613.    adding support for digital signatures more complicated and
  614.    effectively discourage protocol designers from adding digital
  615.  
  616.  
  617.  
  618. Haller & Atkinson                                              [Page 11]
  619.  
  620. RFC 1704               On Internet Authentication           October 1994
  621.  
  622.  
  623.    signature support.
  624.  
  625.    For cases where both authentication and confidentiality are required
  626.    on a host-to-host basis, session encryption could be employed using
  627.    symmetric cryptography, asymmetric cryptography, or a combination of
  628.    both.  Use of the asymmetric cryptography simplifies key management.
  629.    Each host would encrypt the information while in transit between
  630.    hosts and the existing operating system mechanisms would provide
  631.    protection within each host.
  632.  
  633.    In some cases, possibly including electronic mail, it might be
  634.    desirable to provide the security properties within the application
  635.    itself in a manner that was truly user-to-user rather than being
  636.    host-to-host.  The Privacy Enhanced Mail (PEM) work is employing this
  637.    approach [Linn93, Kent93, Balenson93, Kaliski93].  The recent IETF
  638.    work on Common Authentication Technology might make it easier to
  639.    implement a secure distributed or networked application through use
  640.    of standard security programming interfaces [Linn93a].
  641.  
  642. 8. FUTURE DIRECTIONS
  643.  
  644.    Systems are moving towards the cryptographically stronger
  645.    authentication mechanisms described earlier.  This move has two
  646.    implications for future systems.  We can expect to see the
  647.    introduction of non-disclosing authentication systems in the near
  648.    term and eventually see more widespread use of public key crypto-
  649.    systems.  Session authentication, integrity, and privacy issues are
  650.    growing in importance. As computer-to-computer communication becomes
  651.    more important, protocols that provide simple human interfaces will
  652.    become less important. This is not to say that human interfaces are
  653.    unimportant; they are very important.  It means that these interfaces
  654.    are the responsibility of the applications, not the underlying
  655.    protocol.  Human interface design is beyond the scope of this memo.
  656.  
  657.    The use of public key crypto-systems for user-to-host authentication
  658.    simplifies many security issues, but unlike simple passwords, a
  659.    public key cannot be memorized.  As of this writing, public key sizes
  660.    of at least 500 bits are commonly used in the commercial world.  It
  661.    is likely that larger key sizes will be used in the future.  Thus,
  662.    users might have to carry their private keys in some electrically
  663.    readable form.  The use of read-only storage, such as a floppy disk
  664.    or a magnetic stripe card provides such storage, but it might require
  665.    the user to trust their private keys to the reading device.  Use of a
  666.    smart card, a portable device containing both storage and program
  667.    might be preferable.  These devices have the potential to perform the
  668.    authenticating operations without divulging the private key they
  669.    contain.  They can also interact with the user requiring a simpler
  670.    form of authentication to "unlock" the card.
  671.  
  672.  
  673.  
  674. Haller & Atkinson                                              [Page 12]
  675.  
  676. RFC 1704               On Internet Authentication           October 1994
  677.  
  678.  
  679.    The use of public key crypto-systems for host-to-host authentication
  680.    appears not to have the same key memorization problem as the user-
  681.    to-host case does.  A multiuser host can store its key(s) in space
  682.    protected from users and obviate that problem.  Single user
  683.    inherently insecure systems, such as PCs and Macintoshes, remain
  684.    difficult to handle but the smart card approach should also work for
  685.    them.
  686.  
  687.    If one considers existing symmetric algorithms to be 1-key
  688.    techniques, and existing asymmetric algorithms such as RSA to be 2-
  689.    key techniques, one might wonder whether N-key techniques will be
  690.    developed in the future (i.e., for values of N larger than 2).  If
  691.    such N-key technology existed, it might be useful in creating
  692.    scalable multicast key distribution protocols.  There is work
  693.    currently underway examining the possible use of the Core Based Tree
  694.    (CBT) multicast routing technology to provide scalable multicast key
  695.    distribution [BFC93].
  696.  
  697.    The implications of this taxonomy are clear.  Strong cryptographic
  698.    authentication is needed in the near future for many protocols.
  699.    Public key technology should be used when it is practical and cost-
  700.    effective.  In the short term, authentication mechanisms vulnerable
  701.    to passive attack should be phased out in favour of stronger
  702.    authentication mechanisms.  Additional research is needed to develop
  703.    improved key management technology and scalable multicast security
  704.    mechanisms.
  705.  
  706. SECURITY CONSIDERATIONS
  707.  
  708.    This entire memo discusses Security Considerations in that it
  709.    discusses authentication technologies and needs.
  710.  
  711. ACKNOWLEDGEMENTS
  712.  
  713.    This memo has benefited from review by and suggestions from the
  714.    IETF's Common Authentication Technology (CAT) working group, chaired
  715.    by John Linn, and from Marcus J. Ranum.
  716.  
  717. REFERENCES
  718.  
  719.    [Anderson84]  Anderson, B., "TACACS User Identification Telnet
  720.    Option", RFC 927, BBN, December 1984.
  721.  
  722.    [Balenson93]  Balenson, D., "Privacy Enhancement for Internet
  723.    Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC
  724.    1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Haller & Atkinson                                              [Page 13]
  731.  
  732. RFC 1704               On Internet Authentication           October 1994
  733.  
  734.  
  735.    [BFC93]  Ballardie, A., Francis, P., and J. Crowcroft, "Core Based
  736.    Trees (CBT) An Architecture for Scalable Inter-Domain Multicast
  737.    Routing", Proceedings of ACM SIGCOMM93, ACM, San Franciso, CA,
  738.    September 1993, pp. 85-95.
  739.  
  740.    [Bellovin89]  Bellovin, S., "Security Problems in the TCP/IP Protocol
  741.    Suite", ACM Computer Communications Review, Vol. 19, No. 2, March
  742.    1989.
  743.  
  744.    [Bellovin92]  Bellovin, S., "There Be Dragons", Proceedings of the
  745.    3rd Usenix UNIX Security Symposium, Baltimore, MD, September 1992.
  746.  
  747.    [Bellovin93]  Bellovin, S., "Packets Found on an Internet", ACM
  748.    Computer Communications Review, Vol. 23, No. 3, July 1993, pp. 26-31.
  749.  
  750.    [BM91]  Bellovin S., and M. Merritt, "Limitations of the Kerberos
  751.    Authentication System", ACM Computer Communications Review, October
  752.    1990.
  753.  
  754.    [Bishop]  Bishop, M., "A Security Analysis of Version 2 of the
  755.    Network Time Protocol NTP: A report to the Privacy & Security
  756.    Research Group", Technical Report PCS-TR91-154, Department of
  757.    Mathematics & Computer Science, Dartmouth College, Hanover, New
  758.    Hampshire.
  759.  
  760.    [CB94]  Cheswick W., and S. Bellovin, "Chapter 10: An Evening with
  761.    Berferd", Firewalls & Internet Security, Addison-Wesley, Reading,
  762.    Massachusetts, 1994.  ISBN 0-201-63357-4.
  763.  
  764.    [CERT94]  Computer Emergency Response Team, "Ongoing Network
  765.    Monitoring Attacks", CERT Advisory CA-94:01, available by anonymous
  766.    ftp from cert.sei.cmu.edu, 3 February 1994.
  767.  
  768.    [CFSD88]  Case, J., Fedor, M., Schoffstall, M., and  J. Davin,
  769.    "Simple Network Management Protocol", RFC 1067, University of
  770.    Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic
  771.    Institute, Proteon, Inc., August 1988.
  772.  
  773.    [DH76]  Diffie W., and M. Hellman, "New Directions in Cryptography",
  774.    IEEE Transactions on Information Theory, Volume IT-11, November 1976,
  775.    pp. 644-654.
  776.  
  777.    [GM93]  Galvin, J., and K. McCloghrie, "Security Protocols for
  778.    Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC
  779.    1446, Trusted Information Systems, Hughes LAN Systems, April 1993.
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Haller & Atkinson                                              [Page 14]
  787.  
  788. RFC 1704               On Internet Authentication           October 1994
  789.  
  790.  
  791.    [Haller94]  Haller, N., "The S/Key One-time Password System",
  792.    Proceedings of the Symposium on Network & Distributed Systems
  793.    Security, Internet Society, San Diego, CA, February 1994.
  794.  
  795.    [Kaufman93]  Kaufman, C., "Distributed Authentication Security
  796.    Service (DASS)", RFC 1507, Digital Equipment Corporation, September
  797.    1993.
  798.  
  799.    [Kaliski93]  Kaliski, B., "Privacy Enhancement for Internet
  800.    Electronic Mail: Part IV: Key Certification and Related Services",
  801.    RFC 1424, RSA Laboratories, February 1993.
  802.  
  803.    [Kantor91]  Kantor, B., "BSD Rlogin", RFC 1258, Univ. of Calif San
  804.    Diego, September 1991.
  805.  
  806.    [Kent93]  Kent, S., "Privacy Enhancement for Internet Electronic
  807.    Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN, IAB
  808.    IRTF PSRG, IETF PEM, February 1993.
  809.  
  810.    [KN93]  Kohl, J., and C. Neuman, "The Kerberos Network Authentication
  811.    Service (V5)", RFC 1510, Digital Equipment Corporation,
  812.    USC/Information Sciences Institute, September 1993.
  813.  
  814.    [Linn93]  Linn, J., "Privacy Enhancement for Internet Electronic
  815.    Mail: Part I: Message Encryption and Authentication Procedures", RFC
  816.    1421, IAB IRTF PSRG, IETF PEM WG, February 1993.
  817.  
  818.    [Linn93a]  Linn, J., "Common Authentication Technology Overview", RFC
  819.    1511, Geer Zolot Associate, September 1993.
  820.  
  821.    [LS92]  Lloyd B., and W. Simpson, "PPP Authentication Protocols", RFC
  822.    1334, L&A, Daydreamer, October 1992.
  823.  
  824.    [LR91]  Lougheed K., and Y. Rekhter, "A Border Gateway protocol 3
  825.    (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM
  826.    Corp., October 1991.
  827.  
  828.    [Mills92]  Mills, D., "Network Time Protocol (Version 3) -
  829.    Specification, Implementation, and Analysis", RFC 1305, UDEL, March
  830.    1992.
  831.  
  832.    [NBS77]  National Bureau of Standards, "Data Encryption Standard",
  833.    Federal Information Processing Standards Publication 46, Government
  834.    Printing Office, Washington, DC, 1977.
  835.  
  836.    [NS78]  Needham, R., and M. Schroeder, "Using Encryption for
  837.    Authentication in Large Networks of Computers", Communications of the
  838.    ACM, Vol. 21, No. 12, December 1978.
  839.  
  840.  
  841.  
  842. Haller & Atkinson                                              [Page 15]
  843.  
  844. RFC 1704               On Internet Authentication           October 1994
  845.  
  846.  
  847.    [NS87]  Needham, R., and M. Schroeder, "Authentication Revisited",
  848.    ACM Operating Systems Review, Vol. 21, No. 1, 1987.
  849.  
  850.    [PR85]  Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
  851.    RFC 959, USC/Information Sciences Institute, October 1985.
  852.  
  853.    [Moy91]  Moy, J., "OSPF Routing Protocol, Version 2", RFC 1247,
  854.    Proteon, Inc., July 1991.
  855.  
  856.    [RSA78]  Rivest, R., Shamir, A., and L. Adleman, "A Method for
  857.    Obtaining Digital Signatures and Public Key Crypto-systems",
  858.    Communications of the ACM, Vol. 21, No. 2, February 1978.
  859.  
  860.    [Rivest92]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
  861.    MIT Laboratory for Computer Science and RSA Data Security, Inc.,
  862.    April 1992.
  863.  
  864.    [Simpson93]  Simpson, W., "The Point to Point Protocol", RFC 1548,
  865.    Daydreamer, December 1993.
  866.  
  867.    [SNS88]  Steiner, J., Neuman, C., and J. Schiller, "Kerberos: "An
  868.    Authentication Service for Open Network Systems", USENIX Conference
  869.    Proceedings, Dallas, Texas, February 1988.
  870.  
  871.    [Stoll90]  Stoll, C., "The Cuckoo's Egg: Tracking a Spy Through the
  872.    Maze of Computer Espionage", Pocket Books, New York, NY, 1990.
  873.  
  874.    [TA91]  Tardo J., and K. Alagappan, "SPX: Global Authentication Using
  875.    Public Key Certificates", Proceedings of the 1991 Symposium on
  876.    Research in Security & Privacy, IEEE Computer Society, Los Amitos,
  877.    California, 1991. pp.232-244.
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Haller & Atkinson                                              [Page 16]
  899.  
  900. RFC 1704               On Internet Authentication           October 1994
  901.  
  902.  
  903.    AUTHORS' ADDRESSES
  904.  
  905.    Neil Haller
  906.    Bell Communications Research
  907.    445 South Street  -- MRE 2Q-280
  908.    Morristown, NJ 07962-1910
  909.  
  910.    Phone: (201) 829-4478
  911.    EMail: nmh@thumper.bellcore.com
  912.  
  913.  
  914.    Randall Atkinson
  915.    Information Technology Division
  916.    Naval Research Laboratory
  917.    Washington, DC 20375-5320
  918.  
  919.    Phone: (DSN) 354-8590
  920.    EMail: atkinson@itd.nrl.navy.mil
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Haller & Atkinson                                              [Page 17]
  955.  
  956.