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

["Roger Marshall" <[e-mail]>]

Martin:
I agree with your suggestion of a random-unique concatenation, and so
there is some new text in the just posted next version, -03.

Sorry for the lateness of my response.

-roger. 

> -----Original Message-----
> From: Thomson, Martin [mailto:[e-mail]] 
> Sent: Tuesday, April 01, 2008 3:30 PM
> To: Roger Marshall; James M. Polk; Hannes Tschofenig
> Cc: GEOPRIV
> Subject: RE: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> 
> 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
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Roger Marshall
> > Sent: Wednesday, 2 April 2008 9:05 AM
> > To: James M. Polk; Hannes Tschofenig
> > Cc: GEOPRIV
> > Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> > 
> > 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.
> > 
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[e-mail]]
> > > Sent: Tuesday, April 01, 2008 1:36 PM
> > > To: Roger Marshall; Hannes Tschofenig
> > > Cc: GEOPRIV
> > > Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> > >
> > > 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
> > >
> > > At 03:03 PM 4/1/2008, Roger Marshall wrote:
> > > >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.
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] 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
> > > > > > >> [e-mail]
> > > > > > >> https://www.ietf.org/mailman/listinfo/geopriv
> > > > > >
> > > > > >_______________________________________________
> > > > > >Geopriv mailing list
> > > > > >[e-mail]
> > > > > >https://www.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > [e-mail]
> > > > > 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
> > > >[e-mail]
> > > >https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > >
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/geopriv
> 
> --------------------------------------------------------------
> ----------------------------------
> 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]
> 
> 
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv