Subject: Re: Requirements Document

From: Christopher Sipes <[email-masked]>
Date: Tue, 14 Aug 2001 14:21:09 -0400

Hello All,
I apologize for chiming in so late, I've been observing all the 
conversations you've been having over the last couple months, but as I've 
been concentrating heavily on working on my Graduate studies, haven't felt 
as though I would have time to contribute to this WG.  As I am between 
sessions for the next 6 weeks, though, I would like to help out in any way 
I can.  Like, Mari, though, any minutes from the London conference would 
be most appreciated.
Thanks,
Christopher

    || Chris Sipes | Web Developer | Forrester Research, Inc. | 400 
Technology Square | Cambridge, MA 02139 |  email: [email-masked] | 
617.613.6009 ||
----- Forwarded by Christopher Sipes/Cambridge/Forrester Research on 
08/14/2001 02:20 PM -----

[email-masked]
08/14/2001 02:09 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Requirements Document

From: "Mari Korkea-aho" <[email-masked]>
X-Mailer: TWIG 2.6.0.cvs

In-Reply-To: <[email-masked]>

X-Client-IP: 213.243.176.68

Reply-To: [email-masked]

Hi,

Could somebody who participated in the meeting give a short summary 

what actually happened, and what was agreed. Or are there any meeting 

minutes available?

Regards,

Mari

Behcet Sarikaya <[email-masked]> wrote:

> Hello,

>   This is in line with what Allison said during the meeting. I think 
that 

the

> others (Haitao, James, Mari, Kenji, etc.) should follow suite.

>   During the meeting Henning talked about the urgency of this WG's 

business but

> I could not catch his reasons. Why?

________________________________________________________________

Ilmainen Internet @ http://www.nic.fi/

---

From: "Ward, Matthew" <[email-masked]>
Date: Fri, 17 Aug 2001 14:54:06 -0400

-----Original Message-----
From: John W Noerenberg II [mailto:[email-masked]] 
Sent: Friday, August 17, 2001 1:26 PM
To: Randy Bush; Henning Schulzrinne
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Requirements Document

[deletions]

>Randy Bush wrote:
=>>  > - In PSTN emergency call services, callers know (or should know) that
=>>  > dialing 911 or 112 or whatever means that they agree and consent to
have
=>>  > their calling number and possibly their location revealed to the
public
=>>  > safety answering point (or the equivalent in other countries).

>Hmmmm.  I *didn't* know this.  Presumably this is some document that 
>I received at the time I got my cell phone service, or it appears on 
>the back of every bill.  I wonder if the public in general is aware 
>of this.  "Caveat emptor," but I find this worrisome.

The ability of a landline call to be traced to a location is inherent in the
landline net work (each phone number is mapped to an address). For mobile
networks
the ability to locate a phone is also inherent, but on a much coarser level.

Every wireless phone must be located in a "paging area" or else calls cannot
be 
completed to that phone. This is true of all wireless telephony systems
(AMPS, 
TDMA, GSM, CDMA, iDEN, etc). No set size for this "paging area" exists, but
it
can be as small as a single cell site and sector or as large as an entire
country.

As for the the US, the `Wireless Communications and Public Safety Act of
1999'
contains this text:

 	`(f) AUTHORITY TO USE WIRELESS LOCATION INFORMATION- For purposes of

		subsection (c)(1), without the express prior authorization
of the 
		customer, a customer shall not be considered to have
approved the 
		use or disclosure of or access to--

		`(1) call location information concerning the user of a
commercial 
		     mobile service (as such term is defined in section
332(d)), 
		     other than in accordance with subsection (d)(4); or

		`(2) automatic crash notification information to any person
other 
		     than for use in the operation of an automatic crash
notification 
		     system.

So for US

---

From: "Ward, Matthew" <[email-masked]>
Date: Fri, 17 Aug 2001 15:18:26 -0400

Sorry folks, the first email got away from me before completion. 
This more complete and better formatted message contains a bit 
about wireless, US law and location privacy.

-----Original Message-----
[deletions]
>Randy Bush wrote:
=>>> - In PSTN emergency call services, callers know (or should know) that
=>>> dialing 911 or 112 or whatever means that they agree and consent to
=>>> have their calling number and possibly their location revealed to the
=>>> public safety answering point (or the equivalent in other countries).

The ability of a landline call to be traced to a location is inherent in the
landline net work (each phone number is mapped to an address). For mobile
network's the ability to locate a phone is also inherent, but on a much 
coarser level. Yes, every phone is located periodically and always has been.
Wireless carriers do not dispense this information since for the same
reasons 
they do not give out mobile phone numbers, subscriber identities or home 
addresses.

As of right now, millions of rough locations are being generated internal to
the wireless carrier.

Every wireless phone must be located in a "paging area" or else calls cannot
be  completed to that phone. This is true of all wireless telephony systems
(AMPS, TDMA, GSM, CDMA, iDEN, etc). No set size for this "paging area"
exists, 
but it can be as small as a single cell site and sector or as large as an
entire
country.

The use of an emergency services number (9-1-1 in the US) results in a
public
record. The entire message is public domain, including the location (which
for
wired networks is the postal address of the incident). In 1999, the 9-1-1
service
was extended by law to cover wireless networks.

The `Wireless Communications and Public Safety Act of 1999'contains this
text:

 	`(f) AUTHORITY TO USE WIRELESS LOCATION INFORMATION- For purposes of
		subsection (c)(1), without the express prior authorization
                of the customer, a customer shall not be considered to have
                approved the use or disclosure of or access to--

		`(1) call location information concerning the user of a
                  commercial mobile service (as such term is defined in
section
                  332(d)), other than in accordance with subsection (d)(4);
or

		`(2) automatic crash notification information to any person
                  other than for use in the operation of an automatic crash
                  notification system.

So for US, laws already exist covering location dissemination for mobiles. 
With the advent of caller ID on landline phones, a rough geographic match 
can also be made by examination of the area code and office code, which
match 
geographical regions.

For precise location (100 meters or better), The US law is pretty clear that
a subscription or authorization to a location service must be performed
before 
a location can be delivered.

Assumption of a server with a subscription list or a message to the end user
is
valid for this group. The comparison of location to caller ID is again
valid. 
A subscriber can permanently block caller ID or turn it on or off by the use
of 
keypad number strings. Since the caller's phone number maps to a
geographical area, 
it is the same.

-------------------------------------
Matthew Ward
Manager of Strategic Product Planning
TruePosition Inc.

---

From: [email-masked]
Date: Sat, 18 Aug 2001 10:16:34 +0300

Hi Randy,

> once again.  this is not true for all countries or legal environments.
> hence, this group's charter to provide privacy should not be 
> assumed to be abrogated in any circumstances.

Wouldn't it be much better to discuss the real issue, please?
Let's start outlining the security / privacy threats.  If we
have a good threat model, then perhaps we can begin designing
solutions.  

All of this wrangling over what may or may not be permitted 
is a rathole.

Heck, in order to get things moving forward - I'll even offer
to edit the threat analysis document - though I will need 
people to send their favorite security & privacy threats.

Randy, I believe you have a few ...

best regards,
John

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Aug 2001 16:03:22 -0400

> > I mean explicit consent at the point of use.  I see three possible 
> > ways to consent:
> > 1. Out of band - no protocol action at all
> > 2. Prior consent - action completed by some protocol 
> mechanism that has
> > some lifetime (could be infinite)
> > 3. Consent at the point of use
> 
> Could we ammend 1 to say 'Out of band - protocol reminds end device
> that choice has been made?'
No.  Protocols don't remind users of anything.  We aren't even
defining a protocol, but merely an object.  The real issue is that
UI choices are all implementation issues, and it is not a good idea
to force anything on a UI.  How well do you appreciate a warning
shoved under your nose every time you login?  My net administration
forces that on me.  I think it is a supremely BAD idea, and much
more likely to engender apathy than compliance.

I want geopriv to stay OUT of anything having to do with UI
with the possible exception of some advice in the security
considerations section.

> 
> This would allow me as an implementor to debug a possible error, adds
> audit points, etc.  It does have a cost in bandwidth, and I know how
> sensitive mobile folks are to that, but I expect that we can do this
> with fairly few bits.
I don't have a bandwidth problem, I have a security and protocol/device
design problem.  As a product designer I object to standards bodies
telling me how to design the user experience.  You can tell me what
you think a secure system should do, but it's up to me to control
the user experience.  

BTW, I AM designing a product, and I AM picky, very picky about the
user experience.  I'm spending $Ms on the user experience, and I'm
not about to let you tell me what UI mechanisms I'm to use,
when I'm to use them, and what choices I offer.  The hardest
part about UIs is knowing when NOT to offer choices.
This particular product will offer location only in some limited
circumstances (of which E911 is one), and I'm satisfied that 
we will have excellent user consent controls, thank you.
If users don't agree, they won't buy my product :(
 
> I don't see how we can assess privacy requirements without saying that
> you must give choice and notice (amongst other things) to the
> users.
There is no precedence for this in any other IETF standards
track document (using words "must" "choice" and "notice".
Rarely do we even talk about "users", since we have devices
that don't have users.

What if I want to use the protocol to locate robots on the playing
field of robot soccer?  Who is the user?  Do you want me to have
to give consent for every position update for every robot?

How about locating routers in a network?

There is no way to discuss "users" in a general sense.  Again,
we can offer (limited) advice.

> 
> > Consent at the point of use implies things about available UIs.  
> > I may not HAVE a suitable UI at the point of use.  That is 
> my objection.
> > I also think the IETF has stayed away from any kind of UI 
> discussions.
> > I think we should also.
> 
> Its a valid objection, and I understand where you're coming from.  I
> don't see how to reconcile privacy with the idea that I have no
> ability to turn off tracking.  Are you suggesting ECRUSHEDBYAHAMMER as
> a protocol response? ;)
> 
No, I think it's acceptable to have some advice to implementers.
I think it is unacceptable to have any kind of requirement about
notice or consent.

We can lead the horse to water....
We can specify mechanisms to facilitate...

but we can't write requirements that have direct impact on user experience.

Brian

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 20 Aug 2001 13:22:55 -0700

>We can specify mechanisms to facilitate...

Yes, there must be mechanisms to facilitate negotiation of consent. 
If the mechanism is required to be used, that puts a burden on 
devices where consent is not required or meaningful to do The Right 
Thing, and, moreover, take the time to exchange the messages. 
However, requiring the mechanism be used doesn't necessarily affect 
the UI or necessarily materially affect the user experience (Brian, I 
have faith in your cleverness).

Requiring the mechanism does mean that revealing location information 
will always be negotiated.  Overall, that's a Good Thing.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   Perfect authentication would mean that others know for certain all the
   facts about you.  Happiness comes from others knowing a good deal less.
   -- Lawrence Lessig, "Code And Other Laws of Cyberspace", 1999
   ----------------------------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Aug 2001 17:51:15 -0400

You can't write a requirement forcing user interaction.

You can't write a requirement forcing a policy server.

You can't write a requirement defining HOW a delegation
mechanism must work (especially how the user interaction
of such a mechanism must work).

You can't write a requirement requiring specifying
a particular authentication mechanism, or indeed much
more specific than you have to have one.  I suspect it
may be very hard to even specify the requirements
of such a mechanism without knowing more about the
use case.

What you can do is have a discussion of how these mechanisms
might best be specified if they are to be provided.

Let's be specific for three use cases:

1. The one you are most afraid of - my cell phone can report my location
using some new protocol that doesn't exist yet, or perhaps via HTTP.

2. The one that is tops on my list - emergency services

3. The one that breaks most of your assumptions - the user is the consumer,
the service provides the location of all of the possible items of interest
to the consumer (I send you the location of all of my branches, you pick the
one you want).

In case one, all of your concerns come up, and all of the mechanisms you
want could be, for SOME networks, and SOME services appropriate.
I don't agree that they are appropriate for all.  I would want the
requirements to adequately define mechanisms which, if implemented,
allowed the user a fair degree of control.  There are systems which
don't need most of the mechanisms, but likely will want some of them.
The problem is that the ones that I want are the ones that are the easiest
to defeat/ignore/not implement.  If I want to sell your location information
without your consent, I don't care if my geopriv implementation meets
any "mandatory-to-implement" requirements the IETF wrote one day.

In case two, I want a secure way to authenticate that when I call
for emergency services, that I can authenticate that I am connected
to one, but that is a SIP issue.  Once I am assured that I am
connected to an emergency services access point, I need to
have location information sent without requiring any further action.
I COULD have a system which allowed further action, but I require
the ability to build a system that does not.

In case 3, I can't really tolerate ANY of the mechanisms you have
advocated - there is no "user", and the service wants everything
free and open to all. If the protocol wants some privacy or authentication, 
no problem, but the geopriv object should not involved.

From this I conclude that we can offer a menu of security suggestions,
but that is what they have to be, qualified-by-use-case suggestions.

Brian

> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 5:13 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: RE: Requirements Document
> 
> 
> > Sure.  I agree.  But this is 100% an implementation
> > and/or deployment issue, and not a protocolor "object" issue.  
> > We can offer advice on the subject, but I can't see how 
> > you would write anything stronger.
> > 
> > I really DO want to use policy systems in some cases.
> > I really DO want to have delegation mechanisms in some cases.
> > I really DO want to have cryptographically secure authentication
> > in many (most) cases.
> > 
> > What I don't want is to have this group specify any of them.
> > 
> > Use words like "recommend" and "should consider", and not
> > "must" and "mandatory-to-implement".  The ield of use
> > for this object is way to wide to do more.
> 
> this group is to develop requirements, not wishes.  and there
> is an expectation that these requirements may indeed be met by a
> protocol developed by a follow-on wg.
> 
> randy
>

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 20 Aug 2001 15:19:48 -0700

At 5:08 PM -0400 8/20/01, Brian Rosen wrote:
>and/or deployment issue,

absolutely right (I'm not talking about UI here.)

>  and not a protocol or "object" issue.

absolutely wrong.  If we don't specify what is required to comply 
with a protocol (and specifying the object the protocol manipulates 
is part of the protocol), you  have no interoperability guarantee.

>I really DO want to have cryptographically secure authentication

So all these things must be in the protocol.

best,
-- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 20 Aug 2001 15:53:12 -0700

>You can't write a requirement forcing user interaction.

You must be clear what you mean by user.  If you mean a human 
decision during each protocol exchange, I agree with you.  But that 
is not the issue.  The decision may be made a priori.  In that case 
the location sender can use the result of that decision during 
protocol negotiation to  indicate its willingness to send location 
information to the receiver without any specific interaction during 
the negotiation between the sender and a human for which the sender 
is an agent.

>You can't write a requirement forcing a policy server.

I agree this would be unwise, because it complicates deployment.

>mechanism must work

Why not?  Consider dns referrals.  That mechanism seems to have 
worked pretty well.

>(especially how the user interaction

I agree, but it's beside the point.

>a particular authentication mechanism,

There are numerous examples where this has been done: POP, IMAP, SMTP 
Auth, come readily to mind (mainly because I've spent a lot of time 
on email protocols).  Kerberos is all about authentication. 
Authentication is an important part of SSH.  I'm sure others can cite 
examples in other realms.

>I suspect it may be very hard to even specify the requirements

That's why there has to be a negotiation between the sender of the 
location information and the receiver of the location information 
whether or not to send the information at all.

>the ability to build a system that does not.

This doesn't remove the need to negotiate whether or to what degree 
location information is revealed.  I don't much care how the device 
sending the location information determines its goal in the 
negotiation, only that the sender and receiver negotiate.

>free and open to all.

What is "the service" in case 3?  It is operated by some agency (an 
individual, a proprietorship, ...., a corporation) that wants to 
publish location information.  It is the sender of the location, the 
consumer is the receiver.  In this case the sender's negotiation goal 
is to offer all information that is requested by the receiver.

I don't see how this breaks the requirement that a negotiation take place.
>but that is what they have to be, qualified-by-use-case suggestions.

I disagree, Brian.  In all the cases you've cited, there is a sender 
of location information, and a receiver.  The sender must always have 
the opportunity to determine whether location information shall be 
sent.  That is a decision that will be made by some human being as 
some point.  If the geopriv protocol doesn't allow for humans to 
control the protocol's behavior, then we have failed.

best,
-- 

john noerenberg
[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Aug 2001 09:09:41 -0400

> the negotiation between the sender and a human for which the sender 
Please consider that any protocol is not dependent on actions
taken at one end.  It is only dependent on actions taken between
entities implementing the protocol.  A protocol ought not to have
any requirements defining how the sender interacts with the human at the
sending end.  The agent is at the sender, and that is not a subject
for standardization.

There certainly is scope for dealing with agents that are across the wire
from the sender (I send location to a server that authenticates and
provides my location to others on my behalf). I want the object to
be able to be used in such a circumstance.  The issues of how the
delegation is done, and how the authentication between the ultimate receiver
and my agent is, I think, also beyond any strict requirement.  My agent
could receive my delegation by out-of-band means.  It could authenticate
by out-of-band means.  The requirements document can say that the user
must delegate and define the scope, lifetime and privileges of such
delegation, but it can't specify what limits to such delegation there
might be, nor the mechanism that it might use.
> Why not?  Consider dns referrals.  That mechanism seems to have 
In one protocol it could.  If delegation can be done by a variety
of mechanisms in a variety of protocols, then the requirements would
have to be pretty broad.  That is the case here.

> examples in other realms.
Yes, but this isn't the protocol, and we need to use the object in
a variety of protocols.  Each of these protocols will have their own
authentication mechanisms.  That is why this group can't specify an
authentication mechanism.  If it was chartered to write a requirements
document for A protocol, it would still not specify a particular
authentication mechanism, it could only specify what the requirements
for an appropriate mechanism.

We CAN do something like that, but since the field of use for the
object is wider than a single protocol, the requirements will necessarily
have to be "looser" and qualified.  The authentication requirements of the
user for my case 3 (provider is a service that sends multiple locations
to any user than wants them) is different from that of my personal device
divulging my location.  The choice of authentication mechanism is therefore 
dependent on how you use the object, and this group has to consider 
all of them.
> whether or not to send the information at all.
We cannot REQUIRE that negotiation be used in all use cases.
We have already concluded (I think), that consent can be
implied by contract or law or out of band means.  In that case, 
negotiation in any protocol is not appropriate.  

> negotiation, only that the sender and receiver negotiate.
Sure, but the negotiation occurred when you activated your phone and
agreed to the terms of service.  It wasn't done by the protocol.

> I don't see how this breaks the requirement that a 
It's all in your definition.  As long as the requirements allow me
to "negotiate" where the receiver is not obligated to reveal any
information, and the sender is not obligated to perform any action
other than acceptance, and the negotiation can be implied by
contract, then I'm with you 100%.  If the requirements force a protocol
message exchange, which sends no information on either the challenge or
the response, then I guess I can live with it, but question it's utility.
If the challenge or response must reveal any identity information,
or the resources at either the sender or the receiver are taxed, then
I object.
> control the protocol's behavior, then we have failed.
The sender always chooses whether it will, or it won't send location.
The question is, can that choice be left to the sender, or do they
have to consult you?  I'm happy to have the document state that
authentication of sender must be completed before location is sent.
I'm NOT happy with requiring a particular authentication mechanism,
or even defining a minimum set of requirements.  I think consent of the
human is required, but that may be obtained by contract, law, or
out-of-band means.  I think that once you establish who you are
talking to (authentication) and have determined consent (which
may be implied), there is nothing to negotiate.

I am perfectly happy to ALLOW a specific protocol to have strong
authentication, and I'm happy to recommend that in the security
considerations section.  I'm perfectly happy to recommend that
consent of the human be obtained directly, rather than indirectly
when circumstances warrant.  What I'm opposed to is REQUIRING
that strong authentication be implemented at the point of use,
or REQUIRING that the human indicate consent at the point of use,
or REQUIRING that a protocol have a negotiation (of what?) at the
point of use.  Allow, don't require.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Aug 2001 09:16:56 -0400

There is a VERY big difference between "...must be a mechanism"
and "If the mechanism is required to be used"

The former is okay, the latter is not.
There is zero privacy in exchanging protocol messages that don't do
anything:
	"Inform the user that consent is needed"
	"I confirm I informed the user, and he said yes"

Unless you explicitly require cryptographically secure authentication
of consent, you are doomed, and I can't believe that we will force
such a mechanism to be used.  Specified, fine.  Advice on when it's
appropriate to use it, fine.  Requiring it's use, not acceptable, IMO.

Of course, the whole idea that you need ever have a PROTOCOL mechanism
for this purpose is really silly.  At best you have some requirement
about consent that uses words like "mandatory to implement", but it's
all one sided -- the consent mechanism is all on the provider side;
the consumer doesn't have anything to do with it.  As such, it's
not subject to standardization.

I don't agree that we can have such a requirement, but if we did,
it wouldn't have anything like a protocol message exchange.

Also, we have all kinds of deployment scenarios where it's actually
user specified POLICY that decides whether to release information, not
point-of-use.  That brings in other actors.

Do we all have our feet on the ground here? This isn't a protocol.  
The spec would have to have words like
		"protocols using this object must define a consent mechanism
            for the provider side which must be specified as 
            'mandatory-to-implement'. The mechanism must define a 
            user interface element that indicates consent to release 
            location information"

Do you REALLY think that is an appropriate specification?
I don't.  It's WAY far away from what we usually do.

Brian

> Sent: Monday, August 20, 2001 4:23 PM
> To: Rosen, Brian
> Cc: 'Adam Shostack'; Henning Schulzrinne; Randy Bush;
> [email-masked]; [email-masked];

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Aug 2001 09:38:42 -0400

> is part of the protocol), you  have no interoperability guarantee.
There is a very big difference between specifying the object and
specifying the protocol.  In some cases, the protocols exist already,
and may have the appropriate mechanisms for the use case.  In others,
appropriate mechanisms may not be present and would have to be added,
but in all cases, the choice of mechanism, and even the requirements
of the mechanism depend on how the object is used, and not
on what it contains.

We can specify what it contains.  We can write some broad requirements
on authentication and consent.  What we can't do is specify a particular
set of mechanisms, or even specific requirements on those mechanisms
unless it is qualified by the field of use, and we must cater to
a very wide range of uses.

> So all these things must be in the protocol.
No, they MIGHT be in SOME protocols.  
We aren't writing requirements for one protocol.  We are writing
requirements for an object that will be used in several protocols.
Some of them may implement all of these, some of them may not implement
policy or delegation in any form.  Some may have authentication that
is not accomplished cryptographically.

Consider a case where all the senders and receivers within a single
entity (enterprise).  For example, I implement a smart badge that sends
my location continuously so that, for example, a hospital can find the
closest nurse to a patient.

There is no "authentication" of the receiver (the hospital).
It may be that the badge itself has crypto for authentication and privacy,
but 
it's not the user.  There is no explicit consent at the point of use - you 
consent to have your location known when you accept employment, and location

is broadcast continuously.  That is a useful system.  We should allow such
a system to be built using our standards.  That system has no explicit
consent, no explicit user authentication.  It HAS authentication, and it
HAS consent, it's just not part of the protocol that transfers location.

Brian

---

From: John W Noerenberg II <[email-masked]>
Date: Wed, 22 Aug 2001 17:30:32 -0700

At 9:09 AM -0400 8/21/01, Brian Rosen wrote:
>  A protocol ought not to have any requirements defining how the 
>sender interacts with the human at the sending end.  The agent is at 
>the sender, and that is not a subject for standardization.

I think we're in violent agreement.

---

From: John W Noerenberg II <[email-masked]>
Date: Wed, 22 Aug 2001 17:57:42 -0700

At 9:09 AM -0400 8/21/01, Brian Rosen wrote:
>provides my location to others on my behalf).

There are senders and receivers.  What you are talking about is a 
receiver who may become a sender, and calling this receiver-sender an 
"agent".  I'm just clarifying terminology.

>  I want the object to be able to be used in such a circumstance. 
>The issues of how the delegation is done, and how the authentication 
>between the ultimate receiver and my agent is, I think, also beyond 
>any strict requirement.

I disagree.  The delegation rights for the information must be 
encoded in the location message.

>   My agent could receive my delegation by out-of-band means.  It 
>could authenticate by out-of-band means.

I suppose it could.  But why is that desirable?  Even if it is, we 
still need a way to change the delegation privileges in-band.  We 
don't want to force people to go out-of-band to change the delegation 
privileges.  That would be inconvenient in many circumstances.

>   The requirements document can say that the user must delegate and 
>define the scope, lifetime and privileges of such delegation, but it 
>can't specify what limits to such delegation there might be, nor the 
>mechanism that it might use.

It can be a requirement that there must be a mechanism for 
delegation, and that mechanism transmits the scope, lifetime and 
privileges of the delegation.
-- 

john noerenberg
[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Aug 2001 09:20:59 -0400

> "agent".  I'm just clarifying terminology.
Yes, you have interpreted what I meant correctly.

> encoded in the location message.
I agree that it COULD be, for some uses, although I suspect that
in fact the delegation for the vast majority of the cases is
in fact more static, and received out of band.  With respect
to our work, I can see writing up some requirements for a
such a case as an example, but I would be against mandating the
mechanism.  Thus my opposition to a strict requirement.

We can say something like, "where it is appropriate, delegation
of rights could be sent with the location message.  In such a
case, protocol designers may consider the following requirements."

What you can't do is state absolute requirements, because they vary
greatly by use case.
> privileges.  That would be inconvenient in many circumstances.
It is desirable because the UI for the end device may be much less
convenient to allow a full and complete disclosure of when and
under what circumstances delegation is permitted.  A much more
reasonable scenario is that you sign up for a service which has
a website where your contract is spelled out.  You may have a number
of controls, best managed by a desktop UI.  You make your choices,
come to agreement, and then your end device makes reports to the service
and the service does the delegation.  

I don't want to force anything on anybody.  I want to make services
available.
I want options, not restrictions.  I'll be very happy to accommodate
any of the mechanisms you want to see, as long as every one of them
is optional to implement.  
> privileges of the delegation.
No, no, no.  There can be an OPTION for delegation.  There are many
systems where delegation is not appropriate at all.  You can say
IF there is a delegation then the delegation mechanism must have
a means to define scope, lifetime and privileges.  You can say
IF the delegation mechanism is dynamically changeable, then
there COULD be a mechanism that alters the scope, lifetime and
privileges with the location report.    The delegation could be
done by its own message exchange for example.  You cannot mandate
mechanisms in a protocol you aren't designing.

In my first use, there is both law and service agreement restrictions
on what can be changed. If the carrier offers you service, may do so
on condition that you agree to allow location information to be
sent for an emergency call.  In this case, there is implied
delegation - the PSAP can give your location to the emergency responder.
You cannot control this.  There will be no delegation information
in the sip messaging that reveals location.  There will be no
explicit consent.  There will be no UI.  You can choose to not
place an emergency call (actually, I believe if you call the
police/fire/ambulance using the normal telephone numbers, none of
the legal or contractual obligations to provide location apply, it's
only if you call using 911/112/...).  

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Aug 2001 09:34:52 -0400

Well the charter is fixed.  The requirements have to be applicable to
a broad spectrum of use cases.  If you want to try to write examples of
an in-band mechanism, I'll participate and try to be helpful AFTER we
get the requirements that in fact are applicable to the broad spectrum
agreed.  

Brian

> It's better to keep the scope narrow.  Demonstrate a delegation 
> mechanism that works for location in one context.  If we do that 
> sufficiently well, others will find it useful.  I'm not denying our 
> charter's aim the result should be broadly applicable.  I'm 
> concerned, however, that if we try incorporate all possible cases, 
> we'll spin our wheels.
>

---

From: John W Noerenberg II <[email-masked]>
Date: Thu, 23 Aug 2001 15:25:57 -0700

>mechanism.  Thus my opposition to a strict requirement.

Our goal is to insure that location information is revealed in 
compliance with the agreement between the sender's controller and the 
receiver's controller.  We must assume that each transaction is 
independent.  Therefore the access rights applying to any particular 
transaction must be included in every transaction.  To do otherwise 
allows the condition that location revelation is not controlled by 
security considerations in every circumstance.  This would be a 
fundamental flaw.

>under what circumstances delegation is permitted.

I say with all respect, the UI capability of the end device is not 
our primary concern.  First, we must create a protocol which insures 
privacy considerations of sender and receiver are respected to the 
greatest degree possible.

>A much more reasonable scenario is that you sign up for a service which has

This is only reasonable in terms of devices which were designed 
several years ago. Do not be bound by this.  We must not be bound by 
this.  We are designing for devices to be built tomorrow, not 
yesterday.

>is optional to implement.

If they are optional, they are meaningless.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   Like the Sorcerer's Apprentice, we succeeded beyond our
   wildest dreams and our worst fears.
   -- Steve Crocker, quoted in Wired Magazine, Apr, 1999
   ----------------------------------------------------------------------

---

From: John W Noerenberg II <[email-masked]>
Date: Thu, 23 Aug 2001 15:37:59 -0700

At 9:34 AM -0400 8/23/01, Brian Rosen wrote:
>a broad spectrum of use cases.

Certainly our goal is the protocol will be broadly applicable.  But 
you can't get there by trying to account for every possible use.  It 
is impossible to imagine all the potential applications.  That is a 
guarantee this group will simply flail.  First, find a problem you 
can solve.  We've decided to focus on HTTP and HTML.  Once we have 
experience incorporating privacy considerations of location 
information into those protocols, then we have a basis to generalize 
to other situations.
-- 

john noerenberg
[email-masked]

---

From: John W Noerenberg II <[email-masked]>
Date: Fri, 24 Aug 2001 11:15:29 -0700

At 8:29 AM -0400 8/24/01, Brian Rosen wrote:
>I wrote this before I saw your mail on your interpretation
>of the charter.  So, from your point of view, this is mostly
>meaningless, but I think you are incorrect, so I offer it anyway.

We're struggling to come to a common understanding.  That isn't 
necessarily easy, and I apologize for letting my frustration show.

>
>I don't really understand how you intend to accomplish our
>goals.  We are defining the requirements for an object.

Yes, that's part one.

>   We aren't defining a protocol,

No, this is mistaken.  We have to define a protocol to carry the 
object.  Recall that is one of the milestones for this WG.  There are 
a couple of different ways to accomplish this.  a) We could create a 
brand spanking new language to deliver the object from sender to 
receiver.  b) We could take an existing protocol -- like SIP or HTTP 
-- and propose extensions which enable them to carry the object. "b" 
is likely the more preferable route.  I've been down the "a" road 
before, and it's a bumpy ride.

>  and FOR SURE, we are going to
>use this object in existing protocols with existing devices.
>SIP and HTTP are examples, on existing phones and PCs at a minimum. 
>Sure, new devices with new capabilities will come along;
>I'm working on some :), but whatever we do, it has to WORK
>on a "black" phone connected to a SIP gateway, or a current
>technology WAP phone, or the first gen 3GPP phones, and, believe
>it or not, the first level ethernet switch in the closet near
>you.

The best we can hope for with existing devices (excepting the PC, and 
perhaps 1st generation 3G devices), is the protocol results in the 
knowledge by the users of  senders and receivers of these messages 
there is NO privacy associated with the location messages exchanged.

That doesn't mean we can't set the ground so that succeeding 
generations can negotiate the degree and limit of the information 
revealed in the location messages.

>
>A critical need, my first application of this object, is to
>reveal location in an emergency call.   Please tell me what
>SIP messages you want me to send and receive in order to
>send location.  Yes, we can if needed, modify SIP, although
>it might be hard to totally redefine the protocol.

This is essentially what I propose we do.

>
>Please keep in mind the current bandwidth available to a 3GPP
>telephone for signalling (around 4Kbits), and the current processor
>available to run cryptographic operations.

It is for these reasons it is unrealistic to expect current 
generation devices can assure any degree of location privacy.

>   I don't care what the future will bring if the REQUIREMENTS must be met
>by current technology.  What REQUIREMENTS are you placing
>on my current problem?

The requirement I seek is devices exchange the object.  It is 
reasonable to say the attributes defining access limits may be set to 
indicate there is no limitation on the use of the information, but 
doing so provides no assurance the information will not be used in 
contexts beyond the current transaction.

If limitation on the use of the information is desired by the users, 
senders and receivers must be capable of setting other values for 
these attributes.

>
>Hmmm, I just listed several requirements.  Let me restate them:
>1. The solution must be retrofitable into existing protocols such
>as HTTP and SIP.
>2. The solution must function on existing technology SIP gateways
>existing WAP-style mobile devices, first generation 3GPP handsets
>current generation PC technology, and existing first level manageable
>LAN switches.  Software upgrades are acceptable.
>3. The solution must function on low bandwidth (e.g. kilobit-range)
>links with reasonable response times.
>5. The solution must support unattended devices

With the bounds I've set, I think these are all attainable.  Bear in 
mind the application of the protocol in these circumstances likely 
won't improve the control over location information -- which is 
essentially the situation we have today.

>4. The solution must support high-update-frequency tracking

This probably is unattainable because of bandwidth and capacity limitations.

best,

-- 
john noerenberg
[email-masked]
  --------------------------------------------------------------------
   Setting out on the voyage to Ithaca
   you must pray that the way be long,
   full of adventures and experiences.
   -- C.P. Cavavy, "Ithaca", 1911
   --------------------------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Aug 2001 14:48:16 -0400

Huh, now I'm the one with more ambition wrt privacy than you.

I believe we CAN provide a reasonable degree of privacy
to location information within the bounds of my current problem.

For example, I think we CAN require strong authentication
prior to transmission of location information in nearly every
case I'm aware of. 

On the other hand, I'm pretty pessimistic about what real
privacy controls you can put assuming next generation devices.
The problem, as I see it, is that there is no way the
sender can know if the receiver will respect its wishes.
All of the controls you want seem to be hints sent by the
sender to the receiver telling the receiver what you hope
it will do with the data.

Good guys will behave, bad guys won't.  It's always true
that if you tell someone a secret, you can't depend on him
keeping the secret.  I don't see any drawbacks in trying
to write requirements that will give decent capability to
users where the receiver is well-behaved, but I don't see
that you get to claim much more than a prayer.  Certainly,
out of band mechanisms are as good, if not better than
that, since they can either explicitly or implicitly create
a contract, where a protocol mechanism cannot.
A well designed consent form is a much more effective
privacy control than any protocol mechanism could ever be.

The real problem though is that there is no way to test
conformance to the requirements you seem to want to write,
since there is no observable protocol behavior difference
between a conforming and a non-conforming implementation.

Brian

> Sent: Friday, August 24, 2001 2:15 PM
> To: Rosen, Brian
> Cc: 'Randy Bush'; [email-masked]

---

From: [email-masked]
Date: Thu, 30 Aug 2001 17:42:05 +0300

Hi Brian,

Catching up on some mails ...

> with the possible exception of some advice in the security

Agreed.  I think that this is not something that we should do here.

John

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Aug 2001 10:58:44 -0400

I think this is insufficient, because I think there can be
delegation services you trust.  Think of an underpowered
remote device trying to let several services track him.
He would prefer to delegate to a service that could supply
location updates to all he authorizes the delegator to
serve.  He only supplies his report to the delegator.

Although I wouldn't mandate it's use, it is possible to 
encrypt the report such that anyone the user didn't
authorize couldn't decrypt it.   Works, but may be
too expensive to use in lots of cases.  Of course,
those he did authorize could subsequently reveal to anyone
else, but that's the nature of secrets.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 30, 2001 10:46 AM
> To: [email-masked]
> > and i see it as a general issue of delegation of authority, 
> > with its own set of attendant authentication and authorization 
> > issues.  e.g. i want to know to what agent i am delegating, and 
> > to be able to restrict that agent's abilities to act in my place, 
> > in to whom they reveal, what they reveal, and if and what they 
> > may subdelegate.
> 
> My general comment is that when you delegate something, 
> most likely you will not be able to control what your delegate
> does.  I think delegation usually (always ?) introduces
> security & privacy problems.  
> 
> The only way that I could see this working would be that the
> delegate would not be able to understand the location information
> without consulting you.  So, in effect, this would mean that your
> delegate is essentially only screening your calls.  Is this
> sufficient?
> 
> John
>

---

From: [email-masked]
Date: Thu, 30 Aug 2001 18:00:46 +0300

Hi Brian,

> goals.  We are defining the requirements for an object.  We
> aren't defining a protocol, and FOR SURE, we are going to

One thing that I think you left out is that (I believe) we 
need to state requirements on how the object must/should be
used.

br,
John L.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Aug 2001 11:01:59 -0400

I agree

Brian

> Sent: Thursday, August 30, 2001 11:01 AM
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 30 Aug 2001 18:08:33 +0300

Hi Brian,

> else, but that's the nature of secrets.

That would be one model.  I guess we could include this as one 
model.

John

---

From: John W Noerenberg II <[email-masked]>
Date: Thu, 30 Aug 2001 11:32:12 -0700

Been tied up with other things the last couple of days....sorry...

>prior to transmission of location information in nearly every

In order to do that, you need a mechanisms to represent unambiguous 
identity of both parties in the exchange.  The sad truth is no widely 
accepted Internet mechanism for this yet exists.  This is still true, 
even when you try to restrict the domain geographically.  That's why 
requiring strong authentication in the near term is optimistic, imho.

>sender can know if the receiver will respect its wishes.

Be careful of wandering into issues of trustworthiness.  For the 
purposes of design we can specify there is a trust mechanism and it 
works in a particular fashion.  I agree that it's wholly beyond our 
control whether operators of the protocol sender/receivers consider 
their partners trustworthy.  At the same time, I don't think that's 
our responsibility, so I'm not going to worry overmuch about this 
question.

>it will do with the data.

I'd characterize it more definitely.  The purpose of a protocol is 
for each partner to determine if the other is correctly following the 
steps of the negotiation.  Cheaters can misrepresent themselves, and 
there are cryptographic techniques than can limit the effectiveness 
of cheating (zero-knowledge proofs), but they aren't perfect.  I'd 
conclude technology can aid building trust between partners, but 
there are no guarantees cheating can be eliminated.

Essentially we agree.  But this contradicts the original assertion 
that strong authentication can be assured.

>Certainly, out of band mechanisms are as good, if not better than 
>that, since they can either explicitly or implicitly create a 
>contract, where a protocol mechanism cannot.  A well designed 
>consent form is a much more effective privacy control than any 
>protocol mechanism could ever be.

I have two observations here.

A well-designed consent form is a form of a protocol - not one 
created by the IETF, necessarily, but it still is a protocol. 
Because it is a protocol, it can be modeled by one we design.

You've made the leap that a consent form constitutes a legal 
document.  Whether true or not, this is beyond our scope.  Further, 
it is beyond our scope whether law-making bodies would sanction an 
IETF protocol as legally binding.  Certainly this is a possibility, 
but it's not our concern.

>between a conforming and a non-conforming implementation.

If the rules of the protocol are explicit, then whether or not the 
execution of the protocol conforms to the rules is certainly 
testable.  That's what our goal should be.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   If we admire the Net, should not a burden of proof fall on those
   who would change the basic assumptions that brought it about in
   the first place?
   -- David Brin, "The Transparent Society", 1998
   ----------------------------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Aug 2001 16:19:39 -0400

I think we should have strong authentication in as many
use cases as practical.  I suspect that we can't do it
in all cases, so I want the language written appropriately.
I would say that strong authentication with or without
explicit user identity is acceptable.

Brian

> From: Adam Shostack [mailto:[email-masked]]
> Sent: Thursday, August 30, 2001 4:11 PM
> To: Rosen, Brian
> Cc: 'John W Noerenberg II'; [email-masked]
> On Thu, Aug 30, 2001 at 03:07:25PM -0400, Rosen, Brian wrote:
> > I do understand the limitations of authentication.
> > I think there are often difficulties of correlating the user's sense
> > of identity of a party with cryptographically strong authentication,
> > but I suspect that we still can have strong authentication in many,
> > but not all cases.
> > 
> > I'm not aware of any techniques that ensure strong
> > privacy in tha absence of strong authentication.
> 
> Do you mean the inverse, techniques that ensure strong privacy in the
> presence of strong authentication?  Without strong authentication,
> privacy is easy.
> 
> You can achieve strong authorization or credentialing, without needing
> to authenticate who I am, by using techniques such as Brands' Private
> Credentials, SPKI, or PolicyMaker.  You might very well want strong
> authentication when handing out the credentials, but you don't need to
> share the information about who is being authorized to do something.
> 
> This could be useful, for example, in saying that any police officer
> is authorized to force you to reveal your location, but that police
> officer is not required to reveal their name to you.  You can give
> them a Private Credential that allows them to prove their police
> status, jurisdiction, etc, and only reveal the name if there is a
> reason to do so.
> 
> Adam
> 
> 
> -- 
> "It is seldom that liberty of any kind is lost all at once."
> 					               -Hume
> 
>