Subject: Re: Users and Authentication Ids in CAP

From: [email-masked]
Date: Fri, 9 Jul 1999 13:08:07 -0400

Alex reponded with:
>I think that having an authorization command would be easier
>than proxy rights in the VCAR.  The VCAR can then grant rights
>to the identity to which you authorized.

There is a disconnect between an AUTHORIZATION command in CAP and using 
the VCAR info to decide what rights the specified identity has.  _HOW_ does the CS 'know' that I am authorized to use "AUTHORIZE [email-masked]" 
command when all it may know about me is my UPN is [email-masked]?? 
There has to be some OOB or other mechanism for the CS to use to decide 
"Can [email-masked] become [email-masked]?". 

A new AUTHORIZATION/AUTHENTICATE command may not solve this.  Here is why 
not: [email-masked] tells the CS that [email-masked] is able to 
re-authorize as [email-masked].  This effectively would give [email-masked] 
the same access rights to ALL calendars in the CS.  This could provide me 
a _big_ backdoor (hanger door size backdoor!) into the other calendars in 
that CS.  Just how would this 'proxy' ability be scoped to avoid this 
problem?  The other side of the coin is that for Admin types, this scoping 
is exactly what they would want so now we could have CS policies that 
conflict w/the individual scopes. 

This becomes a giant rat hole (elephant sized rat hole!!) balancing the 
the security issues w/the usage desires...

How about some suggestions from other folks out there!?!  (Im off to get 
more caffine and catch up on all the threads Ive missed in the past 2 
weeks...)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Alexander Taler <[email-masked]>
Date: Fri, 09 Jul 1999 20:01:21 -0400

The Authorization command mentioned here has become the IDENTITY
command which was discussed earlier, and in Montreal.  I agree that
the mechanism for determining which Identities/UPNs can be assumed is
OOB and implementation dependent.

I no longer believe that this mechanism should be used for determining
designate rights, but that the use of VCARs is preferable.  Perhaps
there should be a designate access policy.  My major reason for not
wanting to use this mechanism for designate access is that I think
that the mechanism for determing identity/UPN should remain OOB. 
Using CAP I should not be able to decide who can use which identities.

Alex

[email-masked] wrote:
> There is a disconnect between an AUTHORIZATION command in CAP and
> using the VCAR info to decide what rights the specified identity
> has.  _HOW_ does the CS 'know' that I am authorized to use
> "AUTHORIZE [email-masked]" command when all it may know about me is
> my UPN is [email-masked]??  There has to be some OOB or other
> mechanism for the CS to use to decide "Can [email-masked] become
> [email-masked]?".
> 
> A new AUTHORIZATION/AUTHENTICATE command may not solve this.  Here
> is why not: [email-masked] tells the CS that [email-masked] is able
> to re-authorize as [email-masked].  This effectively would give
> [email-masked] the same access rights to ALL calendars in the CS.
>  This could provide me a _big_ backdoor (hanger door size backdoor!)
> into the other calendars in that CS.  Just how would this 'proxy'
> ability be scoped to avoid this problem?  The other side of the coin
> is that for Admin types, this scoping is exactly what they would
> want so now we could have CS policies that conflict w/the individual
> scopes.
> 
> This becomes a giant rat hole (elephant sized rat hole!!) balancing
> the the security issues w/the usage desires...
> 
> How about some suggestions from other folks out there!?!  (Im off to
> get more caffine and catch up on all the threads Ive missed in the
> past 2 weeks...)
> 
> Bruce