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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 6 Nov 2003 10:06:48 +0100

hi jonathan, 

could you describe how the domain authorization procedure works? where do
you get the domain part for the identifier. the problem we saw in the past
was that you have to understand the structure of the identifier in order for
it to work. 

ciao
hannes

btw, another small issue. the name of the authorization draft is very
misleading. there is no need to contain the name xcap in there since the
policies should actually be independent of xcap. i noticed the problem with
the names in various discussions. people automatically think that those two
belong together. 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, November 04, 2003 2:06 AM
> To: Henning Schulzrinne
> Cc: Tschofenig Hannes; 'Rosen, Brian'; Simple WG; [email-masked]'
> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > [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.
> 
> In particular, this seems to be a common cases for many small to 
> medium enterprises, where "domain" is the domain of the enterprise.
> 
> 
> > (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.)
> 
> 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.
> 
> 
> > 
> > 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.
> 
> 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
> 
> 

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 7 Nov 2003 10:52:34 +0100

hi jonathan, 

the problem with your approach is the following: you are simply assuming an
email type of identity (which is taken from the authentication procedure).
there you can simply split the domain part from the user part. 

however, geopriv tries to support different 'using protocols'. one possible
using protocol is sip but there are many others.  

these using protocols typically have different authentication mechanisms
which again use different identities. identities in http digest, x.509
certificates, kerberos principal names etc. have a different structure. you
need to know the structure in order to extract the domain part. 

without your <domain> approach you don't need to understand the structure of
the identifier. you only do an equality match. 

ciao
hannes

> > hi jonathan,
> > 
> > could you describe how the domain authorization procedure works?
> > where do you get the domain part for the identifier. the problem we
> > saw in the past was that you have to understand the structure of
> > the identifier in order for it to work.
> 
> I'm not sure I follow. I work for dynamicsoft.com. All URIs in my 
> domain are [email-masked]. I'd like a policy which 
> allows anyone 
> in dynamicsoft.com, but blocks a few irritating people, say joe and 
> bob. So, I would have a policy like this:
> 
> <applies-to>
>    <domain>dynamicsoft.com</domain>
>    <except>
>       <uri>[email-masked]</uri>
>       <uri>[email-masked]</uri>
>    </except>
> </applies-to>
> 
> 
> Where is the complexity here?
> 
> 
> > 
> > ciao hannes
> > 
> > btw, another small issue. the name of the authorization draft is
> > very misleading. there is no need to contain the name xcap in there
> > since the policies should actually be independent of xcap. i
> > noticed the problem with the names in various discussions. people
> > automatically think that those two belong together.
> 
> Yes, I realize that - others have commented similarly. I will 
> be happy 
> to split it up into pieces, wth the XML schema separately, once we 
> have a better grasp of how to bring these two works together.
> 
> -Jonathan R.
> 
> --

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Nov 2003 10:41:27 -0500

I've been on the receiving end of the "broken record".
I do get it.  I have some sympathy, but not a whole lot.
Basically, I think that "it could be useful", is as
good as you get, because no one has deployment experience.
I think you are guilty of having an implantation in mind
and forcing all requests through the lens of your
implementation.

One possible way to look at this is to observe that the
messages sent could express something that is compact,
where the implementation expands the message to a more
explicit set of rules.  In this example IF (big if)
you have a list of users, you could have an arbitrarily
complex set of AND/OR/EXCEPT/... operations, as long
as the result was reducible to a set of users with
the permission.  That set could then be stored in your
database.

I do realize that in a sense, this kind of complexity is
just an optimization, and thus subject to elimination
in a first phase implementation.  However, I think
that the likelihood here is that it actually matters
(all of a domain EXCEPT a couple of people).

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 10:01 AM
> To: Naoko ITO
> Cc: Simple WG; [email-masked]
> > I think a separate excepton list is very useful, 
> corresponding to the
> > exact concept of 'black list.'
> 
> It is not exactly a black list, although it can be used for 
> that. That's 
> why I called it an exception list.
> 
> > Still, I'd like to have an except clause in a permission statment as
> > well, which can be used for a differenct purpose, i.e., giving
> > different permissions to some groups of the watchers.
> 
> I'm sorry to sound like a broken record: People requesting 
> features that 
> break overall processing models should please have the kindness to 
> provide motivation beyond "it could be useful".
> 
> > 
> > I don't understand why the except clause in each permission 
> statement
> > should be dismissed while the separate exception list model can be
> > supported.
> > 
> > 1) introducing a separate exception list but not supporting it,
> > 2) introducing an except clause in each permission but not 
> supporting
> >   it.
> 
> See my other message.
> 
> > 
> > In the case of Option #1, the rule enforcer should drop all the
> > permission statements in the rule set in order to prevent those
> > should-be-excepted watchers from accidentally obtaining 
> information, if
> > there is an exception statement which cannot be understood. i.e., no
> > permission is granted to anybody at all. In the case of 
> Option #2,  the
> > rule enforcer should drop the permission statements with 
> unknown except
> > clauses, which still allows some watchers to obtain information. It
> > seems to me that both options give us the ways to ensure the
> > privacy-safe even if the rule enforcer does not support the except
> > mechanism, and rather the latter is more elastic or 
> fault-tolerant. Or
> > is this just plausible?
> 
> Please review the discussion on why this doesn't work when rules are 
> composed from multiple sources.
> 
> 
> > 
> > As for maintaining the row-model, I don't think the former model
> > maintains the row-model, while the entire rule set has no meaning if
> > the actual rule set once has an exception statement. If it means not
> > supporting the exception at all, the same thing can be done with the
> > except clause in each permission.
> 
> The exception-list model does support the row model. Each rule has 
> exactly one field value for each field, including the URI matching.
> 
> > 
> > I see no reason to dismiss the latter approach and would suggest to
> > keep both.
> 
> If you're in Minneapolis, I'd be glad to explain this in more 
> detail in 
> person, since you couldn't be at the interim meeting, where 
> we went over 
> this for several hours...
> 
> > 
> > Regards,
> > -----
> > Naoko Ito / NEC
> 
> 
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Nov 2003 10:41:27 -0500

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Nov 2003 10:48:41 -0500

oh well. Not enough attention paid to spell check!

implantation = implementation

Sorry

Brian

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 10:41 AM
> To: 'Henning Schulzrinne'; Naoko ITO
> Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth
> 
> 
> just an opimization, and thus subject to elimination

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Nov 2003 10:48:41 -0500

Sorry

Brian

---

From: [email-masked]
Date: Fri, 7 Nov 2003 10:34:05 -0800

>and forcing all requests through the lens of your

As just another bozo on this bus, let me say that I
don't think that I have the same lens as Henning (and
certainly don't have the same implementation in mind),
but he and I share some concerns.  I agree with you
that no one has deployment experience for this
and that we will no doubt learn something from that
experience.  I question, though, whether that means
the right choice is "put things in that might be needed"
or "put things in we know we need, then see what we're
missing". 

To take up your point on implementation, I note that
folks do seem to be assuming a connection between
the UI and the protocol behavior.  I can easily see
a UI saying "Grant all buddies civil geolocation data
at City level, except $ex-spouse, who should get
my timezone" and translating that as a grant of
timezone to all buddies and a second grant of
City to each of those that isn't the ex-spouse.  From
the user point of view, it's an "except", where from the
protocol point of view it is additive permissions.

There is no question that there are engineering trade-offs here.
You gain simplicity and have an easy method to
ensure maximal privacy, but you may get increased
object size and you may need to structure group data
in ways that ensure it fits this model reasonably
efficiently.  Neither choice is perfect, but this one
does have some very useful characteristics for a
large number of GeoPriv cases.  There may be other
usage patterns in other uses of XCAP that mean
we can't have a perfect fit, but if we can keep that
split to a minimum, I think it's worth it.

			regards,
				Ted

---

From: [email-masked]
Date: Fri, 7 Nov 2003 10:34:05 -0800

regards,
				Ted

---

From: [email-masked]
Date: Sun, 9 Nov 2003 20:13:56 +0200

Hi,

I've followed this thread from SIMPLE WG point of view. I agree mostly with what Jonathan is writing below. I summarize my main points here:
- In many "domains" (run by corporates, ISPs, operators) it is not possible to ad hoc create new identities, and in any case authentication is always required when an identity is used. This means that getting around "black lists" is not as trivial as in e-mail. 
- I agree that the usefulness of exceptions depends on how "group" information is structured. In many cases, especially in corporates, people use groups/lists that they themselves are not able to manage (and in some cases not even see their content). This happens with e-mail, calendars etc. I believe similar shared groups to be useful for hobby-clubs, families etc. too. In those cases it is important to be able to disclude some members by doing exceptions, e.g. "golf-club-list EXCEPT Joe" or "engineering-department-list EXCEPT my boss". I understood Ted's point that UI and protocol can be separated, but I share Jonathan's concern below.
- I didn't quite get why we couldn't define the <applies-to> and <exception> so that if the <exception> part for some reason (external reference etc.) could not be properly resolved, the whole <applies-to> would result in empty set, i.e. at least no leaks would be introduced.
- Also I did't get what was wrong with Ted's proposal to define a separate <restricted-applies-to> element. To me that would be OK as well.

Markus

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 07 November, 2003 22:22
> To: Henning Schulzrinne
> Cc: Andrew Newton; Naoko ITO; Simple WG; [email-masked]
> inline.
> >>> statement should be dismissed while the separate exception list
> >>> model can be supported.
> > 
> > 
> > The exception list is restricted in its functionality to avoid the
> >  privacy problems caused by exception entries. Mixing the two means
> > that both list types would need to be restricted as described.
> > 
> > Also, having unbounded except lists makes processing more
> > complicated since the simple row model no longer applies (it's no
> > longer a relational table).
> 
> I share Ito-san's confusion here. Assuming the same kind of
> restrictions you have asked for - no external references, no
> wildcards, no domain-scopes, I dont see the difference between:
> 
> <applies-to>
>    <domain>example.com</domain>
>    <except>
>      <uri>[email-masked]</uri>
>    </except>
> </applies-to>
> 
> and:
> 
> <applies-to>
>    <domain>example.com</domain>
> </applies-to>
> 
> <exception-list>
>    <uri>[email-masked]</uri>
> </exception-list>
> 
> THe differences seem merely syntactic, but maybe I am missing
> something here.
> 
> Henning also wrote:
> > Blacklists were popular for spam-protection early on, but I think
> > everyone has realized by now that they are close to useless. I'd
> > hate to create a complicated, brittle, difficult-to-predict system
> > just to find out a year later that this expensive feature turned
> > out to be mostly an empty promise, in terms of increasing user
> > privacy.
> 
> There are some serious differences here with the email spam case. 
> Firstly, the systems we are talking about require authentication, 
> which is absent in email. Secondly, and perhaps most 
> importantly, I am 
> not interested in rules like "allow anyone in the world but 
> [email-masked]", as I agree this is silly. We are talking 
> about rules 
> like "allow only people from example.com EXCEPT 
> [email-masked]". That 
> is, I expect these systems to require a user to explicitly grant a 
> permission, but an extremely common case, I think, will be to 
> grant it 
> by indicating a domain with a set of exceptions.
> 
> Ted wrote:
> To summarize (correct me if I am wrong), I think your suggestion was 
> that exceptions can be handled by expanding the lists associated with 
> the domain. As such, even though the user sees an exception rule in 
> the UI, the underlying system pushes a permission with everyone in it.
> 
> My concern is that I believe this will be very difficult to 
> manage. It 
> requires the users to have access to the set of users in the domain 
> from which the exceptions are being specified. That list is 
> undoubtedly dynamic, and potentially pretty large. When a new 
> employee 
> joins the company, everyone would have to update their 
> permissiosn (or 
> have their agents do it automatically somehow), and similarly when 
> someone leaves. The result will be odd behavior for users, where 
> people that a user believes to have permission, actually doesnt.
> 
> -Jonathan R.
> 
> 
> --

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2003 14:28:59 -0600

The difficult issue here is knowledge of group membership.

As has been proposed earlier, the correct way to say
"everyone in my buddy list *except* Bob" is to literally
have your client send the list of everyone in your buddy
list except Bob. For this specific example, I can agree
with the approach of "just explicitly grant permissions."

Now, if a user wants to semantically say "everyone in engineering
at my company except Bob," it gets much more difficult.  From a
user perspective in this case, what he needs to say is "everyone
in engineering except Bob." He doesn't care about the underlying
protocol -- that's the behavior he wants, and anything else is
broken.

To make this model work without an "except" clause, my client
would need to have a mechanism to fetch all the engineering
users from the corporate directory, remove Bob from the list
and enumerate the remainder of them in a grant message.

By my reading, this is basically the solution that advocates
of not using "except" would think is correct.

So, if we take that as a forgone conclusion, the real issue
isn't how long does it take to process rules with exceptions;
rather, the question is: who should expand semantic groups
like "engineering?" Does it make sense for the client to
download the entire several-hundred-member list from the server,
clip one user out of it, and then send it back in a different
format, or to send instructions to the server that say, "take
this list, remove this discrete list of elements from it, and
then install every remaining member as a positive rule"?

I think the key here is that you do *not* need to store the
rules as "group with exceptions." If it makes your processing
model work better, you can trivially expand the group and apply
the exceptions when you receive the message at the server -- and
then everything is reduced to the list of positive statements
that is apparently much easier to implement.

Outlawing the ability to say "except" *will* lead to implementations
that do the horrifically high-bandwidth "fetch, prune, and upload"
client-side exceptions that I describe above -- and, if we don't
have any indicated method for that "fetch" phase, then you *will*
end up with multiple, uninteroperable implementations. (Think of
the case where your client [built into the operating system] and your
server are made by the same large corporation that really likes using
its own proprietary directory service. Is that the direction we want
to drive things?)

/a

(With apologies to all the Bobs out there)

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, November 07, 2003 8:15
> To: Naoko ITO
> As I recall:  at the interim meeting in September we were 
> fortunate to 
> have two people in attendance that had implemented similar access 
> systems.  It was their opinion that the 'except' clause adds enough 
> processing to be a scalability concern for even moderately loaded 
> systems.  The fastest systems are able to take a set of rules and 
> process them one after another until there is a hit.
> 
> Naoko ITO wrote:
> > 
> Neither do I.  But in my opinion, both should be dismissed.
> 
> -andy
> 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2003 14:28:59 -0600

/a