There are several types of ISAKMP protocol messages. They all have the same header format and a variable payload format. The header includes, among other information, the cookies used to prevent denial-of-service attacks, the type of the first payload in the message, and the exchange type. The payload format accommodates different types of messages that can be used in ISAKMP, such as nonce, hash, key exchange, certificate, or signature. A message can contain several payloads in a chain. Denial-of-service attacks are thwarted by using a special type of cookie, also called an anticlogging token (ACT). A cookie authenticates a protocol message and can be verified quickly. In this way, no denial-of-service attack can be launched by flooding a host with random cookies whose verification needs excessive CPU resources. An additional requirement is that the cookie be unique for each SA. This can be achieved by including the current date and time in the cookie. ISAKMP uses a method for generating cookies based on Photuris [16]. The method applies a cryptographic hash function (e.g., MD5) to hash the source and destination IP address, the source and destina- tion UDP ports, and a secret random value. The party generating the cookie is the only one that can verify it and, if the verification is positive, accept it. Unfortunately, ISAKMP cookies suffer from several vulnerabilities that may lead to denial-of-service attacks. The cookie vulnerabilities as well as several other design problems are described in [17]. An ISAKMP exchange type specifies the ordering of the ISAKMP mes- sages as well as the payload ordering within a message. Currently there are five exchange types defined in [14]: • The Base Exchange is used to combine authentication and key exchange, but it does not provide identity protection. Transport Layer Security 237 Initiator Responder Phase 1: ISAKMP SA ISAKMP module ISAKMP module API Security parameters Security parameters Phase 2: Protocol SA Protocol module Protocol module API Protocol Figure 13.9 ISAKMP concept. • The Identity Protection Exchange separates the key exchange infor- mation from the identity- and authentication-related information. It provides identity protection. • The Authentication Only Exchange allows only authentication- related information to be transmitted. It can be used if no key exchange is necessary. • The Aggressive Exchange makes it possible to transmit the SA, key exchange, and authentication-related information together. • The Informational Exchange serves as a one-way transmittal of information that can be used for security association management. As an example, IKE Main Mode in Section 12.3.2.1 is an instantiation of the ISAKMP Identity Protection Exchange. It is possible, however, to define new exchange types, such as IKE Quick Mode, also discussed in Chapter 12. An ISAKMP message consists of an ISAKMP header and one or more payloads. In addition, data attributes can be contained within payloads. Figure 12.6 in Section 12.3.2.1 shows the IKE Main Mode exchange. The first message sent from the initiator to the responder is denoted by 1 (mes- sage 1). Figure 13.10 shows the structure of this message. The ISAKMP header contains the initiator cookie; the responder cookie will be sent in the response. The Next Payload field indicates the type of the next payload, which is an SA payload. MjVer and MnVer denote the major and the minor ISAKMP protocol versions. As mentioned before, this exchange type is Iden- tity Protection Exchange, so the Exchange Type field carries its numerical value (2). Flags indicate if certain options have been set (e.g., if the encryp- tion bit is set, the rest of the message is encrypted; see message 5 or 6 in Figure 12.6). The Message ID field is used in Phase 2 to identify protocol state and contains a randomly generated value. Length represents the mes- sage length (ISAKMP header and all payloads) in octets. The following payload is an SA payload. In the figure, payloads are separated by double lines. Since the Proposal and Transform payloads later in the chain are considered part of the SA negotiation, the SA Next Payload field is in this case 0. Otherwise it would indicate the number of payloads contained in the message after the SA payload. The Payload Length field indicates the length in octets of all SA negotiation payloads. This includes the SA payload and all Proposal and Transform payloads for this SA. A DOI identifier is used to interpret the payloads of ISAKMP payloads. In the exam- ple it is IPSEC DOI [15]. Additionally, the Situation identifier specifies the set of information that will be used to determine the required security 238 Security Fundamentals for E-Commerce TEAMFLY Team-Fly ® Transport Layer Security 239 Initiator Cookie Responder Cookie (none) Next Payload 1 (SA) = MnVer MjVer Exchange Type 2= Message ID Length Next Payload 0= Domain of Interpretation 1 (IPSEC DOI)= RESERVED Payload Length Situation 0x01 (SIT_IDENTITY_ONLY)= Next Payload 0= RESERVED Payload Length Proposal 1# SPI size 0= Protocol Id 1 (PROTO_ISAKMP) −= #=Transforms 2 Security Parameter Index (none) Next Payload 3= RESERVED Payload Length Transform 1# Transform Id 1 (KEY_IKE)−= RESERVED2 Attribute Type 1 (Encryption alg.)= Attribute Length Attribute Value DES CBC=− Next Payload 0= RESERVED Payload Length Transform 2# RESERVED2Transform Id 1 (KEY_IKE)−= (other preferred attributes) (other preferred attributes) Attribute Type 1 (Encryption Alg.)= Attribute Length Attribute value 3DES CBC=− Flags Figure 13.10 Example of an ISAKMP message. services. For IPSEC DOI three situations are possible; in the example SIT_IDENTITY_ONLY is used. This situation implies that the SA will be identified by source identity information present in an associated Identifica- tion Payload. Looking at messages 5 and 6 in Figure 12.6, one notices that ID i and ID r are sent in Phase 1. In the corresponding ISAKMP messages they would be represented by Identification Payloads. The other two situations defined for IPSEC DOC refer to the use of security labels for secrecy and integrity. There is only one Proposal payload in the message because in Phase 1 only the ISAKMP SA is negotiated. Since there are no other proposals in the message, the Next Payload field is set to 0 (otherwise it would be set to 2). The Protocol-Id field indicates the protocol for which the negotiation is per- formed. The ISAKMP SA is to be negotiated, so the value is PROTO_ISAKMP. In Phase 1, no security parameter index is used, so this field is absent. The #Transforms field says how many Transform payloads related to that proposal are present in the message. There may be one or more Transform payloads per proposal. A Trans- form payload carries the negotiation parameters (Proposed_SA_Parameters in Figure 12.6). More specifically, it contains the identification of the spe- cific security mechanism (KEY IKE as Transform-Id), and the SA attributes (Attribute Type and Value). The SA attributes for the IKE are listed in Section 12.3.2.1 (e.g., Encryption Algorithm as Attribute Type and DES-CBC as Attribute Value). The Next Payload field can be set at either 3 (more Transform payloads to come) or 0 (the last Transform payload). The first Transform payload proposes DES-CBC as the encryption algorithm (Attribute Value). The second Transform payload carries an alternative set of SA attributes, which is in this case 3DES-CBC as the encryption algorithm. The responder must choose one Transform and send it in the response (Selected_SA_Parameters in Figure 12.6). In addition, ISAKMP defines the following payload types (please refer to Figure 12.6 and Figure 12.7): • Key Exchange Payload to transport key exchange data (e.g., g x i in message 3); • Certificate Payload to transport certificates (X.509, PGP, SPKI) or CRLs, or other key tokens such as a Kerberos token or DNS signed key (e.g., [Cert] in message 5); • Certificate Request Payload to request a certificate in any message; • Hash Payload to transport hashsums (e.g., HASH(3) in message 9); 240 Security Fundamentals for E-Commerce • Signature Payload to transport digital signatures (e.g., SIG_I in mes- sage 5); • Nonce Payload to transport random nonces (e.g., Nonce i in message 3); • Notification Payload to transport ISAKMP or DOI-specific infor- mation, such as error conditions; • Delete Payload to transport a protocol-specific SA identifier that the sender has removed from its security association database and that is therefore no longer valid. References [1] Venema, W., TCP WRAPPER: Network monitoring, access control and booby traps, Proc. 3 rd Usenix UNIX Security Symposium, Baltimore, MD, Sept. 1992, pp. 8592, ftp://ftp.porcupine.org/pub/security/tcp_wrapper.ps.Z. [2] Cheswick, W. R., and S. M. Bellowin, Firewalls and Internet Security: Repelling the Wily Hacker, Reading, MA: Addison-Wesley Professional Computing, 1994. [3] Leech, M., et al., SOCKS Protocol Version 5, The Internet Engineering Task Force, RFC 1928, March 1996. [4] McMahon, P., GSS-API Authentication Method for SOCKS Version 5, The Inter- net Engineering Task Force, RFC 1961, June 1996. [5] Leech, M., Username/Password Authentication for SOCKS V5, The Internet Engi- neering Task Force, RFC 1929, March 1996. [6] Dierks, T., and C. Allen, The TLS Protocol Version 1.0, The Internet Engineering Task Force, RFC 2246, Jan. 1999. [7] Freier, A. O., P. Karlton, and P. C. Kocher, The SSL Protocol Version 3.0, The Internet Engineering Task Force, Internet Draft <draft-freier-ssl-version3-02.txt>, Nov. 1996. [8] Myers, J., Simple Authentication and Security Layer (SASL), The Internet Engi- neering Task Force, RFC 2222, Oct. 1997. [9] The Internet Assigned Numbers Authority, Simple Authentication and Security Layer (SASL) Mechanisms, 1999, ftp://ftp.isi.edu/in-notes/iana/assignments/ sasl-mechanisms. [10] Wahl, M., T. Howes, and S. Kille, Lightweight Directory Access Protocol (v3), The Internet Engineering Task Force, RFC 2251, Dec. 1997. [11] Wahl, M., et al., Authentication Methods for LDAP, The Internet Engineering Task Force, Internet Draft <draft-ietf-ldapext-authmeth-04.txt>, June 1999. Transport Layer Security 241 [12] Hodges, J., R. L. Morgan, and M. Wahl, Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security, The Internet Engineering Task Force, Inter- net Draft <draft-ietf-ldapext-ldapv3-tls-06.txt>, Feb. 2000 . [13] Leach, P. J., and C. Newman, Using Digest Authentication as a SASL Mechanism, The Internet Engineering Task Force, Internet Draft <draft-leach-digest-sasl-05.txt>, Oct. 1999. [14] Maughan, D., et al., Internet Security Association and Key Management Protocol (ISAKMP), The Internet Engineering Task Force, RFC 2408, Nov. 1998. [15] Piper, D., The Internet IP Security Domain of Interpretation for ISAKMP, The Internet Engineering Task Force, RFC 2407, Nov. 1998. [16] Karn, P., and W. Simpson, Photuris: Session-Key Management Protocol, The Inter- net Engineering Task Force, RFC 2522, March 1999. [17] Simpson, W. A., IKE/ISAKMP considered harmful, ;login:, Vol. 24, No. 6, 1999, pp. 4858. 242 Security Fundamentals for E-Commerce 14 Application Layer Security The last chapter of Part 3 deals with general issues regarding security at the application layer. Each of the issues is itself a broad and interesting area, deserving much more attention than it can be given within the scope of this book. At least a few general concepts will be presented here, however, to help an interested reader start exploring the topics. 14.1 Introduction Although the title of this chapter is Application Layer Security, it will not, for the most part, deal with various security-enhanced Internet applications. Rather, it will address the remaining issues about Internet security infrastructure. Section 14.2 describes the last group of firewall mechanisms: applica- tion gateways and content filters. Section 14.3 deals with a network frame- work supporting access control and authorization which can be used with a variety of mechanisms. Operating system security is a serious issue, but still not taken seriously enough. It is briefly overviewed in Section 14.4. Host- based intrusion detection described in Section 14.5 is the traditional approach to intrusion detection. It should be used together with the network-based intrusion detection mechanisms described in Section 12.5. 243 Section 14.6 mentions some well-known, security-enhanced applications, and Section 14.7 on security testing concludes this chapter. 14.2 Application Gateways and Content Filters Application gateways are mechanisms used by firewall systems to control traffic passing through the bastion host at the application layer. They are often referred to as proxies. A proxy is an intermediary program that acts as both a server (to the original client) and a client (to the server that the origi- nal client wishes to connect to). It accepts a request from a client and then either • Processes it internally and sends a response to the client, or • Forwards the request to another server, or • Translates the request and sends it to another server on the clients behalf. In the last two cases the proxy receives the response and forwards it to the client. For each service that should be allowed to traverse a firewall, an appro- priate proxy is installed on the firewall host (e.g., TELNET, FTP). This approach is taken by, for example, the Firewall Toolkit (FWTK) by Trusted Information Systems 1 which can be used to build a customized firewall. In this way it is possible to deal with the specifics of each service without having to define a set of generaland potentially inconsistentpacket-filtering rules (see Section 12.2). For some services it is even possible to add authenti- cation and access control. Content filters are programs that run on firewall hosts and parse traffic on the basis of application-level semantics. For example, the so-called virus- walls look for viruses and block the application stream if any are found. A content filter can parse e-mail messages and look for the From: or To: headers, or for a specific type of MIME attachment. Still others block Java applets or Java script, which is not always very successful (see Section 18.5). It is not difficult to see that content filters can significantly degrade the 244 Security Fundamentals for E-Commerce 1. http://www.tis.com/research/software/fwtk_over.html throughput from and to an intranet and should therefore be applied very selectively. Stateful inspection, a technology developed at Check Point Software Technologies Ltd. 2 combines and extends the proxy and the content filter approach. A stateful inspection module extracts the relevant communication (i.e., header) and application state information. The module can learn any protocol and application by defining the security rules in INSPECT, an object-oriented, high-level script language. Stateful inspection systems can perform logging and authentication at the application layer by recording the IP addresses of the sources and destinations of packets, port numbers, and any other information required to determine whether packets comply with a site security policy. State and context information is stored in dynamic con- nections tables. 14.3 Access Control and Authorization After a client who contacts a server by using, for example, PPP, SLIP, or TELNET has been successfully authenticated, the server must decide whether the client is authorized for that connection. Many firewall products implement RADIUS [1] or TACACS [2] for authentication and authorization. In RADIUS, the server to which the client connects is referred to as the network access server (NAS). NAS is a client of a UDP-based RADIUS server that manages a database containing user-authentication information and access control lists (e.g., identifying which service an authenticated client can use). NAS passes the client authentication information to the RADIUS server. The RADIUS server can support any password-based authentication mechanism, such as PAP, CHAP, or UNIX login. It verifies the clients pass- word and checks its authorization information for the service the client requested at NAS (e.g., PPP, SLIP, or TELNET). When NAS receives the response, it provides the client with the service if the response was positive, or rejects it if the response was negative. All transactions between NAS and the RADIUS server are authenti- cated through the use of the shared secret, which is never sent over the net- work. In addition, client passwords are sent encrypted between the NAS and RADIUS servers to eliminate the danger of password sniffing. Application Layer Security 245 2. http://www.checkpoint.com 14.4 Operating System Security Operating systems are too complex to be formally specified and verified. Consequently, it is impossible to make them perfectly secure. There are, however, some mechanisms to improve operating system security. One of the serious problems with many commercial operating systems is the superuser permissions. A superuser has all types of access rights to all system resources. Consequently, if an individual can gain the superuser privileges in a system, there is no way to protect any of the systems resources. In military environments more restrictive access control models are used, such as the Bell-La Padula model which was mentioned in Part 1. This model defines a multilevel security policy. Each subject (user) is assigned a security label called clearance defining the subjects security level. Each object (resource) is assigned a security label called classification or sensitivity defining the objects security level. The policy allows no read-ups and no write- downs. In other words, a subject can read only an object whose classifica- tion is lower or equal to the subjects clearance. Also, a subject can write into an object only if the objects classification is higher or equal to the subjects clearance. This type of access control is referred to as mandatory access con- trol. Such security policies are too restrictive for most nonmilitary environments. In a secure operating system, all accesses to resources (objects) are mediated by a trusted and tamper-resistant component called a reference monitor. In other words, the reference monitor enforces the security policy. The reference monitor checks for clearances and classifications in a secure access control database. The monitor, the database, and other security- relevant functions are parts of the security kernel. By encapsulating these parts within the security kernel, which is isolated, corrected, and always invoked, the security-relevant functionality is effectively separated from other operat- ing system functions [3]. If the security kernel is small, it is much easier to verify than a complete operating system. Some commercial operating systems, such as Trusted Solaris by Sun Microsystems, Inc., provide the possibility of security labeling and manda- tory access control in addition to the usual discretionary access control. It is possible, however, to bypass the mandatory access control by giving privileges to programs, and authorizations to users. These can be specified in such a way that only the minimum (i.e., the least) privilege or authorization is given. For this system, 83 different privileges are defined so it is not necessary for a pro- gram to run with superuser (root) privileges to accomplish certain tasks. This concept is certainly an improvement, but as soon as there is a way to bypass 246 Security Fundamentals for E-Commerce [...]... have security holes The Accept headers also provide additional information about the server (e. g., media type, language, encoding method accepted by the server) The Via request or response header is used by intermediaries (e. g., proxies) to indicate the intermediate protocols and recipients between the client and the server (request), and between the origin server and the client (response) This header... resource that will handle the entity enclosed in the message body (this can be used to post a message to a newsgroup or to submit a Web form) • PUT: The client requests that the entity enclosed in the message body be stored under the specified URI • DELETE: The client requests that the origin server delete the resource identified by the URI • TRACE: The client can use this to test what is being received... be a security problem, because information about the hosts behind a firewall may be revealed if a proxy is located at a firewall Like the Server header, the User-Agent request header reveals the client software version (e. g., “CERN-LineMode/2.15 libwww/2.17b3”) The From request header contains an Internet or e- mail address of the user (see the example in the previous section) Obviously, if the user... counting the number of users who request the resource pointed to by the advertisement, where the request contains that Web page’s URI in the Referer header The header information, however, allows the server to observe a user’s behavior and thus violate his privacy In addition, some sites use Web forms activated by the GET method; the GET parameter is the URI, so the sensitive information (e. g., a credit... value protects the integrity of the message contents (i .e. , HTTP request) The Hypertext Transfer Protocol 2 67 In most cases, secret = password (i .e. , a secret shared between the client and the server) With MD5-sess, the value of A1 is computed only once, namely, after the initial authentication exchange The same value is used for authentication of subsequent HTTP requests and responses and therefore... The challenge in the digest authentication scheme is a random value (i .e. , a nonce) The challenge value should be as fresh as the server performance requirements allow (it is timeconsuming to check nonce freshness) in order to prevent replay attacks For example, a nonce function may use a time stamp, the client’s IP address, the requested URI and a secret key as input parameters The challenge is sent... for a single request For example, requesting a price list (GET) for certain products over the Web is an idempotent method, because the state of the server remains the same, no matter how many times the customer requests and receives the list Payment, on the other hand, is not an idempotent operation If a payment method is implemented on the basis of a client’s submitting a Web form, the implementation... card number) is encoded in the URI Even if the HTTP connection is encrypted (e. g., by SSL), a URI containing a credit card number can be revealed through the Referer header In other words, the Referer header is not encrypted even if SSL is used, so any credit card number it may contain will be unprotected Generally, if the referring page was transferred using a secure protocol, the Referer header should... (e. g., From) or only in a response (e. g., Server), and some fields are used to describe the entities in the message body (e. g., Content-Encoding) The Content-Type entity header field indicates the media type of the entity body sent to the client (e. g., text/html, or image/gif, or application/pdf) The start line of an HTTP request is referred to as the request line It specifies the actual client request... resource in the request (see Section 15.2.1) This value is included because proxies may change the request line in transit The qop value chosen by the client must be one of the values indicated by the server (in this case it is “auth” for authentication) The cnonce (client nonce) and nc (nonce count) fields are present only if the server included the qop field in the challenge message The cnonce value (and . component called a reference monitor. In other words, the reference monitor enforces the security policy. The reference monitor checks for clearances and classifications in a secure access control. assigned a security label called clearance defining the subjects security level. Each object (resource) is assigned a security label called classification or sensitivity defining the objects security. the service if the response was positive, or rejects it if the response was negative. All transactions between NAS and the RADIUS server are authenti- cated through the use of the shared secret,