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

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

Because when disasters occur, that information needs to be known by
others.  Even in less that disaster situations, the ability of any PSAP
to determine who the police department serving an area is can be
usefull.

I think you are confusing the operation of the server from the
responsibility of maintaining the information in it.  It's my opinion
that the individual agencies are responsible for defining their service
areas, and while there might be some oversight to make sure the
boundaries don't have gaps and overlaps, it's not a transfer of
responsibility.  I think NENA will publish a mechanism by which an
agency can assert it's boundaries in the database itself.

Brian

> -----Original Message-----
> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Thursday, August 31, 2006 3:48 PM
> To: Rosen, Brian; Andrew Newton
> Cc: [email-masked]
> Subject: RE: [Ecrit] RE: [Geopriv] LoST features
> 
> 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
> 
> 
> > -----Original Message-----
> > 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
> >
> >
> > 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
> >
> 
> *****
> 
> 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
> 

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

---

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

I think I am.

I think a normal query is TLS-with-server-certs, basic or digest auth.
I think the fall-back is query without TLS
I think a PSAP or other non-user querier is TLS-with-client-certs
I don't think a fallback on that would be useful primarily because there
would not be any identity that would work at application layer that
would not also allow TLS to complete. 

You might also be able to use IPSEC at the PSAP.

Brian

> Sent: Thursday, August 31, 2006 5:38 PM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; Rosen, Brian; [email-masked]'
> Subject: Re: [Ecrit] Re: [Geopriv] LoST features
> 
> 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
> 
> Brian Rosen wrote:
> > 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
> >>
> >> 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.
> >>
> >> Andrew Newton 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
> >> Indeed - that's something we implemented locally for our prototype
> >> already. It works quite well.
> >>
> >>
> >>>> (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
>