Subject: Is there a capability RFC?

From: "David L. Nicol" <[email-masked]>
Date: Mon, 09 Jul 2001 20:55:16 -0500

Reading the open issues of 

http://www.normos.org/ietf/draft/draft-ietf-calsch-inetcal-guide-00.txt

(section 5.1 and 5.2)

and the bits about Security, which seem "tacked on," it occurs to me
that a Standard Capability Protocol (capabilities are 1024 bits long,
they include time-stamps and encooded origin info in a standard way,
etcetera) would be a very good thing, if it doesn't exist already,
and it would allow interoperability in much more interesting ways
that the complex mutual trust relationships that the state-of-the
art seems to require.

For instance, the "ability to flood a calendar system with bogus
requests" could be greatly mitigated by use of capabilities in the
basic archtecture.  If every event is persistently tagged with the
capability under which it was posted, removing (and submitting for
re-moderation) all events posted under a compromised capability becomes
trivial.

Using capabilities, all the iTIP (rfc 2446) activities could be safely
delegated.  In fact, anything restricted to any RFC-defined entity
could be safely delegated.

For now, rfc 2445 does define X-* extensions, reserved for experimentation,
so a suite of calendaring products that went ahead and implemented some
kind of X-CAPABILITY field that could cause a CS to eliminate or skip over 
certain administrative checks could exist,  but compliant release, in
light of

     ; Reservered for experimental use. Not intended for use in
     ; released products.

would require CAPABILITY to be promoted to a listed element of something.
Perhaps CAPABILITY would be best inserted as part of MIME rather than
this particular MIME-encapsualted application?

And there remains the big-picture problem of where are all the laid-off
personal secretaries supposed to do once it becomes possible to give
someone a capability code and have a reasonable expectation of
the recipient being able to leverage it into a meeting appointment
with no further human interaction?

-- 
                                           David Nicol 816.235.1187
      Series EE bonds can be exchanged for Series HH savings bonds.

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Jul 2001 12:03:47 -0400

"David L. Nicol" wrote:

> it occurs to me

Can you define "capability" better, please? I don't follow what you want it
for.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |The light at the end of the tunnel is a terawatt|
[email-masked]|laser cannon.                                   |
\=================================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Jul 2001 13:50:00 -0400

> that the complex mutual trust relationships that the state-of-the

(Thanks for explaining what capabilities are, Ronald.  I have doubts that a
generic capabilities protocol would work well first try; better to try using
special-purpose versions in a few IETF protocols first, then build on that
experience.)

Could you expand on how capabilities would let us do away with mutual trust
relationships? It seems to me that a capability actually encodes a mutual
trust relationship.

> basic archtecture.

How? You still need to examine each request to determine whether it's
authenticated.

> If every event is persistently tagged with the

(a) How is this different from removing events posted by a particular user
during a particular time range?
(b) What about events posted by the legitimate user of the capability?

> with no further human interaction?

I'm not sure that this is a desirable goal.  A meeting *is* human interaction;
it necessarily involves investing humans' time.  Better to invest a small
amount of time deciding whether to go than to waste time going because you
delegated your decision-making to a cryptographic token.

Ultimately, there will always have to be a human-level intelligence deciding
whether to accept a meeting invitation, because my calendar does not encode my
entire life.  I have no events scheduled on Saturday; that doesn't mean I'm
willing to accept meeting invitations on Saturdays.  I spend most of each work
day on programming and so forth, which doesn't show up in my calendar; that
doesn't mean that people are free to fill up my calendar with invitations.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Te audire no possum. Musa sapientum fixa est in|
[email-masked]|aure.                                          |
\================================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 10 Jul 2001 16:01:10 -0500

I was looking at the SKiCal draft document recently and realized that it
expired as of June 28th, 2001 - has a new version been prepared and
submitted?

Thanks,

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Jul 2001 10:49:21 -0400

"David L. Nicol" wrote, on a separate list but CC:ed to me:

> John Stracke wrote:
> "capability" is a robust method for delegating (and rescinding, and
> tracking)
> authority or all kinds.
>
> Not Authenticity, but Authority.
>
> X session cookies are a good example.  Another is the random codes that
> prevent
> fake mailing list subscriptions.  CGI session cookies too -- they are
> random
> strings of characters that give one the capability to use a particular
> shopping
> cart object.
>
> If iCal (or MIME, for that matter) had a standard CAPABILIT[Y|IES]: header
> built
> into it, I, as an operator of a calendar, could ask my calendar for some
> posting
> capabilities which would expire at the end of the year, and distribute
> these
> capabilities (they would look like PGP signatures -- you know, binary
> garbage)
> to the people who are authorized to list events on the calendar, and they
> would
> use capability-aware tools to submit the items to the calendar, which would
> include the capability, associated with the event they are sending in, and
> the
> calendar would check the capability, and if it is good, go ahead and list
> the event, and if it is not, the calendar would pass it on for moderating.
>
> I believe this is desired functionality which is not currently addressed by
> the standard, in fact it is explicitly delegated to the implementors.

And for good reason: the IETF generally avoids trying to do things that don't
have wide experience yet; it makes for working groups that trail off into death
spirals.

Implementers of the various iCalendar protocols can experiment with capabilities
on their own; if they turn out to be useful, then they can be standardized.

> Capabilities could become a framework for authorization interoperability.
>
> I am not suggesting that any of the flexiblity in designing arbitrarily
> complex authorization systems be taken from the implementors; I am merely
> suggesting that specifying a place for such information to go, if it is
> used in an implementation, would ease interoperability.
>
> Since a general purpose authority delegation scheme is larger than
> calendaring
> (standardizing VERPs comes to mind as another possibility -- a VAriable
> Envelope
> Return Path could be considered as a Capability that allows a MTA,
> "exercising
> it" by bouncing a mail to the address, to unambiguously report a problem
> with
> a particular address) I think an RFC on incorporating them into MIME, which
> would then get inherited by all projects that rely on MIME, would be a
> better
> solution than including them in the iCalendar project.
>
> Including them in the iCalendar project, and expecting them to get
> back-ported
> into MIME, makes sense too.
>
> --
>                                            David Nicol 816.235.1187
>                    "Perl was born in downtown Hell!" -- Matt Youell

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |We want forty million helicopters and a dollar!|
[email-masked]|--"Dinosaurs"                                  |
\================================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Wed, 11 Jul 2001 11:23:40 -0500

> relationships? It seems to me that a capability actually encodes a mutual

The overview draft defers encoding of trust relationships to the
implementations.  Providing a standard encoding method for them would 
increase interoperability.  "To post to the calendar, use the attached
key" could be given, without verifying that the CUA that will be used
uses the same vendor-extended key protocol.

> How? You still need to examine each request to determine whether it's

a capability could, for instance, be associated with an upper limit
of number of posts can be made with it.  This can be done with user
accounts as well, certainly, and the complexity is about equal, and
associating a capability with a user account would be a reasonable way
to implement the limit.

> during a particular time range?

"By a particular user" is more vague, as it doesn't address how we know it
was them.

> (b) What about events posted by the legitimate user of the capability?

"... and submitting for re-moderation"

Anyway, what about entities that are not individual people?  Wedging
them into "user accounts" is standard practice, yes, but that doesn't
make it elegant.

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Jul 2001 13:45:59 -0400

"David L. Nicol" wrote:

> of number of posts can be made with it.

Then you still need to do a database lookup to decide whether that limit's been
reached.

There is simply no way for an access control mechanism to prevent DoS attacks,
because an effective attack can be mounted just by making lots of bogus
requests, to force the access control system to come into play.  A more
sophisticated access control system may actually be a liability, if it requires
more computrons to evaluate each request.

> "... and submitting for re-moderation"

Uh...that's not trivial.  Technically simple, yes; but it requires vast amounts
of time from the legitimate user.

> them into "user accounts" is standard practice, yes, but that doesn't

Elegant? You want elegant? Have you *looked* at the syntax of iCalendar? :-) Or
MIME, or LDAP? These things are not elegant at all; that's not the design goal.
But they work, where some more elegant proposals have died away.  If you want
the IETF to spend time on capabilities, elegance won't be enough of a reason.

In any case, I don't think this WG can afford to take on more work right now.
Maybe in another year.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Help stamp out vi in our lifetime!           |
[email-masked]|                                             |
\==============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Wed, 11 Jul 2001 12:47:00 -0500

John Stracke wrote:
> 
> the IETF generally avoids trying to do things that don't

Wide experience:

	SPKI "CERTIFICATES"
	X MIT-MAGIC-COOKIE
	HTTP-COOKIE

to list just three, which are in use.

> on their own; if they turn out to be useful, then they can be standardized.

I am not suggesting standardizing the full range of what they might be used
for,
simply requesting that the standard include a place to put them if an
implementation
includes them.  Otherwise, interoperabilty is difficult, in light of the
no-extensions-allowed-in-releases nature of the standard.

I'm also repeating myself to a fault, so I'll stop now.

---

From: "David L. Nicol" <[email-masked]>
Date: Wed, 11 Jul 2001 13:27:13 -0500

> of time from the legitimate user.

Right.  This problem is still there with tradional authenticion implying 
authority, and it is worse, because it is not fine-grained.

If I want to let Jeff post to my calendar and I loan him my calendar
password,
maybe that password does other things too.  If I can have my calendar
create a one-time-use certificate, I can give that away and I don't have
to change my password or worry.

> more computrons to evaluate each request.

Now you're just being difficult.  As a DoS perpetrator, I am sure there
are more resource-intensive things I can do to your box than forge a
gazillion
bogus CUA requests.  For instance, forge a gazillion SMTP requests.

> In any case, I don't think this WG can afford to take on more work right now.

Fair enough.  When I have a working calendar with a full-blown delegation
system, I'll tell you about it.

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Jul 2001 14:54:13 -0400

"David L. Nicol" wrote:

> authority,

True.

> and it is worse, because it is not fine-grained.

See below.

> maybe that password does other things too.

Existing calendar systems handle this by supporting proxy users, or access control
lists.  Rather than give Jeff your calendar password, you tell the system that he
has certain rights on your calendar, and then he logs in as himself.  Then, if Jeff
abuses his privileges, it's known which events came from him, just as well as with
capabilities.

> Now you're just being difficult.

Not at all.  You claimed that capabilities solved the DoS problem; I'm just showing
that that's not possible.

> As a DoS perpetrator, I am sure there

That's if my CS box is running an SMTP server, and permits access to it.  For large
installations, this is unlikely; servers are likely to be single-function, for
effiency and ease of administration.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"You're nothing but a pack of ringleaders!"  |
[email-masked]|--_Wyrd Sisters_, Terry Pratchett            |
\==============================================================/