RE: Requirements Document

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

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Monday, August 20, 2001 5:13 PM
> To: Rosen, Brian
> Cc: geopriv@mail.apps.ietf.org
> 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
>
Received on Mon Aug 20 17:50:38 2001