⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1704.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 3 页
字号:
      it was actually sent by the party that claims to have 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.  A digital
      signature using asymmetric cryptography (Public Key) can also be
      useful in proving that data originated with a party even if the
      party denies having sent it; this property is called non-
      repudiation.  A digital signature provides authentication without



Haller & Atkinson                                               [Page 6]

RFC 1704               On Internet Authentication           October 1994


      confidentiality and without incurring some of the difficulties in
      full encryption.  Digital signatures are being used with key
      certificates for Privacy Enhanced Mail [Linn93, Kent93,
      Balenson93, Kaliski93].

5. 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.

   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., Crosstalk or PROCOMM) that emulates a dumb terminal
      on a PC class computer.  Using a stronger authentication system
      would certainly defend against passive 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 the user's
      workstation.  Instead they are used to decrypt the user's Kerberos
      tickets, which are themselves encrypted information which are sent



Haller & Atkinson                                               [Page 7]

RFC 1704               On Internet Authentication           October 1994


      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 8]

RFC 1704               On Internet Authentication           October 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 might be useful because it distributes time amongst 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.  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.



Haller & Atkinson                                               [Page 9]

RFC 1704               On Internet Authentication           October 1994


   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 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.

   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.







Haller & Atkinson                                              [Page 10]

RFC 1704               On Internet Authentication           October 1994


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 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



Haller & Atkinson                                              [Page 11]

RFC 1704               On Internet Authentication           October 1994


   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

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -