[CUWiN-Dev] Proposed Nodeconfig Change

[David Young]

On Tue, Jun 19, 2007 at 05:00:16PM -0500, Matthew Isaacs wrote:
> On Tue, 2007-06-19 at 17:35 -0400, Paul A. Kennedy wrote:
> > On Jun 19, 2007, at 5:13 PM, Joshua King wrote:
> > 
> > > I think that this would be a good idea. There is nothing keeping us  
> > > from
> > > having the configuration on the testbed builds be different than  
> > > the one
> > > on the public sourceforge builds. As Matt said, those builds are
> > > necessarily insecure, and the most important thing is to make them  
> > > easy
> > > to use so people can fiddle with them more easily. Plus, it would get
> > > more much-needed usability testing for nodeconfig.
> > 
> > Exactly who are we targeting here?
> > 
> > Do we want people who don't know the basics of using ssh to be  
> > responsible for making network security decisions?  Wouldn't we  
> > prefer them to read the man page for ssh rather than consider network  
> > topology and security?
> > 
> > I think not knowing how to use ssh is a fine barrier to entry.
> > 
> > Paul
> > 
> > --
> > Paul A. Kennedy
> > pakenned at pobox.com
> > 
> > 
> > 
> > _______________________________________________
> > CU-Wireless-Dev mailing list
> > CU-Wireless-Dev at lists.cuwireless.net
> > http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
> 
> We're talking folks who simply download the public flash images or
> ISO's, and boot them up, and don't bother doing their own build.
> Without doing their own build, all the system passwords are the defaults
> specified in the documentation.  As such, the system is insecure, and
> someone wishing to wreak havoc with/on such a node would only need to
> ssh using the default root password.  This presents a much more
> interesting security hole for a potential hacker than a web gui that
> only allows someone to configure a predetermined set of options.
> 
> I agree that this solution is not suitable in a production environment,
> however one would hope that no one is using the public images in such a
> manner, due to the password and other security issues.

Sorry I am so late to respond.

I think that we need to move away from distributing software with
passwords set to well-known defaults.  For many demo purposes, nobody
needs to know any password at all.  For users who do want to admin their
own node, but who do not want to build their own image, we need a secure
web site that they can visit to get their own SSH/web admin password.
CUWiN will assign some random password or, if they don't trust us, let
them provide their encrypted password.  When the web site has their
encrypted password, it will provide them a unique URL where they can
download the image they desire for a limited time.

The web interface on nodes really needs some authentication and privacy.
We can put the same certificate on each node in a network, and then we
can give that certificate to every admin for that network, but if any
node is ever compromised, then we cannot trust the certificate any more.

These days there are cheap ICs that contain some "write-only" memory for
a secret and an engine for producing SHA-1 message digests.  After you've
programmed the secret, you can write a bit string to the IC and it will
"mix" the string with the secret, compute the SHA-1 hash of the mixture,
and write it back to you.  Maxim/Dallas makes a few such ICs---for
example, the DS2704.  If somebody gets hold of a node containing one
of these, they can produce hashes using that particular physical IC,
but it will be tremendously difficult for them to replicate the IC or
its secret for reuse, quite unlike a certificate.  I'd like to explore
the use of these ICs for authentication of nodes to nodes and nodes to
admins at CUWiN.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933 ext 24