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

From: Roger Marshall ^lt;RMarshall@telecomsys.com>
Date: Tue Jul 08 2008 - 19:51:08 EDT

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:Martin.Thomson@andrew.com]
> 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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] 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:jmpolk@cisco.com]
> > > 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: geopriv-bounces@ietf.org
> > > > > [mailto:geopriv-bounces@ietf.org] 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
> > > > > > >> Geopriv@ietf.org
> > > > > > >> https://www.ietf.org/mailman/listinfo/geopriv
> > > > > >
> > > > > >_______________________________________________
> > > > > >Geopriv mailing list
> > > > > >Geopriv@ietf.org
> > > > > >https://www.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > 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
> > > >Geopriv@ietf.org
> > > >https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > 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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 8 Jul 2008 16:51:08 -0700

This archive was generated by hypermail 2.1.8 : Tue Jul 08 2008 - 19:52:06 EDT