Subject: proposed CU section for CAP and UPN definition

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 10 Jun 1999 16:06:55 -0400

Hi Steve,

Here is my proposal for a change to the definition section of CAP and text 
for the section on a Calendar User:

For inclusion in the definition section of CAP:

Delete the definition of Principal

Add:

UPN - A UserPrincipalName is CAP's representation of a CU (Calendar 
User).  A user principal name strongly resembles a RFC 822 style email 
address and in some cases it may be identical to the user's email 
address.  It consists of a simple user identifier and a security context in 
the form of a DNS domain name. It may also have an optional instance. In 
it's simplest form it consists looks like [email-masked]. When using the 
optional instance it has the form user/[email-masked].

The optional instance name is only supported by some SASL authentication 
methods and is not widely used. The instance is normally used to designate 
a particular role or instantiation of a user. For example a UPN of the form 
user/[email-masked] implies that the authentication will only be used 
to connect to a dial-up ISP service and will not be used for general 
service usage. A UPN of the form user/[email-masked] implies that 
example.com has decided that authentication credentials used in this case 
will only be used for CAP.

A UPN maps very well into many authentication systems. On a traditional 
host-based password system, the UPN is formed by joining the user account 
name with the hostname. This also works with MD5-Digest, SASL's 
authentication-id, and Kerberos principal names.

A UPN with a NULL instance fits well into schemes that need to pass URIs., 
see section 3.2.2 of RFC 2396. How a UPN may be related to a X.500 DN or 
used in an X.509 certificate is discussed in section 2.4.

Section 2.4 Calendar User

A Calendar User (CU) is an entity that can be authenticated. It is 
represented in CAP as a UPN. A CU is used as an owner of a calendar and as 
the value of a property in the VCAR.

         Examples:
                 [email-masked]
                 user/[email-masked]

The UPN representation is independent of the security mechanism used during 
a particular CUA / CS interaction. A CU may use one mechanism while using 
one CUA but the same user may use a different authentication mechanism when 
using a different CUA, or while connecting from a different location.

For Calendaring and Scheduling systems that are integrated with a directory 
system the UPN SHOULD be stored in the attribute [TBD] with OID [TBD]. This 
enables a clear mapping between a UPN and a Distinguished Name. [note: 
Microsoft's Active Directory is storing UPNs as the userPrincipalName.] 
Within a directory service a UPN is a single valued property.

As iCalendar objects containing VCARs are passed around the UPNs may end up 
being stored on servers that are unable to authenticate a particular UPN. 
In general this will not have any adverse effects within a DENY clause, 
since group operations are not supported. However, a combination of DENY 
ALL and GRANTing to a specific UPN may result in an iCalendar object which 
cannot be viewed or modified on a particular server by any normal user. 
This is the correct behavior for an iCalendar object which has been 
misdirected.

2.4.1 UPNs and certificates

When using certificates for purposes of CAP authentication, the SubjectName 
field of the user's certificate SHOULD contain the user's UPN (for example, 
"[email-masked]") as the value of the "CN=" component, and the user's 
email address (often the same as the UPN) as the value of the "E=" 
component . The altSubjectName will contain the DN of the user's account 
object in the DS. The Issuer field must be that of a root CA trusted to 
issue login certificates, or the DN of a lower level CA whose certificate 
includes an "AuthorizedNamingContext" field that authorizes it to issue 
certificates for "example.com" (exact field name and validation mechanism TBD).

Note: If a server is validating data received via iMIP, if the "From:" said 
(e.g.) "Joe Random User <[email-masked]>" then the "[email-masked]" 
part should be checked against the altSubjectName field of the certificate, 
and the "Joe Random User" part should be checked against the CN component 
of the altSubjectName DN. This is so the "From:" field couldn't be munged 
to something misleading like "John Rictus User <[email-masked]>" and 
have it pass validation. This validation will also defeat other attempts at 
confusion.

2.4.2 Calendar User and UPN interactions with the IDENTITY command

[ need to see text on IDENTITY to determine how this will work.]

2.4.2 Further examples and implementation notes

Section 11, Security Considerations will cover this in more detail.

[ An example showing an actual SASL negotiation will not show the UPN in 
clear text.

C: CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
S: OK done
C: AUTHENTICATE ANONYMOUS
S: +
C: c2lyaGM=
S: OK Welcome, trace information has been logged.

And

C: CAPABILITY
S: * CAPABILITY AUTH=CRAM-MD5 AUTH=ANONYMOUS AUTH=KERBEROS_V4
S: OK done
C: AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: OK Kerberos V4 authentication successful

]

---

From: Frank Dawson/CAM/Lotus <[email-masked]>
Date: Thu, 10 Jun 1999 23:08:34 GMT

Paul:

I don't think that a LDAP property for a single UPN for C&S will do it. For
me, I might have:

[email-masked]
[email-masked]
Frank_Dawson/CAM/[email-masked] (don't you hate this one!)
[email-masked]
[email-masked]
etc, etc.

If indeed, the UPNs often are the same as my RFC822 email address, then we
need multiple properties. Or at least one that is the "primary" and another
multi-valued property for the secondary UPNs.