Subject:
Re: Access control
From:
Jordan Crouse ####@####.####
Date:
13 Dec 2000 23:34:50 -0000
Message-Id: <3A379920.845E5DFA@censoft.com>
Sounds good, but just make sure that this stays *very* optional and
hidden to the current
clients (ie - all the authentication and handling should go on in the
client library).
I believe that
most PDA implentations will continue to use a local server (at least
until a good wireless solution gets better - I don't
even want to think about doing graphics on a PDA without 10 megs - but
then again, I'm spoiled). I
would hate to have to add another level of complexity into the scene,
not to mention the lack of stable
networking on some of these kernels (MIPS??). Alan Cox may overrule me
on this, but I would think across the board,
local sockets (like the ones we are using) are generally more stable
these embedded kernels than TCP/IP sockets.
Comments?
Jordan
Alex Holden wrote:
>
> Hi, I've been looking at what it would take to make nano-X network
> capable (as an optional config choice of course). The stumbling block is
> access control- I could make it network capable without any access control
> whatsoever in about an hour, but I think that would be a really bad idea.
> It seems we have several options for an access control policy:
>
> Host based access modelled after X11's XAddHost(). Two main problems with
> this; it's succeptible to address spoofing, and any user on a host which
> is on the access list can access the server. I don't like this method and
> don't think it's worth implementing.
>
> Plaintext password based access. Basically this would use the server
> machine's local password mechanism to provide a simple authentication
> method. Inherently succeptible to packet sniffer based attacks, but no
> more so than FTP, telnet, POP3, etc. I think it would be a good idea to
> include this as an option (which can be disabled) for applications where
> the network is known to be secure, and code size limitations prevent the
> user from using a more secure algorithm.
>
> Hashed challenge response based access. This has the advantage that an
> implementation of it would be very small, several public domain
> implementations of common hash algorithms such as MD5 exist, and it does
> prevent plaintext passwords from being sent over the wire. It has the
> disadvantage that it's not cryptographically strong. This method is used
> by APOP, CHAP, and some other common protocols. I like the simplicity of
> this method, but I've no idea exactly how strong it is, and whether it
> would provide an acceptable level of security or not. Remember that I'm
> not talking about encrypting the data which goes across the link after
> authentication, just providing a method of access control which doesn't
> require you to send your account password over the wire as plaintext- if
> you were planning to use the system over a public network you'd be better
> off tunneling the whole thing through SSH or similar anyway.
>
> Private key encryption based authentication using DES or similar. This
> method is relatively simple, and I believe it should be cryptographically
> secure. I believe this involves having a private key stored on both the
> client and the server, and using that to send a challenge/response (with
> the response containing the password) in an encrypted form. This has the
> disadvantage that if somebody manages to gets hold of the private key from
> one of the clients, they can use it to snoop for passwords.
>
> Public key encryption based authentication, similar to SSH. This is quite
> big and complex, but should be the most secure. If I understand it right,
> each client and server has it's own public and private key, and these are
> used to exchange some kind of complex challenge/response protocol. To be
> honest I don't think it's worth the code size and complexity penalty
> required to implement this- if you need this level of security, tunnel the
> data through a SSH pipe instead.
>
> So, to sum up, I'm currently planning to implement a password based
> authentication method which can optionally use an MD5 hash algorithm to
> avoid sending the passwords as plaintext. Oh, and the authentication will
> be seperate from the TCP/IP networking support, so it should be possible
> to open up the permissions on the named socket and use the authentication
> in local mode too if you want.
>
> --
> ------- Alex Holden -------
> http://www.linuxhacker.org/
> http://www.robogeeks.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
