Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol

From: Andrew Newton <[email-masked]>
Date: Thu, 27 Jul 2006 08:44:33 -0400

There have been a number of opinions regarding HTTP as a using protocol.

I'd like to know, how many people believe that HTTP requires no or  
very little specification to meet the requirements in RFC 3693 and  
RFC 3694.  If you believe this, what basis do you have for this  
conclusion?  Or do you believe more specification needs to be done,  
but it is possible for HTTP to be a GEOPRIV using protocol?

Finally, how many people believe that HTTP should not be a using  
protocol?

-andy

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 27 Jul 2006 09:27:35 -0400

I think HTTP requires some specification.  A raw GET based retrieval of a
PIDF would be a fairly short RFC, but I think we need that RFC.

While I don't think it's necessary (SIP SUBSCRIBE is sufficient), I don't
object to defining HTTP as a using protocol in a suitable RFC.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, July 27, 2006 8:45 AM
> To: IETF SIP List; GEOPRIV
> Subject: [Sip] teasing apart: http as a GEOPRIV using protocol
> 
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jul 2006 09:33:48 -0400

For all protocols, the hardest part is specifying how authentication  
works in conjunction with the privacy rules. This is far from obvious  
for HTTP, for example. (Is it the Digest user identifier? Can Basic  
over TLS be used instead? What about crypto-random request URIs? Is  
HTTP ok in that case or is HTTPS needed - the answer isn't obvious  
since an observer would only see a location, not a location-identity  
pair.)

For SIP, this is largely done, except for the crypto-random request  
URI case and variations, such as user + password.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 17:36:02 +0200

Hi Andy,

if we talk about location-by-reference then I think all solutions need 
more specification work.

If we talk about end host adding a reference then we need to have a 
story about the source of the reference. This is subject to the current 
Geopriv-L7 DT work that is not yet finished.

If we are talking about the case where the SIP proxy adds a reference 
(no matter what type of reference it is) then also further work is needed.

I think we should develop an HTTP based solution since it is very simple.

Btw, I am not sure that the name 'using protocol' is actually 
appropriate in this case. We haven't used the term using protocol for 
the Geopriv L7 work either. Terminology is hell in this area.

Ciao
Hannes

Andrew Newton wrote:
> I'd like to know, how many people believe that HTTP requires no or  very 
> little specification to meet the requirements in RFC 3693 and  RFC 
> 3694.  If you believe this, what basis do you have for this  
> conclusion?  Or do you believe more specification needs to be done,  but 
> it is possible for HTTP to be a GEOPRIV using protocol?
> 
> Finally, how many people believe that HTTP should not be a using  protocol?
> 
> -andy
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 17:36:07 +0200

Hi Henning,

here is the reason why I think we are not talking about a 'using 
protocol' here: All we want is to perform dereferencing.

We don't want something that does all the fancy features of a presence 
solution.

I am not even sure where the privacy rules should come from. In the 
Geopriv L7 discussion we had at least a proposal that some of us didn't 
like (namely the end host provides the privacy rules to the LIS). I 
haven't seen such a proposal here.

Here is my question (I raised it already with my scenario list): Where 
does the SIP proxy get the information to construct a PIDF-LO?

* We assume that it gets the location information somehow. Not further 
specified and might depend on the deployment environment.

* What is the "entity" attribute of the 'presence' element?

* Where does the content for the usage-rules (e.g, 
'retransmission-allowed', 'retention-expires', 'ruleset-reference', 
'note-well') come from?

Note that these questions are independent of HTTP. They also apply to SIP.

You might also recall the discussion regarding the difference between 
RELO and HELD when it comes to the threat model.

In RELO you assume that the entity that learns the reference is allowed 
to resolve it. In HELD there is the assumption that the end host 
additionally uploads the Geopriv authorization policies to control the 
access. We never came to a conclusion about the threat model that is 
applicable in the Geopriv L7 case.

I strongly believe that the questions are similar here and there are no 
answers to them. We are just exchanging one protocol (HTTP of RELO and 
HELD) with another one: SIP and route the call via this entity in the 
access network. If the SIP proxy that adds location information (by 
reference or value) is not in the access network then it cannot know the 
  location information of the end host....

Ciao
Hannes

  Henning Schulzrinne wrote:
> For SIP, this is largely done, except for the crypto-random request  URI 
> case and variations, such as user + password.
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 27 Jul 2006 13:25:42 -0400

Inline...

> protocol' here: All we want is to perform dereferencing.

Since the place where the reference is made also includes an identity, 
it is very easy to get the location of a user... and hence the line is 
crossed with regard to privacy.

> We don't want something that does all the fancy features of a presence 

So why did GEOPRIV use PIDF as its basis?  Has as been quoted on this 
list recently, 4119 does not require the use of presence solution, but 
presence solutions were very much a target platform.

> haven't seen such a proposal here.

An L7-LCP does not have to be a using protocol primarily because the 
usage is for a much narrower purpose.  It can be a GEOPRIV using 
protocol, but I believe one of the complaints against HELD (which 
attempted to be an L7-LCP and GEOPRIV using protocol) is that it was 
doing too much.

> 'retransmission-allowed', 'retention-expires', 'ruleset-reference', 

It is possible that a network operator does have enough information to 
formulate a PIDF-LO, at least what is necessary for emergencies.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 19:38:51 +0200

Hi Andy,

> crossed with regard to privacy.

What identity is used where?

> So why did GEOPRIV use PIDF as its basis? 

You misunderstood my statement. For dereferencing a 
location-by-reference (not a subscription URI) we don't need a lot of 
functionality.

  Has as been quoted on this
>> Geopriv L7 discussion we had at least a proposal that some of us 
>> didn't like (namely the end host provides the privacy rules to the 
>> LIS). I haven't seen such a proposal here.
> 
> 

I like to discuss about requirements and functionality rather than 
terminology. I think that statements like "has to be a using protocol" 
help to make a lot of progress.

That's my only objection.

I am the last one to say that we do not need to deal with privacy aspects.

> formulate a PIDF-LO, at least what is necessary for emergencies.
Would you be happy with this level of detail?
... and: We are not only focusing on emergency services.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jul 2006 13:46:55 -0400

With hindsight, I think the term 'using protocol' has been the source of 
  more word-lawyering than engineering insight. I personally find the 
distinctions

   - first person vs. third person (i.e., find out location about myself 
vs. find out location about some third party)

   - location vs. location + identity

   - token-based authorization vs. identity-based authorization

more helpful.

Token-based authorization hands the recipient a key that allows him to 
get a location object, without caring as to who is retrieving the 
object. ("Anybody seeing this SIP request can convert the token into an 
LO.") Identity-based naturally uses some authenticated identity to 
release that information. Strictly speaking, this is only a question of 
a level of indirection, since proving identity usually involves proving 
possession of a secret.

We've been trying to get at some of these distinctions with the sighting 
vs. using protocol terminology, but that distinction also seems to 
degenerate into discussions more suited for a law school or theology 
department than an engineering organization.

For example, by strict definition, LoST would be a 'Using Protocol' 
since it "carries a Location Object", but I hope we all agree that this 
is silly. We had earlier agreed that the location-by-DHCP also were not 
Using Protocol, even though they obviously carry a location object of 
some form.

Privacy issues apply iff
   - third person
   - location + identity (not just location)

The L7 discussion was about 'first person' and 'location only' (although 
the latter is subject to debate, depending on whether one considers an 
IP address of identifying an individual or not).

Depending on the circumstances, SIP-based retrieval can either involve 
privacy concerns (subscribe to [email-masked]) or not (subscribe to 
location of one-time random unlinkable identifier 
[email-masked]). There can also be different privacy concerns 
depending on the perspective. For example, if a SIP request contains 
both an identity and the location retrieval reference, this raises 
privacy concerns for the proxy, but the LIS may not have any such 
concerns since it may only be the repository of these randomly-named 
objects, without tie to an identity.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 27 Jul 2006 13:12:56 -0500

>PIDF would be a fairly short RFC, but I think we need that RFC.

I agree with the above now, based on the comments that HTTP has privacy 
concerns raised, and not addressed, in Geopriv.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 27 Jul 2006 14:15:21 -0400

A using protocol carries location between a server and a watcher.  That is
PRECISELY what a dereference is.  Dereferencing protocols MUST be using
protocols.

However, I think that if the reference is a presence URI (sip/sips/pres)
then these issues are addressed.  If there is to be some other protocol used
to dereference, then it has to be a using protocol, and these issues must be
addressed.  If the protocol always returns a PIDF, many of these issues can
be answered by using the PIDF mechanisms to express user rules.

> specified and might depend on the deployment environment.
Yeah, with the identifier mess

> * What is the "entity" attribute of the 'presence' element?
The user, just as it would be if the endpoint asserted it, possibly
anonymized as we discussed.  I think the latter is more appropriate when
used in a Location header.  
>From the user, just as it would be if the user asserted it.  It's just a
different mechanism for sending the same data.  Probably actually has the
same user interface, it's just the difference between whether the prototype
PIDF that the location is laid into gets sent to the phone or the proxy.
The UI to do this is a probably a web browser.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 21:27:23 +0200

Hi Henning,

I would very much appreciate to treat this topic in the way you proposed 
it below.

A few minor comments:

Henning Schulzrinne wrote:
> release that information.

In past common policy discussions we also differentiated between 
limited use addresses and trait-based authorization. A token would match 
the latter.

In some sense we seem to be using limited use addresses in most of the 
cases when we talk about the location-by-references. The difference 
between limited use addresses and trait-based authorization is small in 
this particular usage environment.

  Strictly speaking, this is only a question of
> a level of indirection, since proving identity usually involves proving 

I guess there are some further differences with regard to the lifetime 
of the different identifiers, the ability to revoke rights, the number 
of entities that one can hide behind these identifiers and the storage 
implications.

> Using Protocol, even though they obviously carry a location object of 

Currently LoST is not a using protocol since it does not carry a PIDF-LO 
although some folks would like to use a PIDF-LO; HELD was a using 
protocol before we turned the problem into a Location Configuration 
problem; RELO never was a using protocol;

Isn't this confusing?

> IP address of identifying an individual or not).

That was before we added the Location-by-Reference and subscription-URI 
concept ....

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jul 2006 15:49:03 -0400

> In past common policy discussions we also differentiated between limited 
> use addresses and trait-based authorization. A token would match the 
> latter.

I'm not so sure. I see this as another level of indirection:

secret -> access

and

secret -> identity ("alice") -> access

and

secret -> trait ("contractor") -> access

> of entities that one can hide behind these identifiers and the storage 

Right - the more layers of indirections, the more means to revoke. 
However, I don't see a fundamental difference between the three 
mechanisms in this case. In each case, you can revoke access.

> Isn't this confusing?

Unless you spent three years in Advanced GEOPRIV Language & Philosophy 
class, yes.

>>
>> The L7 discussion was about 'first person' and 'location only' 
>> (although the latter is subject to debate, depending on whether one 
>> considers an IP address of identifying an individual or not).
> 

As long as the recipient of the reference and the URI is the target, it 
doesn't much matter. We get into trouble if we use the same mechanism 
for first-person and third-person retrieval.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 27 Jul 2006 19:50:31 -0500

Hi Andy,

I'll take a stab at it. Not that HTTP is a valid *using protocol* but,
rather, that the location reference does not actually identify a using
protocol and, in fact, HTTP would only be the transport protocol...

3693 states:
   The "using protocol" is the protocol that uses (reads or modifies)
   the Location Object.  A protocol that just transports the LO as a
   string of bits, without looking at them (like an IP storage protocol
   could do), is not a using protocol, but only a transport protocol.
   Nevertheless, the entity or protocol that caused the transport
   protocol to move the LO is responsible for the appropriate
   distribution, protection, usage, retention, and storage of the LO
   based on the rules that apply to that LO.

A location reference which provided an HTTP URI indicates that the
entity that is going to be used to request the LO is to be communicated
with using HTTP. Because of the rules associated with the PIDF-LO, it
can be inferred that the entity and whatever semantics are associated
with the HTTP communications with that entity will honor the
requirements. That is, HTTP is only the transport protocol. An HTTP GET
has to be interpreted by the receiving entity within the scope of a
using protocol - with its associated set of rules and semantics - which
go beyond HTTP and which do respect the geopriv requirements. Indeed,
this is generally the case - sending an HTTP GET to an arbitrary IP node
can yield any number of results depending what that node actually does.
The client needs to understand the purpose of that server in the scope
of some higher level protocol.

To use another example, a location reference could be an IP address.
There's nothing inherent in IP that honors the geopriv rules, but that
doesn't stop the reference being valid nor say that the protocol used
between a client and that IP address would not honor the rules.

The purpose of the SIP conveyance specification is to say how a LO or
reference can be transferred from one entity to another using SIP. It's
out of scope for a SIP specification to mandate anything about the
transport protocol or to infer anything about using protocol implied by
that transport. As has been previously mentioned, this would be subject
to separate specification and BCP - lest the SIP conveyance
specification become overly rigid and subject to unnecessary maintenance
and churn.

Cheers,
Martin

> Sent: Thursday, 27 July 2006 10:45 PM
> Subject: [Geopriv] teasing apart: http as a GEOPRIV using protocol
> 

------------------------------------------------------------------------------------------------
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: Randall Gellens <[email-masked]>
Date: Thu, 27 Jul 2006 18:36:39 -0700

At 9:33 AM -0400 7/27/06, Henning Schulzrinne wrote:

>  For all protocols, the hardest part is specifying how 
> authentication works in conjunction with the privacy rules. This is 
> far from obvious for HTTP, for example. (Is it the Digest user 
> identifier? Can Basic over TLS be used instead? What about 
> crypto-random request URIs? Is HTTP ok in that case or is HTTPS 
> needed - the answer isn't obvious since an observer would only see 
> a location, not a location-identity pair.)
>

A while back there was some brief discussion in geopriv about using 
"pawn ticket" URIs for location information.  That is, URLAUTH from 
RFC 4467, which is a URL that has been signed by the server and can 
be used by the holder to gain access to the information, subject to 
expiration time and/or role restrictions.  Role restrictions limit 
the URL to being used by an entity that is known to the location 
server as performing a specified role.  Additionally, RFC 4467 allows 
all currently-issued URLs to be revoked by changing the key.

I wonder if there is any value in this?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It wasn't as easy to get programs right as we had thought.
                                           --Wilkes, 1949

---

From: Randall Gellens <[email-masked]>
Date: Thu, 27 Jul 2006 18:39:37 -0700

At 5:36 PM +0200 7/27/06, Hannes Tschofenig wrote:

>  We don't want something that does all the fancy features of a 
> presence solution.

Perhaps it is a question of who is doing the dereferencing: if the 
location URI is given to the target, that seems to me to be 
provisioning, the same as the DHCP case; if instead the URI is given 
to anyone else, that looks like location disclosure (or at least the 
first half of it).  In the disclosure case, dereferencing the URI is, 
I think, a using protocol.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
What is mind?  No matter.
What is matter?  Never mind.
        --Thomas Hewitt Key, 1799-1875

---

From: Ted Hardie <[email-masked]>
Date: Thu, 27 Jul 2006 18:53:27 -0700

Hi Martin,
	Having not seen your note, I already took a stab
it, along much the same lines you suggest.  Clearly, the attached
-00 (not yet in the drafts directories) is the barest of bare bones,
but I thought it might be useful to sketch that out as a contrast
to some of the real applications which might use HTTP as a
using protocol.
	I believe this also differs from RELO in that it is
focused on the transport of PIDF-LO, which is slightly different
from RELO's remit.  But clearly, there are strong connections there.
	And if the phrase "strawman" in the title doesn't
signal that I don't think this is a done piece of work, allow
this too.
			regards,
				Ted Hardie

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 27 Jul 2006 23:14:35 -0500

Is this the loophole everyone has been looking for?

   This document does not describe HTTP as a "using protocol" which, 
   in GeoPRIV terms, is a protocol which "uses (reads or modifies)
   the Location Object".

Or, are we above the scrabbling for loopholes - after all we[1] wrote the rules, we know the reasons for the rules[2], so why are we playing games with definitions?  This is avoiding RFC 3693, and I'm guilty of that[3] (if I recall, you told me to stop).  Why not simply address the requirements?

The point that Martin (D) was making is related to the fact that conveyance doesn't have to specify how a reference is used.  That doesn't mean that it doesn't have to be specified at all, but SIP can treat this as opaque data (except cid:, of course).  

Cheers,
Martin

[1] Taking this in the broadest sense of the term "we".
[2] This is stated, but is often demonstrably untrue.
[3] The concept of "sighting" was seen as a convenient loophole.

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, 28 July 2006 11:53 AM
> To: Dawson, Martin; Andrew Newton; IETF SIP List; GEOPRIV
> Subject: RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol
> 
> Hi Martin,

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 28 Jul 2006 00:24:04 -0500

G'day Ted,

Strawman or not, I think what you've written is a good example of why
the location reference does not need to say anything about whether the
geopriv rules for a PIF-LO using protocol are honored or not. The point
being that once the reference is used to establish a "using protocol
session" it must be the case that these rules are then honored.

The authentication and security steps that you have identified in your
draft - where https is used first; and it could be any equivalent
function - are an integral part of the semantics of the using protocol
defined in this example. And they are independent of, and not explicit
in, the reference itself.

Thanks for that.

Cheers,
Martin

>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: Ted Hardie <[email-masked]>
Date: Thu, 27 Jul 2006 22:28:57 -0700

>The point that Martin (D) was making is related to the fact that conveyance doesn't have to specify how a reference is used.  That doesn't mean that it doesn't have to be specified at all, but SIP c…

Going through 3693 again was what inspired me to put up a strawman.  I hope
setting it alight gets us some light and not too much heat.

My own reading says that if you want to use HTTP as a transport of PIDF-LO, rather
than as a using protocol, you have to use it in a way that protects the privacy
of the object in flight (encrypting TLS in the strawman, but it could be mandating
s/mime or something else), and you have to be sure that the parties transporting
it are authenticated to each other (to protect against monkey-in-the-middle attacks
as a start).

More importantly, you have to use it in a protocol context where it is handed off
after transport to some other protocol or application which then does the real
work of reading or modifying the object and of obeying the rules.  To me that
means that it can't be used in this way loosely--just implementing this strawman
and calling it a using protocol would be utterly bogus, since once it arrives
at the client, you haven't said what to do with it all or how the geopriv
requirements are met.  But I think it *might* be valid in very specific protocol
contexts where you have said what happens when the *using protocol*
(SIP, in this example) does from there. 

It may be, of course, that I was thinking to hard and need to take a bit of
a lie down to recover.  But I thought about the URI schemes which encode
data in the URI itself, and I thought:  how can those be using protocols?
Obviously, they aren't; they're just ways of carrying the data around for
the benefit of real using protocols.  If that is the case, we may be able
to do something simple to specify how to use a suitably protected transport
to dereference a URI rather than carrying the data inside the using protocol.
But I think that this fundamentally requires that the transport/dereference
occur in a very bounded protocol context inside the real using protocol.
Otherwise, you are absolutely right that it is just an end-run.

To re-iterate:  this a strawman; feel free to rip up the innards and use as
a pillow, flammable materials, or use as you see fit.  I won't be offended if
the response is any of the above.
			regards,
				Ted

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 28 Jul 2006 00:52:20 -0500

I guess that I was trying to be inflammatory. ;)

What would be nice on your strawman is a hat, a pipe, a carrot nose and some eyes.  That is, I don't think it's complete as a strawman until you address the RFC 3693 requirements.  The lawyering has devalued the term "using protocol" but I still see value in the underlying requirements - evidently you do too.  Irrespective of whether it's a "using protocol" or not, it needs to provide some level of privacy protection.

We can quibble over terminology, but I'd prefer to see this address the requirements.

Req 1. See RFC 4119
...
Req 6. Interesting one... I'd suggest that this might not be very easy to meet. 
Req 7. ...

That would be a better strawman for me.  Aside from Req.s 6 and maybe 15.3 I don't think you will have to equivocate to meet the requirements.

> Sent: Friday, 28 July 2006 3:29 PM
> To: Thomson, Martin; Dawson, Martin; Andrew Newton; IETF SIP List; GEOPRIV
> >Or, are we above the scrabbling for loopholes - after all we[1] wrote the
> rules, we know the reasons for the rules[2], so why are we playing games
> with definitions?  This is avoiding RFC 3693, and I'm guilty of that[3]
> (if I recall, you told me to stop).  Why not simply address the
> requirements?
> >
> >The point that Martin (D) was making is related to the fact that
> conveyance doesn't have to specify how a reference is used.  That doesn't
> mean that it doesn't have to be specified at all, but SIP can treat this
> as opaque data (except cid:, of course).
> >
> >Cheers,
> >Martin
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 28 Jul 2006 09:19:59 -0400

I think location conveyance is about endpoint (or possibly proxy) to some
other entity, and not LIS to endpoint.  That makes any use of the data in a
location header related to the "using protocol".  If it's a URI, then SIP is
not the using protocol, but the dereference protocol is.  It might be
possible to use a URI for an acquisition protocol (LIS to endpoint), but not
in the context of SIP Location Header, at least as the text now covers use
cases.

I think this is describing a using protocol, and is subject to the complete
review.  I think such a review would be straightforward, and a document like
this should do that.

Of course, I think it would also clearly state that the URI used with this
protocol may be obtained via a Location header in a SIP transaction.

This discussion informs the location conveyance discussion only a little,
and the meat of it is strictly a geopriv matter.  Can I suggest (as I did
with this email) that you drop sip from the distribution list?

Brian

> Sent: Friday, July 28, 2006 1:29 AM
> Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using
> protocol
>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 28 Jul 2006 12:14:32 -0700

> server as performing a specified role.  Additionally, RFC 4467 
> allows all currently-issued URLs to be revoked by changing the key.
>

There might be some impact on the policy document to using "pawn 
ticket" URLs.  A holder of such a URL could be authenticated during 
the dereference, or not (to avoid revealing requester identity even 
to the location server).  Using such a URL when not authenticated is 
not the same as an unauthenticated disclosure, though.

If the keys are associated with an identity (possibly unlinkable), 
and if the rule maker can create multiple identities, each with its 
on key, then the specific identity is a condition.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Rank of Catwoman among the "superheroes" American boys under the
age of ten say they would most like to be: 1.
                                              --(Harper's Index)

---

From: Randall Gellens <[email-masked]>
Date: Fri, 28 Jul 2006 12:18:27 -0700

This does look to me to be a "using protocol".

Presumably the HTTP server and the dereferencer have a relationship 
such that HTTP DIGEST can be used.

Perhaps the DIGEST identity can be used when evaluating the policy rules.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
  "press to test"
      <click>
"release to detonate"

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Jul 2006 16:54:29 +0200

Hi Randy,

I read the draft some time back when you pointed me to it. I had 
difficulties to understand because the document lacks a high-level 
overview.

The document says:
"A URLAUTH-authorized URL conveys authorization (not authentication) to 
the data addressed by that URL."

 From a conceptual point of view this document defines something that is 
similar to requesting and conveying a SAML assertion in a data URI. It 
uses its own format and only a limited set of parameters.

I think that there is no additional gain in security or functionality 
for the topic being discussed here.

Ciao
Hannes

Randall Gellens wrote:
>> RFC 4467, which is a URL that has been signed by the server and can be 
>> used by the holder to gain access to the information, subject to 
>> expiration time and/or role restrictions.  Role restrictions limit the 
>> URL to being used by an entity that is known to the location server as 
>> performing a specified role.  Additionally, RFC 4467 allows all 
>> currently-issued URLs to be revoked by changing the key.
>>
> There might be some impact on the policy document to using "pawn ticket" 
> URLs.  A holder of such a URL could be authenticated during the 
> dereference, or not (to avoid revealing requester identity even to the 
> location server).  Using such a URL when not authenticated is not the 
> same as an unauthenticated disclosure, though.
> 
> If the keys are associated with an identity (possibly unlinkable), and 
> if the rule maker can create multiple identities, each with its on key, 
> then the specific identity is a condition.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Jul 2006 19:31:56 +0200

Hi Randy,

Maybe there is such a relationship. I do, however, suspect that in the 
typical case there isn't since this places the deployment bar quite 
high: Every location recipient (e.g., PSAP, SIP user agent, Location 
Server, etc.) needs to have a relationship (or even a shared secret) 
with the access network provider (L3 provider) since this is the place 
where the HTTP server needs to be located.

The identity used for digest authentication can indeed be used in 
combination with the common policy rules. You just need to define how 
the digest identity and the digest realm part are matched with the 
content of the 'id' and the 'domain' part to the common policy rules.

With the Pawn Ticket URLs the solution would, however, be simpler (as 
simple as with URLs with a randomly create and unguessable component): 
If you know the URI then you are allowed to retrieve the PIDF-LO.

(This assumes that I understood the Pawn Ticket approach properly.)

Ciao
Hannes

Randall Gellens wrote:
> Presumably the HTTP server and the dereferencer have a relationship such 
> that HTTP DIGEST can be used.
>

---

From: Randall Gellens <[email-masked]>
Date: Sat, 29 Jul 2006 11:36:01 -0700

At 7:31 PM +0200 7/29/06, Hannes Tschofenig wrote:

>  Hi Randy,
>
>  Maybe there is such a relationship. I do, however, suspect that in 
> the typical case there isn't since this places the deployment bar 
> quite high: Every location recipient (e.g., PSAP, SIP user agent, 
> Location Server, etc.) needs to have a relationship (or even a 
> shared secret) with the access network provider (L3 provider) since 
> this is the place where the HTTP server needs to be located.

I agree.  That's the question I was raising: my reading of the draft 
suggests that, since it relies on HTTP DIGEST, there must be a 
relationship in order for there to be credentials.

> combination with the common policy rules. You just need to define 
> how the digest identity and the digest realm part are matched with 
> the content of the 'id' and the 'domain' part to the common policy 
> rules.
>
>  With the Pawn Ticket URLs the solution would, however, be simpler 
> (as simple as with URLs with a randomly create and unguessable 
> component): If you know the URI then you are allowed to retrieve 
> the PIDF-LO.
>
>>  Presumably the HTTP server and the dereferencer have a 
>> relationship such that HTTP DIGEST can be used.
>>

-------------- Randomly-selected tag: ---------------
Language is a virus from outer space.  --William S. Burroughs

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Jul 2006 21:29:10 +0200

It seems I misunderstood your comment.
In this case I agree with your observation.

Randall Gellens wrote:
>> Location Server, etc.) needs to have a relationship (or even a shared 
>> secret) with the access network provider (L3 provider) since this is 
>> the place where the HTTP server needs to be located.
> 
>