Subject: RE: Notes from Non-meeting

From: [email-masked]
Date: Wed, 20 Mar 2002 14:00:38 -0500

The three priorities identified in Marc's email are absolutely the position
of the National Emergency Number Association (which represents most of the
nations Public Safety providers).

                    Marc Linsner                                                        
                    <mlinsner@cis        To:     "Rosen, Brian"                         
                    co.com>              <[email-masked]>, "'Randy Bush'"      
                                         <[email-masked]>, Henning Schulzrinne           
                    03/20/2002           <[email-masked]>                          
                    12:26 PM             cc:     Adam Shostack                          
                                         <[email-masked]>,                      
                                         [email-masked], (bcc: Nadine B.    
                                         Abbott/Telcordia)                              
                                         Subject:     RE: Notes from Non-meeting        

Using 'SOS' is the practical method!  Attempting to authenticate a PSAP
could 'get in the way' of completing a call to a PSAP.  One would not want
to be the responsible party for that authentication failure.

Lack of caller identity is going to be a problem for the PSAP.  PSAPs want
in this priority:

1. Call completion regardless of adjunct info failures.
2. A callback number (caller identity).
3. The callers location.

-Marc Linsner-

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, March 20, 2002 12:06 PM
To: 'Randy Bush'; Henning Schulzrinne
Cc: Adam Shostack; [email-masked]
Subject: RE: Notes from Non-meeting

Getting the callers identity is a hard problem that is
the subject of current discussion in SIP and not relevant
here.

Authenticating the PSAP cryptographically is not
a practical approach.  Doing it by addressing is
practical, and I assert acceptable in this use case.

Brian

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 11:23 AM
> To: Henning Schulzrinne
> Cc: Adam Shostack; Rosen, Brian; [email-masked]
> Subject: Re: Notes from Non-meeting
>
>
> > The problem is not authenticating the caller, but authenticating the
> > PSAP.
>
> i agree on the latter.  i suspect the psap would like to get
> the caller's
> location if reasonably possible.  i suspect it would also
> like to get the
> caller's identity, but not to check if they are authorized to call.
>
> randy
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Mar 2002 16:43:47 -0500

Because you need a way to vet a PSAP that is acceptable
to the PSAP, and you can't get one that works for all PSAPs, 
and you need a single crypto that all terminals implement
and you can't get that.

Both these problems can be ignored by the IETF.  We often
do, but I'm not interested in unimplemented standards.

It would be nice, for example to create a CA for PSAPs.
Put the root cert of the CA in every phone. Have the 
CA give a cert to every PSAP.  Then a signed message from
a PSAP could be verified to be a bona fide PSAP by the phone.

Sounds easy, and useful.

Completely impractical
	1) No way to create a single CA that every PSAP will
		get a cert from.  Politically impossible (who
		runs the CA), operationally impossible (how
		does the CA determine if an application for a
		cert is a bona fide PSAP)
	2) Impossible to implement
		Can't fit digital signature code in all devices
		
	3) Impractical to use
		takes seconds to verify the signature on the
		processors in the devices. Cannot add a second
		to post dial delay

Anything using public key crypto has these problems.  
Preplaced keys?
Tokens?

However, it is possible to put reasonable mechanisms in
place such that calls to a specific address (sos@anydomain)
gets to the PSAP serving the local domain.  Such mechanisms
may not be perfect, but I think they are adequate.

Brian

> From: Adam Shostack [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 12:25 PM
> To: Rosen, Brian
> Cc: 'Randy Bush'; Henning Schulzrinne; [email-masked]
> Please explain why it is not practical to authenticate a PSAP with
> crypto.   Are you working in the mobile-handset case, the voip case,
> or some other?
> 
> Adam
> 
> 
> On Wed, Mar 20, 2002 at 12:05:32PM -0500, Rosen, Brian wrote:

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 21 Mar 2002 15:54:27 -0500

It would probably be very helpful to start talking about
"attributes sufficient for policy to be applied" and
"some very broad way the purpose of the request"

I understand in a human communication sense what this
means.  I don't know what it means in the protocol
design sense.

Perhaps some examples would be useful.

What I don't understand is how to design a language
for expressing this that has sufficient scope for
all use cases, and yet is implementable anytime soon.
All my experience in such language design is that
it's an np hard problem.

I can have a field with a value, one of whose values
is "emergency call" which would give you in some very broad 
way the purpose of the request" but, in general, I
don't think you can do that.

Similarly, it seems hard to me to describe the form,
let alone the range of values for "attributes sufficient 
for policy to be applied".  When I think of all the
uses we have, trying to define a useful set of
attributes makes my head hurt.  I can try to do something
like "choose one: wife, boss, co-worker, acquaintance,
stranger, INS agent".  I certainly could define a protocol
element  to encode it, an IANA registry to create new
classes, ... but I really don't know how to build a system
to get the right value (ie classify the requestor).

Has anyone built such a protocol with anything like this
kind of problem space?

Where is the basis for thinking we can do this hear and now?

Brian

> From: Randall Gellens [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 11:10 AM
> To: John Morris; Rosen, Brian; [email-masked]
> At 12:04 PM -0500 3/20/02, John Morris wrote:
> 
> >  The two threshold outputs would be:
> >
> >  1)  The structure and elements of a "geopriv object" -- which is 
> > different than the mere "format of location information."  The 
> > object would at a minimum contain a bare bones privacy 
> > instruction/rule, and might also contain location information 
> > (although we will need to address situations in which the privacy 
> > rule and the location information originate in separate places).
> 
> I admit to not being an expert in this area,  but I was thinking that 
> the geopriv object would contain on request a set of attributes 
> sufficient for policy to be applied, and on response the location 
> itself, with attributes describing its state, but not any description 
> of the policy itself.  For example, a location requester could fill 
> in an object with some attributes saying who it is and how much 
> accuracy it requires, and perhaps in some very broad way the purpose 
> of the request.  An entity which was aware of the location and the 
> policy could then apply it, deciding to disclose the location or not, 
> and if so to what accuracy, etc.
> 
> >  2)  A statement of rules that MUST be followed in any 
> > implementation that uses the geopriv object
> 
> This security requirements document can be used for enforcement, to 
> argue that protocol x's use of geopriv does or does not comply, and 
> therefore should or should not be standardized within the IETF.
>

---

From: Ricardo Cuellar <[email-masked]>
Date: Fri, 22 Mar 2002 00:13:53 +0100

Henning Schulzrinne <[email-masked]> schrieb am 21.03.02:
> > This is true: we do not have unique identifier for people. But that doesn’t
> > hinder you to ask where “Jorge” is, although many call me
> > "Ricardo". If the problem is that the name
> > “Jorge” is not unique, well you could replace it by “[email-masked]” or whatever.
> 
> Certainly, but we're not designing a generic directory protocol here.

We do not need a directory. All we need is that when I ask for the
location of target "ABC" the location server is able to know
which "ABC" this is. This "ABC" could be a nickname that I use in
this Location Server. It could also be the hash of a public key.
That gives you on the one hand anonynmity and on the other hand
a proof that you own this "purpose built identifier".
Of course, your pals
would have to know which NAI, e-mail address, nickname or 
"purpose built identifier" you are using, but this is simple.

<snip>

> I didn't say you had to have *exactly one* identifier, but at least one.

This is how I read you original comment:
>make associations with people, buses, taxis or other objects. Wedon't
>have intrinsic identifiers for these objects, certainly not asingle
>one.
 
<snip>
 
> Again, the identifier doesn't have to be unique in the sense that one
> object can have multiple identifiers. But it gets hard if one identifier
> refers to multiple objects that may not always be in the same physical
> place. 

Yes, you are right: this is a requirement! In the corresponding context
of this Location Server (or service) this ID has to point uniquely to one
target. And the target, or the owner, has to be able to prove that he owns this name (in this context). I can start immedialety listing many scenarios where this is true, we do not have to exclude them a-priori. It is one requirement! 

> Also, you need at least one - location information without some
> protocol-representable idea of what it is for is pretty useless. This is
> another argument why this problem gets much easier if you embed location
> information in existing protocols since you usually already have means
> to identify objects of interest.

Still: this doesn't hinder you to ask where "John Morris" is.
And there are other protocols who talk about people and
attributes of people.

Regards,

Jorge
______________________________________________________________________________
100 MB gute Gründe! Jetzt anmelden und FreeMail-Speicher erweitern für
Sprach-, Fax- und Mailnachrichten unter http://club.web.de/?mc=021103