James,

The name of the game here is "entropy" -- if I know the format for a 
URI, how many URIs do I have to try before I win?  Here, 'win' can have 
two possible meanings:
1. I get any URI that dereferences to a location (a valid URI)
2. I get a URI that dereferences to a particular location
If you want to prevent an attacker from winning in either sense, you 
need to give him a big search space and distribute winning values 
randomly in it.

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.

To be more formal about this: By not applying authentication to a URI, 
the LS is making the inference that knowledge of the URI implies 
authorization to dereference the URI.  There are two ways for an 
attacker to get the URI: Someone can give it to him or he can guess it. 
  The first case isn't an issue, because the LS only gives the URI to 
authorized people to start with, and they can pass on authorization by 
passing around the URI.  So the problem is to prevent people without 
access to the URI from guessing it.

The question is then how much information we assume the attacker starts 
with.
1. If he has none at all, then it's pretty hard in any case (e.g., he 
has to guess a domain name / LIS to send the query to).
2. Now assume he knows the name of the LIS and the protocol (not a very 
far-fetched assumption).  That cuts down his search space a lot: he just 
has to search through things like
<pres:XXXXX@lis.example.com> or
<http://lis.example.com/XXXXX>
In order to prevent this search from being feasible, the valid values of 
"XXXXX" need to have enough entropy that they're hard for him to guess, 
for the reasons described above.

Now, it is still worth noting that this is all *optional*.  If the LS 
wants to authenticate and authorize every dereference independently, 
then it's free to choose whatever URIs it wants, even 
<pres:this.is.obviously.james.polk@cisco.com>.  The randomization 
requirements only apply when there is no other authorization policy 
being applied.

<shameless-plug>
This is also something we discuss, along similar lines of reasoning, in 
the BRAND NEW draft-barnes-geopriv-lo-sec-02.
</shameless-plug>

Hope this helps to clarify,
--Richard



> I'm still not clear why requirement R* below mandates a random number, 
> and not a unique identifier with no user identity information. The two 
> are not the same, and yet accomplish the same goal.  I also want to know 
> why 16 bytes is *the* good length, and not a shorter number, as long as 
> it is not guessable, say, at least a multiple X of the number of 
> possible users within a domain.  If Andrew only has 50 employees (which 
> I don't know, btw, but it appears to be a good example), having at least 
> a 16 byte random sequence is way overkill, where a 4 or 5 byte number 
> would suffice.
> 
> Regarding R**, how does the anonymized format of a URI have anything to 
> do with the protocol, which can be text or binary based? Doesn't this 
> only have to do with how the LIS generates the non-domain part of the 
> URI (with whatever length we decide)? The protocol will merely be the 
> transporter of this value, so it doesn't decide, I shouldn't think.
> 
>>   I've also included James' diagram, since it seems to be popular 
>> thing to show the Rulemaker.
> 
> cool
> 
> 
>> thanks.
>>
>> -roger marshall.
>>
>> > -----Original Message-----
>> > From: geopriv-bounces@ietf.org
>> > [mailto:geopriv-bounces@ietf.org] On Behalf Of Richard Barnes
>> > Sent: Sunday, February 17, 2008 6:24 PM
>> > To: James M. Polk
>> > Cc: GEOPRIV
>> > Subject: Re: [Geopriv] Q2 about
>> > draft-ietf-geopriv-lbyr-requirements-01
>> >
>> > First, I like James P's diagram!  It concisely shows how all
>> > the pieces interrelate.
>> >
>> > Second, if I may propose some text for requirements related to
>> > randomness: The LIS is the one that creates URIs, and knows
>> > what policies will be applied to each one.  Some will be
>> > authenticated / access-controlled, and some will not (i.e.,
>> > they'll be "pawn tickets").
>> >   One part of a deref document will be specifying a URI
>> > format for the LbyR scheme.  So how about this requirement:
>> >
>> > 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.
>> >
>> > R**: The dereference protocol MAY define a more general,
>> > non-anonymized URI format.  Only URIs for which dereference
>> > is subject to access-control policy by the LIS may use this format.
>> >
>> > Respectfully submitted,
>> > --RB
>> >
>> >
>> >
>> > James M. Polk wrote:
>> > > [put your seatbelts on!]
>> > >
>> > > I agree completely with what James W said here.
>> > >
>> > > With that said, I'll suggest there be a forth communication path in
>> > > the Figure 1 of this ID, one that sets up the policies of the
>> > > rulemaker, which as RFC 3693 describes - is either the SP, the
>> > > Target's user, or a combination of the two.  I expect there
>> > will be a
>> > > default policy set by any SP (including enterprises), and
>> > the user can
>> > > modify from those defaults up to a certain degree (like who (which
>> > > requesters) go into which category of answer type).
>> > >
>> > > I attached a 2k new Figure 1. offering, with associated
>> > text (in case
>> > > it doesn't render below very well)
>> > >
>> > > Here is the offered Figure 1., that could show this communications
>> > > exchange:
>> > >
>> > >
>> > >                 +-----------+ Geopriv     +-----------+
>> > >                 |          | Location    | Location |
>> > >                 |   LIS   +---------------+ Recipient |
>> > >                 |          | Dereference |          |
>> > >                 +-+---+-----+ Protocol (3) +----+------+
>> > >                  *   |                       --
>> > >      Rulemaker *     | Geopriv             --
>> > >       Policy    *     | Location          --
>> > >     Exchange *      | Configuration   --
>> > >        (1b) *       | Protocol      --
>> > >             *        | (1a)        --     Geopriv
>> > >            *          |           --       Using Protocol
>> > >   + - - - -*- - - - - -|- - - -+ --         (e.g., SIP)
>> > >   |+-------+---+ +-----+-----+ |--           (2)
>> > >   | Remote / | | Target / |--
>> > >   || other  | | End Host + |
>> > >   |   Device | |          |
>> > >   |+-----------+ +-----------+ |
>> > >
>> > >   |      User of Target       |
>> > >   + - - - - - - - - - - - - - -+
>> > >
>> > >
>> > >    Figure 1: Shows the assumed communication model for both
>> > a layer 7
>> > >       location configuration protocol and a dereference protocol:
>> > >
>> > >   (the following paragraph should be #2 below this Figure
>> > in the doc)
>> > >
>> > >   For completeness, Figure 1, includes the interaction between the
>> > >   owner of the Target and the LIS to establish rulemaker policies.
>> > >   This is communications path (1b). This interaction needs to be
>> > >   done before the LIS will authorize anything of than
>> > default policies
>> > >   to a dereference request for location of the Target.
>> > >
>> > >
>> > > At 04:12 PM 2/17/2008, Winterbottom, James wrote:
>> > >> Hi Hannes and James,
>> > >>
>> > >> Hannes, this document to some extent grew out of the L7LCP work in
>> > >> which the reference is generated by a kind of "partially-trusted"
>> > >> server, the LIS. In this model the LIS doesn't generally know who
>> > >> some is, but they do have stuff like IP addresses, and
>> > they are able
>> > >> to work out where they are. I don't believe that when we
>> > originally
>> > >> did this work we factored in, or really considered, the
>> > inclusion of
>> > >> a well-known SIP URI, such as James is describing.
>> > >>
>> > >> To that end, I think that the need for randomness in the URI is
>> > >> really restricted to applications where the target device is:
>> > >>
>> > >> 1) Unable or unwilling to provide identity information to the LIS
>> > >> and/or the Location recipient.
>> > >>
>> > >> 2) Unable or unwilling to provide rules and policies to the LIS
>> > >> concerning who the LIS may provide the Target's to.
>> > >>
>> > >> In short, I think it is okay to have a URI as James suggests,
>> > >> providing that James can tell the LIS who is allowed to access his
>> > >> location information, and the LIS promises to abide by
>> > what James has
>> > >> asked. This is also presumes that the LIS MUST fail a location
>> > >> request if it can't authenticate an LR, since without
>> > authentication,
>> > >> it can't check its authorization policies.
>> > >>
>> > >> Cheers
>> > >> James
>> > >>
>> > >>
>> > >> > -----Original Message-----
>> > >> > From: geopriv-bounces@ietf.org
>> > [mailto:geopriv-bounces@ietf.org] On
>> > >> Behalf
>> > >> > Of Hannes Tschofenig
>> > >> > Sent: Monday, 18 February 2008 3:29 AM
>> > >> > To: GEOPRIV
>> > >> > Subject: [Geopriv] Q2 about
>> > draft-ietf-geopriv-lbyr-requirements-01
>> > >> >
>> > >> > Hi James,
>> > >> >
>> > >> > This is also a good question.
>> > >> > See my thoughts inline:
>> > >> >
>> > >> >  > -----Ursprüngliche Nachricht-----  > Von:
>> > >> > geopriv-bounces@ietf.org  > [mailto:geopriv-bounces@ietf.org] Im
>> > >> > Auftrag von ext James M. Polk  > Gesendet: Samstag, 16. Februar
>> > >> > 2008 02:24  > An: geopriv@ietf.org  > Betreff: [Geopriv]
>> > Q2 about
>> > >> > draft-ietf-geopriv-lbyr-requirements-01
>> > >> >  >
>> > >> >  > Section 5.1 has this requirement  >  > "
>> > >> >  > C4. Random Generated:  The location URI MUST be hard
>> > to guess,
>> > >> > i.e.,  > it MUST contain a cryptographically random component.
>> > >> >  >
>> > >> >  > Motivation: There is some benefit to the client if
>> > the location
>> > >> > URI  > is generated in an obscured manner so that its
>> > sequence, for
>> > >> > example  > in the case of a client's location update,
>> > can't be easy guessed.
>> > >> >  > "
>> > >> >  >
>> > >> >  > Why does this need to be cryptographically random?
>> > >> >
>> > >> > First, the reference must not contain the user identity.
>> > >> > Second, one should make sure that the reference cannot easily be
>> > >> guessed
>> > >> > or that one searches through the space easily in order
>> > to retrieve
>> > >> > the location of all the Targets in a network. This is mainly
>> > >> > motivated by the fact that possession of the reference is
>> > >> > essentially equal to possessing the location itself.
>> > Hence, there
>> > >> > is no additional authorization check.
>> > >> >
>> > >> > As such, it is important from a security and privacy
>> > point of view
>> > >> > that part of the URI is randomly created. I would say
>> > with at least
>> > >> > 128 bit of randomness.
>> > >> >
>> > >> >  >
>> > >> >  > As long as my badge number is "3199", why can't my
>> > LbyR URI be
>> > >> > >
>> > >> >  >          sips:cisco3199.cisco.com
>> > >> >
>> > >> > Easy to search through the space and learn the location
>> > of the Targets.
>> > >> >
>> > >> >  >
>> > >> >  > The domain part is already revealed in the URI, and
>> > who know who
>> > >> > is  > assigned to cisco3199?
>> > >> >
>> > >> > You might not know the real identity of the Target;
>> > maybe - unless
>> > >> > someone puts an appropriate value into the PIDF-LO.
>> > >> >
>> > >> >
>> > >> >  >  My identity can't be derived from it, and  > maybe my domain
>> > >> > assigns the next available number to the next  > requester of
>> > >> > location.  Perhaps after a certain amount of time  > without an
>> > >> > assignment, I go back to being unassigned, and get the  > next
>> > >> > available number from the cisco.com domain.
>> > >> >
>> > >> > I doubt that a network operator wants to let other people know
>> > >> > where
>> > >> end
>> > >> > hosts are.
>> > >> >
>> > >> >  >
>> > >> >  > Also, if it has to be cryptographically random, where's the
>> > >> > guidance  > on what that means, what that is, and how I
>> > know I've
>> > >> > met the  > requirement?  This at least is a glaring hole
>> > in the ID,
>> > >> > and
>> > >> likely a
>> > >> >  > huge burden on the providers of location.
>> > >> >
>> > >> > Providing random numbers is not a huge problem. This is a common
>> > >> > aspect in all security protocols. I would follow the
>> > guidelines in:
>> > >> > http://www.ietf.org/rfc/rfc4086.txt
>> > >> >
>> > >> >  >
>> > >> >  > Further, what constitues a "sequence" -- which is
>> > referred to in
>> > >> > the  > Motivation for the requirement? Is that numeric
>> > only, or can
>> > >> > it be  > alpha too? Is it UTF-8 only, or can it be
>> > UTF-16?  Does it
>> > >> > have
>> > >> to be
>> > >> >  > as random as "unique through space and time" as the Call-ID
>> > >> header in
>> > >> >  > SIP needs to be?  Where's the guidance in this hint (that acts
>> > >> like a
>> > >> >  > requirement itself)?
>> > >> >
>> > >> > I wouldn't use the term sequence in the description. It
>> > is indeed
>> > >> > misleading.
>> > >> > Random (with at least 128bit of entrophy) and difficult to guess
>> > >> > would be fine for me.
>> > >> >
>> > >> >  >
>> > >> >  > I think at the very least, this should be a SHOULD, and not a
>> > >> > MUST,  > "...hard to guess..." requirement.
>> > >> > I believe that this is a really important requirement that
>> > >> > implementers are likely to get wrong and it will
>> > subsequently lead
>> > >> > to a lower level of security and privacy. Hence, a MUST
>> > is justified.
>> > >> >
>> > >> > Ciao
>> > >> > Hannes
>> > >> >
>> > >> >  >
>> > >> >  > James
>> > >> >  >
>> > >> >  > _______________________________________________
>> > >> >  > Geopriv mailing list
>> > >> >  > Geopriv@ietf.org
>> > >> >  > http://www.ietf.org/mailman/listinfo/geopriv
>> > >> >  >
>> > >> > _______________________________________________
>> > >> > Geopriv mailing list
>> > >> > Geopriv@ietf.org
>> > >> > http://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
>> > >> http://www.ietf.org/mailman/listinfo/geopriv
>> > >
>> > >
>> > ----------------------------------------------------------------------
>> > > --
>> > >
>> > > _______________________________________________
>> > > Geopriv mailing list
>> > > Geopriv@ietf.org
>> > > http://www.ietf.org/mailman/listinfo/geopriv
>> >
>> > _______________________________________________
>> > Geopriv mailing list
>> > Geopriv@ietf.org
>> > http://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
http://www.ietf.org/mailman/listinfo/geopriv