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

["Winterbottom, James" <[e-mail]>]

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


> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]]
> 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 ???
> 
> 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]
> 

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