ALTO Shuyi. Chen Internet-Draft Feng. Gao ZTE Corporation Intended status: Standards Track Xiaofeng. Qiu Miao. Xiong Expires: August 27, 2010 MINE Lab, BUPT March 1, 2010 Overview for ALTO security issues draft-chen-alto-security-overview-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Chen, et al. Expires August 27, 2010 [Page 1] Internet-Draft ALTO security overview March, 2010 Abstract This document provides an overview of the security mechanisms that are probably fit for ALTO. Specifically it discusses those mechanisms for authentication, encryption and attack-preventing. The goal of this draft is to list and analyze the existing security mechanisms, and to explore suitable solutions to guarantee the security of ALTO protocol. This draft is a very early draft to outline the possible security mechanisms and leaves considerable contents and details to be added later. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 3. ALTO security requirements . . . . . . . . . . . . . . . . . . 4. ALTO security mechanism . . . . . . . . . . . . . . . . . . . 4.1. Authentication mechanism . . . . . . . . . . . . . . . . . 4.1.1. No Authentication . . . . . . . . . . . . . . . . . .. 4.1.2. HTTP Digest Access Authentication. . . . . . . . . . . . 4.2. Encryption mechanism . . . . . . . . . . . . . . . . . . . 4.2.1. SSLv3/TLS . . . . . . . . . . . . . . . . . . . . . . . 4.3. Attack-preventing mechanism . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7.2. Informative References . . . . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . Chen, et al. Expires August 27, 2010 [Page 2] Internet-Draft ALTO security overview March, 2010 1. Introduction Helping peer-to-peer (P2P) application to select better peers from a set of candidates is currently one of most popular research areas. The goal of Application-Layer Traffic Optimization (ALTO) [I-D.ietf-alto-problem-statement] is to provide guidance to p2p applications, which is based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. However, ALTO may be insecure when the clients are trustless or unauthorized. In this case, clients can steal ISP's ALTO information by snoop or deceit that would do harm to ALTO structure. This draft gives the security issues between ALTO server and client which MAY be unauthorized. Part of these issues had been discussed in the mailing list, but this draft will give a summary of ALTO security issues with all kinds of situations. Since ISP privacy and P2P privacy issues had been discussed a lot in [I-D.wang-alto-privacy-load-analysis], this draft will focus mainly on security issues among unauthorized parties. Additionally the common authentication/encryption and attack- preventing mechanisms which are suitable for ALTO protocol are given below. 2. Terminology and Concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document also reuses the concepts defined in [I-D.ietf-alto-problem-statement] and [I-D.ietf-alto-reqs]. Chen, et al. Expires August 27, 2010 [Page 3] Internet-Draft ALTO security overview March, 2010 3. ALTO security requirements ALTO protocol has some minimum-to-implement security requirements. This set of security requirements has been listed in Section 3.3 in [I-D.ietf-alto-reqs]. General ALTO security requirements include four parts: (1) Preventing an ISP's internal topology from being leaked (2) Preventing an ISP from learning about P2P application behavior (e.g., the information about peers with which it is connecting) (3) Preventing unauthorized access to ISP's ALTO information. There are a couple of cases here: (a) An ALTO Server sends the information directly to an unauthorized ALTO Client (b) An unauthorized party snoops on the data transmission from the ALTO Server to an authorized ALTO Client. (c) An authorized ALTO Client knowingly sends the information to an unauthorized party (4) Preventing an ALTO Server from being attacked by malicious behavior due to the insecure design of ALTO protocol (e.g., DoS) Here is the figure describing this situation: +--------------------+ | Attacker | /| |\ / +--------------------+ \ (4) (4) / \ +-------------+ +------------------------+ | ALTO server | -------(1)----[snoop]-- > | Authorized ALTO client | | ISP | <------(2)----[snoop]---- | P2P application | +-------------+ | +------------------------+ \ | / \ (3b) / (3a) | (3c) \ | / \--------- > +--------------+ <----------/ | Unauthorized | | Party | +--------------+ Figure 1. ALTO security requirements between ALTO entities Chen, et al. Expires August 27, 2010 [Page 4] Internet-Draft ALTO security overview March, 2010 According to classification of ALTO security issues, (1)(2) have nothing to do with authentication/encryption because they only concern about the ALTO servers and authorized ALTO clients. Transmission over them only refers to the content but not the roles. While in part 3, (3a) and (3b) are closely related to authentication/encryption, but (3c) is not. There are not many methods for authorized ALTO client to prevent ISP's ALTO information from being leaked to unauthorized parties. Since when ALTO client requests the desired information, ALTO server will surely send out desired information to the requester no matter whether it is authorized or not. (4) is an independent security part, which refers to mechanisms for ALTO Server against attacks like DoS. There are solutions mentioned in other draft for (1)(2) in most cases, and some solutions for (3)(4) will be given below. 4. ALTO security mechanisms Client in ALTO may be unauthorized that means it can cheat the server to threaten the ALTO security. Based on the four parts above, ALTO security mechanisms at least contain authentication, encryption and attack-preventing. 4.1. Authentication mechanism 4.1.1. No Authentication The simplest case is that all clients in ALTO are trustworthy or a kind of filtering is done before clients join the network. In this case, authentication is needless. Chen, et al. Expires August 27, 2010 [Page 5] Internet-Draft ALTO security overview March, 2010 4.1.2. HTTP Digest Access Authentication HTTP Digest Access Authentication is one of the agreed methods that a web server can use to negotiate credentials with a web user (using the HTTP protocol). Digest authentication is intended to supersede unencrypted use of the Basic access authentication, allowing user identity to be established securely without having to send a password in plaintext over the network. HTTP provides a simple challenge-response authentication mechanism that MAY be used by a server to challenge a client request and by a client to provide authentication information. That is quite suitable for ALTO framework since ALTO is also the server/client framework. When the ALTO server receives the requested message, it will challenge the client who initiates the request and the client in the same time will give the response providing its authentication information. The Digest scheme challenges using a nonce value. A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URI. HTTP Digest Access Authentication is simple and secure in web-level applications providing a more complex authentication than Basic authentication, and it introduces the server/client nonce which will prevent replay and chosen plaintext attacks. However it has many known limitations. Digest access authentication is intended as a security trade-off, therefore it is no secure than public key or Kerberos authentication. But Digest access authentication will make ALTO protocol lightweight so that security will not bring ALTO protocol too much overhead. Chen, et al. Expires August 27, 2010 [Page 6] Internet-Draft ALTO security overview March, 2010 4.2. Encryption mechanism 4.2.1. SSLv3/TLS SSL(Secure Socket Layer)and TLS(Transport Layer Security)are widely used cryptographic protocols that provide security for several applications in the Internet like web browsing, VoIP, e-mail. SSLv3 is the third version of SSL and developed by Netscape Corporation. TLS is an IETF standards track protocol, last updated in RFC 5246. The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography. Typically, the key information and certificates necessary for TLS are handled in the form of X.509 certificates, which define required fields and data formats. SSL operates in modular fashion. It is extensible, with support for forward and backward compatibility and negotiation between peers. SSL/TLS can provide: (1) Authentication between server and client. That will ensure that the information is sent to the correct client or server. (2) Data encryption. Before the secure connection is established, both parties use the asymmetric key cryptography. After the establishment, symmetric key cryptography will be used. That will keep ISP's information not leaked to unauthorized parties. (3) Ensure data integrity. Using hash function makes data integrity. SSL/TLS is a standard method to protect SIP application signaling. SSL/TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP-based applications. Be similar to SIP, SSL/TLS can also be used to provide authentication and encryption of ISP's ALTO information that is communicated between server and client. 4.3. Attack-preventing mechanism Since ALTO server may be the target of attack, ALTO should provide security mechanism to protect ALTO server from being attacked by malicious behavior (e.g., DoS). Due to the insecure design of ALTO protocol, there are several risks for attacker to harm ALTO. When ALTO client/server communicates, they establish a TCP connection. In response to query messages, an ALTO client/server constructs and sends messages containing TCP messages. And it makes DoS attacks possible if the attackers produce thousands of TCP request with fake IP addresses that their ACKs will never be received by the server. This makes the server wastes much time and CPU to wait for non-existent ACK. It harms great to ALTO system. An useful mechanism for DoS attack includes SYN cookie and restraining the connection number in definite time and from definite source. Another widely used method is firewall. Chen, et al. Expires August 27, 2010 [Page 7] Internet-Draft ALTO security overview March, 2010 5. Security Considerations Most of the security issues have been discussed above. 6. IANA Considerations There is no IANA action required by this draft. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-ietf-alto-problem-statement , October 2009. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC2617] Franks, J. and P. Hallam-Baker, "HTTP Authentication:Basic and Digest Access Authentication", RFC2617,June 1999. [I-D.ietf-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-ietf-alto-reqs-02 (work in progress), October 2009. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-01 (work in progress), December 2009. [I-D.wang-alto-privacy-load-analysis] Wang, Y., Song, H., and M. Chen, "Analysis for ALTO privacy and load issues", draft-wang-alto-privacy-load-analysis-00 (work in progress) October 2009. Chen, et al. Expires August 27, 2010 [Page 8] Internet-Draft ALTO security overview March, 2010 Authors' Addresses Shuyi Chen ZTE Corpoporation 17/F, ZTE Plaza, No.19, East HuaYuan Road, Haidian District, Beijing, P.R.China, 100191 Phone:+86-10-82963667 Email: chen.shuyi@zte.com.cn Feng Gao ZTE Corpoporation 17/F, ZTE Plaza, No.19, East HuaYuan Road, Haidian District, Beijing, P.R.China, 100191 Phone:+86-10-82963777 Email: gao.feng1@zte.com.cn Xiaofeng Qiu Mobile lIfe and New mEdia Lab, Beijing University of Posts and Telecommunication, P.O. Box 92, No.10, Xitucheng Road, Haidian District, BeiJing, P.R.China, 100876 Email: qiuxiaofeng@gmail.com Miao Xiong Mobile lIfe and New mEdia Lab, Beijing University of Posts and Telecommunication, P.O. Box 92, No.10, Xitucheng Road, Haidian District, BeiJing, P.R.China, 100876 Email: xiongbearie@gmail.com Chen, et al. Expires August 27, 2010 [Page 9]