Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???

From: "Roger Marshall" <[email-masked]>
Date: Tue, 1 Apr 2008 11:24:32 -0700

The following summarizes the first of the three original subj:
questions, Q1,Q2,Q3:

Q1: 

...about draft-ietf-geopriv-lbyr-requirements-01, Fr: James M. Polk
Sent: Friday, February 15, 2008 4:13 PM
> 
> This document states clearly that it only covers LCPs and 
> Dereference protocols (which seems to leave out conveyance 
> protocols, BTW).
> 
> In that context, I don't understand requirement C7 (in 
> section 5.1), since this requirement is clearly discussing a 
> clients ability to dereference location, yet it appears in 
> the LCP requirements section.  Why is C7 where it is? And why 
> is C7 not in the next section (section 5.2) that discusses 
> dereference protocols? 

... Some List discussion...

My response to the list on 2/25/08...

[
-rsm, true, we need to agree on something.  A couple of proposals:
a. valid until some time t, in seconds, measured from a baseline time
t0, (e.g., UTC), or b. valid until some time t, in seconds, measured
from "now", which would be a relative UTC timestamp - now must be
included as a new baseline reference.
/]

PROPOSAL:
I now think that neither of the above suggestions would work well.
Rather, the best way is a  third option, c., which reuses the 'expires'
attribute approach from LoST, containing values
'dateTime','NO-EXPIRATION', and 'NO-CACHE'.  This makes timing explicit,
and avoids subjectiveness due to potential transport delay, and avoids
unnecessary recalculations.

CHANGE FROM:
Current C7 requirement (-02) reads:
C7. Location URI Valid-for:  A location URI validity interval, if
used, MUST include the validity time, in seconds, as an indication
of how long the client can consider a location URI to be valid.

CHANGE TO:
Proposed C7 requirement would read:
C7*. Location URI expiration:  An expiration indicator MUST be included
with 
the location URI to indicate the URI validity interval.  This indicator
utilizes 
any of the following parameter values, 'dateTime','NO-EXPIRATION', and
'NO-CACHE', 
where dateTime is a timezoned XML type dateTime, in canonical
representation, 
NO-EXPIRATION is indicator that the location URI never expires, and
NO-CACHE 
means that it is valid now, but should not be reused, and if needed
again, it MUST 
be requeried for.

Questions Q2 & Q3 will be sent as separate threads.

-roger marshall.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: Monday, March 31, 2008 1:19 PM
> To: Hannes Tschofenig
> Cc: GEOPRIV
> Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> 
> At 07:53 AM 3/30/2008, Hannes Tschofenig wrote:
> >It seems that you are saying that Roger has to keep things going.
> 
> All I'm saying is that there was never a post articulating 
> what the consensus reached answers were to each of the 3 
> questions I asked on the list.  I don't believe that is 
> asking a lot. Do you think this is asking too much?
> 
> Each of the 3 questions had ~ 5 to 75 responses, so there 
> were a lot of folks interested in the questions, and 
> obviously the first response didn't answer any of the 3 Qs right away.
> 
> 
> >Roger, could you post a description of the outstanding issues with a 
> >suggestions on how to address them?
> >
> >Ciao
> >Hannes
> >
> >James M. Polk wrote:
> > > At 12:40 PM 3/29/2008, Hannes Tschofenig wrote:
> > >> Given the status of HELD this document should have been 
> finished a 
> > >> while ago.
> > >> I am not even sure whether I have seen a WGLC for it.
> > >>
> > >> What are the next steps for it?
> > >> Why isn't it done already?
> > >
> > > weeeeelllll....
> > >
> > > There were 3 fairly substantiative questions posted 
> against -01 of 
> > > the ID just before the -0X deadline, and there needs to 
> be time for 
> > > proper review of -02 to see if this version answers at 
> least these 3 questions.
> > >
> > > I think 1 has been answered
> > >
> > > I think another has not reached consensus
> > >
> > > and the last wasn't answered at all
> > >
> > > but this is memory (which may or may not be reliable)
> > >
> > >
> > >> _______________________________________________
> > >> Geopriv mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> >_______________________________________________
> >Geopriv mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
> 

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

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

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 1 Apr 2008 12:37:36 -0700

The following summarizes the second of the three original subj:
questions, Q1,Q2,Q3:

Q2.

...about draft-ietf-geopriv-lbyr-requirements-01
Sent: Friday, February 15, 2008 4:24 PM, Fr: James M. Polk

> Section 5.1 has this requirement
> 
> "
> C4. Random Generated:  The location URI MUST be hard to 
> guess, i.e., it MUST contain a cryptographically random component.
> 
> Motivation: There is some benefit to the client if the 
> location URI is generated in an obscured manner so that its 
> sequence, for example in the case of a client's location 
> update, can't be easy guessed.
> "
> 
> Why does this need to be cryptographically random?
> 
> As long as my badge number is "3199", why can't my LbyR URI be
> 
>          sips:cisco3199.cisco.com
> 
> The domain part is already revealed in the URI...[cut]

The last of many emails discussing this was on 3/03... (btwn, James P.,
Barbara S., Richard B.).  Based on that discussion, and some earlier R*
text from Richard Barnes, the current requirements draft (-02) contains
the following resolution to Q2:

   C4. [Deleted, replaced by C8,C9,C10]:

...

   C8. Location URI Anonymous:  The location URI MUST NOT reveal any
      information about the Target other than it's location.

      Motivation: A user should have the option to control how much
      information is revealed about them.  This provides that control by
      not forcing the inclusion of other information with location,
      (e.g., to not include any identification information in the
      location URI.)

   C9. Location URI Not guessable:  Location URIs that do not require
      authentication and authorization MUST NOT be guessable, based on
      the use of a cryptographically random sequence somewhere within
      the URI.  (Note that the number of bits depends to some extent on
      the number of active location URIs that might exist at the one
      time; 128-bit is most likely enough for the short term.)

      Motivation: Location URIs without access control reveal private
      information, and a guessable location URI could be easily
      exploited to obtain private information.

   C10.  Location URI Optional:  In the case of user-provided
      authorization policies, where anonymous or non-guessable location
      URIs are not warranted, the location configuration protocol MAY
      support optional location URI forms.

      Motivation: Users don't always have such strict privacy
      requirements, but may opt to specify their own location URI, or
      components thereof.

I'm not currently aware of any further comments received on the list
concerning this approach and language.

-roger marshall.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Apr 2008 14:53:18 -0500

Roger

thanks for doing this

>unnecessary recalculations.

Since DHCP should incorporate what is in this doc as best as it can, 
and is a BINARY protocol, the above would not work easily since it is 
written for text based protocols (i.e., with variable length fields the norm).

I'm not exactly suggesting we reverse engineer this into
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-00.txt
to make it work, but I also don't yet see how this requirement can be 
met in the URI Option ID.  the 'dateTime' indication needs a format 
if conveyed in binary *AND* we need to agree what the value 
indicates. I assume you suggest this dateTime value in the URI Option 
ID means when the URI is no longer considered for use, but want to 
get this clearly agreed upon.

If the 'dateTime','NO-EXPIRATION', and 'NO-CACHE' choices are a new 
DHCP field, how long is the field? 1 byte?

This will necessitate a matrix be built for each of the 3 indicates, 
is there a value in the old "valid-for" field that likely becomes an 
"expiry-Time" field. AS an example, if there is a 'NO-EXPIRATION' 
indication, yet there is a value in the "expiry-Time" field, what 
happens (i.e., what does this mean)? Does a 'NO-EXPIRATION' 
indication mean there cannot be a value in the "expiry-Time" field, 
or does it mean the "expiry-Time" field is ignored?

Regardless, this makes the URI Option ID a little more complicated.

>means that it is valid now, but should not be reused, and if needed

How exactly can a binary protocol satisfy the above requirement as written?
or
Do binary LCPs merely ignore this requirement?

You have a MUST above, but this is clearly tailored for text based 
protocols, at the expense of binary protocols.  This isn't fair, and 
I therefore don't support this as written.

>CONFIDENTIALITY NOTICE: The information contained in this message 
>may be privileged and/or confidential. If you are not the intended 
>recipient, or responsible for delivering this message to the 
>intended recipient, any review, forwarding, dissemination, 
>distribution or copying of this communication or any attachment(s) 
>is strictly prohibited. If you have received this message in error, 
>please notify the sender immediately, and delete it and all 
>attachments from your computer and network.

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 1 Apr 2008 13:03:19 -0700

The following summarizes the third of the three original subj:
questions, Q1,Q2,Q3:

Q3.

...about draft-ietf-geopriv-lbyr-requirements-01
Sent: Friday, February 15, 2008 4:24 PM, From: James M. Polk 

> 
> I may have missed the text, but I don't see it in a 
> requirement -- but at the last meeting, I was told by James W 
> and Hannes that each LbyR URI MUST be unique.  I don't read 
> that anywhere in this ID.
> 
> I read that "...it MUST be hard to guess..."
> 
> why can't all 200 participants in the room draw from a 
> smaller pool of numbers that a cryptographically random 
> value?  It would still be "hard to guess" who has which identifier...

Not much discussion here, but there seemed to be two differing views on
this:

[a.] One view (Hannes) is that we need to add a new requirement...

> [...from...] Tschofenig, Hannes
> Sent: Sunday, February 17, 2008 3:48 AM
> Subject: Re: [Geopriv] Q3 about
draft-ietf-geopriv-lbyr-requirements-01
> 
> Uniqueness is very important. The draft should really have 
> such a requirement. Saying that a part of the identifier is 
> random is not enough.  
> 
> We need to add a requirement. 

[b.] the other view, (James P. responding to Richard's clarification
q's), seems to take some exception with the idea of a new req.

[...from...] James M. Polk
Sent: Sunday, February 17, 2008 7:05 PM To: Richard Barnes; Tschofenig,
Hannes 
Subject: Re: [Geopriv] Q3 about draft-ietf-geopriv-lbyr-requirements-01
> 
> At 08:27 PM 2/17/2008, Richard Barnes wrote:
> >Could you two clarify what you mean by "unique"?
> 
> well, this is part of what I was getting at. For example, 
> within RFC 3261, the Call-ID value "MUST be unique through 
> space and time" -- meaning the alphanumeric value is never 
> repeatable by any UA ever, not just within the same UA.
> 
> This is reeeeally unique.
> 
> I think this is more than we need here.
> 
> >That is, within what scope should the URI be unique?
> 
> I think a URI has to be unique within a LIS for all clients 
> that have asked for one. I'm not sure we need to be any more 
> unique than that.
> 
> >Do you mean to prevent the LS from issuing multiple URIs 
> that refer to 
> >the same location?
> 
> I actually don't see a problem in this... but I could be 
> wrong (and want to know why I'm wrong BTW)
> 
> >Or are you trying to rule out a case where an LS just hands 
> out one URI 
> >(or a few URIs), then hands out different LOs depending on who asks 
> >(i.e., the LS uses one URI to refer to multiple LOs)?
> 
> No, from my pov, unique means that a LIS has one unique URI 
> for each client that has asked for one.
> 
> I do not believe this URI has to be unique from what's given 
> out tomorrow, as long as no two clients have the same URI.  
> This is one of the uses of the valid-for parameter (that both 
> the DHCP Option ID and HELD ID have).  My client shouldn't 
> necessarily always be given the same URI, since there is no 
> real guarantee it won't be compromised, someone will always 
> have knowledge of my URI once they learn it once.
> 
> Having my URI change periodically has a benefit, as long as 
> it doesn't change sooner than the active timer of the 
> 'valid-for' parameter is set (unless there's been a new 
> request and a particular client's URI has been overwritten.

SUMMARY:
I don't have any further record of any progression on the topic, which
kept me from adding said requirement in -02.  What should the resolution
now be?

Thanks.

-roger marshall.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Apr 2008 15:35:59 -0500

Roger

There were comments in Philly that 128 was an arbitrary number 
without backing, so why was it picked.  There was also discussion on 
the difference between unique and random in Philly, which was 
resolved -- but that doesn't mean either issue is dropped.

James

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 1 Apr 2008 15:04:40 -0700

The Philly geopriv minutes reference a "129 bits of entropy...EKR
statement..." - besides the obvious typo, the 128 bits of entropy there
related to the security draft,
http://www3.tools.ietf.org/html/draft-barnes-geopriv-lo-sec-02, whereas
the stuff below came from a couple of Richard's (and others) discussion
thread on Q3:

1. a snippet of Richard's response of one such message...

R*: The dereference protocol MUST define an anonymized format for 
location URIs.  This format MUST identify the desired LO  by a 
random token with at least 128 bits of entropy (rather than an 
!                          ^^^^^^^^^^^^^^^^^^^
explicit identifier, such as an IP address).  Any URI whose 
dereference will not subject to authentication and access 
control MUST be anonymized.

Link to above message:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05352.html

2. ...also an earlier email talking about (base) number examples which
don't work...

Example 1: Using a 5-digit number doesn't work, because that's only 10k 
queries, and I can write a script to run through those in a few minutes.

  Thus, you need more digits.

Example 2: Using a 32-byte number doesn't work if you assign it 
sequentially, since I can just start from the bottom and win a lot 
faster than at random.  Thus, the numbers need to be assigned at random.

Link to complete message:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05346.html

What was the resolution between unique & random?  Whatever the outcome,
it should probably be inserted into the lbyr-requirements draft, yes?

-roger marshall.

> From: James M. Polk [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 1:36 PM
> To: Roger Marshall; Hannes Tschofenig
> Cc: GEOPRIV
> There were comments in Philly that 128 was an arbitrary 
> number without backing, so why was it picked.  There was also 
> discussion on the difference between unique and random in 
> Philly, which was resolved -- but that doesn't mean either 
> issue is dropped.
> 
> James
> 
> requirement -- 
> > > but at the last meeting, I was told by James W and Hannes 
> that each 
> > > LbyR URI MUST be unique.  I don't read that anywhere in this ID.
> > >
> smaller pool 
> > > of numbers that a cryptographically random value?  It 
> would still be 
> > > "hard to guess" who has which identifier...
> >
> > > Uniqueness is very important. The draft should really have such a 
> > > requirement. Saying that a part of the identifier is 
> random is not 
> > > enough.
> > >
> within RFC 
> > > 3261, the Call-ID value "MUST be unique through space and 
> time" -- 
> > > meaning the alphanumeric value is never repeatable by any 
> UA ever, 
> > > not just within the same UA.
> > >
> > > I think a URI has to be unique within a LIS for all clients that 
> > > have asked for one. I'm not sure we need to be any more 
> unique than 
> > > that.
> > >
> > > No, from my pov, unique means that a LIS has one unique 
> URI for each 
> > > client that has asked for one.
> > >
> > > I do not believe this URI has to be unique from what's given out 
> > > tomorrow, as long as no two clients have the same URI.
> > > This is one of the uses of the valid-for parameter (that both the 
> > > DHCP Option ID and HELD ID have).  My client shouldn't 
> necessarily 
> > > always be given the same URI, since there is no real guarantee it 
> > > won't be compromised, someone will always have knowledge 
> of my URI 
> > > once they learn it once.
> > >
> > > Having my URI change periodically has a benefit, as long as it 
> > > doesn't change sooner than the active timer of the 'valid-for' 
> > > parameter is set (unless there's been a new request and a 
> particular 
> > > client's URI has been overwritten.
> >
> >SUMMARY:
> >kept me from adding said requirement in -02.  What should the 
> >resolution now be?
> >
> >Thanks.
> >
> >-roger marshall.
> >
> > > All I'm saying is that there was never a post 
> articulating what the 
> > > consensus reached answers were to each of the 3 questions 
> I asked on 
> > > the list.  I don't believe that is asking a lot. Do you 
> think this 
> > > is asking too much?
> > >
> were a lot 
> > > of folks interested in the questions, and obviously the first 
> > > response didn't answer any of the 3 Qs right away.
> > >
> > >
> > > >Roger, could you post a description of the outstanding 
> issues with 
> > > >a suggestions on how to address them?
> > > >
> > > >Ciao
> > > >Hannes
> > > >
> > > >James M. Polk wrote:
> >CONFIDENTIALITY NOTICE: The information contained in this 
> message may 
> >be privileged and/or confidential. If you are not the intended 
> intended 
> >recipient, any review, forwarding, dissemination, distribution or 
> >copying of this communication or any attachment(s) is strictly 
> >prohibited. If you have received this message in error, 
> please notify 
> >the sender immediately, and delete it and all attachments from your 
> >computer and network.
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 1 Apr 2008 17:18:26 -0500

These requirements only make sense in the case where possession of the
URI is equivalent to possession of the data or resource at the other end
of the URI. They may not apply in situations where authentication,
authorization and subsequent policy invocation occur prior to the data
or resource being made available to the requesting entity. The degree to
which the requestor is authenticated is application and deployment
specific. For example in an enterprise the mere fact that I am on the
enterprise network may be all the authentication that is required.

Providing this clear division of location reference type is made, I am
not sure that I understand what the outstanding issue is.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Roger Marshall
> Sent: Wednesday, 2 April 2008 9:05 AM
> To: James M. Polk; Hannes Tschofenig
> Cc: GEOPRIV
the
> > >the sender immediately, and delete it and all attachments from your

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 1 Apr 2008 17:29:30 -0500

As James said, the point is that the URI be hard to guess iff possession
implies permission.

To implement the "hard to guess" bit we recommend a random number.
However, that doesn't obviate the other requirement, which is that a
location URI must refer to a location - if it isn't unique, then the
server can't be sure which result to provide.  Therefore, it needs to be
BOTH unique and hard to guess.

There isn't anything preventing both uniqueness and randomness from
being used at the same time, just concatenate a random number and
sequence number together.  I note that often people rely on the odds of
a collision with massive random numbers to provide an approximation of
uniqueness.

Cheers,
Martin

> Behalf Of Roger Marshall
the

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Apr 2008 20:10:51 -0500

>related to the security draft,

no, I brought up this point at the mic about unique vs. random and 
EKR -- who's better at security than all of us -- followed me and 
said he didn't understand the 128 number, how it was derived or what 
it was accomplishing.

I can't help it if this exact sequence isn't in the minutes, it 
happened and the audio will back me up.

>queries,

if you have 20 employees in an enterprise (i.e., within the same 
LIS), 10k numbers is just fine.

you're missing the point that having the number doesn't make the 
identity known, given that any of these employees on this LIS could 
in wildly different geographic areas.

>and I can write a script to run through those in a few minutes.
>
>sequentially,

but who knows they're sequential without knowing the identity of the 
users to make a complete examination of the impact on sequential vs 
non-sequential numbering?

>since I can just start from the bottom and win a lot
>faster than at random.

"win"?  who knows where the start point is? doesn't that matter? I 
think it does.

>Thus, the numbers need to be assigned at random.

this is circular logic - and not convincing

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Apr 2008 20:15:34 -0500

At 05:18 PM 4/1/2008, Winterbottom, James wrote:
>specific.

None of this above is clearly articulated in the draft, and if true, 
should be, including in the abstract.  Then I would go along quietly 
about the ID and only point out nits  ;-)

>For example in an enterprise the mere fact that I am on the

If the possession model were made clearer in the draft (i.e., that 
this model is the only model this doc is valid under), I see little 
or no issues with the draft moving forward.

I have issues if the possession model is *not* the only model to be 
used in this document.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 1 Apr 2008 21:14:53 -0500

Hi James,

I don't think that this draft should address just the possession model,
I see a need for it address both models. I totally agree with you that
it needs to be clear about which requirements apply to which model.

Cheers
James

> Sent: Wednesday, 2 April 2008 12:16 PM
> To: Winterbottom, James; Roger Marshall; Hannes Tschofenig
> Cc: GEOPRIV
> Subject: RE: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> 
> > > Example 1: Using a 5-digit number doesn't work, because that's
only
> >10k
such
> >a
that
> > > > > > I do not believe this URI has to be unique from what's given
out
> > > > > > always be given the same URI, since there is no real
guarantee
> >it
it
> > > > > > Subject: Re: [Geopriv]
draft-ietf-geopriv-lbyr-requirements-02
> >???
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------