Subject: revised security section

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 27 Jan 2000 10:59:19 -0500

Hi,

Rich, Dave, Bob and I thought that we sent this out on Wednesday afternoon 
but it never made it to the list :(

---

Suggested replacements to existing sections: 2.4, 2.5, 2.7, 6.0. These 
changes create sections:

2.4 Security Model
2.4.1 Authentication, Credentials, and Identity
2.4.2   Calendar User and UPNs
2.4.2.1 UPNs and Certificates
2.4.2.2 Anonymous Users and Authentication
2.4.3   User Groups
2.4.4   Access Rights
2.4.4.1 VCalendar  Access Right (VCAR)
2.4.4.2 Enforced VCARs
2.4.4.3 Inheritance
2.4.4.4 Policies

This text will later be followed by new text for the AUTHENTICATE command. 
And even later more text of calendar addresses, including stuff on mapping 
UPNs to CSIDs, Calendar Collections, and Resource Calendars.

Paul

----------------------------------

2.4 Security Model

Authentication to the CS will be performed using SASL [RFC2222].

As noted in the CAP system model section, a variety of connectivity 
scenarios are possible. This complicates the security model considerably, 
and a thorough familiarity with the concepts is required to ensure 
interoperability.

Basic threats to a Calendaring and Scheduling System include:

(1)     Unauthorized access to data via data-fetching operations,
(2)     Unauthorized access to reusable client authentication information 
by monitoring others' access,
(3)     Unauthorized access to data by monitoring others' access,
(4)     Unauthorized modification of data,
(5)     Unauthorized or excessive use of resources (denial of service), and
(6)     Spoofing of CS: Tricking a client into believing that information 
came from the CS when in fact it did not, either by modifying data in 
transit or misdirecting the client's connection.

Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), and 
(3) are due to hostile agents on the path between client and server, or 
posing as a server.

CAP can be protected with the following security mechanisms:

(1)     Client authentication by means of the SASL [RFC2222] mechanism set, 
possibly backed by the TLS credentials exchange mechanism,
(2)     Client authorization by means of access control based on the 
requestor's authenticated identity,
(3)     Data integrity protection by means of the TLS protocol or 
data-integrity SASL mechanisms,
(4)     Protection against snooping by means of the TLS protocol or 
data-encrypting SASL mechanisms,
(5)     Resource limitation by means of administrative limits on service 
controls, and
(6)     Server authentication by means of the TLS protocol or SASL mechanism.

Imposition of access controls (authorizations) is done by means of VCARs, 
an overview is provided in section 2.4.4.1, and a detailed syntax is 
provided in section 14.5.  Authentication is explained in detail in section 
7.1.3.

2.4.1 Authentication, Credentials, and Identity

Generically, authentication credentials are the evidence supplied by one 
party to another, asserting the identity of the supplying party (e.g. a 
user) who is attempting to establish an association with the other party 
(typically a server). Authentication is the process of generating, 
transmitting, and verifying these credentials and thus the identity they 
assert. An authentication identity is the name presented in a credential.

There are many forms of authentication credentials. The form used depends 
upon the particular authentication mechanism negotiated by the parties. For 
example: X.509 certificates, Kerberos tickets, simple identity and password 
pairs. Note that an authentication mechanism may constrain the form of 
authentication identities used with it.

SASL only provides a protocol to negotiate a mutually acceptable 
authentication mechanism. SASL itself does not constrain or dictate the 
form of the authentication identities used to perform the authentication.
2.4.2   Calendar User and UPNs
A Calendar User(CU) is an entity that can be authenticated. It is 
represented in CAP as a UPN. A UPN is the owner of a calendar and the 
subject of access rights.
The UPN representation is independent of the authentication mechanism used 
during a particular CUA/CS interaction. This is because UPNs are used 
within VCARs. If the UPN were dependant on the authentication mechanism, a 
VCAR could not be consistently evaluated. A CU may use one mechanism while 
using one CUA but the same CU may use a different authentication mechanism 
when using a different CUA, or while connecting from a different location.

The user may also have multiple UPNs for various purposes.

Note that the immutability of the user's UPN may be achieved by using 
SASL's authorization identity feature. (The transmitted authorization 
identity may be different than the identity in the client's authentication 
credentials.) [RFC2222, section 3] This also permits a CU to authenticate 
using their own credentials, yet request the access privileges of the 
identity for which they are proxying [RFC2222]. Also, the form of 
authentication identity supplied by a service like TLS may not correspond 
to the UPNs used to express a server's access control policy, requiring a 
server-specific mapping to be done. The method by which a server composes 
and validates an authorization identity from the authentication credentials 
supplied by a client is implementation-specific.

The authorization identity feature SHOULD not be used to provide an 
alternate mechanism to implement the ACTONBEHALFOF policy, that is 
described in section 2.4.4.3[ editor check before final cut].

For Calendaring and Scheduling Systems that are integrated with a directory 
system, the CS MUST support the ability to configure which schema attribute 
stores the UPN. The CS MAY allow one or more attributes to be searched for 
the UPN.
2.4.2.1 UPNs and Certificates
When using X.509 certificates for purposes of CAP authentication, the UPN 
should appear in the certificate. Unfortunately there is no single correct 
guideline for which field should contain the UPN.

 From RFC-2459, section 4.1.2.6 (Subject):
 If subject naming information is present only in the subjectAltName 
extension (e.g., a key bound only to an email address or URI), then the 
subject name MUST be an empty sequence and the subjectAltName extension 
MUST be critical.

Implementations of this specification MAY use these comparison rules to 
process unfamiliar attribute types (i.e., for name chaining). This allows 
implementations to process certificates with unfamiliar attributes in the 
subject name.

In addition, legacy implementations exist where an RFC 822 name is embedded 
in the subject distinguished name as an EmailAddress attribute.  The 
attribute value for EmailAddress is of type IA5String to permit inclusion 
of the character '@', which is not part of the PrintableString character 
set.  EmailAddress attribute values are not case sensitive (e.g., 
"[email-masked]" is the same as "[email-masked]").

Conforming implementations generating new certificates with electronic mail 
addresses MUST use the rfc822Name in the subject alternative name field 
(see sec. 4.2.1.7 [of RFC 2459]) to describe such identities.  Simultaneous 
inclusion of the EmailAddress attribute in the subject distinguished name 
to support legacy implementations is deprecated but permitted.

Since no single method of including the UPN in the certificate will work in 
all cases, CAP implementations MUST support the ability to configure what 
the mapping will be by the CS administrator. Implementations MAY support 
multiple mapping definitions, for example, the UPN may be found in either 
the subject alternative name field, or the UPN may be embedded in the 
subject distinguished name as an EmailAddress attribute.

Note: If a CS or CUA is validating data received via iMIP, if the 
"ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random 
User:[email-masked]" then the email address should be checked against 
the UPN, and the CN should also be checked. This is so the "ATTENDEE" 
property couldn't be munged to something misleading like "ATTENDEE;CN=Joe 
Rictus User:[email-masked]" and have it pass validation. This validation 
will also defeat other attempts at confusion.

2.4.2.2 Anonymous Users and Authentication
Anonymous access is often desirable. For example an organization may 
publish calendar information that does not require any access control for 
viewing or login. Conversely, a user may wish to view unrestricted calendar 
information without revealing their identity.

For anonymous access the UPN that MUST be used by the CUA is "@", a UPN 
with a null username and null realm. A UPN with a null username, but 
non-null realm, such as "@foo.com" may be used to mean any identity from 
that realm, which is useful to grant access rights to all users in a given 
realm. A UPN with a non-null username and null realm, such as "bob@" could 
be a security risk and MUST not be used.

For detailed syntax information on anonymous authentication please refer to 
the AUTHENTICATE command in section 7.1.3.
2.4.3   User Groups
A User Group is used to represent a collection of CUs or other UGs that can 
be referenced in VCARS.  A UG is represented in CAP as a UPN.  The CUA 
cannot distinguish between CUs and UGs.

UGs are expanded as necessary by the CS.  The CS MUST accept a CUA request 
for UG expansion, although the CS may be configured to restrict some 
responses.  The CS MAY expand a UG (including nested UGs) to obtain a list 
of unique CUs.  Duplicate UPNs are filtered during expansion.  Incomplete 
expansion should be treated as a failure.

[ Editor's Note: We need to explore the issue and impact of directory 
permissions and precedence.]

The CS SHOULD not preserve UG expansions across operations.  A UG may 
reference a static list of members, or it may represent a dynamic 
list.  Each operation SHOULD generate its own expansion in order to 
recognize changes to UG membership.  However, during fan out to other CSs, 
the originating CS SHOULD expand all UGs so that the target CS receives 
only a list of unique CUs.  This is to prevent confusion when two CSs do 
not share the same UG database or directory.

[Editor's Note: Doug had an issue here relating to multiple CUs not having 
a common directory.  We think the above text resolves this]

CAP does not define commands or methods for managing UGs.

Examples:

      Small UG - The Three Stooges.  There is only and always three at any 
one time.
      Large UG - The MIT graduating class of 1999.  This is a static list.
      Dynamic UG - The IETF membership, which is a large and changing list 
of members.
      Nested UG - The National Football League, made up of the AFC and NFC, 
which are made up of 3 divisions each...
2.4.4   Access Rights
In simple terms, access rights are used to grant or deny access to a 
calendar for a CU. CAP defines a new component type called a 
VCalendar  Access Right (VCAR). Specifically, a VCAR grants, or denies, 
UPNs the right to read and write components, properties, and parameters on 
calendars within a CS.

The VCAR model does not put any restriction on the sequence in which the 
object and access rights are created. That is, an event associated with a 
particular VCAR might be created before or after the actual VCAR is 
defined. In addition, the VCAR and VEVENT definition might be created in 
the same iCalendar object and passed together in a single command.

All rights MUST be denied unless specifically granted; individual VCARs 
MUST be specifically granted to an authenticated CU.
2.4.4.1 VCalendar  Access Right (VCAR)

Access rights within CAP are specified with the "VCAR" calendar component, 
"RIGHTS" value type and the "GRANT", "DENY" and "CARID" component properties.

Properties within an iCalendar object are unordered. This also is the 
case      for the "GRANT", "DENY" and "CARID" properties. Likewise, there 
is no implied ordering required for components of a "RIGHTS" value type 
other than that specified by the ABNF. [ editor's note, this requires a lot 
of review. We think that this paragraph may be incorrect. ]

For details on the VCAR syntax please see section 14.4
2.4.4.2 Enforced VCARs
[ editor's note: new concept. This will also require some syntax 
modification 14.4]

A CS MAY choose to allow forced VCARs on all calendars. This is not the 
same as inheritance.

2.4.4.3 Inheritance

Calendars inherit VCARs from their parent.

VCARs specified in a calendar or a sub-calendar override all inherited VCARs.
2.4.4.4 Policies
Calendar access policies are individual sets of well-defined VCARs that can 
be referenced by their policy name. CAP specifies some standard POLICIES 
that are necessary for interoperability between CS and CUA implementations. 
The POLICY rule part of a VCAR is used to specify these policies.

For details on the VCAR syntax please see section 14.4

NOTE: Possible calendar access policy that may be standardized by CAP  include:

- READBUSYTIMEINFO - Specifies rights for reading busy time data.

- ACTONBEHALFOF - Specifies rights for any CAP function taken on PUBLIC or 
PRIVATE calendar components. However, no CAP function can be taken on 
CONFIDENTIAL classified calendar components.

- REQUESTONLY - Specifies rights for creating new event invitations, to-do 
assignments and journal entries.

- UPDATEPARTSTATUS - Specifies rights for modifying ones own participation 
status.

- OWNER - Specifies the same rights given to the owner of the  calendar 
store or calendar.

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 10:13:31 -0800

> of review. We think that this paragraph may be incorrect. ]

This looks convenient:

	BEGIN:VCAR
	GRANT:UPN=all;<rule-set-Alpha>
	DENY:UPN=[email-masked];<rule-set-Alpha>
	DENY:UPN...;<rule-set-Alpha>
	...
	END:VCAR

and might be different than:

	BEGIN:VCAR
	DENY:UPN=[email-masked];<rule-set-Alpha>
	DENY:UPN...;rule-set-Alpha>
	...
	GRANT:UPN=all;<rule-set-Alpha>
	END:VCAR

If we do not order them, how can we do this? I think we
need to be able to do this. I don't think that we can
specify process ordering (as in DENY then GRANT) as
the example can be reversed:

	BEGIN:VCAR
	DENY:UPN=all;<rule-set-Alpha>
	GRANT:UPN=[email-masked];<rule-set-Alpha>
	GRANT:UPN...;<rule-set-Alpha>
	...
	END:VCAR

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 10:19:05 -0800

> A CS MAY choose to allow forced VCARs on all calendars. This is not the

Also needs new text. What is a 'forced' VCAR?

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 10:54:33 -0800

(I know the text I am commenting below is mostly from the existing CAP-DRAFT,
but I think they need comments).

> - READBUSYTIMEINFO - Specifies rights for reading busy time data.

Not specific... 
 
Does:

	BEGIN:VCAR
	CARID:my carid
	GRANT:UPN=<upnlist>;POLICY=READBUSYTIMEINFO
	END:VCAR

(1) Specify the rights for reading VFREEBUSY components? As in:

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	GRANT:UPN=<upnlist>;OBJECT=VFREEBUSY;ACTION=READ
	END:VCAR

(2) Or do you mean perform any VQUERY with DTSTART/DTEND/DURATION ?
    as in:

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	GRANT:UPN=<upnlist>;OBJECT=DTSTART,DTEND,DURATION;ACTION=READ
	END:VCAR

(3) Or do you mean both? As in:

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	GRANT:UPN=<upnlist>:OBJECT=VFREEBUSY,DTSTART,DTEND,DURATION;ACTION=READ
	BEGIN:VCAR

I think the talks in the past meant (1), I am not sure and we
need to exactly specify its meaning.

If we mean (1), then what is to keep CUs from doing a VQUERY for
DTSTART/DTEND/DURATION and getting the same information outside of
using a VFREEBUSY?  Perhaps circumventing what the CU/administrator
thought they were getting with POLICY READBUSYTIMEINFO + DENY.
As in:

	BEGIN:VCAR
	CARID:my carid-2
	GRANT:UPN=<upnlist2>;POLICY=READBUSYTIMEINFO
	DENY:UPN=[email-masked];POLICY=READBUSYTIMEINFO
	END:VCAR

What (if (1) above) would keep [email-masked]' from a VQUERY
for DTSTART/DTEND/DRUATION and the the same results?

If you say that you can allways in this case add extra DENY properties ...

	BEGIN:VCAR
	CARID:my carid-2
	GRANT:UPN=<upnlist2>;POLICY=READBUSYTIMEINFO
	DENY:UPN=[email-masked];POLICY=READBUSYTIMEINFO
	DENY:UPN=[email-masked];OBJECT=DTSTART,DTEND,DURATION;ACTION=READ
	END:VCAR

 ... then why not say that READBUSYTIMEINFO is (3)? When
 would you not want both of the DENY lines when you DENY any UPN VFREEBUSY?

If we mean (3) or (2) then how can we VQUERY for -ANY- component
where including DTSTART/DTEND/DURATION was restricted with
a POLICY READBUSYTIMEINFO + DENY?

VFREEBUSY is an iTIP idea that I do not think maps well into CAP.

Ether you want or do not want a UPN to be able to see your busy time.
If you do not want a UPN to see your busy time, then how usfull is
it to get 1+ VEVENTs without DTSTART/DTEND/DURATION ?

So in other words - WHY do we have READBUSYTIMEINFO? I think it does not
provide a generic policy that can work in an interoperable way.
And the access control can be provided exactly as the CU-owner
or CS-administrator whished using  non-POLICY VCARs. (as shown
above).

-Doug

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 27 Jan 2000 13:54:44 -0500

Hi,

A CS MAY choose to implement and allow persistent immutable VCARs, that are 
configured by the CS Administrator, which apply to all calendars on the 
server. For example a company may decide that it wants all calendars on its 
server to have the Policy READBUSYTIMEINFO.

They made me use the shorter sentence. :)

Paul

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 12:03:34 -0800

> CONFIDENTIAL classified calendar components.

This has been a request from day one. What 'exactly' is it?

Does this mean I can book using your name, with STATUS=CONFIRMED?
Does this mean I can book using your name , with STATUS=NEEDSACTION?
Both? Nether?

Does this mean I can REPLY for you?
Does this mean I can do anything except REPLY for you?
Does this mean I can ONLY REPLY for you and ONLY update STATUS and nothing else?

Does this mean I can REQUEST using your name, and update your calendar?
Does this mean I can REQUEST using your name, except I can not update your
calendar?

Does it mean I can alter your CAP calendar properties?
Does it mean I can do anything except alter your CAP calendar properties?

What exactly are the rules ?

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 12:08:48 -0800

> assignments and journal entries.

What exactly is this?

Does it mean I can  create new (direct book) an appointment? If so
why not name it CREATEONLY?

-Doug

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 27 Jan 2000 13:58:31 -0500

>need to exactly specify its meaning.

I think we originally said that we do need to specify the policies very 
clearly. But nobody has sat down and taken the time to write up a proposal yet.

Paul

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 12:44:44 -0800

> - OWNER - Specifies the same rights given to the owner of the  calendar

The OWNER is given rights. CS policy may mandate that certain operations
can not be done by an OWNER. An example given at the LA IETF was
some calendars might NEVER allow deletions - for government tracking.

So, if the OWNER policy is the SAME RIGHTS GIVEN TO OWNER. Why
not make them an OWNER? 

And why do we need an OWNER policy?

-Doug

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 27 Jan 2000 15:42:24 -0500

> > 2.4.4.4 Policies

I'm glad the discussion has started but at the interim meeting  we did not 
modify the VCAR and Policy text. In this area all we started on was a 
reorganization so that a reader didn't half to traverse the entire document 
several times to find the relevant sections.

Paul

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 27 Jan 2000 15:46:40 -0500

Hi Doug,

A short sidebar not intended for the list...

>And why do we need an OWNER policy?

:) I think you were the person that wrote all of the policy text :) It was 
not anyone at the meeting that took place this week.

Seriously, I think the time has come for submitting suggested changes to 
this section, possibly along with some comments explaining the reasoning, 
instead of asking someone else to justify and explain. If all we ever do is 
ask, the section is unlikely to get finished.

Paul

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 13:33:20 -0800

> not anyone at the meeting that took place this week.

No, it was Frank. I have always been opposed to POLICY. I have
yet to see any one that can not be done with a VCAR (I wrote VCAR - then
VACL).

> instead of asking someone else to justify and explain.

I am sill looking for a reason for them to exist. I was not complaining,
just starting to do what I can to get rid if them. Someone needs to
justify and explain them, especially in the draft, or we need to  drop them.

I did not mean to imply that they were modified or reviewed this week.

> If all we ever do is

I would like to delete the POLICY section and all references to POLICY.
My next email (formulating it now), I'll propose how to delete POLICY
and replace them with VCARs. I just needed to set the framework for
my next comments.

-Doug

---

From: David Madeo <[email-masked]>
Date: Fri, 28 Jan 2000 01:54:38 -0500

> Does it mean I can do anything except alter your CAP calendar properties?

The general problem we're trying to solve here is how do I let my secretary or P/A
modify my calendar.  One way is to grant permissions such as above.  Another is to
authenticate via SASL as yourself, but then ask for the UPN of your principal (eg:
the boss).  If the SASL server is configured properly, you may be allowed use that
UPN even though it's not your "own".

Each side has it's merits.  In the first case, we have to go through and figure out
what is meant, however we can be precise.  In the second case, as far as the CS is
concerned, the boss just logged in and can do whatever they'd like, subject to the
BOSS's VCAR's.  There's no way to tell which were created by the secretary and which
by the owner.

For the first case, where we need to make some choices, my experience is that most
principals who have secretaries handling their schedules trust them completely at
least as far as their calendar is concerned.  If they don't, there's no way the
principals let them manage their calendar.  I'd vote for "can do anything except
alter your CAP calendar properties.  I'm not too concerned if "CONFIDENTAL" events
were outside the purview of the PA or not.

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Jan 2000 08:11:06 -0800

> UPN even though it's not your "own".

Thanks. Lets hope the group can come to the same agreement.

> BOSS's VCAR's.  There's no way to tell which were created by the secretary and which

The SENT-BY paramater in the ORGANIZER property would be set to the person
that created the component, if not the ORGANIZER.

And I guess that means we must allow for a UPN in the SENT-BY paramater.
Which meanst that section 4.2.18 must be updated in iCalendar.

---

From: David Madeo <[email-masked]>
Date: Fri, 28 Jan 2000 11:53:08 -0500

> Thanks. Lets hope the group can come to the same agreement.

I suspect both methods will be used to provide "secretary" access.

> Which meanst that section 4.2.18 must be updated in iCalendar.

Remember that in the second method where SASL is used, the server "sees"
the principals UPN, not the secretary's.  There's no way the server can
distinguish between them.  What you refer to will be the case if we use
VCAR's to grant this access.

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Jan 2000 09:26:51 -0800

> VCAR's to grant this access.

I thought that the secretary would authenticate with their own UPN,
then do a IDENTIFY command. At that point they authenticated as themselves,
then changed (at run time and without logging out) their identity.

The CS should know this. Any new component sent would have ORGANIZER
set to what IDENTIFY did, and SENT-BY set to their own UPN?

I am still catching up to the authentication text. Or do I have
two separate points mixed up?

-Doug

---

From: David Madeo <[email-masked]>
Date: Fri, 28 Jan 2000 13:00:26 -0500

> set to what IDENTIFY did, and SENT-BY set to their own UPN?

IDENTIFY is out as far as I know.  Paul can explain more, but SASL has a
mechanism where you authenticate as yourself, but ask to be identified
as a different name.  Whatever authentication method you choose through
SASL has to support this of course, and it's responsible for ensuring
you're allowed to do this.  Presumably there will be a local config file
to allow this.

So, from the servers point of view, a user with a UPN just shows up and
it takes it at face value.

That's why I think both methods will be used.  Personally I'd rather
have the VCAR's since I'd like to use the Sent-By and Organizer
properties in the way you describe.  Perhaps if enough people feel
strongly about this, we can put text in to say that the UPN trickery can
not be used for designate access.  

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Jan 2000 11:16:02 -0800

> you're allowed to do this.  Presumably there will be a local config file

Okay - then the SASL mechanism implementation needs to keep track of this 
so that it can be tracked and used in SENT-BY (per iTIP).

In the past (in the WG), we could not find ANY SASL implementation
that allowed this to work - so we invented IDENTIFY - If I remember
the history correctly. The generic SASL framework allowed for it,
but none of the needed mechanisms supported it. (Again as I recall).

However when it comes to security, I will bow to Paul. If he says it will
work, I am sure it can. We will need to tell people how in CAP as most of
us are not security experts. As in:

  If you want to be able to do something on behalf of someone else you
  have these choices:

	(1) Authenticate as them using any agreed on mechanism as
	    returned from CAPABILITY.

	or

	(2) Authenticate as yourself, use SASL <foo-feature> to <describe-what>
	    And at least SASL mechanism <sasl-min> MUST be implemented
	    by the CUA and CS wishing to use this method to act on behalf
	    of someone as the fallback for interoperability.

	or
		...

> not be used for designate access.

Per iTIP, that is what SENT-BY is. And as CAP allow scheduling per iTIP,
I think we MUST support that meaning. Let's not invent another way and
lets support SENT-BY.