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

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

James:
I have made some text changes in the just posted -03 version, in order
to try to accommodate your suggestion to make the distinction between
"access control" and "possession" models a little more clear.  Decided
not to fold it in to the abstract though, since to me it is not as
primary to the document as other things also not mentioned there.

I apologize for the tardiness in getting a response back to you.

-roger.

> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]] 
> Sent: Tuesday, April 01, 2008 6:16 PM
> To: Winterbottom, James; Roger Marshall; Hannes Tschofenig
> Cc: GEOPRIV
> Subject: RE: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> 
> 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