Subject: Re: UPN + GROUP + UPNEXPAND question.

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 09 Mar 2000 21:10:37 -0500

At 10:53 AM 2/27/2000 -0800, Doug Royer wrote:

>Within the context of groups, when do you get MULTIPLE UPNs?

I don't think you do. The UPNEXPAND examples show multiple CSIDs being 
returned but not multiple UPNs.

Section 2.4.3, User Groups, has a misleading paragraph:

    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.

At first I thought that "Duplicate UPNs are filtered during expansion." 
should be changed to "Duplicate CSIDs are filtered during expansion." Now I 
am not so sure. Maybe the UPNEXPAND examples are incorrect? Was the intent 
actually to allow a CU via a CUA determine what users were members of a 
user group?

>There was talk that you MUST do a UPNEXPAND each time you
>authenticate?

I must have misfiled some messages I can't find a message that indicates 
that anyone proposed this.

>Seems a silly to have an extra round trip.

I agree.

>Why not do it as part of the authentication reply?

I don't see why it should be needed as part the authentication reply either.

>Then I still do NOT know what you do with them. At what point
>does the CUA ever pass them back to the CS? If never, then
>what's the point?

I don't think that a CUA would ever pass the result of UPNEXPAND back to 
the CS. That would seem to be going down the road of using CAP to 
administer groups which I thought was out of scope by consensus of the group.

>Perhaps those of you that understand UPN's can send some text or
>email describing when you get them? The current CAP draft and
>the text from Paul (I think it was from Paul) does not seem to say.

A UPN is the result of authentication to the CS with the possibility of a 
few well understood transformations. Normally the user asserts their UPN 
offers sufficient proof to the CS that it is believed. Not that we would do 
this, but as an example: UPN=[email-masked] PASSWORD=foo.

Or a certificate could be presented, verified, and the UPN read out of the 
certificate.

A SASL implementation could also authenticate the user, and present the 
authorization id as defined in the SASL RFC and the authorization id would 
be the UPN.

Finally after the initial authentication, the IDENTITY command could be 
used. I don't see the CS forcing the UPN upon the user. I don't see the CUA 
asserting a list of UPNs during a transaction to be subsequently used by 
other operations. (You may see a CUA putting a list of UPNs on the wire as 
part of a VCAR definition.)

>I think Bruce says they comeback as part of the authentication reply?

That would be a misunderstanding. I must have said something the was 
confusing at some point and later it got asserted as fact. My apologies to 
Bruce.

>Yet no one that proposed any new text has replied to that question.
>And I can't find any text that says that.

>There was no proposed changes to the ABNF or any text, or any example
>in CAP-draft that shows when you get them, other than UPNEXPAND.

I don't think the draft needs to go into them any further, if everybody 
agrees with what I have said up to this point :)

>As I understoon groups of calendars, it was meant to be something like:
>If you happen (at run time) to be part of group-A, and there is
>a calendar that has modify permission to cal-group-a, then you
>can modify that calendar.

That's what I thought too.

>So why does the CUA ever need to know
>the UPN of group-A ? 'user' has or does not have permission
>to modify cal-group-a. Why does the CUA care what the value
>of the UPN property is that allowd that? Why can't it just
>work, or you get permission denied?

I don't think the CUA cares :) I think someone thinks the user might care. :)

I may be confused but I think someone tried to sneak the equivalent of 
SMTP's EPN into CAP.

>Would it be something like:

small modification below

>    C: AUTHENTICATE <user> <password>

[ no in a username password case change the above to: ]
     C: AUTHENTICATE <UPN> <password>

>    S: 2.0
>    S: .
>    S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
>    S: Content-Transfer-Encoding: 7bit
>    S:
>    S: BEGIN:VCALENDAR
>    S: PRODID:-//ACME/CAPserver//EN
>    S: VERSION:2.1
>    S: CAPVERSION=1.0
>    S: ITIPVERSION=1.0
>    S: AUTH=KERBEROS_V4
>    S: AUTH=DIGEST_MD5
>    S: CAR=CAR-FULL-1
>    S: MINDATE=19700101T000000Z
>    S: MAXDATE=20370201T000000Z

Remember that you actually connect as part of CAP, but the time that we use 
AUTHENTICATE we actually dive into SASL, which possibly takes us into other 
transactions over the wire, then we pop back into CAP. The normal C: S: 
.... notation doesn't really accurately reflect what might be going on. 
Treat SASL as a bit of black box.

Does this help?

Paul

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 09 Mar 2000 21:21:14 -0500

>I may be confused but I think someone tried to sneak the equivalent of 

Oops, EPN should have been EXPN.