INTERNET-DRAFT H. Sugano Expires: April, 2000 S. Fujimoto Fujitsu Laboratories October 1999 Design Considerations on Security and Privacy for IMPP draft-sugano-impp-security-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 document and related documents are discussed on the impp mailing list. To join the list, send mail to impp-request@iastate.edu. To contribute to the discussion, send mail to impp@iastate.edu. The archives are at http://lists.fsck.com/cgi-bin/wilma/pip. The IMPP working group charter, including the current list of group documents, can be found at http://www.ietf.org/html.charters/impp-charter.html. Abstract This memo describes the current results of the author's investigations into decisions required for security issues in IMPP protocol design. We discuss possible options for methods of authentication and encryption appropriate to IMPP requirements. In particular, we propose our design decisions for message integrity checking, user authentication, time stamping, and message confidentiality. Moreover, we consider some ACL and firewall issues. This memo attempts to complement the IMPP design basis [Basis] by providing a discussion of privacy and security. Table of Contents 1. Introduction 2. Authentication and Encryption 2.1. Message Integrity Check 2.2. Message Sender Identification 2.3. Time Stamping 2.4. Encryption 2.4.1. Encryption Layer options 2.4.2. Encryption Format options 3. Considerations on ACL Handling 3.1. Operations for ACL Handling 3.2. ACLs for Presence Tuples 3.3. Other Expectations for ACLs 3.3.1. Features for specifying requesters 3.3.2. 'Ask' or 'Consult' feature 4. Firewall Friendliness 4.1. IMPP Proxy on the Border 4.2. Persistent Connections 4.3. Proxies for Persistent Connections 5. Conclusion 6. References 7. Authors' Addresses 1. Introduction As settlement process of the requirements for IMPP moved towards finalization, the contributors started to discuss some of protocol design issues on the mailing list. The document "Proposed Design Decisions for IMPP (draft-day-impp-basis-00.txt)" [Basis] constituted an important step. The document is still being revised based on ongoing discussions on the mailing list. While it provides an important basis for discussions related to IMPP, it seems that security related issues are not fully investigated. This memo attempts to complement Day's document on IMPP design by addressing issues of privacy and security. We mainly discuss possible options for methods of authentication and encryption appropriate to IMPP requirements. In particular, we offer our design decisions for message integrity checking, user authentication, time stamping, and message confidentiality. Moreover, we engage in some discussion of ACLs and firewall issues. 2. Authentication and Encryption In this section, we discuss possible options for authentication and encryption methods in IMPP. According to the IMPP requirements document [Reqts], at least the following four privacy and security services should be provided. - Message integrity check - Message sender identification - Time stamp - Secure message delivery Note that the word 'message' in this memo means both protocol messages and IMs. In the subsequent sections, we investigate possible options for each of these services. 2.1. Message Integrity Check IMPP must provide a means for checking message integrity, i.e. a means for ensuring that the received message is the same as the sent message, and as such has not been corrupted or tampered with. We can suggest two options. * Public Key Digital Signature - calculate secure hash value (i.e. SHA-1) on the message, and encrypt it using the sender's private key. The checker uses the sender's public key to decrypt the hash value, and see if the result matches the separately calculated message hash value. Pros: - does not require distribution of any secrets in advance (if digital cert. is enclosed). Cons: - calculating the result can be slow. - limited availability (due to export control restrictions). * Keyed MAC - share secret key in advance, calculate secure hash value (i.e. SHA-1) on the concatenation of the secret key and the message. Pros: - faster calculation than Digital Signature. Cons: - requires distribution of a secret key in advance. At this point, we have not chosen either of them. However, we think the protocol should provide the means to use Keyed MAC integrity checking if the secret key for the Keyed MAC could be securely delivered. 2.2. Message Sender Identification We investigated the following options: * Password based - The client could send a secret word or phrase to the receiver. Then the receiver checks if the sent secret are valid. Pros: - most widely used. - easy to implement. Cons: - easy to guess. (e.g. dictionary attack) - attacker can tap communication channels. - user shouldn't reuse the same secret for multiple domains. - requires registration in advance. * Challenge/Response password based - A receiver asks a sender to get a (usually randomly chosen) challenge value. The sender generates a credential data from the challenge value and a shared secret, and sends the credential to the server. The server checks if the sent credential is valid. Pros: - more secure than password against 'man in the middle' attack. Cons: - client and server must share a secret in plain text (to generate the credential). - does not solve the other password related problems mentioned above. * Public Key Digital Signature based - A sender digitally signs the message. The receiver checks if the signature is valid. NOTE: the message MUST contain a timestamp to prevent replaying a recorded message. Pros: - impossible to guess. - a user can reuse one secret (key pair) for different domains. Cons: - less common in use. - limited availability (due to export control restrictions). - requires registration until PKIX becomes pervasive. Consequently, we recommend using Public Key based authentication because password base authentication is regarded as UNSAFE in the present environment. Even if enhanced with challenge and response, password based authentication will not work well in an interdomain environment. Public key based authentication can be used to avoid the problem cited above. Additionally, export control restrictions can be avoided using digital signature algorithms (i.e. DSA). 2.3. Time Stamping We have following options for Time Stamping: * Numeric value - Express as seconds since 00:00:00 UTC, Jan. 1, 1970. Pros: - easy to evaluate by a program. Cons: - less readable. - value range (as instance int length) is hard to justify. * ASCII Representation - ASCII standard format like "10:30:30 PDT, Jul 4, 1999" Pros: - better solution for rollup problem. - more readable. Cons: - program required to parse it. In our opinion, an ASCII Representation seems reasonable, because the parsing cost is sufficiently small. 2.4. Encryption 2.4.1. Encryption Layer options We considered the following options: * Transport Encryption - Using a lower layer encryption service such as IPSec[IPSec] or TLS[TLS]. Pros: - minor modification on the plain protocol. Cons: - only works between end entities for the transport. - can not provide end-to-end authentication as one solution. * Message Encryption - Building a dedicated encryption service using current standards such as S/MIME[SMIME] or OpenPGP[OpenPGP]. Pros: - transport independence. - partial encryption is possible. (i.e. header part only) Cons: - major modification is required on the protocol. * Hybrid - Using Transport Encryption for client-server traffic, and using Message Encryption on the data payload. Pros: - can get all benefits from the previous two options. Cons: - large overhead (the payload part must be doubly encrypted). We recommend the "Message Encryption" approach, because we must provide end-to-end privacy for messages (as described in the protocol requirements [Reqts]). We believe that layered encryption as described in the hybrid approach is not acceptable because it imposes too much overhead. 2.4.2. Encryption Format options * Open PGP - An encryption standard for any type of data. Pros: - current de facto standard for E-mail privacy (for personal use). Cons: - incompatible with PKIX certificates. * S/MIME - Another encryption standard on MIME object. Pros: - de facto standard for E-mail privacy (for commercial products). Cons: - requires digital certificates issued by a CA. * Dedicated Format - design our own data format. Pros: - more flexibility. Cons: - cannot use any existing software libraries. - would take time to develop, test, and gain community acceptance. We propose adopting S/MIME for our encryption format for the following two reasons. 1) We should follow the currently deployed standards as much as possible. 2) We exect that PKIX will provide a reasonable basis for inter-domain interoperability. S/MIME seems to offer better support for PKIX. 3. Considerations on ACL Handling If IMPP design focuses to client/server interoperability, operations and formats for ACLs must be addressed. This section assumes this. 3.1. Operations for ACL Handling For operations to handle ACLs, we strongly propose separating Set-ACL and Get-ACL from Change and Fetch. This suggestion is based on privacy considerations. While ACLs and other control information are usually processed by servers, presence information is mainly published for watchers. Thus, presence information sometimes must be encrypted and secured against the servers, but control information should not. Because servers must deal with this information quite differently, operations on ACLs and other control information should be separated from operations that deal with presence information. 3.2. ACLs for Presence Tuples The Model document [Model] defines presence information as a set of Presence Tuples, each of which consists of Status information, and optional Communication Address and Other Presence Markup. While the usage of presence tuples remains to be specified, we investigated possibility of having multiple presence tuples as presence information. As a consequence, we propose that ACLs should be able to be managed for each tuple independently. Presence tuples can be associated with communication media or devices such as IMs, cell phones, and telephones. Characteristics of these communication media are typically fairly different. Users may want to control watchers' accessibility to these media selectively. For example, a user may want to hide the number of her/his cell phone from a particular watcher. This requires that IMPP have a naming mechanism which allows presence tuples to be separately controllable. At a minimum, ACLs should be able to specify an ALLOW LIST and an BLOCK LIST for each presence tuple. 3.3. Other Expectations for ACLs While it seems early to make any proposals for IMPP ACL formats, it is appropriate to list some of the expected features for ACLs. 3.3.1. Features for specifying requesters At a minimum, IMPP ACLs should be able to specify requesters by their names/identifiers and their domains. The IP address or other address/ location of the requesting device or server might be used to do that. But we do not think that it is practically useful for many IMPP applications. While it is expected that access control would be able to be fulfilled based upon attributes other than requesters' names and domains, it is unlikely to acquire interoperability because of the complexity and extent of the specification required. 3.3.2. 'Ask' or 'Consult' feature There are typically two options to handle subscription requests from users not in the ALLOW LIST or the BLOCK LIST: permission or denial. However, users sometimes want to be presented with the requester's identity so they can decide if the request should be permitted or denied. ACLs or related functions should provide means to select this action. 4. Firewall Friendliness There are two methods that have been discussed for establishing subscriptions from inside a firewall to an outside IMPP server and for receiving notifications from the outside; a) Deploying an IMPP proxy (application gateway) on the firewall, and enabling that proxy to receive NOTIFY requests from the outside. b) Establishing a persistent connection via a circuit-level gateway like SOCKS. 4.1. IMPP Proxy on the Border Case a) would look more favorable if it were possible. Unfortunately for IMPP, firewall administrators are typically reluctant to deploy new application proxies because they are very sensitive to incoming packets from outside their organization. It seems that this option would not find widespread deployment. 4.2. Persistent Connections Case b) is more likely to be successful. If IMPP clients are SOCKS-enabled and IMPP servers accept persistent connections from clients, we could easily have a viable solution. However, if a persistent connection is established for each pair of clients and servers, a large number of persistent connections must be maintained. This could lead to the exhaustion of resources of SOCKS servers. This drawback is more serious in fully distributed architectures (where a user client connects directly to a number of servers) than in server-to-server architectures (where a client only connects to its home server). At present we cannot assume a particular architecture. 4.3. Proxies for Persistent Connections We propose that the protocols should allow a simple proxy to establish persistent connections to servers and to relay requests from multiple clients. If such a proxy is deployed inside the firewall and utilized to establish persistent connections to servers outside, the numbers of persistent connections which must be maintained can be largely reduced. Because the proxy must deal with notification requests from servers, it must correctly relay each notification to its destination client. Note that this kind of proxy does not have to be an "aggregator proxy", which is expected to fan out a single notification to relevant multiple destinations. Because aggregator proxies require much more complexity, such as fan-out lists for subscriptions/notifications, we propose not to address aggregator proxies in the current design of IMPP. 5. Conclusion In this memo, we discussed several security related issues in IMPP protocol design. We also proposed our thoughts based upon the results of authors' investigations of the design decisions. We investigated possible options for methods of authentication and encryption appropriate for IMPP requirements, and proposed our design decisions for message integrity checking, user authentication, time stamping, and message confidentiality. Moreover, we discussed some approaches to managing ACLs and firewall issues. This memo tries to provide a discussion of IMPP privacy and security issues that will complement the previous discussion in the IMPP design basis [Basis]. 6. References [Basis] M.Day, S.Aggarwal, G.Mohr, G.Hudson, "Proposed Design Decisions for IMPP", Work in Progress, draft-day-impp-basis-00.txt [Model] M.Day, J.Rosenberg, H.Sugano, "A Model for Presence and Instant Messaging", Work in Progress, draft-ietf-impp-model-03.txt [Reqts] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant Messaging / Presence Protocol Requirements", Work in Progress, draft-ietf-impp-reqts-03.txt [HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, Jan 1999. [SHTTP] E. Rescorla, A. Schiffman, "The Secure HyperText Transfer Protocol", RFC2660, August 1999. [X509] R. Housley, etc., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 2459, IETF. 7. Authors' Addresses Hiroyasu Sugano Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 Japan email: suga@flab.fujitsu.co.jp Shingo Fujimoto Fujitsu Laboratories of America, Inc. 595 Lawrence Expressway Sunnyvale, CA 94086 USA email: shingo@fla.fujitsu.com