RE: Requirements Document

At 5:51 PM -0400 8/20/01, Brian Rosen wrote:
>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.

>
>You can't write a requirement defining HOW a delegation
>mechanism must work

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

>(especially how the user interaction
>of such a mechanism must work).

I agree, but it's beside the point.

>
>You can't write a requirement requiring specifying
>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
>of such a mechanism without knowing more about the
>use case.
>
>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.

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.

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

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.

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

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

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
jwn2@qualcomm.com
   --------------------------------------------------------------------------
   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
   --------------------------------------------------------------------------