Subject: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 17 Feb 2008 18:28:49 +0200

Hi James,

This is also a good question.
See my thoughts inline:  

 > -----Ursprüngliche Nachricht-----
 > Von: [email-masked]
 > [mailto:[email-masked]] Im Auftrag von ext James M. Polk
 > Gesendet: Samstag, 16. Februar 2008 02:24
 > An: [email-masked]
 > 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
 > [email-masked]
 > http://www.ietf.org/mailman/listinfo/geopriv
 >
_______________________________________________
Geopriv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/geopriv

---

From: "Peter J. Cranstone" <[email-masked]>
Date: Sun, 17 Feb 2008 15:01:53 -0700

Question... regarding 

>> First, the reference must not contain the user identity.

If there is no identity in the information then how does someone figure out
who or what it came from? I mean it's got to be tied to something to provide
something of use.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hannes Tschofenig
Sent: Sunday, February 17, 2008 9:29 AM
To: GEOPRIV
Subject: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

Hi James,

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 17 Feb 2008 16:12:41 -0600

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

> Sent: Monday, 18 February 2008 3:29 AM
> To: 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]

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 17 Feb 2008 19:14:32 -0600

Who or what the location is related to is an application dependency.

That is, I have a session with an application and want to provide it location as part of the context of that application. We both know, in that context, what the significance of the location information is.

The location can be provided as a literal (e.g. PIDF-LO) value or it can be provided as a location reference - in which case the application goes and looks up the literal value.

In neither case is it necessary for the location value or reference to contain specific target identification information. That identity is understood in the context of the application.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter J. Cranstone
Sent: Monday, 18 February 2008 9:02 AM
To: [email-masked]; 'GEOPRIV'
Subject: Re: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

Question... regarding 

Peter

-----Original Message-----

Hi James,

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Feb 2008 19:26:48 -0600

Peter

I think there are two definitions you are confusing here:

         "user identity" and "an identifier"

"user identity" is a name of a user  -- and that should not be in the URI

"an identifier" is how the LIS knows which device 
the URI is for -- and this needs to remain 
consistent in order for the LIS to always 
download the same Location URI to the same 
requester (with a valid-for timer).

A simple identifier is an IP address, another is a MAC address.

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Feb 2008 20:02:50 -0600

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

---

From: Richard Barnes <[email-masked]>
Date: Sun, 17 Feb 2008 21:24:10 -0500

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:
> 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)
> 
>> 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 
>> To that end, I think that the need for randomness in the URI is really 
>> restricted to applications where the target device is:
>>
>> 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
>>
>>
> ------------------------------------------------------------------------
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 17 Feb 2008 20:26:18 -0600

I think that that hits the nail on the head.

Thanks Richard

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Monday, 18 February 2008 1:24 PM
> To: James M. Polk
> Cc: Winterbottom, James; [email-masked]; GEOPRIV

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 17 Feb 2008 20:59:03 -0600

Is an anonymous location URI the requirement, or is the requirement that the URI not be guessable?  These are two properties that I consider valuable, but properties that are orthogonal.  I'd suggest three requirements, which don't pre-suppose solutions.

1: Anonymous
 - Requirement: The location URI MUST not reveal any information about the Target. 
   Note that, in effect, the information revealed includes the information retrieved by a dereference, so this could instead say "The location URI does not reveal any more information about the Target than its location."
 - Motivation: A user should have the option to control how much information is revealed about them.  This provides that control by not forcing the inclusion of other information with location.
 - Solution: Don't include any identification information in the URI.

2: Not guessable
 - Requirement: Location URIs that do not require (authentication and) authorization MUST not be guessable.
 - Motivation: Location URIs without access control reveal private information, and a guessable location URI could be easily exploited to obtain private information.
 - Solution: Add a cryptographically random sequence to the URI somewhere.  Note that the number of bits depends to some extent on the number of active location URIs that might exist at the one time; 128-bit is most likely enough for the short term.

3: Optional
 - Requirement:  Users may opt not to seek these properties.  Protocols may opt to not give users the chance.  If the protocol does, it MUST allow for user-provided authorization policies.  (This covers R**).
 - Motivation: Users don't always have such strict privacy requirements.
 - Solution: Give a user the option to specify their own location URI, or components thereof.

It isn't clear from R* below whether this completely covers both cases.  The first sentence isn't clear enough about anonymity.

The problem with using your employee number is that it doesn't meet either requirement.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Winterbottom, James	
> Sent: Monday, 18 February 2008 1:26 PM
> To: Richard Barnes; James M. Polk
> Cc: GEOPRIV
> > >> > From: [email-masked] [mailto:[email-masked]]
> On
> > >> Behalf
> > >> > Of Hannes Tschofenig
> > >> >  > Betreff: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-
> requirements-
> > 01
> > >> >  >
> > >> >  > C4. Random Generated:  The location URI MUST be hard to
> guess,
> > i.e.,
> > >> >  > Motivation: There is some benefit to the client if the
> location
> > URI
> > >> > or that one searches through the space easily in order to
> retrieve
> > the
> > >> > 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.
> > >> >
> > >> >  >
> > >> >  > The domain part is already revealed in the URI, and who know
> who
> > is
> > >> >  > assigned to cisco3199?
> > >> >
> > >> > I doubt that a network operator wants to let other people know
> where
> > >> end
> > >> > hosts are.
> > >> >
> > >> >  >
> > >> >  > Further, what constitues a "sequence" -- which is referred to
> in
> > the
> > >> >  > alpha too? Is it UTF-8 only, or can it be UTF-16?  Does it
> have
> > >> to be
> > >> >  > SIP needs to be?  Where's the guidance in this hint (that
> acts
> > >> like a
> > >> >  > requirement itself)?
> > >> >
> > >> ------------------------------------------------------------------
> -----
> > -------------------------
> > >>
> > >> ------------------------------------------------------------------
> -----
> > -------------------------
> > >>
> > >> [mf2]
> > >>

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Feb 2008 21:19:06 -0600

At 08:59 PM 2/17/2008, Thomson, Martin wrote:
>Is an anonymous location URI the requirement, or 
>is the requirement that the URI not be 
>guessable?  These are two properties that I 
>consider valuable, but properties that are orthogonal.

bingo! (from my perspective)

>  I'd suggest three requirements, which don't pre-suppose solutions.
>
>1: Anonymous
>    Note that, in effect, the information 
> revealed includes the information retrieved by 
> a dereference, so this could instead say "The 
> location URI does not reveal any more 
> information about the Target than its location."
>  - Motivation: A user

I would s/user/rulemaker to be consistent with RFC3693

>should have the option to control how much 
>information is revealed about them.  This 
>provides that control by not forcing the 
>inclusion of other information with location.

I otherwise agree with Req#1 here

>2: Not guessable
>  - Requirement: Location URIs that do not 
> require (authentication and) authorization MUST not be guessable.

I'm not sure I understand this yet. Is it that 
the URI string isn't guessable, or a Target's URI isn't guessable?

I think everything here is about relating a 
Target to its URI only, therefore only the latter 
of the two applies, so I'd modify the Req#2 to this

- Requirement: a Location URI for any specific 
Target that does not require (authentication and) 
authorization MUST not be guessable.

>  - Motivation: Location URIs without access 
> control reveal private information, and a 
> guessable location URI could be easily exploited to obtain private information.
>  - Solution: Add a cryptographically random sequence to the URI somewhere.

eeks! there goes that "cryptographically random 
sequence" again. I just think this string needs 
to be unique and not revealing any identity information.

>Note that the number of bits depends to some 
>extent on the number of active location URIs 
>that might exist at the one time; 128-bit is 
>most likely enough for the short term.
>
>3: Optional
>  - Requirement:  Users

again, I'd like to have s/users/rulemaker(s)

here's why

#1 RFC 3693 says this - and gives a good 
explanation of it (this is a user, a provider or 
both) ,, it gives motivation for it being this 
way, so we should follow that Requirements RFC

#2 a user might want to do something a network 
operator (SP or enterprise) doesn't want to 
allow. If the user doesn't like it, they can go shop for another provider.

>may opt not to seek these properties.  Protocols

err, Policies... (see just above)

>may opt to not give users the chance.  If the 
>protocol does, it MUST allow for user-provided 
>authorization policies.  (This covers R**).
>  - Solution: Give a user the option to specify 
> their own location URI, or components thereof.
>
>It isn't clear from R* below whether this 
>completely covers both cases.  The first 
>sentence isn't clear enough about anonymity.
>

I agree, and I *never* suggested using one's 
badge number... I think that would be stupid.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 17 Feb 2008 22:00:22 -0600

If these are good in principle, then I can clean up the wording.  Obviously, the third is a little flippant.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Monday, 18 February 2008 2:19 PM
> To: Thomson, Martin; Winterbottom, James; Richard Barnes
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01
> 

Done!

> the URI string isn't guessable, or a Target's URI isn't guessable?

The location URI is not (easily) guessable.  To take a bad example, if my LIS generated a location URI for me that contained my workstation number:

	held://lis.andrew.com/ws-209

I could "guess" that James W had a location URI of:

	held://lis.andrew.com/ws-210

Without authorization control on these URIs, I've just gained access to his private data.  In this case it's not so bad, because I know where he sits, but the same principle extends to any "guessable" sequence.  A unique number is insufficient requirement, because I could just pick sequential numbers to satisfy that, and those are very guessable.

> to be unique and not revealing any identity information.

Strike "cryptographically" and substitute random sequence of characters of sufficient entropy.  

> err, Policies... (see just above)

Err, no, protocol.  This requirement was squashed when the WG decided not to accept HELD while it contained a means to move authorization policies.  I'd be most happy to add it back, but as it stands, a protocol cannot be required to meet this requirement...unless the WG doesn't mind performing a back-flip.

(Aside: Back-flips are allowed, but that doesn't mean that they don't annoy people.  In this case, they mean missed deadlines and much more work; I'd prefer to defer this work.)

> badge number... I think that would be stupid.
 
Sorry to pick on your (rather useful) anti-example.

> > > > Subject: Re: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-
> requirements-
> > > 01
> > > >
> > > >   One part of a deref document will be specifying a URI format
> for
> > > the
> > > > identifier, such as an IP address).  Any URI whose dereference
> will
> > > not
> > > > > With that said, I'll suggest there be a forth communication
> path in
> > > the
> > > > > 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
> > > > > I attached a 2k new Figure 1. offering, with associated text
> (in
> > > case it
> > > > > Here is the offered Figure 1., that could show this
> communications
> > > > > exchange:
> > > > >
> > > > >
> > > > >    Figure 1: Shows the assumed communication model for both a
> layer
> > > 7
> > > > >   (the following paragraph should be #2 below this Figure in
> the
> > > doc)
> > > > >
> > > > >> server, the LIS. In this model the LIS doesn't generally know
> who
> > > some
> > > > >> work out where they are. I don't believe that when we
> originally
> > > did
> > > > >> To that end, I think that the need for randomness in the URI
> is
> > > really
> > > > >> 1) Unable or unwilling to provide identity information to the
> LIS
> > > > >> and/or the Location recipient.
> > > > >>
> > > > >> location information, and the LIS promises to abide by what
> James
> > > has
> > > > >> if it can't authenticate an LR, since without authentication,
> it
> > > can't
> > > > >> >  > [mailto:[email-masked]] Im Auftrag von ext
> James M.
> > > Polk
> > > > >> >  > is generated in an obscured manner so that its sequence,
> for
> > > > example
> > > > >> > Second, one should make sure that the reference cannot
> easily be
> > > > >> guessed
> > > > >> > the fact that possession of the reference is essentially
> equal
> > > to
> > > > >> >  > 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.
> > > > >> >
> > > > >> >  >
> > > > >> >  > without an assignment, I go back to being unassigned, and
> get
> > > the
> > > > >> >  > Also, if it has to be cryptographically random, where's
> the
> > > > guidance
> > > > >> >  > requirement?  This at least is a glaring hole in the ID,
> and
> > > > >> likely a
> > > > >> > Providing random numbers is not a huge problem. This is a
> common
> > > > aspect
> > > > >> >  > Motivation for the requirement? Is that numeric only, or
> can
> > > it be
> > > > >> >  > as random as "unique through space and time" as the Call-
> ID
> > > > >> header in
> > > > >> > 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,
> > > > >> > are likely to get wrong and it will subsequently lead to a
> lower
> > > > level
> > > > > ---------------------------------------------------------------
> ----
> > > -----
> > > > >
> > > -------------------------------------------------------------------
> ----
> > > -------------------------------------------------------------------
> ----

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Feb 2008 23:06:48 -0600

At 10:00 PM 2/17/2008, Thomson, Martin wrote:
>If these are good in principle, then I can clean up the wording.

I think we are working on that together -- which 
is good -- to get a better version of this ID

>Obviously, the third is a little flippant.

ya think?

;-)

more below

> > I would s/user/rulemaker to be consistent with RFC3693

cool

>The location URI is not (easily) guessable.  To 
>take a bad example, if my LIS generated a 
>location URI for me that contained my workstation number:
>

in this instance, I would agree that this is a 
problem, but in the my bad example of

         sips:cisco3199.cisco.com

One couldn't necessarily make the same leap that Marc Lisner is

         sips:cisco3200.cisco.com

and hope to be right.  Cisco in this example, and 
in real life, much bigger than a 4 digit number could cover.

This number would be even bigger at Barbara's AT&T (with what, 200k employees?)

the point is that if folks in the same department 
aren't consecutively asking for a URI, they 
shouldn't be consecutive numbers of 
identifiers.  This makes guessing much less probable

>Without authorization control on these URIs, 
>I've just gained access to his private data.

I think you gained nothing other than the place 
to go ask (i.e., the LIS), and if the LIS has a 
good architecture, you're challenge should be 
hard to penetrate.  Without penetrating the LIS, 
all you can hope to do is (D)DOS  the server... 
not gain any information from it.

The ability to penetrate a LIS and gain 
information of the user of a Target at a Location 
URI is the ultimate vulnerability or not of 
having possession of the URI, in my mind -- and 
that's where requirements ought to be focused (which they currently are not).

>  In this case it's not so bad, because I know 
> where he sits, but the same principle extends 
> to any "guessable" sequence.  A unique number 
> is insufficient requirement, because I could 
> just pick sequential numbers to satisfy that, and those are very guessable.
>
> >
>Strike "cryptographically" and substitute random 
>sequence of characters of sufficient entropy.

better, the next question is how random does this 
need to be (i.e., how likely is there to be a collision anytime soon)?

>Err, no, protocol.  This requirement was 
>squashed when the WG decided not to accept HELD 
>while it contained a means to move authorization policies.

well, that's an indictment on HELD attempting to 
do this function more than doing the function somewhere, isn't it?

We've never dealt how a rulemaker(s) organize 
policies into a single form that's used by a LIS. 
We've also not dealt with the external 
communications of how those policies, if entered 
(set) by a user, get to the LIS.

>I'd be most happy to add it back, but as it 
>stands, a protocol cannot be required to meet 
>this requirement...unless the WG doesn't mind performing a back-flip.
>
>(Aside: Back-flips are allowed, but that doesn't 
>mean that they don't annoy people.  In this 
>case, they mean missed deadlines and much more 
>work; I'd prefer to defer this work.)
>

no problem, doing so hopefully gets everyone 
thinking how this needs to cover a long of types of identity information.

> > requirements-01

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 17 Feb 2008 23:36:32 -0600

Hi James,

I'll cut out some of the noise...

> identifiers.  This makes guessing much less probable

I can't agree that relying on sequence numbers is sensible, but it might
just work if your enterprise is large enough and if you could make a few
other assurances about security assurances (like the fact that packets
between two hosts can't be captured in any way, see below).  Better, in
my mind, to get that probability down using all sensible means.

E.g. If I knew that the numbers were sequential (and I could find out by
making two requests in quick succession), then I could make some fairly
simple inferences based on traffic patterns.  I don't have to see the
contents of packets now to be able to guess what's in them.  All you
need to do is count all the small packets (assuming the big ones have
location-by-value).  The attack wouldn't be that hard to mount.

> that's where requirements ought to be focused (which they currently
are
> not).

Since the LIS keeps all of these, it can fix collisions, so randomness
isn't necessary paramount.  The randomness is most useful to prevent
guessing only, so its entropy needs to be large enough to deter guessing
attacks.  This is a function of the number of guesses that would have to
be allowed before you lock down and the probability of one of those
guesses working and how much you really care about the problem.  We can
recommend 128-bit, as Richard did, which is reasonable, but someone
might decide that 16-bit is enough (I'd advise against that though,
since you'd exhaust the space rather quickly).

> do this function more than doing the function somewhere, isn't it?

Maybe, but it reflects poorly on the usability of the authorization
policy format as well.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 10:50:38 +0200

Hi James,

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.
depending on the type of network access authentication procedure the 
access network (and consequently the LIS) may have more information 
about the user available.

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

OK. With this additional requirement I am fine with providing a 
non-random URI. However, please note that someone would have to write a 
document on how to upload authorization policies from the Target to the 
LIS.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 12:15:54 +0200

This is a good picture. It reflects the "Authorization Model" pretty well.

Still, are you going to also provide support for the other model?

James M. Polk wrote:
> 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)
>
>> 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:
>>
>> 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
>>
>>
>> where end

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 12:16:02 +0200

Hi Peter,

> who or what it came from? I mean it's got to be tied to something to provide
The reference still contains the domain name of the access network. 
Hence, the reference can be resolved but identifying the user is not 
possible.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 19 Feb 2008 15:15:06 -0600

>Still, are you going to also provide support for the other model?

remind me what the "other model" is?

Are you referring to the original Figure 1?

If so, I think the old one was always a 
non-starter since it didn't have the rulemaker 
interaction that we know must be there.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Feb 2008 17:12:35 -0500

James,

The "other model" is the model where there is no access control policy 
applied on the dereference step (to avoid having to authenticated the 
requestor, etc), with the trade-off that the security of the value is 
now determined by the security with which the reference is handled. 
These are the URIs that require randomization, so that constraining 
their distribution is a meaningful security measure.

That said, I think that case is covered by the existing picture -- it's 
just the special case when the Rule Maker doesn't supply rules (or, 
equivalently, there is no Rule Maker interaction).

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Feb 2008 17:13:17 -0500

... and of course, by "existing picture" in the below, I meant to 
indicate James's picture (which includes the optional rule maker 
interaction).
--RB

Richard Barnes wrote:
>> If so, I think the old one was always a non-starter since it didn't 
>> have the rulemaker interaction that we know must be there.
>>
>>> James M. Polk wrote:
>>>> [put your seatbelts on!]
>>>>
>>>>>> who is

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Feb 2008 16:16:09 -0600

Hi Richard,

The statement below about access control policy isn't quite correct.
Any policy invoked is directly attributed to the URI itself, perhaps this is better referred to as a constraint, and is what the current context draft describes.

Cheers
James

> Of Richard Barnes
> Sent: Wednesday, 20 February 2008 9:13 AM
> To: James M. Polk
> Cc: GEOPRIV
> Subject: Re: [Geopriv] James' Figure: Q2 aboutdraft-ietf-geopriv-lbyr-
> requirements-01
> 
> James,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Feb 2008 09:10:01 +0200

You are both right.

I mentioned two extreme models. There is a gray zone in between where 
the Target provides additional information to constraint the 
dereferencing step (without using policies but by restricting the 
information that is returned to any Location Recipient).

Winterbottom, James wrote:
>>>> This is a good picture. It reflects the "Authorization Model" pretty
>>>>         
>> well.
>>     
>>>>>>>  > [mailto:[email-masked]] Im Auftrag von ext James M.
>>>>>>>               
>> Polk
>>     
>>>>>>>  > Betreff: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-
>>>>>>>               
>> 01
>>     
>>>>>>>  >
>>>>>>>  > C4. Random Generated:  The location URI MUST be hard to guess,
>>>>>>>               
>>>>>> i.e.,
>>>>>>             
>>>>>>>  > Motivation: There is some benefit to the client if the location
>>>>>>>               
>> URI
>>     
>>>>>>>  > is generated in an obscured manner so that its sequence, for
>>>>>>>               
>>>>>> example
>>>>>>             
>>>>>>> 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
>>     
>>>>>>> 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.
>>>>>>>
>>>>>>>  >
>>>>>>> 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?
>>>>>>>
>>>>>>>  > Also, if it has to be cryptographically random, where's the
>>>>>>>               
>>>>>> guidance
>>>>>>             
>>>>>>>  > requirement?  This at least is a glaring hole in the ID, and
>>>>>>>               
>>>>>> likely a
>>>>>>             
>>>>>>> Providing random numbers is not a huge problem. This is a common
>>>>>>>               
>>>>>> aspect
>>>>>>             
>>>>>>>  > 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)?
>>>>>>>
>>>>>>> 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,
>>     
>>>>>>> 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
>>     
>>>> -----------------------------------------------------------------------
>>>>         
>>>> -----------------------------------------------------------------------
>>>>

---

From: "Roger Marshall" <[email-masked]>
Date: Sun, 24 Feb 2008 22:27:22 -0800

Richard:
I've included these two new requirements, somewhat rewritten in the -02.  I've also included James' diagram, since it seems to be popular thing to show the Rulemaker.

thanks.

-roger marshall. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Barnes
> Sent: Sunday, February 17, 2008 6:24 PM
> To: James M. Polk
> Cc: GEOPRIV
> First, I like James P's diagram!  It concisely shows how all 
> the pieces interrelate.
> 
> 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!]
> > 
> >> >  > -----Ursprüngliche Nachricht-----  > Von: 
> >> > [email-masked]  > [mailto:[email-masked]] Im 
> >> > Auftrag von ext James M. Polk  > Gesendet: Samstag, 16. Februar 
> >> > 2008 02:24  > An: [email-masked]  > Betreff: [Geopriv] 
> Q2 about 
> >> > draft-ietf-geopriv-lbyr-requirements-01
> >> >  >
> >> >  > Section 5.1 has this requirement  >  > "
> >> > i.e.,  > it MUST contain a cryptographically random component.
> >> >  >
> >> > 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.
> >> >  > "
> >> >  >
> >> > 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.
> >> >
> >> > that part of the URI is randomly created. I would say 
> with at least 
> >> > 128 bit of randomness.
> >> >
> >> >  >
> >> > is  > assigned to cisco3199?
> >> >
> >> >  >  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.
> >> >
> >> > 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
> >> > aspect in all security protocols. I would follow the 
> guidelines 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
> >> > would be fine for me.
> >> > MUST,  > "...hard to guess..." requirement.
> >> > 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
> >> >  >
> >> This message is for the designated recipient only and may contain 
> >> privileged, proprietary, or otherwise private information.
> >> immediately and delete the original.  Any unauthorized use of this 
> >> email is prohibited.
> >> 

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.

---

From: "Roger Marshall" <[email-masked]>
Date: Sun, 24 Feb 2008 22:35:25 -0800

Martin:
Flippant or no, I've tried to include this, and the others into the next iteration of the lbyr requirements (-02).

Wasn't sure if I misunderstood your intent (or missed the email) to "clean up the wording", etc.

This has been a long discussion on a variety of requirements, so there may need to be quite a bit of re-weeding.

thanks.

-roger marshall. 

> [mailto:[email-masked]] On Behalf Of Thomson, Martin
> Sent: Sunday, February 17, 2008 8:00 PM
> To: James M. Polk; Winterbottom, James; Richard Barnes
> Cc: GEOPRIV
> If these are good in principle, then I can clean up the 
> wording.  Obviously, the third is a little flippant.
> 
> > >Is an anonymous location URI the requirement, or is the 
> requirement 
> > >that the URI not be guessable?  These are two properties that I 
> > >    Note that, in effect, the information  revealed includes the 
> > >information retrieved by  a dereference, so this could instead say 
> > >"The  location URI does not reveal any more  information about the 
> > >Target than its location."
> > >  - Motivation: A user
> > 
> > >should have the option to control how much information is revealed 
> > >about them.  This provides that control by not forcing the 
> inclusion 
> > >  - Requirement: Location URIs that do not  require 
> (authentication 
> > >and) authorization MUST not be guessable.
> > 
> > I'm not sure I understand this yet. Is it that the URI string isn't 
> > guessable, or a Target's URI isn't guessable?
> 
> The location URI is not (easily) guessable.  To take a bad 
> example, if my LIS generated a location URI for me that 
> contained my workstation number:
> 
> Without authorization control on these URIs, I've just gained 
> access to his private data.  In this case it's not so bad, 
> because I know where he sits, but the same principle extends 
> to any "guessable" sequence.  A unique number is insufficient 
> requirement, because I could just pick sequential numbers to 
> satisfy that, and those are very guessable.
> 
> > 
> > I think everything here is about relating a Target to its URI only, 
> > therefore only the latter of the two applies, so I'd modify 
> the Req#2 
> > to this
> > 
> > - Requirement: a Location URI for any specific Target that does not 
> > >  - Motivation: Location URIs without access control 
> reveal private 
> > > information, and a guessable location URI could be easily 
> exploited 
> > > to obtain private
> > information.
> > eeks! there goes that "cryptographically random sequence" again. I 
> > just think this string needs to be unique and not revealing any 
> > identity information.
> 
> > >Note that the number of bits depends to some extent on the 
> number of 
> > >active location URIs that might exist at the one time; 128-bit is 
> > #1 RFC 3693 says this - and gives a good explanation of it 
> (this is a 
> > user, a provider or
> > both) ,, it gives motivation for it being this way, so we should 
> > follow that Requirements RFC
> > 
> > #2 a user might want to do something a network operator (SP or 
> > enterprise) doesn't want to allow. If the user doesn't like 
> it, they 
> > can go shop for another provider.
> > 
> Err, no, protocol.  This requirement was squashed when the WG 
> decided not to accept HELD while it contained a means to move 
> authorization policies.  I'd be most happy to add it back, 
> but as it stands, a protocol cannot be required to meet this 
> requirement...unless the WG doesn't mind performing a back-flip.
> 
> (Aside: Back-flips are allowed, but that doesn't mean that 
> they don't annoy people.  In this case, they mean missed 
> deadlines and much more work; I'd prefer to defer this work.)
> 
> > >may opt to not give users the chance.  If the protocol 
> does, it MUST 
> > >allow for user-provided authorization policies.  (This covers R**).
> > >It isn't clear from R* below whether this completely covers both 
> > >cases.  The first sentence isn't clear enough about anonymity.
> > >
> > >The problem with using your employee number is that it 
> doesn't meet 
> > >either requirement.
> > 
> > I agree, and I *never* suggested using one's badge 
> number... I think 
> > that would be stupid.
>  
> [mailto:[email-masked]] 
> > > > On Behalf Of Winterbottom, James
> > > > > First, I like James P's diagram!  It concisely shows 
> how all the
> > > > pieces
> > > > > interrelate.
> > > > >
> > > > > policies will be applied to each one.  Some will be 
> > > > > authenticated
> > /
> > > > > for location URIs.  This format MUST identify the 
> desired LO  by 
> > > > > a
> > random
> > > > > > defaults up to a certain degree (like who (which 
> requesters) 
> > > > > > go
> > > > into
> > > > > >   For completeness, Figure 1, includes the 
> interaction between
> > the
> > > > > >   This is communications path (1b). This 
> interaction needs to
> > be
> > > > > >   done before the LIS will authorize anything of 
> than default
> > > > policies
> generally know
> > > > > >> this work we factored in, or really considered, 
> the inclusion
> > of a
> information to the
> James suggests, 
> > > > > >> providing that James can tell the LIS who is allowed to 
> > > > > >> access
> > his
> > > > request
> > > > > >> > [email-masked]  > 
> > > > > >> >  > Gesendet: Samstag, 16. Februar 2008 02:24  > An: 
> > > > > >> > [email-masked]  > Betreff: [Geopriv] Q2 about 
> > > > > >> > draft-ietf-geopriv-lbyr-
> > > > requirements-
> > > > > 01
> > > > > >> >  >
> > > > > >> >  > in the case of a client's location update, 
> can't be easy
> > > > guessed.
> > > > > >> >  > "
> > > > > >> >  >
> > > > > >> > As such, it is important from a security and 
> privacy point
> > of
> > > > view
> > > > > that
> > > > > >> >  > 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
> > > > > >> >  >  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
> > > > > >> >  > on what that means, what that is, and how I know I've 
> > > > > >> > met
> > the
> > > > > >> >  > alpha too? Is it UTF-8 only, or can it be 
> UTF-16?  Does
> > it
> > > > have
> > > > > >> to be
> > > > > >> > I wouldn't use the term sequence in the 
> description. It is
> > > > indeed
> > > > > >> > misleading.
> -------------------------------------------------------------
> > > > > >> -
> > ----
> > > > -----
> -------------------------------------------------------------
> > > > > >> -
> > ----
> > > > -----
> > > > -
> > > > -
> >---------------------------------------------------------------------
> > >-
> > --------------------------
> >---------------------------------------------------------------------
> > >-
> > --------------------------
> > >[mf2]
> > 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 25 Feb 2008 15:27:51 -0600

Thanks Roger, I've been too busy to give this enough attention.  I'll have a read and let you know what I think.

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Monday, 25 February 2008 5:35 PM
> To: Thomson, Martin; James M. Polk; Winterbottom, James; Richard Barnes
> Cc: GEOPRIV
> Flippant or no, I've tried to include this, and the others into the
> next iteration of the lbyr requirements (-02).
> 
> This has been a long discussion on a variety of requirements, so there
> may need to be quite a bit of re-weeding.
> 
> thanks.
> 
> -roger marshall.
> 
> format
> > > > > > > any SP (including enterprises), and the user can modify
> from
> > > those
> > > > > > >> 2) Unable or unwilling to provide rules and policies to
> the
> > > LIS
> > > > > > >> > I doubt that a network operator wants to let other
> people
> > > know
> > > > > where
> > > > > > >> end
> > > > > > >> > hosts are.
> > > > > > >> >
> > > > > > >> >  >
> 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.
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 25 Feb 2008 17:03:14 -0600

At 12:27 AM 2/25/2008, Roger Marshall wrote:
>Richard:
>I've included these two new requirements, somewhat rewritten in the -02.

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

> > [mailto:[email-masked]] On
> > >> Behalf
> > >> > Of Hannes Tschofenig
> > >> ---------------------------
> > >>
> > >> ---------------------------
> > >>
> > >> [mf2]
> > >>
>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.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Feb 2008 20:47:51 -0500

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:[email-masked]> 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:[email-masked]>.  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 
>>   I've also included James' diagram, since it seems to be popular 
>> thing to show the Rulemaker.
> 
> cool
> 
> 
>> thanks.
>>
>> -roger marshall.
>>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 14:28:57 -0600

At 07:47 PM 2/25/2008, Richard Barnes wrote:
>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:
>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.

ok, but if there's no identity associated with 
the URI, how does an attacker know if they have 
one, or if they have a valid one (for anyone), or for someone in particular?

If the attacker wants my location, they have to 
penetrate the LIS, which shouldn't happen, and 
that's not a URI length issue is it? That's a 
weak LIS challenge capability, which requires a 
different solution in a different area altogether.

IF an attacker wants anyone's location, then what 
do they really have? A location doesn't get them 
anything other than the location, which can be a 
street address (but they don't know who is at 
that address/location) So I don't know what this means to want to prevent.

In other words, I don't want to assume there is a 
problem and come up with a solution until we 
agree on what the requirement is, and why we need 
to address the requirement (which we aren't doing yet.

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

but what would you get in those attempts? I don't 
understand what's achieved by have a 1-4 digit 
number that's associated with my location an 
attacker couldn't know unless they penetrated my LIS.

>Example 2: Using a 32-byte number

you suggested a 16 byte number, btw, not 32 bytes

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

Time Warner Cable has 20 Million customers, it 
shouldn't take a similar script to what you have 
stated above is the flaw in a 4 digit number to 
get "someone's" URI sequence, but an attacker 
doesn't know which user it is unless they 
penetrate TW's LIS.  again, this is a LIS security problem, not a URI problem.

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

see, I don't believe merely having the URI means 
the LIS will answer a query for the 
location.  This means there is no purpose in the 
rulemaker in setting up role based rules and black lists.

>So the problem is to prevent people without 
>The question is then how much information we assume the attacker starts with.

I think we have to assume the rulemaker made 
good, non-open rules about who can access your 
location if they included your URI in a SUBSCRIBE 
to the URI to the proper LIS. This needs to be the first assumption.

To give an extreme example, if I don't want my 
wife to know where I am, even if she has my URI, 
the LIS should deny her dereference.  Therefore 
possession of the URI doesn't mean the possessor will get my location, period.

IMO, everything below needs to be adjusted based 
on this aspect/fact (core fundamental of location work here)

>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
>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:[email-masked]>. 
>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>

well, I think this doc also has to change based 
on the assumptions you make in it that you've 
been articulating to me over the past 10 days.

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Feb 2008 15:43:09 -0500

James,

> see, I don't believe merely having the URI means the LIS will answer a 
> query for the location.  This means there is no purpose in the rulemaker 
> in setting up role based rules and black lists.

This is the crux of the disagreement: Others in the group do believe 
that such URIs without Rule Makers or any access controls are useful. 
If you have a HELD LIS that will give a URI to any host on its network, 
that LIS may or may not have any way to authenticated dereferences to 
the URIs it issues.

My previous emails have been addressing this use case, and only this use 
case.  If access controls are being applied, then there is no 
requirement for randomization or anonymity.  If you have a close enough 
relationship with your LIS that you can tell it what policy to apply, 
then you don't need a randomized URI.

Look again at R*:

First, it says that there MUST be a format that includes sufficient 
entropy -- not that anyone has to use it.  The only cases where it does 
mandate usage is when the LS isn't applying policy to the dereference.

There are two separate use cases here, access-controlled (with RM) and 
non-access-controlled (without RM).  The requirements for randomization 
and anonymization apply *only* to the latter.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Feb 2008 22:59:45 +0200

> that such URIs without Rule Makers or any access controls are useful. 

Yep. In short, I am one of these guys.

My main reason for being a fan of this approach: The other stuff is just 
undeployable in the generic case.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Feb 2008 15:02:29 -0600

I support this position too.
And you can put some controls about what the reference actually points
to, without requiring complex authentication architectures and
machinery.

Cheers
James

Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, 27 February 2008 8:00 AM
> To: Richard Barnes
> Cc: GEOPRIV; James M. Polk

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 15:22:37 -0600

At 02:43 PM 2/26/2008, Richard Barnes wrote:
>James,
>
>>see, I don't believe merely having the URI means the LIS will 
>>answer a query for the location.  This means there is no purpose in 
>>the rulemaker in setting up role based rules and black lists.
>
>that such URIs without Rule Makers or any access controls are 
>useful. If you have

>a HELD LIS

A "LIS" is part of an architecture, it isn't part of a protocol, so 
what you are talking about is how HELD implements its LIS, which is 
different from how a LIS works under any conditions or protocols. I 
have an example below

>that will give a URI to any host on its network, that LIS may or may 
>not have any way to authenticated dereferences to the URIs it issues.

This is a rulemaker decision, but not every rulemaker will make this 
configuration decision, since a Geopriv rulemaker is partly a user, 
which means I am a rulemaker. And I won't have a policy like 
this.  The protocol MUST NOT make that choice for me, because it will 
conflict with RFC3693 if it tries.

>My previous emails have been addressing this use case, and only this 
>use case.

then you need to change the 1st sentence of R*

         "The dereference protocol MUST define an anonymized format 
for location URIs. "

in this way

s/dereference protocol/HELD

to maintain consistency with what you say above with what you say below

>  If access controls are being applied, then there is no requirement 
> for randomization or anonymity.  If you have a close enough 
> relationship with your LIS that you can tell it what policy to 
> apply, then you don't need a randomized URI.
>
>Look again at R*:
>
>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.

Is SIP an LCP? (no, SIP will have zero control over the length of the 
URI or the randomness of the URI)

Is SIP a dereference protocol? (yes, see Location Conveyance -10)

Will SIP have any control over the length or randomness of the URI? (no)

Therefore, your R* is stating, with MUST strength, that it MUST NOT 
be a dereference protocol.

needless to say, I have a problem with this requirement

>entropy -- not that anyone has to use it.  The only cases where it 
>does mandate usage is when the LS isn't applying policy to the dereference.
>
>There are two separate use cases here, access-controlled (with RM) 
>and non-access-controlled (without RM).  The requirements for 
>randomization and anonymization apply *only* to the latter.
>
>--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 15:26:07 -0600

At 02:59 PM 2/26/2008, Hannes Tschofenig wrote:
>>>answer a query for the location.  This means there is no purpose 
>>>in the rulemaker in setting up role based rules and black lists.
>>>
>>
>>This is the crux of the disagreement: Others in the group do 
>>believe that such URIs without Rule Makers or any access controls 
>>are useful.
>
>My main reason for being a fan of this approach: The other stuff is 
>just undeployable in the generic case.

rulemaking is undeployable? I don't understand this belief (if I have it right)

this is a configuration decision and Geopriv-Policy is pointless 
without the ability to have a rulemaker.  The IETF can only recommend 
certain policies and give guidance on security risks in this regard, 
but this is still merely a policy decision (that a LIS will blindly 
give a PIDF-LO to any dereference request).

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 15:28:29 -0600

>to, without requiring complex authentication architectures and

you're saying you don't want (the protocol ability to have) any rulemakers...?

do I have this right?

If so, how can you expect this WG to take this position seriously, 
given how fundamental this is the our Geopriv Requirements in RFC 3693?

>answer a
>useful.

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 26 Feb 2008 17:09:23 -0500

I think I'm agreeing with James P. on this.

Here's a scenario that I think should be valid:

A hospital has an internal IP network. In that network is a LIS (not
accessible from the Internet) that is able to track the whereabouts of
the 600 wheelchairs that the hospital owns. Each wheelchair is assigned
a number (001 - 600), which the LIS uses directly to create a unique
LbyR URI. Anyone with access to the hospital intranet can send a message
to a wheelchair and ask it to provide its location URI. Since these are
just wheelchairs, and it's all inside an intranet, the wheelchair always
complies with such requests, and the LIS doesn't have rules or require
authentication to dereference. 

Why should the hospital need to implement random generation of URIs in
its LIS? That makes no sense to me whatsoever. As in the past, I think
it's wonderful when the IETF provides guidance. But this sort of
heavy-handed approach of "it is our duty to make sure that the protocols
we create cannot be used by evil LIS operators to deny a person's
God-given rights to privacy" seems unnecessary to me.

The LIS operator will know what the parameters are under which the LIS
is operating. The LIS operator is always responsible for ensuring that
appropriate privacy rules and regulations are followed. If a government
says that a LIS in a public network must use however many bits of
randomness, then that's what the LIS will do. If a hospital is
implementing an internal LIS for internal purposes, and there are no
laws guaranteeing rights of privacy to wheelchairs, then the LIS
operator is free to use whatever algorithm they wish, to create URIs.
It's not for the IETF to dictate what LIS operators must and must not
do. Guidance is good. Limiting the usefulness and applicability of
protocols to only the narrow set of uses that the creators initially
envisioned is bad.

Making sure that the protocol and URI format allow long and random
strings is good. Requiring their use is bad.
Barbara
_______________________________________________
Geopriv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Feb 2008 16:20:10 -0600

Hi Barbara,

To some extent I thing your example hits the nail on the head.
In your example, the thing wanting the wheelchairs location must first
talk to the wheelchair to gets it location. The issue that I think is
being debated is that it should not be easy for the thing wanting to
location to go straight the LIS, without first going to the wheelchair
to get the location URI. In a completely closed system is this
important, I don't think so, but some might. In an open system is this
important, yes I think it is.

Cheers
James

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Wednesday, 27 February 2008 9:09 AM
> To: James M. Polk; Winterbottom, James; [email-masked];
Richard
> Barnes

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 16:44:41 -0600

At 04:20 PM 2/26/2008, Winterbottom, James wrote:
>to get the location URI.

I think thinking the LIS will be somehow hidden from discovery 
therefore let's not have it be secure is like an ostrich putting it's 
head in the sand and preying...

(an attacker is going to find the LIS. Now what...)

>In a completely closed system is this

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Feb 2008 16:58:33 -0600

I am not sure that I understand your argument. Is it that you think we
are trying to hide the LIS in some way to stop people trying to access
it?
If it is, then I think we are not talking about the problem in the same
way.

I think in order for location to be of use you require one of two things
(apart from the location).

1) You need to have context for the location (who or what is there)
2) You need to have knowledge of when something was at the location.

Simply knowing the address of the LIS doesn't help with either of these.
It is analogous to knowing the address of a web server and hitting it
with random URIs until something is returned that looks interesting. In
exactly the same light I can try and guess the root password on a unix
box.

If the URI that the LIS creates doesn't include information about how I
am seen in a network, then the URI doesn't really give away anything
more than the fact I am in a given network. I would argue that this
latter piece of information can be worked out by other means anyway.

Let me know if this helps.

Cheers
James

> Sent: Wednesday, 27 February 2008 9:45 AM
> To: Winterbottom, James; Stark, Barbara; [email-masked];
> Richard Barnes
> Cc: GEOPRIV

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 17:24:09 -0600

well.... my Presence can allow my buddies (from my buddy list) to 
look at where I am at any given moment.  I don't send my buddies the 
LbyR each time, and they don't get the LbyR each time they want to 
see where I am -- they learn it once and store it, to look at it 
later.  The rulemaker establishes the local policy for how precise 
the location is in the PIDF-LO it sends each buddy that wants to know 
where I am at any given moment in time.  If I don't want Bob to know 
where I am from 5pm to 8am (i.e., whenever I'm not at work), then the 
dereference from Bob is denied, or returns a very imprecise location 
during those hours.  Bob didn't forget my LbyR, he just doesn't get 
an (good) answer.

Thinking no one is going to run a LIS this way is just plain wrong. 
This is exactly how (at least) all enterprises will run theirs. And 
I'll bet most SPs will run it this way too.

Possession of a URI does not mean a LIS will respond with a PIDF-LO 
of a Target!

Nothing here means there isn't a default configuration of dereference 
replies that some users won't configure off of.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 26 Feb 2008 17:28:56 -0600

Actually for the closed system you have OBO... which is not the same as
LbyR.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Winterbottom, James
Sent: Wednesday, 27 February 2008 9:20 AM
To: Stark, Barbara; James M. Polk; [email-masked]; Richard
Barnes
Cc: GEOPRIV
Subject: Re: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

Hi Barbara,

Cheers
James

Richard

------------------------
------------------------
[mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Feb 2008 17:40:13 -0600

Hi James,

What you have described is a classic presence service. I have absolutely
no argument with you, when you say it will work that way. It will!

There is also the case where I enter an arbitrary network (I do that
quite a lot), and one of the services that that network provides me may
be a LIS service. I don't want to give it my buddy list, and even if I
did, it may not be able to authenticate the person anyway. This
particular use case has been argued to death in geopriv over the last 3
years, and the "open URI" was what people general converged towards.

One use case that has also been described (a lot), is for the Target to
request a location or a location URI from the local LIS and to push this
to their SP-LIS (their presence provider's presence server). This would
allow my regular buddies to find me, without knowing the identity of the
LIS or access network I am in. This is a valid use case, and is the use
case that I think these requirements were written to address.

The presence server case is an example of the general case, where I can
give my URI to any application that I want to use, and it can get my
location. If I use the presence server approach, and things access my
location through it, then I get the rules that my presence server is
capable of applying, and these may be very rich. If I use a local LIS,
these rules may be more restrictive and as a Target, I should be aware
of that. I see the list of requirements in this document as addressing
the minimal set of functionality that this latter type of LIS
(non-SP-LIS) needs to provide.

I have said, and I will continue to say, that these requirements must
not preclude the use of existing presence systems where the URI of a
user is well known. I think what is probably in debate is how we make
sure that this document doesn't preclude presence.

Cheers
James

> Sent: Wednesday, 27 February 2008 10:24 AM
--
> -----------------------
--
> -----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 18:25:31 -0600

>Actually for the closed system you have OBO... which is not the same as

OBO is not and likely won't be standardized, so anyone wanting to 
follow standards, can't use it as a solution - now can they?

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 18:44:33 -0600

At 05:40 PM 2/26/2008, Winterbottom, James wrote:
>quite a lot)

ok, but requirement R* says "MUST", which means "all", and you admit 
my example is the model for presence, which will be a good portion of 
deployments, which means the requirement has to be rewritten.  This 
is what I'm going for.  I do not want to prevent possession from 
implicitly granting authorization to learn location of a target (I 
think that will be the case some of the time), I just don't want it 
to be the only way it is done (which is how Richard wrote the 
requirement, that you see).

(more below)

>, and one of the services that that network provides me may

But the LbyR requirements ID doesn't limit the scope to just this 
latter case, and the title doesn't help in that matter either.  If 
limited to just this latter case, then this set of requirements is a 
good start, but needs to be honed more, but it is in the right 
direction.  This requirements ID needs to go out of its way *not* to 
be misunderstood to cover all other cases (namely the presence 
example, which it doesn't do now).

>sure that this document doesn't preclude presence.

yeah, and this needs to be overly overt (including in the title of 
the doc), instead of buried in a middle paragraph of a section.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Feb 2008 19:00:00 -0600

Ummm.. I think we are going to have to disagree on this.
We have clear statements in requirements documents saying that this is
needed. How can you turn around and say that we won't be doing it?

Cheers
James

> Sent: Wednesday, 27 February 2008 11:26 AM
> To: Dawson, Martin; Winterbottom, James; Stark, Barbara;
> [email-masked]; Richard Barnes
> Cc: GEOPRIV
> > > to a wheelchair and ask it to provide its location URI. Since
these
-
-
--
--

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 26 Feb 2008 19:44:00 -0600

Anyhow - I was just making sure that people weren't confusing one use
case with another.

In terms of the question of "securing URIs", Richard correctly spotted
that the difference in opinion with James P appeared to stem from the
non-authenticated use case - which James didn't appear to consider in
scope. Richard pointed out that it was necessary to make systems
deployable and James P asked why that should be so.

The reason, as has been mentioned, is that presence clients will want to
publish the location URI - obtained from an arbitrary access network -
to their presence service. The presence service has no relationship with
the access network .The presence service does know its subscriber and
can apply all the privacy rules associated with that subscriber as each
watcher asks the service for location information for the presentity.
However, because the presence service has no relationship with the
access network it cannot offer any authentication tokens to that access
network.

Note - you can substitute IMS for "presence service" in that description
and it's consistent with the view of IMS that has been articulated in
this forum.

To deploy with this model, there have to be "possession model" URIs. To
securely deploy with this model, the URI has to be highly cryptic.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James 
Sent: Wednesday, 27 February 2008 12:00 PM
To: James M. Polk; Dawson, Martin; Stark, Barbara;

Cheers
James

these
-
-
--
--