RE: Requirements Document

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

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

>
> >
> >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.
Sure, but the negotiation occurred when you activated your phone and
agreed to the terms of service. It wasn't done by the protocol.

>
> >
> >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.
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.
> >
> >>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.
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
Received on Tue Aug 21 09:09:12 2001