> > > In terms of requirements:
> > > 1. entities which have location information and place
> > > emergency calls where location is required to be reported must
> > > be able to send such location without requiring user
> > > identity or any other form of authentication not provisionable
> > > in the end device itself.
> > Nothing in the charter says that user identity will be required in all
> > cases.
> Sure, but the charter isn't a requirements document.
On the contrary, the charter most certainly is a requirements document. It
describes what the WG is required to do in order to be successful. I actually
think of it as a kind of contract. Done right charters can be wonderfully
focusing and can prevent WGs from wandering off into the weeds.
> Are we writing one?
Whether or not the requirements warrant a separate document is up to the WG
chairs to decide.
> > > 2. PSAPs must be able to request location of any device
> > > placing an emergency call from any service that has such
> > > location. The PSAP must authenticate itself as a PSAP.
> > Exactly. In this case authentication still occurs, it is just
> > the callee being authenticated, not the caller.
> Yes but many authentication mechanisms imply mutual authentication.
And many don't.
You seem to be assuming that our fairly restrictive charter is going to force
us to design something that doesn't meet your needs. But after many years of
experience in the IETF, I've found that often exactly the opposite happens: By
making security paramount we avoid having a lot of nonproductive debate
about proposals with totally inadequate security.
> So this has an impact on choice of mechanisms.
Of course.
> I agree this is doable.
Good.
> > > 3. End devices placing emergency calls must be able to request
> > > its own location from any service that has such location without
> > > requiring user identity of any other form of authentication
> > > not provisionable in the end device itself.
> > This is harder, but still not impossible. An end device in such a
> > situation has the credential provided to it by the emergency service it
> > has contacted. That credential could be designed in such a way that it could
> > be used by proxy to obtain location information from another service.
> I hadn't thought of this, but it might work if it had a
> use-once characteristic.
> > > 4. Any privacy control mechanisms specified as required in
> > > emergency calls must be able to be completed in an expeditious
> > > manner, when conditions are far from ideal (consider disaster
> > > situations, for example). Thus the choice of mechanisms and
> > > algorithms must take into account impaired networks, etc.
> > In general privacy control mechanisms should be as light weight as
> > possible. So while I agree that this is something to consider, I don't
> > see it as a concern unless we seem to be getting into trouble.
> I see a lot of reason to be concerned.
> A good example is that sip is normally UDP based. Take a
> UDP based mechanism and send a big cert on a system with 80%
> packet loss and a constrained bandwidth and tell me how long it will take to
> get authenticated.
> If it's a 200 byte token, no problem.
Again you seem to be assuming that security requirements will force us into
using the wrong mechanisms. And again I've often observed exactly the opposite
to be true: The biggest messes we have are when security is tacked on as an
afterthought. That's when you end up with a large, cumbersome, and somewhat
inappropriate security building block being rammed in heedless of the
consequences.
> Ask anyone who is waiting for the emergency operator's phone
> to ring how much he cares about authentication.
Actually, he may care a lot. Examples abound where exposure of information
about emergency situations is a very serious concern in its own right.
Ned
Received on Fri Jul 13 19:07:52 2001
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST