Zero-Knowledge Authentication

Another mechanism for secure authentication without passwords is zero-knowledge proofs. Networks that use this system have a client and a server that share what is in essence a very long sequence of digits. When the client connects to the server, the server queries the client about a set of digits in a small set of positions in the sequence. Because the number of digits in the sequence is very long, knowledge of a few digits by a sniffer is not sufficient. The server will query for a different set of positions each time the client connects.

This type of authentication is growing in popularity. You store the digit sequence held by the client on a credit card sized device or even in a ring worn by the user. No computer needs to be carried by a mobile user of this technique; only a few kilobytes of data storage.

RFC 1704 and RFC 1750 provide a good background in the principles of authentication and choosing good random numbers for use in the Internet community.

DESlogin 1.3 uses a challenge/response technique in conjunction with DES encryption for authentication. The latest version is available at ftp://ftp.uu.net/pub/security/des.

S/KEY by Neil Haller, a Bellcore research director, uses the challenge/response technique as well. S/Key is available at http://www.bellcore.com/SECURITY/skey.html where you can register to download a 30-day trial copy. S/Key has support for a variety of platforms, including Unix, Macintosh, and Windows, to generate the one-time password used as a response to a challenge. It also includes a replacement for /bin/login and the FTP daemon on the Unix host. Read the S/Key white paper at http://www.bellcore.com/SECURITY/skeywp.html.

RFC 1760 describes the system in technical detail. RFC 1938 proposes an Internet standard for a One-Time Password (OTP) system that evolved from the S/KEY system.

Employing Encryption for Entire Connection/Session

Public key cryptography can manage the authentication process to prevent password sniffing but is not practical for entire terminal sessions or TCP/IP connections. Public key cryptography is sometimes called asymmetric because different keys are used for encryption and decryption with no practical way to compute one key from the other key. Classical, symmetric techniques are much more computationally simple and practical for entire sessions. Just as public key cryptography can be used to authenticate a user, it can also be used to solve the key distribution problem of a symmetric encryption technique. Each sender receives the key electronically with the key encrypted by a public key technique. Thus, the key cannot be sniffed and used to decrypt the rest of the session.

One such mechanism employing the RSA public key encryption algorithm is the secure socket layer (SSL) that is being used on the web. Because the entire contents of a TCP connection are encrypted, many people believe that this system is good enough for sending credit card numbers over the Internet. You can use SSL as a layer on top of TCP for any server that might otherwise use raw TCP. To take advantage of session encryption on the web, you must have compatible encryption techniques being used on both the browser and the web server. Typically, encryption is only used for transmission of sensitive information such as passwords and credit card information, not routine HTML and image files. Any vendor doing business on the web should be quite clear about what encryption techniques the server supports and give a list of some of the browsers that support it so that a user will know in advance if the information being sent is protected by encryption. Conversely, a good browser should indicate if a response to a form on the web is not going to be encrypted so that vendors who do not provide a compatible encryption technique do not endanger their customers.

---

Warning:  Contrary to popular belief, cryptography is not a panacea that will cure all the security ills of the Internet. Since its inception, encryption has lulled its users into a false sense of security. The details of encryption algorithms and the number of bits used in keys are an interesting part of the Internet drama, but have distracted developers from paying attention to security fundamentals in all other aspects of the system. The security of any system is no better than its weakest link—which on the Internet has been demonstrated to be serious flaws in the operating systems or applications at one or both end points of a network connection. This chapter on spoofing should not lead you to believe that all will be well just because web servers and browsers support encryption.

---

Spoofing

Spoofing can occur at all layers of the IP system. The hardware layer, the data link layer, the IP layer, the transport layer, and the application layer are susceptible. All application layer protocols are at risk if the lower layers have been compromised. In this chapter, only the application layer protocols intimately linked to the IP protocol are discussed. This includes routing protocols and the DNS naming protocol. Other application layer protocols depend on these two protocols to provide basic services to almost all applications using the Internet.