Subject: AW: [Ecrit] requirements

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 23 Mar 2005 19:24:43 +0100

hi ken, 

please see my comments inline:

> > 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). 
> 
> 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. 

maybe we just have a terminology problem here. i think that we need to
provide authentication in order to provide authorization and accountability.
in many cases authentication alone is insufficient. 

btw, i avoid using the term service since it has so many different meanings
that it is quite like that we talk past each other. 

> 
> > 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).
> 
> I have not been following geopriv as closely as I should 
> have, so I can't
> comment on this.

that's fine. based on the history and the relationship with geopriv we will
reuse their work. 

>  
> > 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). 
> 
> 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.

i think we cannot mandate what decisions are made in emergency response
centers (since this is not our business). 
what we can do is to provide solutions that they would be able to use, if
they want. 

>  
> > 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. 
> 
> 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.

with regard to authorization i like to refer to rfc 2828 and with regard to
authentication to the handbook of applied cryptography (since they
differentiate entity and data origin authentication). 

> 
> I'm probably being very picky in my terminology,

that's very good. i had the impression that we have a mess with regard to
terminology. we need to get it fixed soon.  

>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.

i will certainly read your document. 

ciao
hannes

> -ken

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