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

["James M. Polk" <[e-mail]>]

At 05:18 PM 4/1/2008, Winterbottom, James wrote:
>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.

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
>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.

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.


>Cheers
>James
>
>
> > -----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