revised security section

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

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., 
"fanfeedback@xxxxxxxxxx" is the same as "FANFEEDBACK@xxxxxxxxxx").

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:juser@xxxxxxxxxxx" 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:juser@xxxxxxxxxxx" 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.