nanogui: Thread: Access control

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/

> -----Original Message-----
> From:	Alex Holden ####@####.####
> Sent:	Wednesday, December 13, 2000 1:15 PM
> To:	####@####.####
> Subject:	Access control
> 
> 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.
> 
	[Simon Wood] 
	Personally I have no need to make nano-x network/multi user capable, though I expect others (like your self) want these features. Is it possible to #def the code so that this option(s) can be excluded in the build process so that I don't have to carry the extra code around.

	I assume that clients that want to use this feature(s) will have to have some way of being informed that they are to communicate with a foreign server. Will existing clients HAVE to be re-written/re-compiled/neither, even if they don't uses this feature(s)???

	Simon W. 

On Wed, 13 Dec 2000, Simon Wood wrote:
> it possible to #def the code so that this option(s) can be excluded i

Yes, of course it will be optional. Both the access control and the remote
networking support.

> 	I assume that clients that want to use this feature(s) will have
> to have some way of being informed that they are to communicate with a
> foreign server. Will existing clients HAVE to be 
> re-written/re-compiled/neither, even if they don't uses this
> feature(s)???

The nano-X protocol hasn't been frozen yet, so it's subject to change from
version to version anyway. An old client might work with a new server,
or it might not- my reccomendation would be to always rebuild your clients
when a new server is released until such a time as we consider the API to
be "stable" and freeze the protocol. Other than that, the clients
shouldn't generally need any changes.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

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

If the network is secure then any old plaintext is fine. If the network is
not secure then you need full crypto or its only washing over the problem
not fixing it.

Is there a reason for not keeping the problem external ?

Say something like

	export NANODISPLAY=application:/usr/sbin/nanox-crypto-forwarder

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: ####@####.####

On Wed, 13 Dec 2000, Alan Cox wrote:
> If the network is secure then any old plaintext is fine. If the network is
> not secure then you need full crypto or its only washing over the problem
> not fixing it.

How about a challenge-response mechanism using HMAC? rfc2104.html talks
about a cracker needing to acquire roughly 2**64 responses to a known
plaintext to be able to deduce the secret key (2**80 if SHA1 is used
instead of MD5). Would I be right in thinking that they mean that with a 
challenge response mechanism which uses this method to generate the hash
and random keys of a sufficient length, the secret is basically 
uncrackable within a reasonable timescale? It isn't actually encryption,
just a keyed hash, but that doesn't matter because we don't need to
decrypt the data which was hashed (just check that we get back the same
hash that we generated locally). It does require both the client and the
server to have a copy of the same plaintext private key though.

I'm not trying to implement encryption of the session itself (that could
be done via ssh if you need it and are prepared to pay the code size and 
performance penalties); just to prevent a cracker from being able to snoop
the password and then use the remote access capability to gain control of
the machine.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

On Wed, 13 Dec 2000, Jordan Crouse wrote:
> 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 

It would be nice to be able to run a graphical monitoring program on
a headless embedded processor sat in the middle of a production line
somewhere from the comfort of your desk though...

Actually the thing that spurred me to get around to solving the 
authentication problem was a review I read a couple of days ago comparing
X to Nano-X, which listed the main advantage of X as being that it was
network capable. I could have given Nano-X TCP/IP networking right at the
beginning when I first wrote the client/server code, but I decided against
it at the time because of the difficulty of providing a secure
authentication (and I don't consider X's XAddHost() stuff secure) without
increasing the code size beyond all recognition (if done wrong, you could 
easily more than double the size of the server). The code to use a TCP/IP
instead of a Unix domain socket itself is trivial.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

> I'm not trying to implement encryption of the session itself (that could
> be done via ssh if you need it and are prepared to pay the code size and 
> performance penalties); just to prevent a cracker from being able to snoop
> the password and then use the remote access capability to gain control of
> the machine.

If the cracker can snoop the password he can do session takeover without
starting a new session. So how does it help ?

On Thu, 14 Dec 2000, Alan Cox wrote:
> If the cracker can snoop the password he can do session takeover without
> starting a new session. So how does it help ?

I thought the cracker had to have control of an intermediate router to
do that (as opposed to just being able to listen to the traffic on the
line)?

So you're saying that all the existing protocols which use hashed or
encrypted authentication but not actual session encryption (kerberos,
etc.) are no better than ones which use plaintext authentication?

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

> So you're saying that all the existing protocols which use hashed or
> encrypted authentication but not actual session encryption (kerberos,
> etc.) are no better than ones which use plaintext authentication?

Unless they use the hash to protect all the data - pretty much.

What does work with your challenge/response type scheme is to always send

MD5sum(data_block, secret) with each 'packet' or 'packet group'. For 
performance you may want to bundle stuff and send a block of messages together
with one MD5 hash for the set.

I used to use this for a pile of code because it was authentication not
encryption and therefore had no (old) US export issues. I still use a variant
of it for giving web browsers tamperproof cookies