Re: Groups revisited

[rans@xxxxxxxxxxxx (Richard Shusterman)]

Bruce,

Sorry I took so long in responding. Some responses below:

Bruce_Kahn@xxxxxxxx wrote:

> When I AUTHENTICATE with my CS, the credentialling process
> will result in 1 or more UPNs being 'spat out' if the process works.
> Lets say that when Frank AUTHENTICATEs with his CS, it (his CS
> thanks to the authentication mechanism) says that the pair of UPNs
> Frank_Dawson@xxxxxxxxx and CAPEditors@xxxxxxxxxxxxxxxxxxxxxx
> are 'valid' identities for Frank. He can use them as part of VCARs or
> wherever else we allow UPNs.

How does Frank get his list of UPNs? One of the new CAP commands
that we came up with in Boston to solve this problem was LOOKUP
(a proposal was recently made to rename this to UPNEXPAND). Or,
are you suggesting that as part of the AUTHENTICATE response, these
UPNs are returned?

> The CS _really_ should keep all the UPNs that are spat out for VCAR
> comparison, etc.  That way, if there is a VCAR on a paricular event
> in the calendar that has a VCAR that only allows
> CAPEditors@xxxxxxxxxxxxxxxxxxxxxx to read or edit it then Frank should
> be able to access that entry.  Just because Franks "primary" (ugh, for lack
> of a better description so do not take literally) UPN is
> Frank_Dawson@xxxxxxxxx does not mean that he has to do nasty things
> like switching identities to be able to access an entry that does have
> CAPEditors@xxxxxxxxxxxxxxxxxxxxxx on the VCAR.  The CS should do
> this equivalence for him!

I agree. That's why we also agreed in Boston to remove the IDENTIFY
command (which somehow still lives in the CAP draft - I will ask the
editors to remove it) since it's not needed.

> Smack the group UPN creator up side the head.  Groups are much more
> useful if their are descriptive than if they are just mangled sequences of
> seemingly random junk. Sometimes they are not easily distinguished from
> that of a single CU (ie: postmaster@xxxxxxxxx is probably shared among a
> couple folks even though it could be just 1 person).

Since group names are not always descriptive, hence the need again for
the LOOKUP (or UPNEXPAND) command. BTW, if the CS chooses not
to support group expansion, it can simply return the same UPN passed in
by this command.

> Im still a big KISS advocate and Im not sure we need/want to have the
> CS do group expansion by request.  That sounds like a directory issue really
> rather than a C&S one.  Just as a CUA would probably do some kind of
> lookup (ie: LDAP, etc) on Frank_Dawson@xxxxxxxxx to get some info Frank,
> the same can and probably should be done by the CUA for the other UPN.
>
> In addition, I think the CS should fully unwind nested groups for the fairly
> obvious reason that ANY nested group could be on a VCAR.  As such
> as long as Frank is a member of a nested group he should be granted/denied
> access accordingly.

Whether a CS supports groups and whether a CS unwinds nested groups is
an implementation issue. If the CS supports groups (as in your VCAR example),
it might as well make this information available to the CUA via the LOOKUP
(or UPNEXPAND) command.

> Personal address books cannot be used by the CS to enforce or expand
> group UPNs during AUTHENTICATion.  Besides being a BIG security hole,
> its not feasible to even consider HOW the CS could safely get the info from
> the CUA and really trust it..  I dont want to murky the waters by talking
> about local replicas of the CSs address book (or partial replicas, etc).
> Thats
> OOB for CAP I think.  For the CU to create their own group UPNs that
> the CS can use, it would have to be done in such a way that the CS can
> trust the data (ie: via read/write control to a shared LDAP server, etc).
> We can dive on some of the nitty gritty issues later but Im trying to see
> if the higher level view/logic I posted originally is accurate...

Depends on where the personal address books are stored ... maybe they're on
the CS? In any case, this is implementation specific.

> We are of similar thought I think but you are doing the expansion in a
> different way then I proposed.  If the CS determines ALL the UPNs I am
> synonymous with when I AUTHENTICATE then it does not have to
> expaned EVERY VCAR on every ACCESS to try and find a match
> for my 'primary' (sic.) UPN. Its much much cheaper to take the hit up
> front than for every request/response that needs to be done.  As long as
> ANY UPN in my list of identities matches the VCARs then that VCAR
> drawback is that a change to a group UPN wont take effect until I
> is applied to me.  That only reAUTHENTICATE.  Typically though this
> is not such a big deal and can be handled by some good up front CS
> architecture for handling change notifications.

Implementation specific.

> Argh, a step backwards in agreement.  WAAY back in Montreal we
> agreed that the authentication process could generate > 1 UPN for a set of
> credentials.  We never precluded that all of those UPNs must be unique for
> a CU.  If its not unique per CU then it in effect is a group UPN.

Agreed.

> Im claiming that groups can be easily handled by this ability to have > 1
> UPN generated when I AUTHENTICATE with the CS and that is
> something that all CS vendors will have to deal with.  Im NOT a big fan
> of bloating CAP even more by having the CS act as a UPN directory
> server of sorts as it just deters vendors from making CS implementations.

The CS is not required to be a UPN directory. However, if we agree that
it's a good thing to put group UPNs in CAP, then we need definitions and
commands to allow a CS to share this information with a CUA. A CUA
should not assume that it's CS supports groups. Perhaps, it would help
if we added a CAPABILITY response from the CS that can tell the CUA
exactly what level of group support is available in this CS, e.g., group UPNs
are allowed, nested groups are expanded, etc.

> Just how do were you (collectively now) envissioning that the CS would use
> the other UPNs that are generated as part of the certification process??
> Are they to be ignored?  If all CSs must generate the same list of UPNs
> for a given set of credentials then what is the big deal in the CS using
> them to evaluate VCARs, etc later one?

I think the AUTHENTICATE process has to allow a CS to ignore multiple
UPNs just like a CS should be allowed to ignore group UPNs. Not every
CS vendor will want to support these features.

> Ok this may be bass ackwards but Ill try to rephrase my idea in as simple
> terms as Im able at this time of day:
>
> Given:
> 1: The AUTHENTICATion process may result in > 1 UPN being generated for a
> given set of credentials and
> 2: Not all UPNs are 100% unique per CU

Agreed.

> That:
> 1: It is possible to have a 'group' UPN  generated as one of a CUs UPNs
> when they AUTHENTICATE and
> 2: A CS should be able to match ANY of the UPNs generated during
> authentication in a normal UPN check (ie: in VCAR evaluation)

Agreed, especially the "should" part.

> Therefore:
> 1: This 'group' UPN can be used anywhere a UPN is normally used (ie: VCAR)
> and
> 2: No extra or overly complex extra mechanisms are needed in CAP to
> distinguish a 'group' UPN from an 'non-group' UPN and
> 3: We do not need to distingush beteen 'group' and 'non-group' UPN flavors
> anymore.

Agreed. I think this is what we came up with in Boston and is now reflected in
the
CAP draft.

Richard