INTERNET-DRAFT Hadmut Danisch Category: Experimental Jan 2004 Expires: Aug 1, 2004 SCAF - Simple Caller Authorization Framework draft-danisch-scaf-00.txt Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo describes a framework for simple caller authorization. It is a generalization of the RMX draft[1], which was designed to protect against e-mail fraud and spam. This new draft describes a general mechanism suitable for other protocols used in the Internet or other networks. It is designed to be simple and to not make use of any kind of secret, and to establish a cheap, robust, and lightweight authorization scheme. It is intended to be used for low security requirements. Hadmut Danisch Experimental [Page 1] INTERNET-DRAFT SCAF Jan 2004 Table of Contents 1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background and History . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Frontends . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. SMTP - E-Mail Spam and Fraud protection . . . . . . . . . 6 4.2. HTTP - Web Access Authorization . . . . . . . . . . . . . 6 4.3. Phone Calls . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Other examples . . . . . . . . . . . . . . . . . . . . . . 7 5. The Middle Engine - The Interpreter . . . . . . . . . . . . . . 7 5.1. The Authorization Record . . . . . . . . . . . . . . . . . 7 5.2. Authorization Types . . . . . . . . . . . . . . . . . . . 8 5.2.1 Address based authorization . . . . . . . . . . . . 8 5.2.2 Directory based authorization . . . . . . . . . . . 8 5.2.3 Authorization server . . . . . . . . . . . . . . . 8 5.2.4 Public Key Authorization . . . . . . . . . . . . . 9 6. Backends - The directory services . . . . . . . . . . . . . . . 9 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Filesystems and Relational Databases . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Hadmut Danisch Experimental [Page 2] INTERNET-DRAFT SCAF Jan 2004 1. General Issues 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 RFC 2119 [2]. 2. Background and History In December 2002 the first version of the RMX draft[1] was published, which proposed the storage of authorization records in DNS, in order to specify which IP addresses were authorized to use a particular domain name in SMTP sender addresses. The mechanism was designed to protect against e-mail forgery and spam (which usually is a special case of forgery). At this time, the idea of listing permitted hosts in DNS was already known and discussed in some mailing lists, but as far as I know not officially published. It was first mentioned presumably in 1998 by Jim Miller, David Green, and Paul Vixie [3], who used the DNS as a simple lookup table for IP addresses. In the spring of 2003 the Internet Research Task Force (IRTF) opened the Anti Spam Research Group (ASRG). It's mailing list started with the presentation of the RMX draft. Similar proposals were published as SPF[4], DRIP[5], or DMP[6]. In the fall of 2003 a special subcommittee was launched, the ASRG-RMX group. A summary of its work can be found in [7]. The group was recently folded into a new SMTP VERIFY working group. In parallel and based on RMX[1], LMAP[7], and SPF[4], the Exchange working group of Microsoft developed a a new draft "Caller-ID For Email" [8], which improved the handling of the sender address, defined an XML schema for the authorization record, and a method to store XML data in DNS. There are currently several people involved in the further discussion and development of methods to verify the SMTP senders authorization to use a particular domain name as a part of the sender address (or alternatively to use the full e-mail address for verification). This draft wants to point out that these mechanisms can have much more use than just the protection against e-mail forgery. The proposal is to simply drop two limitations of these mechanisms, i.e. the limitation to e-mail sender addresses, and the limitation to DNS, and to use it as a common framework for general lightweight caller authorization. The main purpose will still be the protection against e-mail forgery. However, forgery is not limited to e-mail, Hadmut Danisch Experimental [Page 3] INTERNET-DRAFT SCAF Jan 2004 so the same mechanism can be used to protect other services and protocols as well. Furthermore, it can replace the password authentication in many applications with only low level security requirements and can eliminate user databases and the need to negotiate and store credentials such as passwords. Thus, a general lightweight authorization can be provided which can be easily plugged in almost any Internet- or even non-Internet application with a simple function call through the simple API described below. It requires only minimal adminstration and security skills and therefore can be provided by any administrator, and it should not violate any legislation. This draft does not introduce a new mechanism. It suggests new utilizations of those mechanisms and to split the mechanisms into three distinct layers. It is assumed that the reader is familiar with the mechanisms published so far. See the references at the end of this draft. 3. Overview The proposed authorization framework applies to services where - the incoming call comes with a sufficiently reliable technical address such as an IP address or phone number (e.g. Caller-ID or ISDN). There must be any kind of mechanism which guarantees that this technical address can be sufficiently trusted, i.e. that it is sufficiently difficult to forge. In context of IP addresses, this can not be guaranteed by the internet layer, but additional mechanisms like the TCP sequence number or a random number in UDP protocols should be sufficient for many purposes. Another example are phone numbers which are usually given by the network provider and not the caller himself. - the caller claims an identity specified by an identifier which allows to unambigously find an entry in a directory service. In general, these will be identifiers based on the world wide domain name hierarchy, e.g. e-mail addresses. - there is any kind of authority bound to some part of the directory, willing to provide authorization records describing which technical addresses are authorized to use identifiers belonging to the Hadmut Danisch Experimental [Page 4] INTERNET-DRAFT SCAF Jan 2004 authority's part of the directory space. In other words, there is a domain owner who has control over directory contents within the domain, and who is willing to publish a statement about who should be authorized to use this domain. - the server handling the call is able to query the apropriate directory service. To use this mechanism, an application must perform three steps: 1. Determine the technical peer address. Within TCP/IP networks, this is basically the getpeername() function call. 2. Determine the identifier claimed by the caller. This is immanent to protocols such as SMTP or FTP, but need to be invented for others such as HTTP (see below). 3. Use the mechanism through a simple API. This is basically a single function call Q(Addr, AddrFamily, Identifier, IdentifierFamily, ApplicationType) where Address is the technical peer address and AddrFamily is the class of addresses, e.g. ipv4, ipv6, or phone numbers. Identifier is who the caller claims to be, and the address family used to determine which directory service to use, e.g. an e-mail address. ApplicationType is just a symbolic label for the application, needed to allow different authorizations for different applications. E.g. "smtpauth" or "httpauth". The mechanism behind the API will basically perform two steps to find the answer: The first step is to fetch an authorization record. To do so, the IdentifierFamily is used to select the appropriate directory service. The Identifier, the AddressFamily, and the ApplicationType are then used as a key to query the authorization record from the directory service. For example, the authorization record used to Hadmut Danisch Experimental [Page 5] INTERNET-DRAFT SCAF Jan 2004 protect against spam e-mails could be found in DNS at ipv4.smtpauth._scaf.DOMAIN where DOMAIN is the domain part of an e-mail address or even the translation of the full e-mail address into the DNS domain space. The second step is to interprete the autorization record and to evaluate whether it grants permission to the given technical address. This might or might not require further directory queries or other communication processes (see below). 4. Frontends This section roughly describes some example applications which could use the proposed mechanism and what an implementation or a plugin would look like. This list is far from being a complete list, it is just a list of a few examples to give an idea about how to use the mechanism. You will easily find more applications to use this framework. 4.1. SMTP - E-Mail Spam and Fraud protection The application the mechanism was originally designed for is SMTP. RMX and similar mechanisms were supposed to detect forgery. See [1], [7], [4] and other such drafts for details. Basically the receiving MTA uses the IP address of the incoming SMTP connection to verify authorization to use the given sender address. Originally, the envelope sender address was used for authorization. To solve the problem with forwarding and empty sender addresses, it was discussed to additionally verify the hostname given as an argument to the SMTP HELO or EHLO command. See [8] for a different approach: This proposal makes use of the e-mail header information only and also covers pathological cases such as forwarding, mailing lists, bouncing etc. 4.2. HTTP - Web Access Authorization The mechanism could also be used for simple web access authorization to avoid the need for user and password databases where only a low level of security is required. To allow this, web browsers and proxies need to add an additional field to the HTTP request, like a CallerID: entry. Obviously, browsers would allow the user to choose whether and which CallerID Hadmut Danisch Experimental [Page 6] INTERNET-DRAFT SCAF Jan 2004 to use. The server might then verify this ID and grant access to web pages or dynamically generate pages depending on the identity, similar to the ubiquitous username/password, but without the need to protect and remember passwords. It is applicable where it is sufficient to verify that someone belongs to a domain, e.g. some company, and not to verify the personal identity. 4.3. Phone Calls Voice over IP will become a standard application soon, and even desktop phones will be connected to directory services and might display the callers business card details while ringing. The mechanism could be used to verify the callers identity, based on the technical phone number presented by ISDN or similar protocols. 4.4. Other examples Other examples are chat protocols (especially Jabber, where users have an e-mail alike identity), FTP (semi-anonymous access with lightweight verification), LDAP services, printing services, peer- to-peer networks. 5. The Middle Engine - The Interpreter The middle engine does the main job. It is independent of both the calling application and the underlying directory backends. It is mainly an interpreter which evaluates the authorization records fetched by the directory backends. It's task is to answer the question whether the authorization records - which were localized by using the claimed indentifier, the application type, and possibly the caller's technical address as a search key - grant permission to the given technical address. 5.1. The Authorization Record This draft does not (yet) describe how the authorization records will look like, because that's work in progress and covered by other drafts. Basically, the authorization record describes which technical addresses (e.g. IP addresses) are authorized to use the given identifier (e.g. an e-mail address or it's domain part) for the given application (e.g. send e-mail or access a web page). It can also describe more advanced methods to determine the authorized addresses instead of providing simple address lists. Hadmut Danisch Experimental [Page 7] INTERNET-DRAFT SCAF Jan 2004 The most simple approach is a simple lookup table as described in [1] or [5]. In this case the interpreter's work is trivial, since the authorization records consists of just a single bit of information: Does a record exist or not?. The complex approach was introduced by [1], where a record consists of single entries, covering single addresses, address ranges, and more complex descriptions. The encoding was still simple. Meanwhile, [8] presented an XML schema, thus the authorization record can become even more complex, at the cost of increased record size and a higher complexity and size of the interpreter. A similar but more compact approach would be to use ASN.1 encoding. 5.2. Authorization Types This section roughly describes the basic types of authorization records. 5.2.1. Address based authorization The most simple type is to list addresses or address ranges in the authorization records. The interpreter can immediately determine whether the caller is authorized or not. 5.2.2. Directory based authorization It is not always possible to directly list the authorized addresses. Sometimes an indirection step is required, where the interpreter needs to fetch more directory entries subsequently, either referenced authorization records or entries of other types. The main reasons to do so are addresses that change dynamically (e.g. IP addresses from dialin providers) or which are managed by a different authority (e.g. some service provider). 5.2.3. Authorization server As I learned from the comments I received to the RMX draft, a few domain owners do not want to publicly reveal the structure of their network and thus do not want to publish authorization records. Another problem are huge mail service providers such as Hotmail, AOL, Yahoo, T-Online, and others, where all users share the same domain name for their identifiers (=e-mail addresses). It would be possible to describe their relay machines with authorizaton records, but too many of their users refuse to deliver e-mail through central relays, and do want to deliver from their own computers. It is, on the other hand, impossible to describe all Hadmut Danisch Experimental [Page 8] INTERNET-DRAFT SCAF Jan 2004 those private computers with a common authorization record for the full domain. The service providers could maintain an individual authorization record for every single user (when the full e-mail address is used for the lookup), but this would defeat their user's privacy, since anybody could query the user's individual record and learn the user's IP address. A solution would be to have an authorization server for these large providers or those domain owners who do not want to reveal their relay structure. The authorization interpreter simply forwards the question to the domain's server, and the server replies with "yes" or "no". For those large e-mail service providers, a user would be authorized to send with his account's e-mail address while he is logged in into his account from the same IP address. This would allow any receiving MTA (or other application) to verify whether a particular IP address is authorized to use a particular identifier in that very moment, and would protect the user's identity much better. (A small privacy leak still remains: A third party cannot determine a user's IP address, but once it guesses an identifier and IP address pair, it can verify whether the guess was correct.) The authorization interpreter would find the server either by an explizit entry in the authorization record, or through a DNS SRV record in case no authorization record was found. 5.2.4. Public Key Authorization The main advantage and property of the proposed framework is to avoid the use of any secret information, i. e. to not use passwords or cryptography. However, the framework could still support cryptography. For example, an e-mail could also be accepted if the sender successfully provides a challenge response, or if the message has a valid and fresh digital signature. The authorization record could contain the public key or a reference to it. 6. Backends - The directory services The backends contain the drivers for the directory services. They do the work of actually retrieving the authorization record while completely ignoring it's syntax and semantics. The drivers just download any opaque octet sequence from the directory and pass it to the interpreter described previously. 6.1. DNS The most important and obvious directory service is DNS. See [1] Hadmut Danisch Experimental [Page 9] INTERNET-DRAFT SCAF Jan 2004 and [8] for discussions about DNS security flaws and their impact. The authorization record is found in the DNS hierarchy at the position given by the concatenation of the address family, the application type, and the domain name derived from the identifier, e.g. at ipv4.smtpauth._scaf.somedomain.com or ipv6.smtpauth._scaf.john.doe._at_.somedomain.com See [8] for a proposal about how to store multiline texts in DNS. 6.2. LDAP It is also possible to use LDAP in corporate networks or when there ever will be a world wide LDAP directory structure completely covering the domain space. It is still to be discussed whether the DN of the object is directly derived from the authorization parameters, such as (objectclass=scaf) at addrfam=ipv4, appl=smtpauth, ou=scaf, dc=... or whether to search for any entry with matching attributes: search (&(objectclass=scaf)(addrfam=ipv4)(appl=smtpauth)) at some basedn. 6.3. Filesystems and Relational Databases It is also possible to store the authorization records in local filesystems or any relational database. For example, if a company A wants to grant the company B access to it's webserver, B could provide an authorization records describing B's network, which is sent to A and stored in A's database. Thus, the authorization records somehow mimic firewall rules or a web server's access permissions. Hadmut Danisch Experimental [Page 10] INTERNET-DRAFT SCAF Jan 2004 References 1. H. Danisch, The RMX DNS RR and method for SMTP sender authorization (Oct 2003). http://www.danisch.de/work/security/txt/draft-danisch- dns-rr-smtp-03.txt. 2. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- els," RFC 2119 (March 1997). 3. Paul Vixie (Ed.), Repudiating MAIL FROM. 4. Meng Weng Wong et al., Sender Permitted From (SPF). http://spf.pobox.com. 5. R. S. Brand, L. Sherzer, R. W. Rognlie, Designated Relays Inquiry Protocol (DRIP). draft-brand-drip-02.txt. 6. G. Fecyk, Designated Mailers Protocol (DMP). draft-fecyk- dmp-01.txt. 7. A. DeKok (Ed.), Lightweight MTA Authentication Protocol (LMAP) Dis- cussion and Applicability Statement (Nov 2003). http://asrg.kavi.com/apps/group_public/download.php/18/draft-irtf- asrg-lmap-discussion-00.txt. 8. Microsoft Corporation, Caller-ID For Email (Jan 2004). Draft History 00 Jan 2004 Author's Address Hadmut Danisch Tennesseeallee 58 76149 Karlsruhe Germany Phone: ++49-721-843004 or ++49-351-4850477 E-Mail: rfc@danisch.de Comments Hadmut Danisch Experimental [Page 11] INTERNET-DRAFT SCAF Jan 2004 Please send comments to rfc@danisch.de. Expiry This drafts expires on Aug 1, 2004. Hadmut Danisch Experimental [Page 12]