Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 01 Nov 2003 01:16:13 -0500

[Starting clean...]

There are two somewhat separate issues:

(1) Splitting into domain and user components, i.e., we could have 
permissions that apply to all users in a domain and some that apply to 
only specific users. That, by itself, does not break the additive model, 
if specific users have at least the permissions of the specific users 
within the domain.

While I don't believe that, in practice, domain-specific permissions are 
all that useful for organizations of non-trivial size, the model of 
"everybody within domain gets baseline permissions, special people get 
more" seems plausible.

There may be other issues with the split, along the "can this be 
generalized" question posed by Hannes, but other than modest additional 
complexity, this seems conceptually plausible.

(2) I share Hannes concern about making exceptions on any field, 
including the user or domain match. I don't see the real-world 
motivation for this and it complicates the conceptual model. (In the 
geopriv interim we discussed at length as to why blacklists are 
generally a bad idea, even with authentication, unless you can guarantee 
that the bad guys you want to keep out can't change their verified 
identity to a new one.)

At one point, I thought the basic design principle was that we weren't 
done until we couldn't *remove* any features - with policies, it's 
always tempting to pile on more and more "could be useful somewhere" 
items, so I think proponents of particular items should be held to a 
fairly high standard of proof as to why a particular feature is 
absolutely, positively necessary for a first version. In the geopriv 
draft, we spend some time talking about future extensions and how they 
are privacy-safe under certain baseline assumptions. We can't anticipate 
all the things that we might need and the things that turn out to be 
less than useful in practice, so I'd much rather start clean and small 
and then expand based on implementation experience. We just don't have a 
whole lot (if any) experience with policy languages or rule sets in the 
IETF.

Henning

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 01 Nov 2003 01:16:13 -0500

[Starting clean...]

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Nov 2003 20:05:31 -0500

> "everybody within domain gets baseline permissions, special people get 

In particular, this seems to be a common cases for many small to 
medium enterprises, where "domain" is the domain of the enterprise.

> that the bad guys you want to keep out can't change their verified 

I think this is a legitimate complaint for the case "accept anyone 
EXCEPT for Joe". However, for the case "accept anyone from example.com 
EXCEPT Joe", I dont think this concern is applicable. There, it is not 
so easy for the user to change their identity to a new one. The 
classic use case would be a company where I initially allow anyone in 
my enterprise, but then this one bothersome employee keeps pestering 
me for information every time I log in, and I want to put him on my 
black list so he doesnt see my status anymore. This seems like a 
legitimate case.

Also, another case where except clauses make sense is where I want 
different information provided to different people. For example, 
everyone in my company sees my cell phone status and my PC status, 
except for that annoying Joe again, who only sees my PC.

My main point, however, is that none of my arguments above are 
specific to presence as opposed to geopriv. If blacklists are bad for 
geopriv, they are also bad for presence, and vice a versa.

> whole lot (if any) experience with policy languages or rule sets in the 

I am with you on removing features, and as you can see have taken the 
axe to xcap-auth in a pretty serious way. I am also totally in 
agreement with the value of something being privacy-safe. I think the 
concerns about except-clauses in the applies-to section only apply 
when the except-clauses reference external lists. I see several 
options there:

(1) don't allow except clauses to reference external lists at all

(2) allow them to reference lists present only on the same server

(3) AND/OR if the list cannot be obtained, then the permissions in the 
associated statement are granted to NO ONE.

I believe that (1), (2,3) or (3) would make the except clause privacy 
safe.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Nov 2003 20:05:31 -0500

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Nov 2003 20:27:33 -0500

> 
> My main point, however, is that none of my arguments above are specific 
> to presence as opposed to geopriv. If blacklists are bad for geopriv, 
> they are also bad for presence, and vice a versa.

Most certainly - the arguments for and against are unrelated to the 
domain. I still think that blacklists are a bad idea. Even in a company 
situation, it is quite common for users to have multiple identifiers. I 
can be reached under at least three identifiers, and can indeed create 
any number of new ones at any time. (Like for any sendmail-based system, 
hgs+anything@cs will work. That's how I know which spammer is harvesting 
Internet drafts for email addresses :-)) This is probably a good 
feature, since cheap identifiers, created for specific purposes, are one 
advantage that IP-based systems have compared to, say, the phone system.

I prefer conceptually consistent models, i.e., with a very simple set of 
rules with no exceptions. The additive-permissions model, I believe, 
offers that, so in my book, the burden of proof is particularly high if 
the base model is violated.

> axe to xcap-auth in a pretty serious way. I am also totally in agreement 
> with the value of something being privacy-safe. I think the concerns 
> about except-clauses in the applies-to section only apply when the 
> except-clauses reference external lists. I see several options there:
> 

The problem is if the external element has an except clause, not the 
referencing document. Note that it is quite possible that the same 
applies-to appears in multiple rules.

> (2) allow them to reference lists present only on the same server

Even that is insufficient. Different documents can have different 
permissions or be on different file systems. It is, in general, rather 
difficult to ensure that two files will always be accessible 
simultaneously and atomically, regardless of whether they are on the 
same server or not.

> associated statement are granted to NO ONE.

Yet one more exception to worry about. There are other composing 
operations that may take place, e.g., company policy and personal 
policy. As soon as you violate the additive property anywhere, we have 
to worry about this everywhere, with serious consequences if we or the 
implementor get it wrong.

> 
> 
> I believe that (1), (2,3) or (3) would make the except clause privacy safe.

I'm still unconvinced that blacklists are sufficiently easy to explain 
to users (with all their practical limitations) that they are worth 
breaking the basic additive-rule principle with a set of complicated 
exceptions.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 04 Nov 2003 20:27:33 -0500