nanogui: Thread: Access control

Alex Holden wrote:

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

I'm no crypto expert, as my comment below may quickly reveal...:-)

But, I think a hashed challenge is just as strong as any other
authentication as long as the hash function is good, and the
random number source on the server is "truly" random.

The MD5 is AFAIK not the strongest hash invented, but I'd personally
prefer a 128 bit MD5 hash over a 56 bit DES.  When using DES,
you would also need a challenge type of algorithm, using DES
for the "irreversible scrambling".

I don't think the flexibility of public key encryption would be
very usefull in most circumstances, e.g. most often you want a
pool of clients to be able to connect.  The process of
distributing the keys/passwords in advance and guarding them
afterwards from compromise would be much the same independent of
the authentication method used.

Public key encryption is also dependant on a good random number
generator.

Regards,
Morten Rolland

On Thu, 14 Dec 2000, Alan Cox wrote:
> > 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.

Okay, so it looks like encryption of the session data is a must for any
real level of security. How about this, we have a two level system:

* No encryption, plaintext passwords using the ordinary Unix password
mechanism (assumes the network is fully secure).
* Full encryption of both authentication and session.

However, as to my previous idea of providing the encryption via ssh:
[alex@hyperspace alex]$ ls -l /usr/sbin/sshd
-rwxr-xr-x   1 root     root       622900 Nov  8 15:56 /usr/sbin/sshd
[alex@hyperspace alex]$ ls -l /usr/bin/ssh
-rws--x--x   1 root     root       663300 Nov  8 15:56 /usr/bin/ssh

Those are stripped binaries, and they also depend on several other
libaries.

So I'm currently thinking of implementing an encryption layer based on TEA  
(Tiny Encryption Algorithm). TEA is an incredibly small (748 bytes on
386), very fast (faster than IDEA), very strong (much stronger than DES)
128 bit private key cypher which isn't patented and has a completely
public domain C reference implementation available.
See http://vader.brad.ac.uk/tea/tea.shtml for more information.

By the way, I realise that if we put this in the main distribution itself,
it would prevent people in countries with draconian encryption import
regulations (like France) from downloading it, and might not be exportable
from the US (I'm not sure what the exact situation with regard to that
is at the moment) so it'll be available as a seperate archive hosted in
the UK instead. I assume there are no regulations preventing people from
downloading software which contains hooks for making use of encryption
code but not the encryption code itself?

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

As a crypto expert - the administrative (and potential size) issues are
making this look a bigger job than should be undertaken for a tiny GUI such
as Microwindows.

A suggestion:
    Most things that can be done inside an application can also be done by
wrapping it.
    Why not convert Microwindows unix domain socket to a real socket and
then use a separate tool/program/utility to wrap and protect the connection.
That way the microwindows core code is not burdened with something as
off-topic as the crypto world and the strength of the final solution can be
controlled by the strength of the separate wrapper that is used.
This is similar to using for example an SSH tunnel to protect an otherwise
insecure service.

The one requirement I would suggest is that the network listener within
microwindows should be able to specify the listen address.
For example ...

Listen-on=127.0.0.1:1500
Talk-to=127.0.0.1:3000-3500

Would enable you to set up a secure system where your security wrapper
talked to microwindows on port 1500 where the security wrapper ran on the
same machine using ports 3000 - 3500 when talking to microwindows.

Listen-on=*:1500
Talk-to=*:*

Would conversely talk to anyone making a connection to microwindows on port
1500.

Now you have the best of all worlds,
    a) A very simple solution for microwindows
    b) Non-pollution of the intent and code base of microwindows
    c) Customisable level of security depending on the situational
requirements
    d) Potential to use already available and tested security solutions.

Hope this helps,

----- Original Message -----
From: "Alex Holden" ####@####.####
To: ####@####.####
Sent: Thursday, December 14, 2000 9:53 PM
Subject: Re: Access control


> On Thu, 14 Dec 2000, Alan Cox wrote:
> > > 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.
>
> Okay, so it looks like encryption of the session data is a must for any
> real level of security. How about this, we have a two level system:
>
> * No encryption, plaintext passwords using the ordinary Unix password
> mechanism (assumes the network is fully secure).
> * Full encryption of both authentication and session.
>
> However, as to my previous idea of providing the encryption via ssh:
> [alex@hyperspace alex]$ ls -l /usr/sbin/sshd
> -rwxr-xr-x   1 root     root       622900 Nov  8 15:56 /usr/sbin/sshd
> [alex@hyperspace alex]$ ls -l /usr/bin/ssh
> -rws--x--x   1 root     root       663300 Nov  8 15:56 /usr/bin/ssh
>
> Those are stripped binaries, and they also depend on several other
> libaries.
>
> So I'm currently thinking of implementing an encryption layer based on TEA
> (Tiny Encryption Algorithm). TEA is an incredibly small (748 bytes on
> 386), very fast (faster than IDEA), very strong (much stronger than DES)
> 128 bit private key cypher which isn't patented and has a completely
> public domain C reference implementation available.
> See http://vader.brad.ac.uk/tea/tea.shtml for more information.
>
> By the way, I realise that if we put this in the main distribution itself,
> it would prevent people in countries with draconian encryption import
> regulations (like France) from downloading it, and might not be exportable
> from the US (I'm not sure what the exact situation with regard to that
> is at the moment) so it'll be available as a seperate archive hosted in
> the UK instead. I assume there are no regulations preventing people from
> downloading software which contains hooks for making use of encryption
> code but not the encryption code itself?
>
> --
> ------- Alex Holden -------
> http://www.linuxhacker.org/
>  http://www.robogeeks.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

On Thu, 14 Dec 2000, Andrew Hannam wrote:
> This is similar to using for example an SSH tunnel to protect an otherwise
> insecure service.

You could still use it in unencrypted mode then wrap it in SSH externally
if you didn't trust TEA and were prepared to spend close to a meg of flash
and several hundred KB of RAM on it.

Anyway, enough talk- I'm going to shut up and implement it now.

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

> it would prevent people in countries with draconian encryption import
> regulations (like France) from downloading it, and might not be exportable

You are out of date on France, they got the message.

> from the US (I'm not sure what the exact situation with regard to that
> is at the moment) so it'll be available as a seperate archive hosted in
> the UK instead. I assume there are no regulations preventing people from
> downloading software which contains hooks for making use of encryption
> code but not the encryption code itself?

The US government counts crypto hooks as crypto. They are such fun folk. 
Distribution of crypto from the US is now pretty trivial though

: Now you have the best of all worlds,
:     a) A very simple solution for microwindows
:     b) Non-pollution of the intent and code base of microwindows
:     c) Customisable level of security depending on the situational
: requirements
:     d) Potential to use already available and tested security solutions.


I like Andrew's suggestions.

Regards,

Greg

Ok, I have a question.   Other than trying to run a session across the
internet or another unprotected network, what would be the use of adding
security to the system?  Wouldn't it be better to leave the security to a
seperate piece of hardware by running your microwindows session inside a
protected network? 

I admit that I am far from a security expert, but it seems to me that adding
md5 encryption on all transmissions would severly tax a minimal resource
platform that microwindows is written for.

Thanks.

Tim Gray

(PS.  If I am way off here feel free to flame. :-)

On Fri, 15 Dec 2000, Gray, Tim wrote:
> Ok, I have a question.   Other than trying to run a session across the
> internet or another unprotected network, what would be the use of adding
> security to the system?  Wouldn't it be better to leave the security to a
> seperate piece of hardware by running your microwindows session inside a
> protected network? 

It's very difficult and expensive to ensure that a network is 100%
physically secure (ie. there's no point where somebody could install a 
tap without it being immediately detected) over any significant distance.
Arguably strong encryption and the clock cycles to run it is almost free
in comparison. I'm sure there will be people who want to use Nano-X in a
networked situation, and I would say it's likely that a significant number
of those will be running on an insecure network and will want to protect
against crackers from being able to take control of their machine
remotely. Using strong encryption both protects against unauthorised
access and has the additional advantage of preventing people from being
able to snoop the traffic between the application and the server. Consider
when PDAs with high speed wireless Internet access start to get widely
available and portable, and you want to be able to run graphical
applications on your high powered (but non portable) server with the PDA
as the display...

> I admit that I am far from a security expert, but it seems to me that adding
> md5 encryption on all transmissions would severly tax a minimal resource
> platform that microwindows is written for.

MD5 is a hash algorithm, not encryption. It is possible to do
authentication using hash algorithms and this would be really nice
because it's simple and only incurs an overhead at connection time, but
unfortunately as Alan pointed out it isn't really much use because it's
possible to hijack a TCP session after the authentication has already
taken place. I'm actually writing a tiny encryption suite based on TEA
(Tiny Encryption Algorithm). So far I've done a key generator and a file
encryption and decryption program (I tried to announce it to Freshmeat
last night but it was down at the time), and I'm working on a set of
network forwarding programs. The algorithm is actually pretty fast- my
old P166 can encrypt and decrypt at about 760KB/s. I think it will be 
usably fast on even very slow machines, and the memory and flash usage is
trivial.

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

Thanks,  That's clears it up for me. I was at a loss in understanding how
things came together.
 
 

-----Original Message-----
From: Alex Holden ####@####.####
Sent: Friday, December 15, 2000 12:30 PM
To: Gray, Tim
Cc: ####@####.####
Subject: RE: Access control


On Fri, 15 Dec 2000, Gray, Tim wrote:
> Ok, I have a question.   Other than trying to run a session across the
> internet or another unprotected network, what would be the use of adding
> security to the system?  Wouldn't it be better to leave the security to a
> seperate piece of hardware by running your microwindows session inside a
> protected network? 

It's very difficult and expensive to ensure that a network is 100%
physically secure (ie. there's no point where somebody could install a 
tap without it being immediately detected) over any significant distance.
Arguably strong encryption and the clock cycles to run it is almost free
in comparison. I'm sure there will be people who want to use Nano-X in a
networked situation, and I would say it's likely that a significant number
of those will be running on an insecure network and will want to protect
against crackers from being able to take control of their machine
remotely. Using strong encryption both protects against unauthorised
access and has the additional advantage of preventing people from being
able to snoop the traffic between the application and the server. Consider
when PDAs with high speed wireless Internet access start to get widely
available and portable, and you want to be able to run graphical
applications on your high powered (but non portable) server with the PDA
as the display...

> I admit that I am far from a security expert, but it seems to me that
adding
> md5 encryption on all transmissions would severly tax a minimal resource
> platform that microwindows is written for.

MD5 is a hash algorithm, not encryption. It is possible to do
authentication using hash algorithms and this would be really nice
because it's simple and only incurs an overhead at connection time, but
unfortunately as Alan pointed out it isn't really much use because it's
possible to hijack a TCP session after the authentication has already
taken place. I'm actually writing a tiny encryption suite based on TEA
(Tiny Encryption Algorithm). So far I've done a key generator and a file
encryption and decryption program (I tried to announce it to Freshmeat
last night but it was down at the time), and I'm working on a set of
network forwarding programs. The algorithm is actually pretty fast- my
old P166 can encrypt and decrypt at about 760KB/s. I think it will be 
usably fast on even very slow machines, and the memory and flash usage is
trivial.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

Do you even have to change the interface from a unix domain socket? I 
would think you could just have 'nxsshd' open the unix socket.

Andrew Hannam wrote:

> As a crypto expert - the administrative (and potential size) issues are
> making this look a bigger job than should be undertaken for a tiny GUI such
> as Microwindows.
> 
> A suggestion:
>     Most things that can be done inside an application can also be done by
> wrapping it.
>     Why not convert Microwindows unix domain socket to a real socket and
> then use a separate tool/program/utility to wrap and protect the connection.
> That way the microwindows core code is not burdened with something as
> off-topic as the crypto world and the strength of the final solution can be
> controlled by the strength of the separate wrapper that is used.
> This is similar to using for example an SSH tunnel to protect an otherwise
> insecure service.
> 
> The one requirement I would suggest is that the network listener within
> microwindows should be able to specify the listen address.
> For example ...
> 
> Listen-on=127.0.0.1:1500
> Talk-to=127.0.0.1:3000-3500
> 
> Would enable you to set up a secure system where your security wrapper
> talked to microwindows on port 1500 where the security wrapper ran on the
> same machine using ports 3000 - 3500 when talking to microwindows.
> 
> Listen-on=*:1500
> Talk-to=*:*
> 
> Would conversely talk to anyone making a connection to microwindows on port
> 1500.
> 
> Now you have the best of all worlds,
>     a) A very simple solution for microwindows
>     b) Non-pollution of the intent and code base of microwindows
>     c) Customisable level of security depending on the situational
> requirements
>     d) Potential to use already available and tested security solutions.
> 
> Hope this helps,
> 
> ----- Original Message -----
> From: "Alex Holden" ####@####.####
> To: ####@####.####
> Sent: Thursday, December 14, 2000 9:53 PM
> Subject: Re: Access control
> 
> 
> 
>> On Thu, 14 Dec 2000, Alan Cox wrote:
>> 
>>>> 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.
>> 
>> Okay, so it looks like encryption of the session data is a must for any
>> real level of security. How about this, we have a two level system:
>> 
>> * No encryption, plaintext passwords using the ordinary Unix password
>> mechanism (assumes the network is fully secure).
>> * Full encryption of both authentication and session.
>> 
>> However, as to my previous idea of providing the encryption via ssh:
>> [alex@hyperspace alex]$ ls -l /usr/sbin/sshd
>> -rwxr-xr-x   1 root     root       622900 Nov  8 15:56 /usr/sbin/sshd
>> [alex@hyperspace alex]$ ls -l /usr/bin/ssh
>> -rws--x--x   1 root     root       663300 Nov  8 15:56 /usr/bin/ssh
>> 
>> Those are stripped binaries, and they also depend on several other
>> libaries.
>> 
>> So I'm currently thinking of implementing an encryption layer based on TEA
>> (Tiny Encryption Algorithm). TEA is an incredibly small (748 bytes on
>> 386), very fast (faster than IDEA), very strong (much stronger than DES)
>> 128 bit private key cypher which isn't patented and has a completely
>> public domain C reference implementation available.
>> See http://vader.brad.ac.uk/tea/tea.shtml for more information.
>> 
>> By the way, I realise that if we put this in the main distribution itself,
>> it would prevent people in countries with draconian encryption import
>> regulations (like France) from downloading it, and might not be exportable
>> from the US (I'm not sure what the exact situation with regard to that
>> is at the moment) so it'll be available as a seperate archive hosted in
>> the UK instead. I assume there are no regulations preventing people from
>> downloading software which contains hooks for making use of encryption
>> code but not the encryption code itself?
>> 
>> --
>> ------- Alex Holden -------
>> http://www.linuxhacker.org/
>>  http://www.robogeeks.org/
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839