RSS
|
||||||||||||||
  The Need for Host Authentication February 22, 1999
Although we have survived the past eight years without clear, strong host identifiers, the need for them grows more pressing every day. Eight years ago, little business was conducted on the Internet, but today's business processes are exposing requirements for limited trust among untrustworthy systems. Protocol hacks, such as tunneling and dynamic virtual address assignments, merely mask the demand for real, secure host identifiers. Careful reviews of the state of IP (both versions 4 and 6) by Internet and security experts, such as Dr. Steve Bellovin (www.research.att.com/~smb/), confirm the need for a host identity based on public key cryptography. Furthermore, we require a mechanism by which two hosts can actually work together with their cryptoidentities. The Loss of Identity At their inception in 1973, IP addresses were adequate, though insecure, host identifiers. This changed in 1990 with RFC 1171 (Point-to-Point Protocol). During this 17-year span, IP addresses could be counted on to identify a specific host. But with PPP, the IP address is assigned for the duration of the connection, and since the addresses allocated to a PPP server are reused, they have little meaning to other hosts on the Internet. Unfortunately, IP addresses have never been unique host identifiers. This problem is discussed in Dr. Douglas E. Comer's Internetworking With TCP/IP, Volume 1 where "dual-homed" hosts and the problems associated with them are explored. A dual-homed host has two network interfaces, each with its own IP address. Hosts have been typically dual-homed to increase access reliability or network performance. Although dual-homed hosts are actually the opposite of our problem--multiple identities--it directs efforts for host identities to the DNS. But DNS names or FQDNs (Fully Qualified Domain Names) have been even less reliable than IP addresses, since many hosts were never named (RFC 1439 contains some of the early naming problems) and far too many hosts have multiple names. Also, DNS is quite vulnerable to attack--it's actually a wonder that we've had so few DNS attacks to date. Unfortunately, again, FQDNs have evolved too far along the directory path to now function as host identities. That takes us back to IP addresses; even though we know they can be easily spoofed, we continue to rely on them as host identifiers. RFC 1533 (DHCP Options and BOOTP Vendor Extensions) and RFC 1597 (Address Allocation for Private Internets, updated by RFC 1918) delivered another blow to IP addresses by further eroding their uniqueness and therefore their value as host identifiers. Simply put: We must stop using IP addresses as host identities. An IP address, at this point, is at best an ephemeral interface label, barely sufficient even for use solely during one session. Our hosts are without identity. The Need for Host Identity The semantics in both Unix's and WinSock's API for TCP is "open a connection to this host"--this being the identifier for the host which is the IP address. Back when an IP address meant a host, and all host addresses were known to the OS, any one host could connect to any other host. Peer-to-peer processes like SMTP were built on these assumptions and semantics. But with IP telephony, a new peer-to-peer process, the lack of a host identity for mapping to a "phone number" generates the need for a rendezvous protocol. Rendezvous protocols make sense in multicast applications, but in unicast applications, they're simply one more area of complexity, creating an opportunity for errors. Adding layers of complexity to the trust model with every new technology can only result in mistakes to the trust model. Getting our trust model wrong at any level essentially means we have no trust model at all, leaving us open to attack. A completely trustworthy host identity would act as a foundation for all applications now and in the future. The Makings of a Host Identity Ever since the Internet architects foresaw the inadequacy of only 4 billion IP addresses (poorly used since they do routing along with identity), proposals for a new IP address scheme began to surface. All had one thing in common: the use of a simple string of bits as addresses, some fixed in length, some variable. The problem with these suggestions is that such addresses cannot function as host identifiers on today's untrustworthy Internet. A host identifier must be authenticated and any packet generated should be nonreputable, meaning that the sender cannot refute sending the packet. An authenticated host identifier ends up as a cryptographic function as shown in RFC 2274 (SNMPv3 security). SNMPv3 uses a secret key as the host/user identity and establishes packet authentication via an HMAC (hashed message authentication code) as stated in RFC 2104. This packet authentication lets the receiving SNMP system truly know with which host/ user it's communicating. The truly interesting feature in secure SNMPv3 is that this host identity never passes in the datastream. Each host in the SNMP community is hardwired with the other host identity's secret key. The SNMP identifier that corresponds with the secret key is "securityName" and is included in the authenticated message. But if you look in from outside the process, this identifier merely hints at the secret key needed to prove the authentication, and thus the identity of the SNMP sender. Cryptographic Choices Our SNMPv3 example uses a shared secret for each host/user. While this approach far outshines the use of IP addresses, it poses two problems: scaling and "trust leakage." With regard to scaling, shared secrets must be kept secret, meaning each host must have a secure file of them; they must never exist in a public store. Kerberos illustrates how keeping shared secrets in semi-public places is both complicated and does not scale well. Next is our trust leakage problem. Every host that communicates with any other host must possess the secret key needed to prove the authentication of packets received from the host with which it is communicating. In this approach, the key can be stolen, enabling another host to impersonate the secret key's true owner. These weaknesses have always tainted shared secrets. Thankfully, public key cryptography addresses both of these problems. Public keys can be stored anywhere, and since only the key-pair owner needs the private key, the risk of theft is greatly reduced--provided the private key storage is well-designed against theft. The downside to public key cryptography is the processing cost; some claim it is 100 times more CPU-intensive to use public key cryptography than it is to employ a comparable shared-secret-based system. But Moore's law teaches us that solutions perceived as too expensive for processing today will be cheap tomorrow; all we need do is co-opt some of the gains in CPUs for the network. Clearly, business processes will benefit from a reliable identity, and one should be built by host manufacturers into every central processor. Yet, while all our previous analysis points toward the use of public key cryptography, two factors may significantly delay implementation. First, the market value must be asserted by initial fielding of software-based solutions. Second, the current government position on cryptography creates a challenging engineering project: Provide authentication without encryption. Unfortunately, the technical community may be unable to solve this problem. As stated, secure SNMPv3 supplies an example for host identity. But SNMPv3 pursues speed at the cost of scalability. IPSec (IP Security)'s AH (Authentication Header) format is no better in this regard. Only when taken together with IKE (Internet Key Exchange) does it scale, but here, scalability is gained at the cost of circuit setup. If either of these technologies were to employ public key cryptography, it would become a model protocol conveying a secure host identity. It behooves us as architects to develop a secure host identity. The alternative is continued proliferation of host authentication techniques that will give attackers more ways to defeat authentication or to use host authentication as a denial of service attack. We need to look to the roots of the packet-switched model and design a packet that is trustworthy, without sacrificing scalability or performance. Let IP addresses be media- independent interface names and the routing hint. We can then add reliable IP identities so that the Internet can "trust but verify." Robert Moskowitz is a senior technical director at ICSA Inc.; he is also a member of the Internet Architecture Board. Send your comments on this column to him at rgm@htt-consult.com. |
Here
Here
An IP address is nothing more than a string of bits; our trust in it as a given host's identity is based on our trust of everyone configuring IP addresses. And as long as an IP address performs routing functions, it can never really be reworked into a trustworthy identity.
