[<<] [<] Page 1 of 3 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Access control
From: Alex Holden ####@####.#### Date: 13 Dec 2000 13:17:43 -0000 Message-Id: <Pine.LNX.4.04.10012131239160.603-100000@hyperspace.linuxhacker.org> 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/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Access control
From: Simon Wood ####@####.#### Date: 13 Dec 2000 14:05:06 -0000 Message-Id: <44632C76B97BD211AF6B00805FADCAB202D7391B@exchange.saltaire.pace.co.uk> > -----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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Access control
From: Alex Holden ####@####.#### Date: 13 Dec 2000 14:40:39 -0000 Message-Id: <Pine.LNX.4.04.10012131427360.632-100000@hyperspace.linuxhacker.org> 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/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Access control
From: Alan Cox ####@####.#### Date: 13 Dec 2000 14:58:07 -0000 Message-Id: <E146DRM-0002sa-00@the-village.bc.nu> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Access control
From: Alex Holden ####@####.#### Date: 14 Dec 2000 01:34:48 -0000 Message-Id: <Pine.LNX.4.04.10012140040560.665-100000@hyperspace.linuxhacker.org> 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/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Access control
From: Alex Holden ####@####.#### Date: 14 Dec 2000 01:47:45 -0000 Message-Id: <Pine.LNX.4.04.10012140132320.665-100000@hyperspace.linuxhacker.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/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Access control
From: Alan Cox ####@####.#### Date: 14 Dec 2000 09:47:24 -0000 Message-Id: <E146V4D-00043J-00@the-village.bc.nu> > 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 ? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Access control
From: Alex Holden ####@####.#### Date: 14 Dec 2000 10:19:24 -0000 Message-Id: <Pine.LNX.4.04.10012140959510.603-100000@hyperspace.linuxhacker.org> 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/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Access control
From: Alan Cox ####@####.#### Date: 14 Dec 2000 10:42:07 -0000 Message-Id: <E146VvB-00047L-00@the-village.bc.nu> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 3 [>] [>>] |