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]