Internet Engineering Task Force Jiri Kuthan Internet Draft GMD Fokus draft-kuthan-iptel-cpl-auth-00.txt November, 2000 Expires: May 2001 CPL Authentication and Database Access Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract A set of Call Processing Language (CPL) extensions is proposed. They allow access to external databases and call-processing logic dependent on authentication information. Design issues are identified and example solutions shown. 1. Motivation Call Processing Language (CPL [2]) is a simple, yet powerful tool that enables programmability of signaling services. It is based on similar ideas like mail processing languages such as procmail or sieve [3] are. Because it is aimed primarily at service creation by end users and high security, it is intentionally simple. There are scenarios that are difficult or impossible to solve with CPL. In particular, CPL does not enable users to make call processing dependent on authentication status. This would be needed if, for example, users wanted to receive calls at cell phones only from friends in possession of a secret password. To enable such scenarios we suggest extending CPL with the ability to affect signaling logic by authentication status. Internet Draft CPL Authentication and DB Access August 2000 Another scenario that is difficult to deal with is call logic dependent on long sets of data such as lists of friends or undesired subjects. In particular, if more scripts use the same list replicating it instead of referring to it is likely to result in inconsistencies and unreadable scripts. If a list, e.g., a database of well-known spam sources is maintained by a third party, referring to the list seems a more viable approach than downloading the list and updating the script repeatedly. The ability to refer to an external data list may also be used to adapt CPL scripts to local environments. For instance, a reference to "helpdesk" would always translate to locally appropriate synonyms. In the remainder of this document, we discuss both suggested CPL extensions and various design choices. Section 2 focuses on authentication extensions. Section 3 deals with access to external databases. Examples are given in Section 4. Security is considered in Section 5. 2. Authentication Extensions 2.1 Authentication Switch CPL users may want to derive call processing from authentication status of different granularity. In the simplest case call processing depends on authentication result, i.e., on whether authentication succeeded or failed. In another case, call processing logic may depend on identity of authenticated user. The following CPL extension is an authentication switch that allows CPL scripts to match both authentication ID and resulting authentication status. The authentication switch abstracts from used authentication mechanism. We also assume that binding between authentication IDs and security credentials is maintained separately. This is similar to Web servers that maintain Access Control Lists and User-Password lists in separate configuration files. Node: Auth-switch Parameters: None Outputs: Auth Authentication id will be matched. Not-present Applies if no authentication information is available. Failed Applies if authentication failed Otherwise Output: Auth (takes exactly one of the following parameters) Parameters: Is Exact match. If authentication id is in form user@FQDN, then the user part comparison is case-sensitive and FQDN part comparison case-insensitive. Otherwise the comparison is case- sensitive. Internet Draft CPL Authentication and DB Access August 2000 Subdomain-of Sub-domain match. Matches only if authentication id is in form user@FQDN and FQDN is equal to operand or a subdomain of it. Case-insensitive. Figure 1: Syntax of Authentication Switch 2.2 Credential Database To retain portability of CPL scripts relying on a credential database, the following is needed: - A portable database export format supporting various types of credential encoding. - Secure transport mechanism. - Mechanism for linking CPL scripts to credential databases. An example of how the export format could look like is attached: ... 2.3 Realm If a script author requires a caller to authenticate he has to challenge him with a realm. A possible solution would be to include an appropriate status code and realm parameter in reject node: 2.4 Origin Verification Internet Draft CPL Authentication and DB Access August 2000 It seems desirable that message receivers are able to find out if address of message originator belongs to the person who authenticated the message. In SIP, forging the From field is easy with Digest and Basic Authentication. For example, a SIP request authenticated with Digest by user 'nobody' may still bear 'boss' in its From field. To make sure that the origin address is not forged a script author needs to inspect the source address and see if it is eligible for an authentication id. Such comparisons may result in significantly longer CPL scripts and decrease their readability. If there is a one-to-one relation between source address and authentication id we recommend that that source address be used as authentication id. Then, a single CPL condition can determine if the origin address is eligible or not. This condition can be evaluated either explicitly by script author or implicitly by CPL interpreter. Both design choices are illustrated in the next paragraphs. 2.4.1 Implicit Verification A new output 'verified' is added to auth-switch. It matches if CPL interpreter verified origin address successfully. 2.4.2 Explicit Verification A global, explicit, read-only variable ':auth_id' is defined. It takes the value of authentication id conveyed in call signaling in form 'user@FQDN'. It is empty if authentication did not succeed. To enable matching the fully qualified authentication ID in address switches, the auth_id variable has two members "user" and "domain". Alternatively, a "user-host" subfield could be added to address switches. 3 Referring to External Databases Major design requirements for CPL support for access to external databases are: - Ability to replace any value in scripts with a reference to an external list of values without changing existing language elements. - Addressing databases in a unified manner. Accessing them independently on database systems. - Resistance against database access failures. We describe a possible solution meeting these requirements in the following text. A special escape prefix ("@@") used in beginning of an operand indicates the rest of the operand is to be interpreted as a reference to an external database. The reference consists of a URL identifying the accessed database and specification of access Internet Draft CPL Authentication and DB Access August 2000 failure handling. In particular, access timeouts and failure handlers are specified. If database access is invoked by a '@@'-prefixed operand from a switch condition, the condition matches if ANY entry in the referred database does. If accessing the external data source fails or does not succeed within specified timeout, control is passed to a failure handler. Note the security impact of timeout and failure handler. If error handling was not defined, an attacker could affect call processing maliciously by attacking the external database service. 4 Examples The following CPL fragment rejects unauthenticated calls, calls with authentication ID differing from origin address and calls from originators present on a spam list. All other calls are accepted.
Figure 3: Example Script 5 Security Considerations The mechanisms introduced here enabled call processing based on authentication. Internet Draft CPL Authentication and DB Access August 2000 Strength of used authentication protocols is out of scope of this document. Security considerations from CPL specification [2] apply. If credential databases are used they must be transport securely. Security aspects of access to external databases are discussed in Section 3. 6 Acknowledgments H. Schulzrinne provided extensive comments. Appendixes A DTD Changes TBD B Glossary of Abbreviations CPL Call Processing Language DTD Document Type Definition FQDN Fully Qualified Domain Name LDAP Lightweight Directory Access Protocol NIS Network Information Service SIP Session Initiation Protocol C References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 J. Lennox, H. Schulzrinne: " CPL: A Language for User Control of Internet Telephony Services", Internet Draft, IETF, November 2000. Work in progress. 3 T. Showalter, "Sieve: A mail filtering language", Internet Draft, IETF, May 2000. Work in progress. D Author's Address Jiri Kuthan GMD Fokus Kaiserin-Augusta-Allee 31 D-10589 Berlin, Germany E-mail: kuthan@fokus.gmd.de E Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Internet Draft CPL Authentication and DB Access August 2000 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.