Subject: [Geopriv] AD review: draft-ietf-geopriv-deref-protocol-03

From: Robert Sparks <[email-masked]>
Date: Tue, 11 Oct 2011 12:30:00 -0500

I am requesting IETF LC for this draft - watch for its announcement soon.

There is some text that I think could be further improved before publishing this as an RFC.
The following notion appears several times in the document:

   However, no authentication framework is provided, which
   limits the policy options available when the "Authorization by Access
   Control" model is used.
There is other work coming from this working group that supports the authorization
by access control model. Is the point of these phrases to highlight that other documents
are needed to make authorization by access control more useful? Or is it to note that the
current tools deployed for authentication over http make authorization by access
difficult.

As written, I expect readers who have not been following this work closely to interpret
the phrase to mean that the group chose not to provide a framework and thus doesn't
expect people to use authorization by access control much. 

RjS

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Oct 2011 10:34:43 +0800

> current tools deployed for authentication over http make authorization

The intent was to simply highlight an area where a commonplace or reasonable assumption (that identity-based access control is an option) could lead to an unexpected conclusion.  HTTP authentication doesn't work until you put in a lot of ground-work: identifying principals, deciding on realms, authentication credentials, trust anchors, and much more.  We don't define them here, so it would be dishonest to even give the impression that HTTP authentication is going to work.  

Whether or not we ever get to the point that we can reliably use (client) authentication in HTTP, I don't want to speculate.

> As written, I expect readers who have not been following this work
> closely to interpret the phrase to mean that the group chose not to provide a framework and
> thus doesn't

I didn't think that it was a good idea to presume anything about how a specification would be deployed.  But your conclusion is the exact one that I would hope that readers take away.

Given the maturity of -policy-uri, it might improve the situation by adding a citation in Section 3.2.  That might at least point a reader in the right direction.

--Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 12 Oct 2011 22:55:04 -0400

Hey Martin,

You message made me realize that my carefully crafted a response to Robert had not been CC'ed the group.  

Kind of like you said, my reading of the section that Robert cites was more that the access control model is just harder to implement in practice than the possession model.  For example, the lack of a global authentication system makes it hard to enforce policies based on requester identity.

Suggested text:

NEW:
"
However, the lack of a uniform authentication infrastructure for the Internet means that certain access control policies will be difficult to implement in practice, especially policies based on the identity of the requestor.
"

OLD:
"
A possible format for these authorization policies is available with GEOPRIV Common Policy [RFC4745] and Geolocation Policy [I-D.ietf-geopriv-policy]. 
"
NEW:
"
A possible format for these authorization policies is available with GEOPRIV Common Policy [RFC4745] and Geolocation Policy [I-D.ietf-geopriv-policy].  If a device receives location URIs via DHCP or HELD, the location server may also provided with a policy URI that can be used to provision privacy policy [I-D.ietf-geopriv-policy-uri].
"

NEW:
[informative reference to draft-ietf-geopriv-policy-uri]

Thoughts?

--Richard

On Oct 12, 2011, at 10:34 PM, Thomson, Martin wrote:

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Oct 2011 11:57:30 +0800

:)

The first could be shorter:

Without a uniform authentication infrastructure for HTTP, access control policies that rely on the identity of the requestor are difficult to implement in practice.

But I'm not sure where you thought that it might go.  Section 3.2 perhaps?

The second change: great.  Exactly what I had in mind.

On 2011-10-13 at 13:55:04, Richard L. Barnes wrote:
> Kind of like you said, my reading of the section that Robert cites was 
> more that the access control model is just harder to implement in 
> practice than the possession model.  For example, the lack of a global 
> authentication system makes it hard to enforce policies based on 
> requester identity.
> 
> Suggested text:
> 
> NEW:
> "
> However, the lack of a uniform authentication infrastructure for the 
> Internet means that certain access control policies will be difficult 
> to implement in practice, especially policies based on the identity of 
> the requestor.
> "
> 
> OLD:
> "
> A possible format for these authorization policies is available with 
> GEOPRIV Common Policy [RFC4745] and Geolocation Policy [I-D.ietf- 
> geopriv-policy].
> "
> NEW:
> "
> A possible format for these authorization policies is available with 
> GEOPRIV Common Policy [RFC4745] and Geolocation Policy [I-D.ietf- 
> geopriv-policy].  If a device receives location URIs via DHCP or HELD, 
> the location server may also provided with a policy URI that can be 
> used to provision privacy policy [I-D.ietf-geopriv-policy-uri].
> "
> 
> NEW:
> >> There is other work coming from this working group that supports 
> >> the authorization by access control model. Is the point of these 
> >> phrases to highlight that other documents are needed to make 
> >> authorization
> by
> >> access control more useful? Or is it to note that the current tools 
> >> deployed for authentication over http make authorization by access 
> >> difficult.
> >
> > The intent was to simply highlight an area where a commonplace or
> reasonable assumption (that identity-based access control is an 
> option) could lead to an unexpected conclusion.  HTTP authentication 
> doesn't work until you put in a lot of ground-work: identifying 
> principals, deciding on realms, authentication credentials, trust 
> anchors, and much more.  We don't define them here, so it would be 
> dishonest to even give the impression that HTTP authentication is going to work.
> >
> > Whether or not we ever get to the point that we can reliably use
> (client) authentication in HTTP, I don't want to speculate.
> >
> >> closely to interpret the phrase to mean that the group chose not to 
> >> provide a framework and thus doesn't expect people to use 
> >> authorization by access control much.
> >
> > I didn't think that it was a good idea to presume anything about how
> a specification would be deployed.  But your conclusion is the exact 
> one that I would hope that readers take away.
> >
> > Given the maturity of -policy-uri, it might improve the situation by
> adding a citation in Section 3.2.  That might at least point a reader 
> in the right direction.
> >
> > --Martin