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

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Aug 2006 14:11:55 -0400

Is LoST a GEOPRIV item?  My comments follow your message for the sake of 
people on the ECRIT list.

Rosen, Brian wrote:
> In NENA, we're talking about using LoST as a way for a PSAP to get the
> right responders for a location.  In North America, there is one number
> (in most, but not all jurisdictions), 9-1-1.  If you ask for the
> sos.police service, with a location in New York City, you will be given
> the sos, 9-1-1 response.  
> 
> What we would like is if the PSAP makes the same query, it would get the
> URI for NYPD. 
> 
> It might also be used for a multilevel routing decision, where a user
> query got you to a high level (say, a state-level) ESRP, which reran the
> query itself (same service, same location) to get the actual URI of the
> PSAP.
> 
> This means (only) that the response depends on the identity of who is
> asking.
> 
> I have advocated that the query could be restricted to a secure
> connection (TLS or IPSEC), and the authentication information for that
> could be used to make an authorization decision on what to return.
> 
> Does this seem reasonable enough that the document could say the
> response MAY depend on the identity of the requestor, and the identity
> MAY be the identity supplied for a secure connection to the server?  I'm
> not sure we need anything else.

I'm not to wild about the concept in general, but I'm certainly against how 
you want to implement it.  You are counting on the TLS stack to do client 
authentication, but what this means to a lot of TLS libraries is that no 
client authentication results in no query.  I do not believe that is a 
desirable behavior.  In fact, I thought we had as a requirement that LoST 
queries can come from anywhere... and as we all should know by now, there is 
no universal PKI.

I'd rather an optional authentication id be passed in with the query, from 
which the LoST server can make any special authorization decisions.

-andy

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

---

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Aug 2006 14:19:38 -0400

The PSAP really is going to be authenticated to its local LoST service.
There is no PKI problem there.  

So, the answer depends on who you are, but if we don't know who you are, you
get an answer, and it's the appropriate answer for a random querier.

We CAN have another identity parameter; I just don't think we need it, and I
especially think if the security authentication fails, the identity check
would fail for the same reason.

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, August 31, 2006 2:12 PM
> To: Rosen, Brian
> Cc: GEOPRIV; [email-masked]
> Subject: Re: [Geopriv] LoST features
> 
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

---

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

I'm dropping GEOPRIV, since that doesn't seem like the right venue.

I agree with Andrew, but I'm not sure Brian actually intended to imply 
TLS-with-client-certs. A much more common solution would be to simply 
use TLS-with-server-certs and HTTP basic or digest authentication. This 
requires no extra LoST effort, is trivial to implement in any web server 
or application platform and avoids the PKI issues.

The only problem is that the query might need to go to a different 
virtual server (if you don't want to go through a 
ask-for-auth-and-then-fail-to-public-information approach), but that 
seems mainly a configuration problem.

>> right responders for a location.  In North America, there is one number

Indeed - that's something we implemented locally for our prototype 
already. It works quite well.

> I'm not to wild about the concept in general, but I'm certainly against 
> how you want to implement it.  You are counting on the TLS stack to do 
> client authentication, but what this means to a lot of TLS libraries is 
> that no client authentication results in no query.  I do not believe 
> that is a desirable behavior.  In fact, I thought we had as a 
> requirement that LoST queries can come from anywhere... and as we all 
> should know by now, there is no universal PKI.
> 
> I'd rather an optional authentication id be passed in with the query, 
> from which the LoST server can make any special authorization decisions.
> 
> -andy
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Aug 2006 17:32:38 -0400

> seems mainly a configuration problem.

That method requires an extra transaction, though not as heavy-weight as 
retry from step 1 without authentication.  And again, depending on the 
libraries in use, this may not have the desired affect.  Passing of 
credentials from the HTTP layer to the CGI layer is implementation dependent 
and not always implemented to allow the request to pass through even if the 
credentials cannot be validated.  Inclusion in the POST data is guaranteed 
to reach the proper layer and does not require an extra round trip.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Aug 2006 17:33:30 -0400

Yes, I agree with Henning.  TLS-with-server-certs would be how a normal user
gets security on a LoST query.  A PSAP would have a client cert, and then
would be given different answers from a user.  A failure to establish TLS
connections would be accepted, but the answers would be the same as
TLS-with-server-certs.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, August 31, 2006 5:07 PM
> To: Andrew Newton
> Cc: Rosen, Brian; [email-masked]
> Subject: [Ecrit] Re: [Geopriv] LoST features
>

---

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

Since we're not talking about high-security applications here, a simple 
HTTP Cookie mechanism will also work just fine. Also, with Basic, after 
the first request, there shouldn't be a need to re-challenge, so there's 
no real need for a dual transaction for the PSAP.

In other words, I think HTTP offers plenty of tools to do what we need.

With the separate (virtual) server, there is also no fallback case to 
worry about.

Andrew Newton wrote:
>> use TLS-with-server-certs and HTTP basic or digest authentication. 
>> This requires no extra LoST effort, is trivial to implement in any web 
>> server or application platform and avoids the PKI issues.
>>
> credentials from the HTTP layer to the CGI layer is implementation 
> dependent and not always implemented to allow the request to pass 
> through even if the credentials cannot be validated.  Inclusion in the 
> POST data is guaranteed to reach the proper layer and does not require 
> an extra round trip.
> 
> -andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Aug 2006 17:38:21 -0400

Brian,

Are you reading the same thread I am?  Because it would appear that you are 
not saying the same thing Henning just said, and it would appear you haven't 
addressed the concern I mentioned.

-andy