user != username != authentication-id, and what's a realm

["Paul B. Hill" <pbh@xxxxxxx>]

Hi,

At the last IETF meeting there were some hallway discussions about the
possible limitations, or implications, of SASL, and how specific SASL
mechanims might interact with CAP or other C&S related protocols. The
following is a short introduction to some of the concepts. I know that some
people that had an early look at this wanted to make comments, but I also
wanted to get this to the list before the next interim meeting. Hopefully
the comments will be made to the list.

Definitions:

User - in the context of this discussion a person, or a physical customer
of a Calendaring and Scheduling system.  A User should not be confused with
the CUA, which is the application or device with which the user interacts.
["The difference is, if you stick a user with a needle, it bleeds." - Bob
Mahoney ]

Username -  An identifier which is intended to map to a user. Note that
usernames do not include host names or service names, because of this
limitation other types of identifiers have been created  for the jargon of
computer security.

Principal - 1) A completely generic term used by the security community to
include both people and computer systems. Coined because it is more
dignified than "thingy" and because "object" and "entity" (which also mean
thingy) were already overused. [1] 2) A uniquely named client or server
instance that participates in a network communication. [2] 3) An entity
which can both prove its identity and verify the identities of other
principals who wish to communicate with it; each user and each service
registered with Kerberos is thus a principal. [3]

authentication-id - The "authentication identifier" used to uniquely
identify the individual connecting to a service. The syntax and semantics
of an authentication-id may be specific to a particular authentication
mechanism, network, and/or host operating system. Coined by people that
couldn't remember what principal means. [4]

Realm -1) Conceptually, it is the name of a collection of accounts that
might include the user's account. Mechanistically, a string to be displayed
to users so they know which username and password to use. [5] 2) A Kerberos
term for all of the principals served by a particular KDC, Key Distribution
Center. [2] 3) Microsoft uses the term Domain to mean Realm in most cases,
the exception being when they talk about DNS domains.

Impersonation vs. on-behalf-of - For the purposes of this discussion
"impersonation" means that a server can reproduce the authentication
information for a user. Doing so permits one server to appear to another
server as if it were the authenticated CUA of the original user.
"On-behalf-of" means that the server is not able to reproduce a user's
authentication and instead must authenticate itself to other servers as a
machine principal. Once it has been authenticated as the machine principal
it may then attempt to carry out the original user's requests.

Some further discussion of the above terms:

Principals, authentication-ids, and usernames are in general simple strings
that do not convey much information. How an authentication mechanism uses
these and other related information has a major impact on system design and
functionality. The following is a brief description of some authentication
mechanisms and their possible impact on the design of a Internet protocol.

Everyone is pretty familiar with the concept of a username, but usernames
are not globally unique. The previous definitions of principal and
authentication-id include uniqueness in the definition.

What do we mean by uniqueness? 

That depends. Uniqueness comes at a price when you try to scale systems to
large numbers. If you try to scale a principal name or authentication-id to
be unique across the entire Internet most names with be difficult to
memorize or type. X.500 addresses the uniqueness with distinguished names,
but most people do not like using DNs in day to day tasks. However, if you
combine a principal name with other information the name will remain
useable by humans but may also be sufficiently unique to be usable on the
Internet. For example paul@mit.edu is sufficiently unique to deliver email
to Paul B. Hill, employed by the Massachusetts Institute of Technology, but
"paul" is not sufficiently unique to be useful on the Internet.

Most IETF participants are familiar with UNIX password files. Traditionally
when using these each host system contains a local copy of a file which
contains a username and an encrypted form of the user's password. Systems
may or may not use a synchronization method to propagate the password
files. In many environments the username "paul" on one machine may not
represent the same user on a different machine. Or the username may
represent the same person but a different password may be required on each
machine. Much of the history of computer security has revolved around
eliminating this source of confusion and the errors that it creates.

SASL, RFC2222, is a framework for implementing strong authentication in an
application. SASL support many different authentication mechanisms. Let's
take a brief look at some of the possible mechanisms and see how they might
impact the functionality of a system.

One possible mechanism is defined in draft-ietf-authentication-03.txt dated
September 2, 1999 and draft-leach-digest-sasl-03.txt. These drafts discuss
the Basic and Digest Access Authentication for HTTP. The first draft is
intended to replace RFC2069. Section 3.1.4 discusses the limitations of the
Digest Access Authentication mechanism. These comments are also directly
applicable to RFC2195, "IMAP/POP AUTHorize Extension for Simple
Challenge/Response".

The Digest authentication scheme suffers from some known limitations. It is
intended as a replacement for Basic authentication and nothing more. It is
a password-based system and (on the server side) suffers from all the same
problems of any password system. In particular, no provision is made in
this protocol for the initial secure arrangement between user and server to
establish the user's password. [6] Users and implementers should be aware
that this protocol is not as secure as Kerberos, and not as secure as any
client-side private-key scheme.  Nevertheless it is better than nothing,
better than what is commonly used with telnet and ftp, and better than
Basic authentication. However, since it prevents chosen plain text attacks,
it is stronger than (e.g.) CRAM-MD5, which has been proposed for use with
LDAP, POP and IMAP (see RFC 2195). It is intended to replace the much
weaker and even more dangerous use of plain text passwords. [5]

Digest Authentication offers no confidentiality protection beyond
protecting the actual password. All of the rest of the challenge and
response are available to an eavesdropper, including the user's name and
authentication realm.  [5]

The draft for HTTP Digest Authentication does offer more than the CRAM-MD5
mechanism defined in RFC 2195. It introduces a realm. This is very
important when you consider the possibility of a CUA connected to one
server but trying to manipulate data on a different server.

A realm may imply many different things depending on the context within
which it is used. For sites using Kerberos a realm maps to a collection of
users and machines within a DNS domain. One Kerberos realm may server an
entire DNS domain. Or a DNS domain may use several different Kerberos realms. 

Ignoring Kerberos for the moment let's look at how a realm may be
interpreted when using traditional UNIX password files. If the password
file is unique to a single host, i.e. not replicated to any other hosts or
centrally managed via some other mechanism, then a realm consists of just
that one machine. However, if a collection of machines have a replicated,
or identical, password file then the realm would map to that collection of
machines. In other words a realm defines the set of machines that have a
consistent username/password pair. (A realm does _not_ include the case
where individual users maintain their own consistent username/password
mapping.)

Assume that Alice uses CUA1 to connect to SV1.example.com and that the
authentication method is CRAM-MD5. Also assume that Alice's principal name
or authentication-id is "alice". Next assume that on the same connection
Alice decides to write to calendar XYZ on SV2.foobar.com. Will this be
permitted? 

My recommendation is NO. If SV1 was able to recreate the CRAM-MD5
authentication for "alice" and "replay" it to SV2 intact there would still
be no guarantee that "alice" on SV1 and "alice" on SV2 both map to Alice.
If neither site forces a good password policy and you scale this scenario
to the Internet it is possible that you could find two systems that had the
same username/password pair but two different users. The degenerate case
occurs when you consider the authentication-id "guest". 

What if we modified the previous scenario slightly. Instead of having SV1
recreate Alice's CRAM-MD5 authentication, SV1 uses any mechanism to
authenticate itself to SV2, as SV1. Then SV1 could assert to its trusting
friend SV2 that it has made sure that "alice" is Alice to please make these
changes to its data. If the initial authentication is done using CRAM-MD5
this behavior is also bad. There is not enough information to determine
that "alice" on SV1 is equivalent to "alice" on SV2.

If we use an authentication method that supports realms we have a lot more
flexibility. Let's assume we have a multi-valued realm where the realms are
example.com and foobar.com. In this case we can assert that
alice@sv1.example.com and alice@sv2.foobar.com both map to the user Alice.
This implies that we can either have SV1 impersonate "alice" and provide
her credentials to SV2, or SV1 can authenticate itself to SV2 as the
service principal sv1@example.com and then assert that it has authenticated
"alice" and would like to modify some data on her behalf.

As the working group refines the VCAR documentation the "authenticated user
list" should be changed to reflect that we want a more complete declaration
which includes a realm or security context information.

ISPs, Portals, and enterprise customers all have very different ways of
managing user information, how could any of this be implemented? 

I think one of the best market segments to compare this against is email
servers. ISPs, Portals, and enterprise customers all buy or build email
servers and manage the user accounts for the system. Some systems have an
internal, proprietary, directory. E.g. the original design of Microsoft
Exchange and Lotus CCmail. Some systems use directories or meta-directories
which are not tightly integrated into the email infrastructure, and which
do not use standard protocols. E.g. the mail systems used at Stanford, CMU,
MIT, and UMich in the late '80s and through most of the '90s. More recently
we have developers understanding the importance of a separate, centralized,
directory which can be accessed via well documented protocols. E.g. LDAP,
NDS, and ADSI being used by Netscape, Novell's Groupwise, and Microsoft
Exchange.  In all cases of using POP3 and SMTP, the CUA does not have to
understand how the server implements its user account management.




Bibliography

[1] "Network Security, Private Communication in a Public World" by Charlie
Kaufman, Radia Perlman, Mike Spencer, Prentice Hall, 1995, ISBN 0-13-061466-1

[2] Kerberos RFC?

[3] "Kerberos: An Authentication Service for Open Network Systems",
Jennifer G. Steiner, Clifford Neuman , Jeffrey I. Schiller

[4] RFC2195, "IMAP/POP AUTHorize Extension for Simple Challenge/Response"

[5] draft-leach-digest-sasl-03.txt, "Using Digest Authentication as  a SASL
Mechanism"

[6] draft-ietf-http-authentication-03.txt, "HTTP Authentication: Basic and
Digest Access Authentication."