Subject: [Ecrit] RE: [Geopriv] LoST features

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 31 Aug 2006 15:09:44 -0400

You attempt to create a TLS connection.  If it works, you ask, and the
answer depends on who you are.  If you supply no credentials you are
considered a "user".  If you can't establish a TLS connection, retry
without it; you will be considered a "user".  "users" get the normal
public answer.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, August 31, 2006 3:06 PM
> To: Brian Rosen
> Cc: Rosen, Brian; [email-masked]'
> Subject: Re: [Geopriv] LoST features
> 
> Brian Rosen wrote:
> > Actually, I believe it works the way you want it to.
> >
> > You always have what amounts to a default answer: the answer you
give to
> an
> > endpoint.  That has to work with no authentication.
> 
> How does the LoST application layer have the chance to return a
default
> answer if it never receives the query?
> 
> -andy

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Aug 2006 15:27:54 -0400

> without it; you will be considered a "user".  "users" get the normal

This whole idea about retrying, especially for a legitimate case, seems 
wrong.  The better advice is to never pass a client cert unless you are a 
user.  Unfortunately, there are TLS libraries that do not make a distinction 
between "the client has no certificate" and the "client cannot be 
authenticated".

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 31 Aug 2006 15:47:45 -0400

Why wouldn't each 911 center (or group of geographically related 911
centers) just maintain their own local LoST server with the detailed
information? This server would always require
authentication/authorization. Only PSAPs would be authorized to query
it. The PSAP would probably just maintain an open session to it at all
times.

This LoST server woudn't be discoverable by end devices, but would be
known to all PSAPs that can query it. 

In this case, the LoST protocol is untouched by and unaware of
permissions.

This would also simplify administration of such info. From the
perspective of the US, I could see a state needing to manage the LoST
information that defined PSAP boundaries, or 911 jurisdications. But the
state would want the local 911 jurisdications to define (and maintain
definitions for) boundaries for fire and police precincts. By lumping
them all in a single server, administration of data administrators
becomes much more complex. Or else localities lose some control, by
always being forced to go through a centralized state administrator when
changes are needed.

It seems to me to be much simpler to maintain separate servers. But I
could be looking at this all wrong.
Barbara

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, August 31, 2006 3:10 PM
> To: Andrew Newton; Brian Rosen
> Cc: [email-masked]
> Subject: [Ecrit] RE: [Geopriv] LoST features
> 
> 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Aug 2006 17:51:08 -0400

> could be looking at this all wrong.

I think this is exactly right. Simple and easy. I'd only add that it 
doesn't even have to be a physically separate server; HTTP virtual 
hosting will do just fine.

There are plenty of real complications; I don't think we need to add 
this as an artificial one.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 31 Aug 2006 15:50:09 -0700

>Barbara

I tend to agree with Barbara, but I would go further:  you seem to be asking
two different questions.  From a protocol perspective, trying to distinguish
between them by who asks seems pretty difficult to get right, where simply
using the protocol semantics to ask different questions seems easier.

Instead of urn:service:sos.fire, for example, you might look up
urn:service:emergency-infrastructure.fire . Sos.fire tells you who to
say "help" to; "emergency-infrastructure.fire", for example, might tell
authorized folks how to contact the correct part of the emergency
infrastructure in order to invoke the fire service.

Having those lost service queries answered by different servers
pretty much automatically makes sense, as well.

Two cents, no hats on,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 31 Aug 2006 18:20:58 -0500

I think that this the right solution, given that we went to great
lengths not to include any level of identity (with regard to the asking
party) in LoST. If we re-introduce identity based decision making then
some people might be inclined to ask for reference support again.. ;)

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 1 September 2006 7:51 AM
> To: Stark, Barbara
> Cc: [email-masked]
> Subject: Re: [Ecrit] RE: [Geopriv] LoST features
> 
> >

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Aug 2006 18:02:32 -0400

In my reply to Barbara, I suggested that you can't predict in advance who
will need the data, and therefore it should be available to any authorized
entity.  I will amplify my response to say that I do believe the PSAP will
maintain a copy of the data, so that the query wouldn't normally go beyond
its local copy.  I think we're supporting many non-authoritative local
copies of the database.

Brian

> Sent: Thursday, August 31, 2006 5:51 PM
> To: Stark, Barbara
> Cc: [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Aug 2006 20:47:06 -0400

> its local copy.  I think we're supporting many non-authoritative local

Brian,

I'm finding this whole idea of authentication to find a PSAP URI to  
smack against the very purpose we created this working group.  If we  
want private little clubs of people who are only allowed access to  
this data, we don't need a unifying protocol or requirements that say  
"The mapping protocol MUST support interaction between the client and  
server where no enrollment to a mapping service exists or is  
required." or "The mapping protocol MUST NOT require the true  
identity of the target for which the location information is  
attributed."  Group A can do it over LDAP.  Group B can do it over  
FTP.  And Group C can just fall back to the PSTN.

Second, the idea of engineering a system where we know the vast  
majority of queries will have to "retry" is just bad practice.  It's  
like structural engineers designing in two roofs for a house because  
they have a pretty good idea that the first one will collapse.  It  
means your servers will reach peak load much faster than if you just  
engineered the system properly.  It also violates the spirit of one  
of our requirements: Ma17.  Minimal additional delay: Mapping  
protocol execution SHOULD minimize the amount of delay within the  
overall call-setup time.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Aug 2006 22:02:33 -0400

On Aug 31, 2006, at 9:27 PM, Brian Rosen wrote:
> I do want to preface my answer with: if IETF doesn't want to do  
> this, it's
> okay, we can meet our needs in NENA in a couple of ways.  This just  
> seems to
> be efficient.

In this case, I'd rather you do that.

> Now the original, and defining need for LoST is for an end host to  
> get the
> URI to send its emergency calls to.  I don't want anything to  
> complicate
> that.

You mean like user authentication.

> The vast majority of queries are expected to successfully establish  
> TLS
> connections using basic or digest authentication and server certs.   
> It ought
> to work all the time.  However, you and I know that it will never  
> be thus,
> and so we need a backup, which should rarely be needed, but might be.

Exactly what do you plan on doing?  Publishing the user id and  
password in an RFC?  That's the only way to expect every UA and first- 
hop proxy to authenticate to a LoST server.

> We NEED to protect the query.  I can't imagine designing a system  
> designed
> for an end host to send its location in the clear for any purpose.

I don't see much reason to design a system where the end host expects  
to fail authentication.  And regarding this noble of idea of  
protecting my location at the risk of my life, I'd rather you not.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Aug 2006 23:19:02 -0400

> I don't see much reason to design a system where the end host  
> expects to fail authentication.  And regarding this noble of idea  
> of protecting my location at the risk of my life, I'd rather you not.

I'm confused by this discussion. Are we discussing

(1) protecting privacy of LoST queries for regular PSAP URLs?

(2) protecting access to emergency-infrastructure information ("what  
is the police commander URL for this point")?

For (1), I just don't see the big deal with normal server-side TLS,  
as this query will occur well before the emergency in almost all  
cases and is thus not time-critical. This is also where privacy seems  
to matter most, since most people would probably not want to be  
tracked continuously. (The tracking isn't really continuous since  
you'd only do a query when entering a new coverage region. For most  
people, that's maybe once a day, during their commute.)

For queries at the point of an emergency call, TLS with server-side  
authentication seems harmless, as long as the client can decide to  
ignore cert validation failures at that time. There is a low risk of  
a MIM attack, but that's a reasonable trade-off, given the alternatives.

But I'm probably completely missing the problem we're trying to solve  
here...

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Aug 2006 21:27:31 -0400

Andrew

I'm not following you.

I do want to preface my answer with: if IETF doesn't want to do this, it's
okay, we can meet our needs in NENA in a couple of ways.  This just seems to
be efficient.

Now the original, and defining need for LoST is for an end host to get the
URI to send its emergency calls to.  I don't want anything to complicate
that.  If I can use the mechanisms for other purposes that are close enough
that it IS appropriate to use the same mechanism, fine, but I am mindful of
the IETF philosophy to have protocols do one thing well, rather than many
things poorly.

I don't see any private clubs here.  I think PSAPs and other entities inside
what we call the Emergency Services IP Network will indeed have access to
information that is not generally available, but I think we can engineer
that aspect to not affect the general service we are defining.  Remember
that the only thing I asked for was a line of text that said "The answer may
depend on who asks and the identity used to establish the security
connection (TLS) may be used for the identity to make such a decision".
That's all I'm looking for.  There certainly are other, more commercial uses
for a location based routing engine that I HOPE we can use LoST for that
would have similar needs.

The vast majority of queries are expected to successfully establish TLS
connections using basic or digest authentication and server certs.  It ought
to work all the time.  However, you and I know that it will never be thus,
and so we need a backup, which should rarely be needed, but might be.

We NEED to protect the query.  I can't imagine designing a system designed
for an end host to send its location in the clear for any purpose.

Brian

> Sent: Thursday, August 31, 2006 8:47 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: How many people do we plan to kill
> 
>