4. Common Issues

4. Common Issues

Although each system's security requirements are unique, certain common requirements appear in a number of protocols. Often, when naive protocol designers are faced with these requirements, they choose an obvious but insecure solution even though better solutions are available. This section describes a number of issues seen in many protocols and the common pieces of security technology that may be useful in addressing them.

4.1. User Authentication

Essentially every system which wants to control access to its resources needs some way to authenticate users. A nearly uncountable number of such mechanisms have been designed for this purpose. The next several sections describe some of these techniques.

4.1.1. Username/Password

The most common access control mechanism is simple USERNAME/PASSWORD. The user provides a username and a reusable password to the host which he wishes to use. This system is vulnerable to a simple passive attack where the attacker sniffs the password off the wire and then initiates a new session, presenting the password. This threat can be mitigated by hosting the protocol over an encrypted connection such as TLS or IPSEC. Unprotected (plaintext) username/password systems are not acceptable in IETF standards.

4.1.2. Challenge Response and One Time Passwords

Systems which desire greater security than USERNAME/PASSWORD often employ either a ONE TIME PASSWORD [OTP] scheme or a CHALLENGE- RESPONSE. In a one time password scheme, the user is provided with a list of passwords, which must be used in sequence, one time each. (Often these passwords are generated from some secret key so the user can simply compute the next password in the sequence.) SecureID and DES Gold are variants of this scheme. In a challenge-response scheme, the host and the user share some secret (which often is represented as a password). In order to authenticate the user, the host presents the user with a (randomly generated) challenge. The user computes some function based on the challenge and the secret and provides that to the host, which verifies it. Often this computation is performed in a handheld device, such as a DES Gold card.

Both types of scheme provide protection against replay attack, but often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of passive attack): As previously mentioned, often the one-time password or response is computed from a shared secret. If the attacker knows the function being used, he can simply try all possible shared secrets until he finds one that produces the right output. This is made easier if the shared secret is a password, in which case he can mount a DICTIONARY ATTACK -- meaning that he tries a list of common words (or strings) rather than just random strings.

These systems are also often vulnerable to an active attack. Unless communication security is provided for the entire session, the attacker can simply wait until authentication has been performed and hijack the connection.

4.1.3. Shared Keys

CHALLENGE-RESPONSE type systems can be made secure against dictionary attack by using randomly generated shared keys instead of user- generated passwords. If the keys are sufficiently large then keysearch attacks become impractical. This approach works best when the keys are configured into the end nodes rather than memorized and typed in by users, since users have trouble remembering sufficiently long keys.

Like password-based systems, shared key systems suffer from management problems. Each pair of communicating parties must have their own agreed-upon key, which leads to there being a lot of keys.

4.1.4. Key Distribution Centers

One approach to solving the large number of keys problem is to use an online "trusted third party" that mediates between the authenticating parties. The trusted third party (generally called a a KEY DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with each party in the system. It first contacts the KDC which gives it a TICKET containing a randomly generated symmetric key encrypted under both peer's keys. Since only the proper peers can decrypt the symmetric key the ticket can be used to establish a trusted association. By far the most popular KDC system is Kerberos [KERBEROS].

4.1.5. Certificates

A simple approach is to have all users have CERTIFICATES [PKIX] which they then use to authenticate in some protocol-specific way, as in [TLS] or [S/MIME]. A certificate is a signed credential binding an entity's identity to its public key. The signer of a certificate is a CERTIFICATE AUTHORITY (CA), whose certificate may itself be signed by some superior CA. In order for this system to work, trust in one or more CAs must be established in an out-of-band fashion. Such CAs are referred to as TRUSTED ROOTS or ROOT CAS. The primary obstacle to this approach in client-server type systems is that it requires clients to have certificates, which can be a deployment problem.

4.1.6. Some Uncommon Systems

There are ways to do a better job than the schemes mentioned above, but they typically don't add much security unless communications security (at least message integrity) will be employed to secure the connection, because otherwise the attacker can merely hijack the connection after authentication has been performed. A number of protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap a

user's password into a shared key which can be used as input to a cryptographic protocol. One major obstacle to the deployment of these protocols has been that their Intellectual Property status is extremely unclear. Similarly, the user can authenticate using public key certificates (e.g., S-HTTP client authentication). Typically these methods are used as part of a more complete security protocol.

4.1.7. Host Authentication

Host authentication presents a special problem. Quite commonly, the addresses of services are presented using a DNS hostname, for instance as a URL [URL]. When requesting such a service, one has to ensure that the entity that one is talking to not only has a certificate but that that certificate corresponds to the expected identity of the server. The important thing to have is a secure binding between the certificate and the expected hostname.

For instance, it is usually not acceptable for the certificate to contain an identity in the form of an IP address if the request was for a given hostname. This does not provide end-to-end security because the hostname-IP mapping is not secure unless secure name resolution [DNSSEC] is being used. This is a particular problem when the hostname is presented at the application layer but the authentication is performed at some lower layer.

4.2. Generic Security Frameworks

Providing security functionality in a protocol can be difficult. In addition to the problem of choosing authentication and key establishment mechanisms, one needs to integrate it into a protocol. One response to this problem (embodied in IPsec and TLS) is to create a lower-level security protocol and then insist that new protocols be run over that protocol. Another approach that has recently become popular is to design generic application layer security frameworks. The idea is that you design a protocol that allows you to negotiate various security mechanisms in a pluggable fashion. Application protocol designers then arrange to carry the security protocol PDUs in their application protocol. Examples of such frameworks include GSS-API [GSS] and SASL [SASL].

The generic framework approach has a number of problems. First, it is highly susceptible to DOWNGRADE ATTACKS. In a downgrade attack, an active attacker tampers with the negotiation in order to force the parties to negotiate weaker protection than they otherwise would. It's possible to include an integrity check after the negotiation and key establishment have both completed, but the strength of this integrity check is necessarily limited to the weakest common algorithm. This problem exists with any negotiation approach, but

generic frameworks exacerbate it by encouraging the application protocol author to just specify the framework rather than think hard about the appropriate underlying mechanisms, particularly since the mechanisms can very widely in the degree of security offered.

Another problem is that it's not always obvious how the various security features in the framework interact with the application layer protocol. For instance, SASL can be used merely as an authentication framework -- in which case the SASL exchange occurs but the rest of the connection is unprotected, but can also negotiate traffic protection, such as via GSS, as a mechanism. Knowing under what circumstances traffic protection is optional and which it is required requires thinking about the threat model.

In general, authentication frameworks are most useful in situations where new protocols are being added to systems with pre-existing legacy authentication systems. A framework allows new installations to provide better authentication while not forcing existing sites completely redo their legacy authentication systems. When the security requirements of a system can be clearly identified and only a few forms of authentication are used, choosing a single security mechanism leads to greater simplicity and predictability. In situations where a framework is to be used, designers SHOULD carefully examine the framework's options and specify only the mechanisms that are appropriate for their particular threat model. If a framework is necessary, designers SHOULD choose one of the established ones instead of designing their own.

4.3. Non-repudiation

The naive approach to non-repudiation is simply to use public-key digital signatures over the content. The party who wishes to be bound (the SIGNING PARTY) digitally signs the message in question. The counterparty (the RELYING PARTY) can later point to the digital signature as proof that the signing party at one point agreed to the disputed message. Unfortunately, this approach is insufficient.

The easiest way for the signing party to repudiate the message is by claiming that his private key has been compromised and that some attacker (though not necessarily the relying party) signed the disputed message. In order to defend against this attack the relying party needs to demonstrate that the signing party's key had not been compromised at the time of the signature. This requires substantial infrastructure, including archival storage of certificate revocation information and timestamp servers to establish the time that the message was signed.

Additionally, the relying party might attempt to trick the signing party into signing one message while thinking he's signing another. This problem is particularly severe when the relying party controls the infrastructure that the signing party uses for signing, such as in kiosk situations. In many such situations the signing party's key is kept on a smartcard but the message to be signed is displayed by the relying party.

All of these complications make non-repudiation a difficult service to deploy in practice.

4.4. Authorization vs. Authentication

AUTHORIZATION is the process by which one determines whether an authenticated party has permission to access a particular resource or service. Although tightly bound, it is important to realize that authentication and authorization are two separate mechanisms. Perhaps because of this tight coupling, authentication is sometimes mistakenly thought to imply authorization. Authentication simply identifies a party, authorization defines whether they can perform a certain action.

Authorization necessarily relies on authentication, but authentication alone does not imply authorization. Rather, before granting permission to perform an action, the authorization mechanism must be consulted to determine whether that action is permitted.

4.4.1. Access Control Lists

One common form of authorization mechanism is an access control list (ACL), which lists users that are permitted access to a resource. Since assigning individual authorization permissions to each resource is tedious, resources are often hierarchically arranged so that the parent resource's ACL is inherited by child resources. This allows administrators to set top level policies and override them when necessary.

4.4.2. Certificate Based Systems

While the distinction between authentication and authorization is intuitive when using simple authentication mechanisms such as username and password (i.e., everyone understands the difference between the administrator account and a user account), with more complex authentication mechanisms the distinction is sometimes lost.

With certificates, for instance, presenting a valid signature does not imply authorization. The signature must be backed by a certificate chain that contains a trusted root, and that root must be

trusted in the given context. For instance, users who possess certificates issued by the Acme MIS CA may have different web access privileges than users who possess certificates issued by the Acme Accounting CA, even though both of these CAs are "trusted" by the Acme web server.

Mechanisms for enforcing these more complicated properties have not yet been completely explored. One approach is simply to attach policies to ACLs describing what sorts of certificates are trusted. Another approach is to carry that information with the certificate, either as a certificate extension/attribute [PKIX, SPKI] or as a separate "Attribute Certificate".

4.5. Providing Traffic Security

Securely designed protocols should provide some mechanism for securing (meaning integrity protecting, authenticating, and possibly encrypting) all sensitive traffic. One approach is to secure the protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this provides security which is most fitted to the protocol, it also requires considerable effort to get right.

Many protocols can be adequately secured using one of the available channel security systems. We'll discuss the two most common, IPsec [AH, ESP] and [TLS].

4.5.1. IPsec

The IPsec protocols (specifically, AH and ESP) can provide transmission security for all traffic between two hosts. The IPsec protocols support varying granularities of user identification, including for example "IP Subnet", "IP Address", "Fully Qualified Domain Name", and individual user ("Mailbox name"). These varying levels of identification are employed as inputs to access control facilities that are an intrinsic part of IPsec. However, a given IPsec implementation might not support all identity types. In particular, security gateways may not provide user-to-user authentication or have mechanisms to provide that authentication information to applications.

When AH or ESP is used, the application programmer might not need to do anything (if AH or ESP has been enabled system-wide) or might need to make specific software changes (e.g., adding specific setsockopt() calls) -- depending on the AH or ESP implementation being used. Unfortunately, APIs for controlling IPsec implementations are not yet standardized.

The primary obstacle to using IPsec to secure other protocols is deployment. The major use of IPsec at present is for VPN applications, especially for remote network access. Without extremely tight coordination between security administrators and application developers, VPN usage is not well suited to providing security services for individual applications since it is difficult for such applications to determine what security services have in fact been provided.

IPsec deployment in host-to-host environments has been slow. Unlike application security systems such as TLS, adding IPsec to a non-IPsec system generally involves changing the operating system, either by modifying with the kernel or installing new drivers. This is a substantially greater undertaking than simply installing a new application. However, recent versions of a number of commodity operating systems include IPsec stacks, so deployment is becoming easier.

In environments where IPsec is sure to be available, it represents a viable option for protecting application communications traffic. If the traffic to be protected is UDP, IPsec and application-specific object security are the only options. However, designers MUST NOT assume that IPsec will be available. A security policy for a generic application layer protocol SHOULD NOT simply state that IPsec must be used, unless there is some reason to believe that IPsec will be available in the intended deployment environment. In environments where IPsec may not be available and the traffic is solely TCP, TLS is the method of choice, since the application developer can easily ensure its presence by including a TLS implementation in his package.

In the special-case of IPv6, both AH and ESP are mandatory to implement. Hence, it is reasonable to assume that AH/ESP are already available for IPv6-only protocols or IPv6-only deployments. However, automatic key management (IKE) is not required to implement so protocol designers SHOULD not assume it will be present. [USEIPSEC] provides quite a bit of guidance on when IPsec is a good choice.

4.5.2. SSL/TLS

Currently, the most common approach is to use SSL or its successor TLS. They provide channel security for a TCP connection at the application level. That is, they run over TCP. SSL implementations typically provide a Berkeley Sockets-like interface for easy programming. The primary issue when designing a protocol solution around TLS is to differentiate between connections protected using TLS and those which are not.

The two primary approaches used have a separate well-known port for TLS connections (e.g., the HTTP over TLS port is 443) [HTTPTLS] or to have a mechanism for negotiating upward from the base protocol to TLS as in [UPGRADE] or [STARTTLS]. When an upward negotiation strategy is used, care must be taken to ensure that an attacker can not force a clear connection when both parties wish to use TLS.

Note that TLS depends upon a reliable protocol such as TCP or SCTP. This produces two notable difficulties. First, it cannot be used to secure datagram protocols that use UDP. Second, TLS is susceptible to IP layer attacks that IPsec is not. Typically, these attacks take some form of denial of service or connection assassination. For instance, an attacker might forge a TCP RST to shut down SSL connections. TLS has mechanisms to detect truncation attacks but these merely allow the victim to know he is being attacked and do not provide connection survivability in the face of such attacks. By contrast, if IPsec were being used, such a forged RST could be rejected without affecting the TCP connection. If forged RSTs or other such attacks on the TCP connection are a concern, then AH/ESP or the TCP MD5 option [TCPMD5] are the preferred choices.

4.5.2.1. Virtual Hosts

If the "separate ports" approach to TLS is used, then TLS will be negotiated before any application-layer traffic is sent. This can cause a problem with protocols that use virtual hosts, such as [HTTP], since the server does not know which certificate to offer the client during the TLS handshake. The TLS hostname extension [TLSEXT] can be used to solve this problem, although it is too new to have seen wide deployment.

4.5.2.2. Remote Authentication and TLS

One difficulty with using TLS is that the server is authenticated via a certificate. This can be inconvenient in environments where previously the only form of authentication was a password shared between client and server. It's tempting to use TLS without an authenticated server (i.e., with anonymous DH or a self-signed RSA certificate) and then authenticate via some challenge-response mechanism such as SASL with CRAM-MD5.

Unfortunately, this composition of SASL and TLS is less strong than one would expect. It's easy for an active attacker to hijack this connection. The client man-in-the-middles the SSL connection (remember we're not authenticating the server, which is what ordinarily prevents this attack) and then simply proxies the SASL handshake. From then on, it's as if the connection were in the

clear, at least as far as that attacker is concerned. In order to prevent this attack, the client needs to verify the server's certificate.

However, if the server is authenticated, challenge-response becomes less desirable. If you already have a hardened channel then simple passwords are fine. In fact, they're arguably superior to challenge-response since they do not require that the password be stored in the clear on the server. Thus, compromise of the key file with challenge-response systems is more serious than if simple passwords were used.

Note that if the client has a certificate than SSL-based client authentication can be used. To make this easier, SASL provides the EXTERNAL mechanism, whereby the SASL client can tell the server "examine the outer channel for my identity". Obviously, this is not subject to the layering attacks described above.

4.5.3. Remote Login

In some special cases it may be worth providing channel-level security directly in the application rather than using IPSEC or SSL/TLS. One such case is remote terminal security. Characters are typically delivered from client to server one character at a time. Since SSL/TLS and AH/ESP authenticate and encrypt every packet, this can mean a data expansion of 20-fold. The telnet encryption option [ENCOPT] prevents this expansion by foregoing message integrity.

When using remote terminal service, it's often desirable to securely perform other sorts of communications services. In addition to providing remote login, SSH [SSH] also provides secure port forwarding for arbitrary TCP ports, thus allowing users run arbitrary TCP-based applications over the SSH channel. Note that SSH Port Forwarding can be security issue if it is used improperly to circumvent firewall and improperly expose insecure internal applications to the outside world.

4.6. Denial of Service Attacks and Countermeasures

Denial of service attacks are all too frequently viewed as an fact of life. One problem is that an attacker can often choose from one of many denial of service attacks to inflict upon a victim, and because most of these attacks cannot be thwarted, common wisdom frequently assumes that there is no point protecting against one kind of denial of service attack when there are many other denial of service attacks that are possible but that cannot be prevented.

However, not all denial of service attacks are equal and more importantly, it is possible to design protocols so that denial of service attacks are made more difficult, if not impractical. Recent SYN flood attacks [TCPSYN] demonstrate both of these properties: SYN flood attacks are so easy, anonymous, and effective that they are more attractive to attackers than other attacks; and because the design of TCP enables this attack.

Because complete DoS protection is so difficult, security against DoS must be dealt with pragmatically. In particular, some attacks which would be desirable to defend against cannot be defended against economically. The goal should be to manage risk by defending against attacks with sufficiently high ratios of severity to cost of defense. Both severity of attack and cost of defense change as technology changes and therefore so does the set of attacks which should be defended against.

Authors of internet standards MUST describe which denial of service attacks their protocol is susceptible to. This description MUST include the reasons it was either unreasonable or out of scope to attempt to avoid these denial of service attacks.

4.6.1. Blind Denial of Service

BLIND denial of service attacks are particularly pernicious. With a blind attack the attacker has a significant advantage. If the attacker must be able to receive traffic from the victim, then he must either subvert the routing fabric or use his own IP address. Either provides an opportunity for the victim to track the attacker and/or filter out his traffic. With a blind attack the attacker can use forged IP addresses, making it extremely difficult for the victim to filter out his packets. The TCP SYN flood attack is an example of a blind attack. Designers should make every attempt possible to prevent blind denial of service attacks.

4.6.2. Distributed Denial of Service

Even more dangerous are DISTRIBUTED denial of service attacks (DDoS) [DDOS]. In a DDoS the attacker arranges for a number of machines to attack the target machine simultaneously. Usually this is accomplished by infecting a large number of machines with a program that allows remote initiation of attacks. The machines actually performing the attack are called ZOMBIEs and are likely owned by unsuspecting third parties in an entirely different location from the true attacker. DDoS attacks can be very hard to counter because the zombies often appear to be making legitimate protocol requests and

simply crowd out the real users. DDoS attacks can be difficult to thwart, but protocol designers are expected to be cognizant of these forms of attack while designing protocols.

4.6.3. Avoiding Denial of Service

There are two common approaches to making denial of service attacks more difficult:

4.6.3.1. Make your attacker do more work than you do

If an attacker consumes more of his resources than yours when launching an attack, attackers with fewer resources than you will be unable to launch effective attacks. One common technique is to require the attacker perform a time-intensive operation, such as a cryptographic operation. Note that an attacker can still mount a denial of service attack if he can muster substantially sufficient CPU power. For instance, this technique would not stop the distributed attacks described in [TCPSYN].

4.6.3.2. Make your attacker prove they can receive data from you

A blind attack can be subverted by forcing the attacker to prove that they can can receive data from the victim. A common technique is to require that the attacker reply using information that was gained earlier in the message exchange. If this countermeasure is used, the attacker must either use his own address (making him easy to track) or to forge an address which will be routed back along a path that traverses the host from which the attack is being launched.

Hosts on small subnets are thus useless to the attacker (at least in the context of a spoofing attack) because the attack can be traced back to a subnet (which should be sufficient for locating the attacker) so that anti-attack measures can be put into place (for instance, a boundary router can be configured to drop all traffic from that subnet). A common technique is to require that the attacker reply using information that was gained earlier in the message exchange.

4.6.4. Example: TCP SYN Floods

TCP/IP is vulnerable to SYN flood attacks (which are described in section 3.3.2) because of the design of the 3-way handshake. First, an attacker can force a victim to consume significant resources (in this case, memory) by sending a single packet. Second, because the attacker can perform this action without ever having received data from the victim, the attack can be performed anonymously (and therefore using a large number of forged source addresses).

4.6.5. Example: Photuris

[PHOTURIS] specifies an anti-clogging mechanism that prevents attacks on Photuris that resemble the SYN flood attack. Photuris employs a time-variant secret to generate a "cookie" which is returned to the attacker. This cookie must be returned in subsequent messages for the exchange to progress. The interesting feature is that this cookie can be regenerated by the victim later in the exchange, and thus no state need be retained by the victim until after the attacker has proven that he can receive packets from the victim.

4.7. Object vs. Channel Security

It's useful to make the conceptual distinction between object security and channel security. Object security refers to security measures which apply to entire data objects. Channel security measures provide a secure channel over which objects may be carried transparently but the channel has no special knowledge about object boundaries.

Consider the case of an email message. When it's carried over an IPSEC or TLS secured connection, the message is protected during transmission. However, it is unprotected in the receiver's mailbox, and in intermediate spool files along the way. Moreover, since mail servers generally run as a daemon, not a user, authentication of messages generally merely means authentication of the daemon not the user. Finally, since mail transport is hop-by-hop, even if the user authenticates to the first hop relay the authentication can't be safely verified by the receiver.

By contrast, when an email message is protected with S/MIME or OpenPGP, the entire message is encrypted and integrity protected until it is examined and decrypted by the recipient. It also provides strong authentication of the actual sender, as opposed to the machine the message came from. This is object security. Moreover, the receiver can prove the signed message's authenticity to a third party.

Note that the difference between object and channel security is a matter of perspective. Object security at one layer of the protocol stack often looks like channel security at the next layer up. So, from the perspective of the IP layer, each packet looks like an individually secured object. But from the perspective of a web client, IPSEC just provides a secure channel.

The distinction isn't always clear-cut. For example, S-HTTP provides object level security for a single HTTP transaction, but a web page typically consists of multiple HTTP transactions (the base page and

numerous inline images). Thus, from the perspective of the total web page, this looks rather more like channel security. Object security for a web page would consist of security for the transitive closure of the page and all its embedded content as a single unit.

4.8. Firewalls and Network Topology

It's common security practice in modern networks to partition the network into external and internal networks using a firewall. The internal network is then assumed to be secure and only limited security measures are used there. The internal portion of such a network is often called a WALLED GARDEN.

Internet protocol designers cannot safely assume that their protocols will be deployed in such an environment, for three reasons. First, protocols which were originally designed to be deployed in closed environments often are later deployed on the Internet, thus creating serious vulnerabilities.

Second, networks which appear to be topologically disconnected may not be. One reason may be that the network has been reconfigured to allow access by the outside world. Moreover, firewalls are increasingly passing generic application layer protocols such as [SOAP] or [HTTP]. Network protocols which are based on these generic protocols cannot in general assume that a firewall will protect them. Finally, one of the most serious security threats to systems is from insiders, not outsiders. Since insiders by definition have access to the internal network, topological protections such as firewalls will not protect them.