Date: Wed, 30 Jul 1997 10:04:14 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Adam Shostack <adam@homeport.org> Cc: security@FreeBSD.ORG, rgrimes@GndRsh.aac.dev.com, dholland@eecs.harvard.edu Subject: Re: secure logging (was: Re: security hole in FreeBSD) Message-ID: <Pine.BSF.3.95q.970730085852.8165A-100000@cyrus.watson.org> In-Reply-To: <199707300111.VAA16730@homeport.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Jul 1997, Adam Shostack wrote: > Robert Watson wrote: > | Is there any concensus on the use of DNSsec in the network community, as > | it has not yet been made widely available (or at least, it is available, > | but not largely used.) The key namespace here could be used however one > | desired, nor necessarily in a DNS-style way. The entity-name, whatever > | that is, simply suggests which key/algorithm should be used, a server > | could be configured to pull that information from DNSsec, or from an > | internal key-file (or both.) > > I don't trust the DNS right now. I also don't see a need to > put keys there for local use. Use ssh to distribute them. :) DNSsec requires one root key to authenticate against any outside key located in DNSsec. SSH requires a complete list of all keys in a manually-managed keyfile. SSH is wonderful, and I use it lots, but it really isn't scalable. DNSsec is designed to be globally scalable. I wouldn't be surprised if SSH starts using DNSsec to pick up and store SSH keys in the near future. :) Also, to use secure logging (hopefully a feature that will be available on all platforms eventually), I don't want to require the configuration and use of SSH. Right now SSH is more available than DNSsec, but if the Internet Infrastructure is to get any more secure, we really need DNSsec in place very, very soon. Manual keying is never desirable (except for the root key, or an organizational root key), although it should be supported. My hopes were to support a general keying architecture, hopefully with a key management daemon eventually being written by someone. Key names would be supported in a DNS-like form, and permit .local. or such to indicate a local key, which would be extracted from a local key-file, possibly distributed with SSH. I'd rather not design the key support to not use DNSsec. :) > | An ACK message has already been stated as desirable -- would a simple > | signature over the last packet (or header + signature) using the shared > | secret, entity public key, or whatever, back on the TCP connection > | suffice? Maybe something lighter-weight? > > I'm leaning to acks being simpler than involving the last > packet, and towords them involving just a sequence number: > > ACK log://somehost.evil.net:234566, HMAC Sequence numbers have their upsides and downsides. One downside is that I will easily generate a million log messages a week (some use syslog for HTTP logging) -- if I have 100 machines doing that, a 32 bit number has restrictions. The URL format only accepts 16-bit values in that field, I think, although I don't know if that's an artifact of port limits, and can be any numeric value. Sequence numbers on individual log messages might be nice, as then one can eliminate duplicates in a cleanup operation, as well as detect missing log entries. ACK's should definitely be signed in some way, possibly over: Signature of packet responded to | ACK packet sans signature BTW, is there any interest in starting up a seperate mailing list on this issue? It doesn't pertain specifically to FreeBSD, although I plan to do any experimentation and implementing on this platform, myself. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Security Research, Trusted Information Systems http://www.tis.com/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@tis.com http://www.watson.org/~robert/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970730085852.8165A-100000>