Subject: AW: [Ecrit] requirements

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 23 Mar 2005 15:30:18 +0100

hi ken, 

please see my comment inline: 

> > authorization is a pretty broad term (and the same is true for
> > "prioritization"). we came across a few authorization issues in our
> > discussion at the ecrit working group meeting. maybe you 
> can explain which
> > requirement you would like to see being outside the scope of 
> > ecrit (or in scope for ieprep). 
> 
> I would not agree that authorization is a broad term within 
> the confines
> of the ietf, or for that matter the ecrit wg.  authorization 
> has specific
> meanings within the IETF (rfc-2906, AAA Authorization requirements is 
> probably a good reference point).  But the point is taken that *how* 
> authorization is applied within ecrit should be more specific.
> 
> I don't recall authorization issues being brought up at the 
> last meeting.
> There were discussions about authentication and integrity 
> with respect to
> location information, both those are different beasts.

i should have been more specific. 

you might remember the presentation by james about validation of location
information. he pointed out that access network provides location
information to the end host in such a way that the emergency response center
is able to verify that a "trusted" access network created the object and
(maybe that this network is indeed reponsible for the area). 

we had some further discussions about this issue in the geopriv working
group. i also consider this as part of the authorization decision. 
there are still a number of issues that need to be investigated and
discussed (and i am not sure that i understood all aspects; the same is
probably true for other folks as well).

> 
> just to loosely recap from my previous message, I think it would be 
> beneficial in one of the requirements documents to state something to 
> the effect that "solutions must not require authorization by (end) 
> users to access 911/999/112-type services".

there will not be a 'must be authenticated' and 'must be authorized'
requirement for 911/etc. calls (what we have heard so far in the
discussions). 

we have also heard that the treatment of emergency calls will be different
depending on the provided atttributes. some calls are better than others. if
you receive a call that does not contain location information nor the
identity of the calling party then you need to give it special treatment. 
some of these attributes, such as the assertion mentioned above, can be used
to compute an authorization decision. 

we should also discuss what the meaning of the authorization decision in the
context you mention (rfc 2906) is. do you think about 'user x is subscribed
i.e. was successfully authenticated' or 'user x has sufficient funds' or
'user x is within a specific geographical area' etc. 
 
i think that most people do not make an assumption about authorization in
this particular area. i would like to know what type of authorization the
ieprep folks consider. 

  The keyword of "must"
> versus "should" is something I'd leave to the prospective author(s).
> 

ciao
\hannes

> -ken

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

---

From: "Ken Carlberg" <[email-masked]>
Date: Wed, 23 Mar 2005 11:15:31 -0500

> (maybe that this network is indeed reponsible for the area). 

James may correct me, but I would say that the scenario you paint above 
is one of authentication and integrity in the "validation of location
information".  I would not consider that a case of authorization, since
I bind that security component with usage of a service.  we may have to 
chalk this up as a case of agreeing to disagree. 

> discussed (and i am not sure that i understood all aspects; 
> the same is probably true for other folks as well).

I have not been following geopriv as closely as I should have, so I can't
comment on this.
 
> requirement for 911/etc. calls (what we have heard so far in the

well, my personal feeling is that users and information should be
authenticated to offer a measure confidence to others as to the
validity of the user and/or the information (eg, location info)
being provided.
 
> this particular area. i would like to know what type of authorization the

in my view, you are mixing components of security.  a service is 
potentialy authorized and information in potentially authenticated 
-- I say potentially because the security portion may not be deployed.

I'm probably being very picky in my terminology, but I would say that
ieprep does not consider a "type of authentication" because that would
correlate to a solution, which is not in the current charter of ieprep.

rfc-3689 from ieprep provides some general requirements with respect
to authorization/integrity/authentication, but the rfc is only a 
baseline starting point from which more specific requirements can
be defined within that group.  it can be debated how effective this
approach was, but that was the direction we took at the time.

-ken

---

From: John Rosenberg <[email-masked]>
Date: Wed, 23 Mar 2005 10:28:10 -0600

All -

I think the basic question being asked deals with two (or more) different 
flavors under the umbrella of Emergency Services. Two existing examples are:

  o B/E911 in the US - does not require that the "caller" be authorized, or 
even identified (most 911 systems today are required to provide anonymous 
access);

  o GETS (Government Emergency Telecommunications Service) in the US, which 
can only be used by authorized users - uses PIN mechanism something like a 
calling card to allow the caller to authenticate.

I think the original e-mail was asking for a specific requirement for ecrit 
(911 service domain) stating that "caller" MUST NOT be required to be 
pre-authorized or to have to authenticate in order to place an emergency 
service (e.g. 911-type) call.

John

------------------------
John Rosenberg
Lucent Technologies
LSS Core Product Mgmt
LSS Emergency Services, GETS, & Regulatory Features Product Mgmt
630-713-7162
[email-masked]