Subject: [Geopriv] Proposal for 3693bis

From: Richard Barnes <[email-masked]>
Date: Fri, 06 Jun 2008 10:23:29 -0400

Hi everyone,

At the GEOPRIV meeting in Philadelphia, there seemed to be some 
agreement that GEOPRIV should work on an update to RFC 3693, what I'll 
call a 3693bis.  I'd like to get a feel for what problems people think 
this document should address.  Here's my take:

3693bis should be a guiding conceptual architecture for GEOPRIV, both an 
overview document to make other work comprehensible, and a framework on 
which to hang work items -- it should be possible to point to a GEOPRIV 
document and say (1) how it fits into the overall architecture, and (2) 
what that means in terms of requirements (especially for security and 
privacy).  With that goal in mind, I think there are two major ways in 
which 3693/3694 need to be extended:

1. Expand the architecture to cover more use cases
For a while now, GEOPRIV has been working on protocols that play 
functional roles not easily described by the architecture defined in 
3693.  In part, this is because RFC 3693 is very focused on LO format 
requirements that have since been satisfied by the PIDF-LO format; the 
working group has thus moved on to protocols that carry location and 
more advanced concepts like location by reference.  There is thus a need 
for a framework to describe how these protocols fit together and what 
the resulting privacy and security trade-offs are.

2. Address a broader range of security concerns
While RFC 3693 and 3694 are mostly concerned with risks facing the 
privacy of location information, it has become increasingly clear that 
there are requirements in the community for other types of security 
assurances, in particular location integrity and data origin 
authentication.  With the development of location configuration 
protocols, there is also an increasing need to clarify the security and 
privacy trade-offs associated with the use of location object formats 
that do not satisfy the requirements of RFC 3693, in particular, the 
formats used in DHCP and RADIUS-LO.  This discussion will also impact 
HELD by helping clarify the role of privacy rules in the LCP use case.

A secondary question is whether the WG wants to use 
draft-barnes-geopriv-lo-sec as a starting point.  This document 
certainly has a more general architecture and addresses more security 
concerns, but (as was pointed out in Philly) both of these need more 
refinement in order to be usable.

I would appreciate comments any of the above questions:
1. Do we need a 3693bis?
2. Does the above capture what that should be?
3. Is draft-barnes-geopriv-lo-sec a good starting point?

Thanks a lot,
--Richard

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

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 07 Jun 2008 21:14:52 -0500

Richard

I understood (i.e., thought) you were going to work on what might be 
considered a RFC3694bis (security threat assessment) doc, especially 
given the direction of your preso, and not redo the requirements doc. 
I believe that effort would seem more in need of updating.

James

---

From: Richard Barnes <[email-masked]>
Date: Mon, 09 Jun 2008 00:44:49 -0400

James,

Good catch: What I'm proposing is a combined update to 3693 and 3694.

You're right that a driving need here is to understand the security 
situation better (e.g., in light of things like LCPs and LbyR), but in 
order to do that, we need to understand how those things fit into the 
big picture.  So the idea of this document would be to update the 
architecture so we know what the roles and interactions are, then update 
the security considerations to enable the security properties that the 
actors require of those interactions.

This is the approach taken in the current document: Section 3 is an 
updated architecture (i.e., the part that would update 3693), and 
Sections 4 and 5 consider the security implications of this model (i.e., 
they would update 3694).  We can break it into two documents if you 
like, but I think it hangs together pretty well as one document for now.

--Richard

James M. Polk wrote:
> given the direction of your preso, and not redo the requirements doc. I 
> believe that effort would seem more in need of updating.
> 
> James
>