Subject: [Simple] AW: [Geopriv] presence authorization issue: anonymous, authentica ted, etc.

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 17 Feb 2005 16:24:22 +0100

hi jonathan, 

> Folks,
> 
> We've had a few stalled discussions and stalled threads (most recently
> on the geopriv list) on the issue of what the common policy and/or
> presence authorization specications should provide in terms of
> conditions that match any authenticated identity, and whether 
> or not an
> unauthenticated identity counts as anonymous or not.

that's more than true. 

> 
> For background material, check out the meeting minutes from the last
> SIMPLE session:
> 
> http://www.softarmor.com/simple/meets/ietf61/proceedings/simpl
> e61-session1-minutes.html
> 
> and a recent thread on geopriv:
> 
> http://www.ietf.org/mail-archive/web/geopriv/current/msg00519.html
> 
> We need to resolve this issue. It is a gating factor for 
> common policy 
> and the presence authorization work.
> 
> Dean put up a slide during the SIMPLE session last time which 
> attempted 
> to figure out whether the concepts of anonymous and 
> unauthenticated were 
> really separable. Some further thoughts on when such 
> combinations can occur:
> 
> Unauthenticated, Anonymous: this would happen when the From field is 
> present with the value of anonymous and there is no P-A-ID or 
> Identity 
> header field.
> 
> Unauthenticated, Not Anonymous: From field is present, but 
> with a value 
> that is not anonymous

additionally you might want to add that this identifier is not authenticated
or asserted.

> Authenticated, Anonymous: There is a P-A-ID which a value like 
> sip:[email-masked], or a From field that is 
> sip:[email-masked] and an Identity field signed by 
> provider.com. 
> Seems reasonable.

the latter one makes more sense then the former one. 
i think you always need to provide an assertion to justify your claim that
you have been authenticated to some entity. 

> 
> Authenticated, not anonymous: the normal case
> 
> 
> I think its fair to say that if a request is NOT 
> authenticated, there is 
> really no difference between anonymous and not anonymous from 
> a policy 
> perspective; in either case the originating identity is as good as 
> useless. Thus, we'd like to be able to specify policies for 
> three cases: 
> unauthenticated, authenticated and anonymous, and 
> authenticated and not 
> anonymous.
> 
> However, it is also reasonable to say that one would provide 
> different 
> access to presence for anonymous and authenticated users than 
> unauthenticated users. Indeed, the permissions one would apply for 
> unauthenticated users really represent the 'baseline' 
> permissions - no 
> one would ever receive fewer permissions than those guys. Indeed, the 
> question is whether unauthenticated users would ever get any 
> permissions 
> beyond the minimum.
> 
> I would propose that the answer is no, and then make the following 
> concrete proposal:
> 
> 1. An unauthenticated request never matches any rules, and thus never 
> has any permissions granted
> 
> 2. A rule with no conditions matches any authenticated 
> request. Thus, to 
> specify permissions that go to any authenticated request, you 
> would have 
> rules with no conditions.
> 
> 3. A rule with some conditions matches if those rules match and the 
> request is authenticated. This means that the <anonymous> permission 
> assumes the request is authenticated.
> 
> I believe this proposal meets the requirements outlined by 
> Aki; that is, 
> to be able to define a baseline permission of "confirm" for any 
> authenticated user, and then for users that get granted, provide a 
> permission of "allow". It also allows for expression of policies 
> separately for the three main cases above.
> 
> This proposal would require the following changes:
> 
> 1. the geopriv common policy needs to be explicit on the meaning of a 
> rule with no conditions, that it means it applies to any 
> authenticated 
> request

true. basically it needs to contain the content of this mail. 

> 
> 2. the presence auth rules needs to update the definition of the 
> <anonymous> condition
> 
to reflect the argument by paul we might want to introduce another condition
<unauthenticated>. 
this would allow unauthenticated users to obtain some information. 

ciao
hannes

> 
> Can we agree on this and move forward?
> 
> Thanks,
> Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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