zfs crypto discuss - Aug 2007 - what if we added a new command..... zfskeymgr

See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/

-- 
Darren J Moffat

On Mon, Aug 06, 2007 at 04:33:27PM +0100, Darren J Moffat
wrote:
> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
> 
I like the idea of splitting this out into a seperate command rather
than continuing to add zpool and zfs. For the GUI bits, I wonder if the
best choice wouldn''t be to make a simple library letting people easily
add whatever frontend they like? Pam support seems like a nice option
for encrypted homedir setups.

vh

Mads Toftum
-- 
http://soulfood.dk

Darren,

My concern is not the specific command presented, but instead
the multiple variants of this command needed for other components
of Sun Solaris.

Would this only cover ZFS Key management?
What about iSCSI Key management? iscsikeymgr and iscsitkeymgr?
What about SSH Key management? sshkeymgr?
What about IPsec Key mangement, if there is such a thing?
etc...

How does this compare to RADIUS key mangement?

Are there plan(s) for a unified NIS/LDAP User Key Mangement?
Are there plan(s) for a unified System/Host Key Management?
Are there plan(s) for a unified Global Enterprise Key Mangement?

Just imagine the key ring you need on your belt to manage
x thousand systems globally...  heavy. ;)

Cheers,
Joel.

Joel.Buckley at Sun.COM
Systems Group, Engineering Automation
303-272-5556, x75556
"Luck is a Planned Event."

----- Original Message -----
From: Darren J Moffat <Darren.Moffat at Sun.COM>
Date: Monday, August 6, 2007 9:33 am
Subject: [zfs-crypto-discuss] what if we added a new command..... zfskeymgr
To: zfs-crypto-discuss at opensolaris.org

> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
> 
> -- 
> Darren J Moffat
> _______________________________________________
> zfs-crypto-discuss mailing list
> zfs-crypto-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Joel.Buckley.vcf
Type: text/x-vcard
Size: 403 bytes
Desc: Card for Joel Buckley <Joel.Buckley at Sun.COM>
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070806/dcbfe6af/attachment.vcf>

Joel Buckley wrote:
> Darren,
> 
> My concern is not the specific command presented, but instead
> the multiple variants of this command needed for other components
> of Sun Solaris.
> 
> Would this only cover ZFS Key management?
Yes because it is covering specifics of how to use given keys for ZFS.
> What about iSCSI Key management? iscsikeymgr and iscsitkeymgr?
iSCSI has no real concept of keys beyond the near useless CHAP.  iSCSI 
is best protected using IPsec.
> What about SSH Key management? sshkeymgr?
ssh-keygen(1)
> What about IPsec Key mangement, if there is such a thing?
We already have a suite for IPsec/IKE, see ikecert(1M).
> etc...
Yes I very much know about the problem you are describing and this is 
one of the reasons the KMF project was started.

ZFS crypto will be using KMF.

However there is a limit to how generic you can make things.
> How does this compare to RADIUS key mangement?
Totally different.  RADIUS is about authentication this is about data 
encryption/wrapping keys.
> Are there plan(s) for a unified NIS/LDAP User Key Mangement?
> Are there plan(s) for a unified System/Host Key Management?
> Are there plan(s) for a unified Global Enterprise Key Mangement?
See the KMF project and the pktool(1) command it introduced as the start 
of some of this.

> Just imagine the key ring you need on your belt to manage
> x thousand systems globally...  heavy. ;)
> 
-- 
Darren J Moffat

On Mon, Aug 06, 2007 at 05:39:46PM +0100, Darren J Moffat
wrote:
> Joel Buckley wrote:
> > What about iSCSI Key management? iscsikeymgr and iscsitkeymgr?
> 
> iSCSI has no real concept of keys beyond the near useless CHAP.  iSCSI 
> is best protected using IPsec.
iSCSI _demands_ IPsec for on-the-wire data conf. + integ. protection.

Darren J Moffat wrote:
> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
> 
given that import has no requirements to get a key, there sees no point 
in putting keying it in zfs/zpool..

On Mon, Aug 06, 2007 at 04:33:27PM +0100, Darren J Moffat
wrote:
> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
The two proposed options, as I understand, are using pool/dataset
properties or separate command. Maybe using another subset of subcommand
would be better? For example:

	# zpool crypto attach tank
	Enter passphrase:

	# zpool crypto change tank
	Enter old passphrase:
	Enter new passphrase:
	Reenter new passphrase:

	# zpool crypto detach tank

Or in case of per-dataset keys:

	# zfs crypto attach -f /path/to/random/bytes tank/foo
	# zfs crypto attach -f /path/to/random/bytes tank/foo/bar
	Enter passphrase:
	# zfs crypto detach -r tank/foo

PS1. The main DSKEK key will be used as a wrapping key for per-dataset
keys, but do you plan to allow per-dataset wrapping keys? So in case of
delegated administration or zone-owned dataset, user can
''attach''
selected dataset without knowing wrapping key for DSKEK?
If so, there should be probably a property that says if a dataset should
be automatically ''attached'' when DSKEK is decrypted.

PS2. I''m trying to figure out order of operations. First we call
''zpool
import'', which will import a pool, and mount all non-encrypted file
systems, but won''t touch encrypted datasets. The same for ''zfs
mount -a''
and ''zfs volinit'' after the reboot. Now we can execute
''zpool crypto
attach <pool>'' to decrypt and mount all datasets, or just
selected
dataset by executing ''zfs crypto attach <dataset>''?
(Sorry for using
just proposed commands, but you get the point.)

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070806/cd7ad8d7/attachment.bin>

On Mon, Aug 06, 2007 at 04:33:27PM +0100, Darren J Moffat
wrote:
> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
I don''t see why this can''t be a new sub-command to zfs(1).  I
do agree
that we don''t want zfs get/set to become interactive though.

Darren J Moffat wrote:
> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
I think it would be useful to know what the exact usage of this new proposed 
command would be.  Eg, a usage messae, prototype manpage, etc.

My gut reaction is that this should not be a different command; it should 
use zfs(1m) / zpool(1m).  I don''t see why we can''t add a new
subcommand
which is interactive if necessary (to provide more security for the
user''s
typed password).

--matt

Matthew Ahrens wrote:
> Darren J Moffat wrote:
>> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
> 
> I think it would be useful to know what the exact usage of this new
proposed
> command would be.  Eg, a usage messae, prototype manpage, etc.
> 
> My gut reaction is that this should not be a different command; it should 
> use zfs(1m) / zpool(1m).  I don''t see why we can''t add a
new subcommand
> which is interactive if necessary (to provide more security for the
user''s
> typed password).
I was going on the assumption that adding a subcommand to 
zfs(1)/zpool(1M) that worked very differently to the existing parts 
wouldn''t be considered good form.  If that isn''t a problem
then I agree
that there is no need for an additional command.

All the "real" work will be in libzfs/libzpool anyway.

-- 
Darren J Moffat

Darren J Moffat wrote:
> Matthew Ahrens wrote:
>> Darren J Moffat wrote:
>>> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
>> I think it would be useful to know what the exact usage of this new
proposed
>> command would be.  Eg, a usage messae, prototype manpage, etc.
>>
>> My gut reaction is that this should not be a different command; it
should
>> use zfs(1m) / zpool(1m).  I don''t see why we can''t
add a new subcommand
>> which is interactive if necessary (to provide more security for the
user''s
>> typed password).
> 
> I was going on the assumption that adding a subcommand to 
> zfs(1)/zpool(1M) that worked very differently to the existing parts 
> wouldn''t be considered good form.  If that isn''t a
problem then I agree
> that there is no need for an additional command.
> 
> All the "real" work will be in libzfs/libzpool anyway.
> 
If this was still under zpool, I would expect ''zpool import
<pool>'' to
not prompt for a passphrase or PKCS#11 PIN by default.  That would mean 
either import has an option to get the prompt or there is another 
subcommand, like ''zpool key'' that does what Darren wrote up
for zfskeymgr..

Anthony Scarpino wrote:
> If this was still under zpool, I would expect ''zpool import
<pool>'' to
> not prompt for a passphrase or PKCS#11 PIN by default.  That would mean 
> either import has an option to get the prompt or there is another 
> subcommand, like ''zpool key'' that does what Darren wrote
up for zfskeymgr..
I think we need a new subcommand, the only reason I was considering a 
new usr/bin binary was because I didn''t think that it would be 
acceptable to make zfs/zpool operate in such a different way for a new 
subcommand.

I don''t think that any of the existing subcommands need any new options
for zfs-crypto.   I do still intend to use dataset and pool properties 
as much as possible.

We also need to not just focus on an explicit ''zpool import''
because it
doesn''t work quite like that during boot - if I''ve worked it
out
correctly the kernel module does the "equivalent" thing but by using 
/etc/zfs/zpool.cache.


-- 
Darren J Moffat

Darren J Moffat wrote:
> Matthew Ahrens wrote:
>> Darren J Moffat wrote:
>>> See http://opensolaris.org/os/project/zfs-crypto/zfskeymgr/
>>
>> I think it would be useful to know what the exact usage of this new 
>> proposed command would be.  Eg, a usage messae, prototype manpage, etc.
>>
>> My gut reaction is that this should not be a different command; it 
>> should use zfs(1m) / zpool(1m).  I don''t see why we
can''t add a new
>> subcommand which is interactive if necessary (to provide more security 
>> for the user''s typed password).
> 
> I was going on the assumption that adding a subcommand to 
> zfs(1)/zpool(1M) that worked very differently to the existing parts 
> wouldn''t be considered good form.  If that isn''t a
problem then I agree
> that there is no need for an additional command.
Well, it all depends on what you mean by "works very differently". 
Hence,
my request for a detailed design.

--matt

Matthew Ahrens wrote:
> Well, it all depends on what you mean by "works very
differently".
> Hence, my request for a detailed design.
Tony and I will work this out we are still trying to sort this out.  We 
first wanted to resolve the issue of wither or not we should introduce a 
new command or a new subcommand for zfs(1)/zpool(1M).

At a high level it will be prompting for passphrase/PIN interactively 
and in the key change case the interactive dialog would be a little 
similar to changing a user password.

The "very differently" is because the current zfs commands
don''t go
interactive with the user just now.

We don''t want to be radically different, in fact I''ve been
trying as
much as possible to stick with using dataset/pool properties and the 
existing set/get but there are cases where that just doesn''t fit well.

-- 
Darren J Moffat

> On Mon, Aug 06, 2007 at 05:39:46PM +0100, Darren J
> Moffat wrote:
> > Joel Buckley wrote:
> > > What about iSCSI Key management? iscsikeymgr and
> iscsitkeymgr?
> > 
> > iSCSI has no real concept of keys beyond the near
> useless CHAP.  iSCSI 
> > is best protected using IPsec.
> 
> iSCSI _demands_ IPsec for on-the-wire data conf. +
> integ. protection.
While there are evolving security provisions in Fibre Channel,
I don''t recall that level of emphatic expression that they''re
not widely
implemented or used.  Insofar as a separate network with physical security is
"good enough" for many sites, in cases where iSCSI could be used
over a private and local network (distinct from other IP traffic),
would that really be any worse than non-encrypted/non-integrity-protected
Fibre Channel?
 
 
This message posted from opensolaris.org

On Wed, 2007-08-08 at 01:34 -0700, Richard L. Hamilton
wrote:
> Insofar as a separate network with physical security is
> "good enough" for many sites, in cases where iSCSI could be used
> over a private and local network (distinct from other IP traffic),
> would that really be any worse than non-encrypted/non-integrity-protected
> Fibre Channel?
Getting physical security and physical separation like that correct all
the time is hard.  It''s easier to keep networks intended to be separate
actually separate if they don''t speak the same protocol.

If I accidentally cross-connect a FC san with the ethernet vlan that''s
the backbone of my untrusted wireless network ... nothing bad happens
because bits don''t move.

Replace the FC san with an iSCSI over ethernet san, and things get a
little more exciting.

(I won''t name names, but I *have* seen cases where someone screwed up
while recabling a patch panel, cross-connecting an internal "secure"
network with an external-facing wireless network, despite the use of
color coded patch cords intended to make the separation obvious...)

So, two physically separate networks running the same protocol in the
clear have worse security than two physically separate networks running
inherently incompatible protocols.

					- Bill