[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: non-interactive authentications...



On Wed, Aug 19, 1998 at 09:36:01AM -0700, Andrew Morgan wrote:

>> Savochkin Andrey Vladimirovich writes:
>>> Conversation function is introduced to display the prompt and read
>>> the answer in the current environment: via a box in GUI or just
>>> printing the prompt or making an appropriate request to the peer in
>>> the case of a remote session.
>> 
>>> The fact that a plenty of applications using PAM are broken by
>>> design only shows that PAM as it is doesn't satisfy developer's
>>> needs.
	
>> Is this because PAM does not satisfy developer's needs or because
>> someone with a knowledge of PAM has not taken the time to better
>> integrate PAM into an application?

	If a "fully PAMified" daemon/server can't provide 
	compatability with existing clients for a give protocol
	(particularly those that aren't designed for 
	"conversational login" like POP, IMAP, FTP, UUCP) then 
	it is essentially useless.

	At first I thought PAM sounded like a good idea.  As 
	a sysadmin and consultant I'm starting to come to the
	opinion that it will never be adequately implemented.

	Part of it is a matter of expectations and system 
	administration.  If I'm providing FTP service to
	a bunch of users with GUI and menu drive client software
	--- or users using SOCKS or some other proxying system
	and I configure my PAM ftp service to play a game of 
	20 questions with those clients --- I'm an idiot. 

	In that case the requirements (specified by my authenctication
	configuration) are irreconciable with my constraints (that
	"all" existing clients be supported without modification).

	Now, if I (as a user of one of these clients) know in advance
	all of the required information (from my server's configuration)
	and I have some way of encoding that into the "name/password"
	pair that is basically universally supported among existing
	authenticating clients --- then it might still be "reconcilable."

	For example:  if I know that the PAM/FTP configuration on
	fooserver will ask for my name, rank, serial number and a 
	hash of a challenge nonce concatenated with my IP address
	and a shared secret (said challenge nonce to be delived
	via a finger command or something?) perhaps I'd be 
	providing the following to my ftp client's "user" and
	"password" dialog fields:

		Name: name/rank/serialnumber
		Pass: <hash as calculated from separate application>

	
	Frankly I get the feeling that we're trying to over-generalize.
	I'd be happy limiting PAM to allow the sysadmin to plug in new 
	hashing and one-time password modules, set group membership
	based on connection source (tty and IP address) and type, and
	perform various "secondary" authentications (kerberos) 
	automatically while my "password" is "in hand" (obviating 
	the need to separately run "klogin" or whatever).

	(Keep in mind that I know basically nothing about the
	programming --- I'm just reading this and thinking
	"ENOUGH IS ENOUGH!").  

	One thing that's frustrating is that FreeBSD has very clean,
	well-integrated support for traditional Unix, MD5, shadow, and
	S/Key (OPIE) passwords built-in --- DONE!  Finished!  Working!
	Consistently and throughout.

	When are we going to have that?

--
Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []