RE: CompuServe Positions on Passphrases and TLS

>From: 	Peter Lipp[SMTP:plipp@iaik.tu-graz.ac.at]
>
>On Jul 22, 11:09am, Dan Simon wrote:
>> Personally, I consider authentication 
>> to be far too sensitive a task to trust to applications.
>
>Hm, and why? If I play the role of an application programmer, I consider 
>authentication to be far too sensitive a task to trust to the operating 
>system or something similar (;-). Its all a question of standpoint.

I'm not so sure.  From the application programmer's standpoint, is file
access control too sensitive a task to trust to the operating system?

I can think of at least two good reasons for leaving file access control
to the operating system:

1)  Access permissions are normally independent of the application.  If
I want a certain file to be read only by certain people, then I don't
care which application those people may be using; I simply want access
denied them.  It therefore makes sense to control access in a
centralized way.

2)  Access control being a sensitive matter, I would rather have the
operating system try to implement it correctly once than rely on each
application writer to do it correctly every single time.  Eventually,
after all, one of them is bound to get it wrong.

As far as I can tell, both of these reasons apply equally to
authentication (and the latter, at least, applies to authorization as
well).  
>
>Especially in  the Web environment, the server needs to authenticate 
>users, that might not necessarily be authenticated at the operating 
>system level at all, at their system, and may only be authenticated at 
>the application-level, considering the web-server an application. 

>This is the only argument I've heard so far for leaving authorization in the
>hands of the application:  operating systems have not (yet) stepped up to do
>the job.  Now, that's a perfectly good argument for *letting* the application
>do authorization.  But it seems like a very bad argument for *preventing* the
>OS (via TLS, perhaps, in the future) from doing a job that (in my view) it
>should be doing in the first place.
>
>> (Then again, I also consider authorization to be far too sensitive a
>> task to trust to applications; how many operating systems, after all,
>> treat file access control as an application-level matter?)  
>
>You are an operating-systems person, aren't you :-).

No, I'm just a cryptographer who spends far too much of his time naively
berating operating systems people for not doing their job properly.  But
thanks for the compliment.  :^)
> 
>Of course it is the responsibility of the OS to protect the files, but 
>isn't it the Web-Servers responsibility to protect the pages? If we 
>assume a full integration of web-services into the OS, such that there 
>no longer is a web-server per se, your wishes become true of course, and 
>we only have to discuss/specify how a user on Unix authenticates himself 
>to a MS-Windows-NT machine at the OS-level. Fine with me, but is this 
>realistic for now?

Is the TLS model unrealistic?  Authentication of both clients and
servers under TLS has already been implemented in several places in a
manner which makes authentication pretty much invisible to the
application.  This is an important first step, in my view, towards
wresting general authentication out of the hands of applications and
placing it in the OS where it belongs.  That more steps are necessary
doesn't make this one any less welcome.    
>
>Until then, I see that authorization needs to be done at the 
>Server-level. And, if the server does not trust the OS, or TLS, 
>authentication of the user needs to be done there too. I would prefer, 
>for architectural reasons, to have a machine-level authentication of 
>some sort at the transport level, and user-level authentication on the 
>application level. 

I'm not familiar with these "architectural reasons".  If the OS took
care of both, why would that be an "architectural" problem?
>
>
>				Daniel Simon
>				Cryptographer, Microsoft Corp.
>				dansimon@microsoft.com
>

Received on Wednesday, 24 July 1996 17:52:25 UTC