Subject: CAP users and authentication

From: Alexander Taler <[email-masked]>
Date: Fri, 11 Jun 1999 17:48:16 -0400

The following is a proposal for how CAP should handle authentication
and user identities.  This proposal goes hand-in-hand with Paul Hill's
proposal from yesterday.

    In CAP access to calendar data is determined using the value of
    the "OWNER" property of a "VCALENDAR", and the "GRANT" and "DENY"
    properties of "VCAR" components.  The values of these properties
    are UPNs.

    The CUA of a CAP session must identify itself as such a UPN so
    that access rights can be determined for its attempts to access
    the calendar store.  This UPN need not be the authentication id
    with which the CUA authenticates to the CS, but is associated with
    the authentication id through an internal server mapping.  This
    UPN is called the identity for the session.

    A CAP session may be assigned a default identity by the server
    immediately after a successful authentication.  This identity is
    communicated to the CUA through the advertised capabilities.  A
    CUA may also select or change identity using the CAP "IDENTIFY"
    command which takes such a URI as a parameter.  The success of
    this command is determined by the CS in an implementation specific
    fashion.

    Once a CAP session has gained an identity it can proceed to
    perform calendar access.  All such access will be governed by the
    CAP access paradigm, and the identity of the CAP session.  Prior
    to the gaining of an identity no calendar access may be performed.

The important feature of this proposal is that it divorces the
id used in authentication from the id used for governing CAP access
control.  This is advantageous because it makes the calendaring
database independent of the current authentication mechanism.

With this scheme I can choose among several authentication mechanisms,
but once I am authenticated to the system I have exactly the same
identity.  (I may use Kerberos in the office, but a One Time Password
when I am on the road.)  Furthermore, upgrading authentication
mechanisms is merely a matter of installing an authentication module
into the server and updating the mapping table between auth-ids and
CAP user URIs.

This scheme also allows a single authentication id to assume any
number of CAP identities.  The sysop could assume any identity on the
system, and resource managers could assume the identity of any of
their resources.

The following examples illustrate how this system could be
implemented.

1] Single User, Single Authentication scheme

Plato authenticates to the calendar store "cal.ancients.org" (a),
using the Digest-MD5 mechanism (b).  His realm is "ancients.org" (c),
his authentication id is "plato" (d), his password is "Forms" (e), his
identity for the calendar store is "[email-masked]" (f).
The calendar store is made up of three components:

        --------------------------------------------------
        |      Auth Module       |    Calendar Store     |
        |                        |                       |
        |                        |   ------------------  |
        |                        |   |  session       |  |
        |                        |   |                |  |
        |                        |   |Auth:(b)+(c)+(d)|  |
        -------------------------|   |Identity: (f)   |  |
        |    Mapping Module      |   |                |  |
        |                        |   ------------------  |
        | (b)+(c)+(d) -> (f)     |                       |
        |                        |                       |
        |                        |                       |
        |                        |                       |
        --------------------------------------------------

Plato uses his CUA to connect to cal.ancients.org on port <xxx>.  His
CUA then issues the CAP AUTHENTICATE command with the DIGEST-MD5
mechanism name.

CUA: AUTHENTICATE DIGEST-MD5

. . .

CS:  2.0

The CUA performs the authentication exchange with the
authentication module of the Calendar Server, and successfully
authenticates with auth id "plato" in realm "ancients.org".  This
information is added to the session information stored by the calendar
server.

Before the CUA can perform any calendar access it must obtain an
identity for the session by calling the "IDENTIFY" command.

CUA: IDENTIFY [email-masked]
CS:  2.0 [email-masked]

The calendar server queries the mapping module, to determine if the
current authentication allows the assumption of the requested
identity.  In this case the table inside the mapping module indicates
that is allowed, so the calendar server updates the session
information to include the assumed identity, and returns status code
2.0.

2] Single User, Multiple Authentication schemes.

In this example Xanthippe uses a calendar store which provides access
using either Kerberos or One Time Password.  She is on the road, and
does not have access to the Kerberos server, so she wishes to use One
Time Password to connect to the server.

Her particulars are: calendar store "cal.ancients.org" (a), OTP
mechanism (b), OTP realm "." (c), OTP auth-id "[email-masked]"
(d), Kerberos Mechanism (e), Kerberos realm "ancients.org" (f),
Kerberos auth-id "xanthippe" (g), and calendar store identity
"[email-masked]" (h).

When she authenticates using OTP, and identifies as (h), the calstore
looks like this:

        --------------------------------------------------
        |      Auth Module       |    Calendar Store     |
        |                        |                       |
        |                        |   ------------------  |
        |                        |   |  session       |  |
        |                        |   |                |  |
        |                        |   |Auth:(b)+(c)+(d)|  |
        -------------------------|   |Identity: (h)   |  |
        |    Mapping Module      |   |                |  |
        |                        |   ------------------  |
        | (b)+(c)+(d) -> (h)     |                       |
        | (e)+(f)+(g) -> (h)     |                       |
        |                        |                       |
        |                        |                       |
        --------------------------------------------------

Note that it contains mappings for both authentication mechanisms to
the same identity.