Balazs Scheidler <[EMAIL PROTECTED]> writes:
> I'm trying to work on the publickey authorization database in lshd. I'd like
> to ask for comments how to implement it.
Ok. Here's a brain dump. Simplifications to what is described below
are welcome.
> Goals:
> * in the long term, support SPKI style certificates and acls to grant
> permissions to certain parts of the system
> * in the shorter term, support ssh2 publickey authentication with ssh2
> keyblobs, possibly using spki style keys outside the protocol.
> * granting permission should be as easy as with ssh1 (e.g. copying a public
> key file to a certain directory)
There is one more thing I'd like to add to the requirements list: When
doing authentication with spki keys, it's not necessary to transmit
the public key as part of the protocol. It is enough to send the hash
of the corresponding sexp.
> Currently, as a publickey authentication request is received, the ssh2
> keyblob (coming in the auth request) is converted to an SPKI S-expression,
> the canonical form of this S-expression is hashed, and the value of the
> hash is taken as a filename and checked for in the ~/lsh/authorization
> directory. This scheme is not general enough to support several publickey
> methods (e.g. real SPKI, OpenPGP, and SSH2)
I think hashing, in some way or another, is necessary. One way to
arrange things is to have one directory where we store public keys (or
possibly symlinks to keys), with a name derived from the key hash. One
advantage of using an extra symlink indirection is that we could store
the keys in one directory, using user-selected names, and then have a tool
to hash them and populate the link farm.
> 1) publickey methods are not interchangeable, meaning that you can't use an
> ssh2 key for authenticating using the SPKI method (e.g. internal
> conversions are not done, and several authorization database exists, one for
> each method)
One problem that we must solve for interoperation between both
formats, is to define a one-to-one map between spki public keys and
ssh-dss keys and keyblobs, and stick with the specialized
representations for spki keys whenever possible. Note that the
"canonical" format for sexps provides an one-to-one map between sexps
and octet strings, but the spki spec does not define any one-to-one
map from <p,q,g,y> (the "interesting" part of a key) to a unique
s-expression.
> 2) publickey methods are interchangeable as much as possible, only one
> authorization database exists, keyconversions are done automatically (and
> blindly)
>
> I for one would go for #1, and provide a program to convert keys from one
> format to another.
If possible, I'd like to see two. I'd like to be able to use lsh most
of the time, and an acl-database in my .lsh, and still be able to
authenticate using Datafellow's ssh2, if that happens to be the client
I happen to have available on a particular machine. Of course, this
gets more important when we have a Datafellows compatible ssh-agent.
> The authorization database would look like:
> ~/.lsh/authorization/ssh-dss - for ssh-dss public keys, in ssh keyblob format
Which format does Datafellows ssh2 use? ssh1 uses an simple text
format for public keys. If we want to make usage with Datafellows ssh
easier, we should use the same format as .ssh/identity.pub, which is
probably not the keyblobformat.
> ~/.lsh/authorization/spki - for spki acl s-expressions
> ~/.lsh/authorization/openpgp - for openpgp public keys
Hmm. What about something like this:
~/.lsh/public_keys/ - Public keys, in spki format
~/.lsh/keys_sha1/ - Linkfarm, indexed by spki-hash
(in base64, so that the names
corresponds to human-readable
acls:s.
~/.lsh/acls - SPKI-acls, mostly referencing
keys (principals) by hash
~/.lsh/ssh_authorized_keys - File of keys in ssh identity.pub
format
And have a tool that reads the last ssh_authorized_keys file, maps
each key to spki format (in the unique way we have to define), and
creates an acl that grants full access (or, if desired, some limited
access) to the key. It's not absolutely necesasry to store the
converted spki key, but it could be saved in public_keys/
(or someplace else), and a have a corresponding symlink added.
The tool could be perhaps invoked automatically based on timestamps or
something like that.
When the server receives an spki hash, it first looks it up in the
hash subdirectory to get a public key to verify the signature. Next,
it checks the acl file to see if access should be granted to the key.
When the server receives a full spki key, it verifies the signature,
computes the hash, and checks for matching acl:s, as above.
When it receives a sha-dss key, it verifies the signature (using the
ssh-dss conventions), converts the key to a spki key (in the unique
way we have to define), hashes it and checks for matching acl:s.
If we want to skip the acl-stuff for now (and we definitely should
look at the existing spki implementation before doing too much along
that way), we could use a simple file listing all hashes
that should be granted full access. Or keep using your authorization
code (existence of a file named as the hash implies access).
As for openpgp keys, it's too long since I read those documents, but I
think they could be handled much the same way as ssh-dss. For handling
openpgp-certificates (or any other certificates), one would have to
map them into "tupels" and invoke the spki tupel-reduction machinery.
/Niels
