[Authentication] Some input

[Michael Leupold]

Hi,

On Friday 10 July 2009 20:40:54 Dieter Plaetinck wrote:
> And now the "real" input, which are mostly just thoughts that popped
> into my head:
>
> - configurable encryption for persistent storage? algo, key size etc.
>   gnupg integration?

This is currently meant to be implementation-defined though the algorithms 
used for negotiating a session remain to be specified.

> - master password unlocks key, key unlocks data?

That's one way to do it, though at least KWallet uses the hashed password as a 
key to decrypt all of a wallet's ("collection") contents. Not quite sure about 
keyring, but I guess it's currently the same.

> - can it be usable without dbus? some people don't like dbus. simple
>   CLI program to query the database?

While it should be possible it's currently not planned as part of the 
specification. After all even CLI programs may use the D-BUS :)

> - datastore : some kind of binary format?

Implementation defined. While most users will be using encrypted files for 
storing their secrets they might also be written to a TPM, a smartcard or even 
some central server (ldap?).

> - ACL for apps: a plaintext config maintained by user? maybe itself
>   stored within the secret storage?  would apparmor/selinux/.. already
>   support something like this?

ACLs aren't part of the specification either but are currently used by 
keyring/wallet. AFAIK keyring uses /proc to find out, KWallet just trusts 
whichever name the applications says it has. As I understand it SELinux could 
be used to manage some of those ACLs. Still ACLs are currently not meant to be 
part of the API. They can't be a required part anyway because there's no 
guarantee that all platforms will have sufficient support for low-level 
features required to implement them (eg. Windows is a target platform for KDE 
and I fear we won't see proper ACL on it).

> - unlocking ssh keys by unlocking the secret store? or the other way
>   around: unlocking the secret store with an ssh key? or hell..
>   make the secret store an ssh-agent ? gnupg? PAM ?
>   type master pass once, have ssh/gnupg/pam (login) for free?

As I understand it most of those features will be able to live on the client-
side though eg. PAM support may require an additional call to unlock a 
collection using a password.

> - the previous could be taken a step further: some people have
>   encrypted blockdevices (hard disks) in Linux which they unlock at
>   boot time (or in initramfs for / ), could this be integrated somehow?

I think it should well be possible provided the daemon (which is running 
inside a user's session on the session bus) is up before and there's a way to 
unlock it (eg. after user login inside the X session). I'd categorize this as 
a client feature as well.


On a sidenote not everything has been settled. The thin line between 
implementation- and specification defined features is currently still sketchy 
and we might reconsider where to put a feature if we see the need. Yet I think 
it's best to keep the spec as slim as possible.

Regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090711/8233374b/attachment.pgp