Subject: further suggestion for section 2.4.2.1

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 27 Jan 2000 13:01:37 -0500

Hi,

Below are further suggested modifications to section 2.4.2.1 and section 
[TBD] for the syntactic details of anonymous authentication.
2.4.2.1 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 detailed syntax information on anonymous authentication please refer to 
the AUTHENTICATE command in section 7.1.3.

[7.1.?.?] ATHENTICATE - ANONYMOUS

RFC-2245 defines the Anonymous SASL mechanism. This RFC states that "the 
mechanism consists of a single message from the client to the server. The 
client sends optional trace information in the form of a human readable 
string. The trace information should take one of three forms: an Internet 
email address, an opaque string which does not contain the '@' character 
and can be interpreted by the system administrator of the client's domain, 
or nothing. For privacy reasons, an Internet email address should only be 
used with permission from the user. "

RFC-2245 goes on to state, " A client which uses the user's correct email 
address as trace information without explicit permission may violate that 
user's privacy." Information about who accesses an anonymous CS on a 
sensitive subject (e.g., AA meeting times and locations) has strong privacy 
needs. "Clients should not send the email address without explicit 
permission of the user and should offer the option of supplying no trace 
token -- thus only exposing the source IP address and time. "

Example of CUA using the Capability command followed by an anonymous 
authentication:

C: CAPABILITY
       S: 2.0
         S:CAPVERSION=1.0
         S:AUTH=KERBEROS_V4
         S:AUTH=DIGEST_MD5
         S:AUTH=ANONYMOUS
         S:.
         C:AUTHENTICATE ANONYMOUS
         S:+
         C:c21yaGM=
         S:2.0

Subsequent to the initial Anonymous Authentication with a CS, a CUA will 
have to provide a UPN for some CAP operations. 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 
"@example.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 MUST not be used.

----------------------

As always, please send questions, comments, or concerns to the list.

Thanks.

Paul

---

From: David Madeo <[email-masked]>
Date: Fri, 28 Jan 2000 01:23:27 -0500

> non-null username and null realm, such as "bob@" could MUST not be used.

Minor nit.  Remove "could" from the previous sentance.  Or insert the rest of
it eg: "could be a security issue and MUST"

A more serious point is that I believe it's inappropriate to describe
"@example.com" in the "anonymous" section.

"@example.com" is not anonymous access.  It's "any authenticated user in
example.com".  An anonymous UPN is "@".  Unless you actually authenticate the
user, it's not possible for the server to determine if the user really is from
"@example.com".

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Jan 2000 08:06:38 -0800

> user, it's not possible for the server to determine if the user really is from

I did not get that from the email. I understood it to mean any user
that happens to come from example.com. PLEASE clarify!

It is possible to determine which host (or IP address) a connection
is from as soon as the connection is made - prior to any data transfers.

So I think the text needs to be clarified; does it mean that any user
from example.com is allowed as anonymous. Or does it mean any already known
user (non-anonymous) is allowed as long as they can authenticate?

-Doug

---

From: David Madeo <[email-masked]>
Date: Fri, 28 Jan 2000 11:49:13 -0500

> that happens to come from example.com. PLEASE clarify!

My understanding was that we depend on the UPN provided by the
authentication method negotiated via SASL.  The UPN is supposed to be an
rfc822 compliant name (eg: [email-masked]).  A VCAR which has
"@example.com" means allow any authenticated user who's UPN matches the
regexp /^(.*)\@example.com$/   An anonymous login who's UPN is "@"
doesn't match that.  I can potentially authenticate as
[email-masked], regardless of my ip address.

The server will need to check each UPN against the VCARs for a calendar. 

UPN -> "[email-masked]"
VCAR [email-masked]   -> matches
VCAR [email-masked]   -> doesn't match
VCAR @example.com         -> matches
VCAR @                    -> matches

UPN -> "@"
VCAR [email-masked]   -> doesn't match
VCAR [email-masked]   -> doesn't match
VCAR @example.com         -> doesn't match
VCAR @                    -> matches

Do you want to force the server to keep two upn's for each user, one
based on the authentication and one based on the domain name of the ip
address connecting to the server?  I suspect that's a can of worms you
really don't want to open.  If you authenticate as anonymous, your UPN
should be "@", not "@example.com".  Paul's text about the "trace" text
associated with anonymous login applies here.

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Jan 2000 09:56:43 -0800

> VCAR @example.com         -> matches

An anonymous user should not match? Or did I miss that?
The CS will get '@' as the UPN during authenticate for an anonymous user?
Or will it get [email-masked]' look for that first; if not found
look for [email-masked]', and authenticate 'dmadeo'; then if no match
and if a '@' VCAR exist, treat [email-masked]' as anonymous?

I did not understand that when I read the text.  'I' think
the text needs to clearly explain this misunderstanding. I don't
care which way it goes, I just would not know which way to code a CS.
Or maybe I am just nuts and everyone else understood? :-)

> address connecting to the server? 

From IP address you can get host.domainname .
From host.domain I can check for a VCAR with [email-masked]'.

Again I am not proposing anything - I am asking for clarification. I do
not know what the text as proposed means as I think I could write two
implementations each that seemed to be compliant to the text, both or one of
which would be incompatible with others.

> I suspect that's a can of worms you

I read the "trace" text to mean that a CUA SHOULD not by default send
the users email address as their UPN. I think that is great!

But I do not see in that text where it states that a VCAR with "@example.com"
means any user that the CS already knows about (email address or not),
or does it mean that any user from that domain is allowed anonymous access?

So is:

	@example.com	an anonymous user? So if I see this in a VCAR
			then any user given access without any other VCAR
			has the same access as an anonymous user?

Or does it mean:

	<known-name-to-CS>@example.com would be allowed access by the CS?
			And their may be <known-name-to-CS> in a VCAR.
			Because any user from example.com is NOT anonymous?

			And at the same time <unknown-to-CS>@example.com
			would be rejected and NOT be treated as anonymous?

Again - I am not proposing anything. I still do not understand.

---

From: David Madeo <[email-masked]>
Date: Fri, 28 Jan 2000 14:45:19 -0500

This is my last post on the subject for a few days, so let's hope it's a
good one :)

Comments throughout.

> The CS will get '@' as the UPN during authenticate for an anonymous user?

Yes.  The server has no idea who the user is if it's anonymous.

> and if a '@' VCAR exist, treat [email-masked]' as anonymous?

The server should not need to know how to do this.  It should take
whatever UPN that SASL and the authentication method gives it.  The
server will often compare this UPN against a VCAR to see if the UPN is
authorized.  That's what I in the matching example above.  The VCAR has
"@example.com" and the server is comparing the UPN "[email-masked]"
against it.  It matches.

Originally I thought that there should be no way for a user to
authenticate as "@example.com".  However, I can see a case where a SASL
mechanism is configured such that any local user who authenticates but
wants to be "@example.com" can do so.  This allows two levels on
anonymity: global and domain specific.

GRRR.  Paul, we'll need to refine the UPN definition to include two
additional cases which aren't RFC822 compliant.  "@" and
"@example.com".  We should expressly forbid "user@" here too.

> Or maybe I am just nuts and everyone else understood? :-)

In some areas, the security text assumes you know nothing.  In others,
it assumes you've already picked your SASL libraries and know what
you're doing.

> From host.domain I can check for a VCAR with [email-masked]'.

Clearly, you can figure out which domainname is associated with an ip
address.  However, the Calendar server shouldn't even try to extrapolate
this.  Trust the authentication, nothing else.

> the users email address as their UPN. I think that is great!

Yes.

> or does it mean that any user from that domain is allowed anonymous access?

I meant that if you're logging in as anonymous, the server shouldn't be
storing anything that identifies you, including your domain.

>                         has the same access as an anonymous user?

Depending on the context, this is either the UPN of a domain specific
anonymous user OR a UPN in a VCAR which will match any authenticated
user (even an anonymous one).  If I see this in a VCAR, I think that
this rule applies to any user who authenticated  and their UPN either is
or ends in "@example.com".  

>                         would be rejected and NOT be treated as anonymous?

Hope this helps everyone clarify the issues.

Thanks,

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Jan 2000 13:25:26 -0800

David Madeo wrote:
> Yes. ...

Yes to both questions, or the last one?

> ... The server has no idea who the user is if it's anonymous.

True - but that was not my question.

> whatever UPN that SASL and the authentication method gives it.

Not entirely true. We have to specify what we want. If we are saying
that '@' means anonymous, then that is a new thing that I have not
seen in any SASL mechanism. Same with '@domain'. In both cases
no SASL implementation that I have seen will allow '@' to
mean global-anonymous or '@domain' to mean domain specific anonymous.
Someone still needs to write an implementation of the SASL mechanism
for their CS implementation.

There are ways to authenticate using SASL as anonymous. None that
I have seen specify returning '@' or '@domain' to the underlying layers,
or as the authentication id.

SASL indirectly does allow us to specify those things. It is just not
clear to me that we have done that in the text.

>  The server will often compare this UPN against a VCAR to see if the UPN is

That part of the picture I understand. The question is:

	Are your now 'dmadeo' or 'anonymous'?

If the answer is that you are 'anonymous' how do we specify *any*
valid user at domain? (ANY@domain ?).

If the answer is that you are 'dmadeo' how do we specify
any user at domain - as anonymous? (anonymous@domain ?)

> anonymity: global and domain specific.

What if we want a VCAR to allow for ANY-KNOWN -AND- authenticated
user at a named domain. Such as:

	BEGIN:VCAR
	CARID:allow all users from our clients
	GRANT:UPN=[email-masked];....
	END:VCAR

-OR-
	Do I have to enumerate all of usersin a VCAR? Yuck!

> it assumes you've already picked your SASL libraries and know what

Only if we in advance specify the minimum SASL mechanism that can interoperate.
Then WE must specify in advance what it means to a CS if it gets '@'
or '@name'.

> this.  Trust the authentication, nothing else.

Spammers and hackers would love that. I can see that we would NOT require it. 
However any large site would need to keep track of the connections for security
auditing when someone hacks. 

As I see it, anonymous connections to a CS are need only because each
public calendar will not be able to authenticate ALL possible CUs.
As in, if I don't know you, then login as anonymous and I will give
you access to read all public events that have a VCAR for anonymous access.

There may also be a need at some sites to provide a way for a CS to ensure
anonymity. And we can define that way in advance, and we can mandate
that a CS understands this request (even if it says NO). We can not
mandate that a CS does not track connections or users.

> storing anything that identifies you, including your domain.

I disagree. A public baseball field may have a calendar. Because the CS-admin
does not want to have to provide an authentication id to all possible
residents. They may allow anonymous access. In this case they do want
and need (so they can email you back) you real-id. So as I read text, this
should not be automatic. But the CU may say yes.

> user (even an anonymous one).

When would you see [email-masked]' NOT in a VCAR?

>  If I see this in a VCAR, I think that

Okay - now how would in a VCAR I say any anonymous user in that domain,
but only anonymous users? Because all known users in that domain would
have their own VCAR.

> Hope this helps everyone clarify the issues.

Closer, but I am still not convinced that all points on the matrix have
been covered.

I would like to see something like (Or perhaps all of this is covered and I
am still not getting it):

(a)	@domain			-	Means any KNOWN user @domain

(b)	anonymous@domain	-	ONLY anonymous users @domain and
					excludes known users.

(c)	user-name@domain	-	ONLY the named 'user-name' @domain

(d)	@			-	Means anonymous user from ANY domain.
					And excludes known users.

I think this would simplify VCARs. I see the proposed text and this discussion
as saying that:

	(I) anonymous can be (a) or (d).
	(II) Known users can be (a)  or (c).

	No way to say anonymous only VCAR access.
	No way to say only non-anonymous known users.

	VCAR with (a) is ambiguous when the CS would be trying to enforce 
	a VCAR, it could have a problem with two conflicting VCARS.
	One for anonymous and another for when they are known.

		BEGIN:VCAR
		CARID:access for anonymous users.
		GRANT:UPN=@example.com; ....
		DENY: ... CREATE,WRITE,...
		END:VCAR

		BEGIN:VCAR
		CARID:access for tweaker
		GRANT:UPN=[email-masked]; ... CREATE,WRITE...
		END:VCAR

	So when they authenticate as [email-masked], in your example
	they match the 1st rule. As there is no unambiguous way to specify
	only-if-anonymous. Where as  see this as unambiguous:

		BEGIN:VCAR
		CARID:access for anonymous users.
		GRANT:UPN=[email-masked]; ....
		DENY: ... CREATE,WRITE,...
		END:VCAR

		BEGIN:VCAR
		CARID:access for tweaker
		GRANT:UPN=[email-masked]; ... CREATE,WRITE...
		END:VCAR

Or do I still have it wrong? :-)

-Doug