Josef Wolf <jw AT raven.inka DOT de> writes:

> On Wed, Dec 21, 2005 at 08:38:56AM -0500, Greg Troxel wrote:
> 
> > The fundamental point that I think you are missing is that other
> > people will have different concerns and threat models that you do.
> 
> So please, can we keep this conversation going until we all have a clear
> understanding?  I tried to cover all of the aspects you mentioned.
> But since you failed to mention _all_ aspects, I admit that I am far
> from being perfect ;-)
> 
> > So I believe
> > that a number of people will choose, and rationally so, not to encrypt
> > the tapes.
> 
> Thus I proposed the option to write the private key onto the tape.  No
> key management needed for those who don't want security...

Having a key on the tape and needing to decrypt them is far more
complicated.  To many (including me), the most important thing, which
is far more important than all others, is to be able to get my bits
back from tape when something bad happens, ranging from rm -rf / to a
disk failing, to total loss of the building due to fire/flood/etc.  So
the notion that things are encrypted but the key is on the tape means
that I can no longer read my backup tapes with a basic NetBSD install
without amanda and just dd, gzip, and restore.  Plus, this complexity
can have errors, and I'd have to do more extensive testing.  So for my
situation, encrypting the tapes and putting the key on them is just
totally unreasonable.  I suspect many others feel the same way, as it
is just complexity without security benefit.


> >   D. What would be the benefit of this case?  I see only disadvantages here:
> >      - high load on tapeserver.
> >      - more surface for attackers.
> > 
> > I don't see much benefit, but it could work with existing krb4 support
> > for transport (with old clients) and a local modification on the
> > server.
>
> Those who use krb4 today can continue to use it the way they use it today,
> don't they?  I don't see why they are no more able to do what they are
> doing today.

They can, but you are proposing architectural changes, and it's
important that they be done in way which admits future good things and
doesn't make them harder.

> >   So E has no disadvantages here.
> > 
> > With respect to confidentiality, no.  But E is weaker than the cases
> > that don't encrypt tapes from the backup availability perspective.
> 
> No doubt here.  As long as encryption is an _option_, no one is forced
> to use it.  Those who actually use encryption, should be aware of the
> fact that they loose data when they loose the key.  IMHO, this is basic
> knowledge.  If an admin is not aware of such facts, he needs to be
> fired (IMHO).

Sure, but I'm making the point that (clueful) people will object to
encrypted tapes.

> >     define dumptype foo {
> >       foo-bar-dumptype
> >       crypt-pubkey  /path/to/pubkey-%h-%d  # public  key is on client
> >       store-privkey /path/to/privkey-%h-%d # private key is on server
> >     }
> > 
> > If the private key is on the server the data on the server might as
> > well be in the clear.
> 
> This is to solve the case where you wanted to have the tapes to be
> in clear-text.  I don't think it is a big security issue to have the
> keys in clear on the server when the alternative would be to have no
> keys at all because the tapes are in clear.  If you don't want the
> priv-key on the tape (that is, if you have some sort of key-management)
> then there is no need to keep the priv-key on the tape-server or to use
> the store-privkey option at all.

I find this key management scheme to be very weak.  It suffices for
manual management, but for transport encryption it seems awkward.  I'd
far rather do something like ssh (or with a real PKI) to authenticate
DH for transport.

> > But, not having so makes interactive restores harder.
> 
> Security don't come for free.  You have to pay a price if you want
> encryption (AFAIK).  Either you need a key to get the data, or everyone
> can get the data without a key.  If you want to be secure, you need to
> store the key in a secure place.

I think it would be helpful for you to write out your assumptions
about threats.  I am relatively unconcerned with people getting access
to my tapes - they are locked up as well as the computers.

I don't claim that encrypted tapes aren't useful.  If I wanted to
store sensitive data offsite with a storage facility that I trusted
not to break/lose the tapes but didn't trust (or couldn't
contractually) not to read them, I'd want this.

Really, I am trying to ask you to think about keeping transport and
storage encryption conceptually separate, even if you have a mechanism
that does both without any bits on the server.  This 'both' is also
very useful for sensitive clients on common backup servers.  I could
actually use that right now, but it would require client config to
only do encrypted dumps to be safe.

> > This really needs quite a lot of key management thought.  But
> > later, I see that you intend to be able to implement cleartext on
> > tapes but with transport encryption via this.
> 
> I don't inted this.  It was just a quick thougt in response to your
> requirement list.  It was just an example of how such a requirement
> could be satisfied.  Security don't come for free.  You _need_ to do
> some thoughts about key management.

Yes, and IMHO that's the hardest part of security design.

> > It's broken from a security viewpoint to only configure this on the
> > server, particularly without authentication of the dump requests.
> 
> You're right here.  It was just an example, since amanda don't have
> client-side configs yet.  But I bet you got the idea :)

Right, but if you don't fix that, you haven't really gained the
security properties you are trying to get.

> A completely different question (which was not touched yet in this thread)
> is to make sure that the data comes from the correct _client_.

Sure, that's important as well.  the krb4 stuff more or less handles this.

-- 
        Greg Troxel <gdt AT ir.bbn DOT com>