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

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

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

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

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

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

> 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 :)

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

-- 
No software patents in Europe -- http://nosoftwarepatents.com
-- Josef Wolf -- jw AT raven.inka DOT de --