Subject: CAP Issue: Decreed VCARs

From: [email-masked] (Steve Mansour)
Date: Thu, 19 Jul 2001 17:08:58 -0700

Hey All,

I'm trying to determine if there is any detectable difference between a
decreed vcar versus any other vcar. If there is no difference between
them, I'm wondering how we would know a vcar is decreed.

Are they declared differently than any others? Is there anything about
their data content that distinguishes them from any other vcar? What
does a query for the decreed vcars look like?

If you have an idea about how they work, please reply and help me out.

If no one has good answers to these questions, and since decreed vcars
are a "MAY" implement, I think we should we drop them. Any comments on
that?

-Steve

---

From: "David L. Nicol" <[email-masked]>
Date: Mon, 23 Jul 2001 13:54:05 -0500

to avoid getting distracted by an irrelevant discussion, please
skip ahead to the line marked "PLEASE SKIP TO THIS POINT."

Steve Mansour wrote:

> > How do you feel about the AUTHORIZE suggestion?  Nobody wrote back about
> > it and I'm having Warnock's Dilemma.
> 
> I'm scared of it. I think anything that deals with authentication is a difficult
> point.

It deals with authorization, not authentication.  Authentication is dealt
with
thoroughly already.

>  I think for us to try to specify a generic way to make two servers establish
> a trust model is a *hard* problem. 

That is not the problem AUTHORIZE was proposed to solve.  The problem
AUTHORIZE
was proposed to solve is anonymous or partial delegation.  There is
language in the
current draft standard dealing with delegation, but the mechanisms proposed
(impersonation) are clumsy.

I believe that striking all mention of impersonation and replacing all
delegation
systems with a SPKI-certificate based system would be a good step.

> I think it will slow us down for a long time. I
> think it is a solvable problem, but we have *SO* much going on in CAP already, I
> feel like we need to focus on the absolute minimum subset.  I think that we should
> leave trust models up to server vendors, and when somebody comes up with a good
> solution, they should write up a separate draft that covers the topic.

The current draft standard has nowhere in it for presentation of an SPKI
certificate.
The AUTHORIZE command is proposed as How To Present An SPKI Certificate. 
How that
certificate is to be obtained and what it might mean are deferred to
implementors.

> Don't get me wrong. I think it's an important problem to solve. I think it will be
> awesome to have cap servers talking to each other using a trust model.  I just
> think we not focus on that problem now.

Having calendar stores talking with each other (via something like nntp)
may be
difficult (I personally don't see it, having operatied a usenet server
for several years) but that is ABSOLUTELY NOT the problem that the
AUTHORIZE
command is proposed to solve (although SPKI is general enough to solve
it: have the CS peer present a certificate authorizing itself as a peer,
then synchronization occurs.  More likely might be a database system that
already has synchronization (files in CODA, or recent Oracle releases, for
instance)
could be used as the storage for a distributed Calendar Store, making the
synchronization entirely a vendor problem.  But I am following your
digression
here.

PLEASE SKIP TO THIS POINT

The SPKI documents  need not be read in their entirety to understand
the theory of authentication certificates.  Here is the relevant passage:

>    The authorization certificates that are envisioned for SPKI (and
>    needed to meet the demands of the list given at the end of this
>    document) should be generated by any keyholder empowered to grant or
>    delegate the authorization in question.

Calendar editing rights are a problem domain where delegation
happens all the time.  An explicit anonymous delegation mechanism is not
mentioned.  Not for cs-cs data sharing.  For delegation of very small
access rights without needing to create dummy users.

Creating dummy users is objectionable for these reasons:

	1: it interferes with having identity checked by an outside server,
or requires that the delegator have the authority to create accounts on the
identity server

	2: it may require switching the identity options on one's CUA, or
"impersonating," which are both ugly things.

	3:  a standard CS would need to either have its own cache of fake users
for use in delegation situations only write access to the indentity server.

the AUTHORIZE command, as I suggested last week, would allow a calendar
owner
to create arbitrary rights and grant them to the bearer of a certificate. 
This
would mean that the calendar owner could issue a certificate that allows
the bearer of it to, for instance, edit the description of the event that
occurs
in conference room 3 every tuesday at 2 PM.

I realize now that without a standard GENERATE command for specifying the
scope of a bearer-certicicate authoirzation would be, the AUTHORIZE
standard
might be weaker.  But Generating makes more sense to me as a CS-implementor
issue.  For interoperability, there needs to be a standard way to present
your SPKI authenticaion certificates, no matter how they were generated.  I 
looked through the whole standard trying to figure out where a good place
to shoehorn them in would be, and there isn't one.

GENERATE/AUTHORIZE is a cleaner solution to anonymous delegation than
impersonation of fake users.  It provides impersonation (ability to
operate with someone else's authority) without the security problems
of allowing someone to operate with someone else's full authority.

It is even possible to restrict a generated certificate to only work
when presented by a user who is already authorized to present it, for
instance.  These things can be arbitrarily complex, which is why
I think the operation of the GENERATE primitive, if it is included as
well, needs to be defined loosely enough to allow for arbitrary
vendor extensions.

-- 
                                           David Nicol 816.235.1187
                       "Mary had a little chainsaw" -- Angus Oblong

---

From: John Stracke <[email-masked]>
Date: Mon, 23 Jul 2001 16:09:12 -0400

>>>it and I'm having Warnock's Dilemma.
Nobody wrote back because we already turned you down.  This is not the 
time for mission creep.

>The current draft standard has nowhere in it for presentation of an SPKI
(Side note: please learn the language--go read RFC-2026.  Draft Standard 
is a reserved word in the IETF, and you're misusing it.)

Can't you use TLS? IIRC, CAP uses SASL, SASL has STARTTLS, TLS has 
certs.  (If the problem is that it doesn't have the right *kind* of 
certs, don't tell us; go talk to the TLS WG.)

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |If you're going to walk on thin ice, you might|
[email-masked]|as well *dance*!                              |
\===============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Mon, 23 Jul 2001 17:25:00 -0500

> certs, don't tell us; go talk to the TLS WG.)

Like I said before, TLS is about authentication, not authorization.

-- 
                                           David Nicol 816.235.1187

---

From: "David L. Nicol" <[email-masked]>
Date: Mon, 23 Jul 2001 18:06:44 -0500

> Like I said before, TLS is about authentication, not authorization.

Rather, TLS is about having an encrypted channel.  SASL is about
authentication.
Neither one of them is about authorization.  Trying to cram 
authorization certs into either one of them makes less sense than
setting up limited dummy users, which is the solution in line with
the current version of the draft of the document this mailing list
is working on, whatever its proper name is.

---

From: George Babics <[email-masked]>
Date: Mon, 30 Jul 2001 12:00:40 -0400

I believe decreed VCARs can be useful. It allows an administrator
to prevent users changing certain access rights on their calendars.
For instance, one can have a decreed VCAR that prevents users from
making their calendars modifiable by anonymous users.

As for the differences between VCARs and decreed VCARs:

  The UPN for GRANT and DENY seems to be special users of "OWNER"
and "*". That is rights can be denied or granted to everyone and
to all owners. One can do a query for these types of VCARs.
(However, all the above is not clearly defined in CAP. We should
add an example and clarify what decreed VCARs mean.)

  Another difference is that VCARs are owned by the CS
administrator. CAP also says that they are immutable. However,
a CS administrator may want to change it at some point.

  Decreed VCARs are a MAY. If we do remove them from CAP, an implementor
may decide to implement these security features in their own way. 
However, decreed VCARs seem straightforward, useful, and do not add
complexity to CAP. Thus, we could leave them in CAP. However, we may
want to change their being immutable.

George

---

From: [email-masked] (Steve Mansour)
Date: Mon, 30 Jul 2001 21:40:55 -0700

George,

How do you know, given a particular VCAR, whether or not it is decreed? Since
decreed vcars cannot be overridden, we have to know.  For example

     BEGIN:VCAR
      CARID:Users Default Access
      GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
      DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
       VALUE="Users Default Access"
       ;OBJECT=METHOD,VALUE=DELETE,MODIFY
      END:VCAR

What is it about this VCAR that is tells me that it is decreed?

The complexity decreed vcars is that they add at least two exception cases
that I can see. The complexity is small, but it is present. First, they
override all others VCARs. So for every access control check you'll need to
check decreed vcars first to see if they apply, and if they don't, then you
apply the normal vcars. Second, they cannot be changed -- which, I assume,
means that only an administrator can change them, because someone will
inevitably make a mistake on a decreed vcar and need to change it. So, there
will need to be some sort of special handling to create/modify/delete them.

-Steve