Adding 'name' key types

[Nicolas Williams]

Playing around with the [wonderful] GSS-API patches for OpenSSH [1] I
noticed that there is a bit of functionality missing from
OpenSSH/GSS-API, namely that authorized_keys2 has no meaning when using
GSS authentication.

Yes, ~/.k5login can be used to grant access to an account for
applications that support Kerberos, as does OpenSSH with those GSS
patches, but .k5login does not and cannot provide the
from/command/environment and other useful options that SSH's
authorized_keys2 file entries can.

So, after looking around, especially in key.h and key.c and auth2.c, it
occurred to me that a new key type could be added for dealing with named
keys, that is, names which can be authenticated (e.g., certificate
names, Kerberos principal names).

The neat thing is that auth2.c:user_key_allowed() is key-type
independent (so arguably it doesn't belong in auth2.c), and thus could
be called from ssh_gssapi_userok() [instead of, or in addition to the
GSS mechanism specific *userok() methods].

The only questions, in my mind, are

 - how to format key names for use in authorized_keys2?

   I propose starting the key blob with 'name:' followed by a possibly
   null mechanism name, another ':' and the key name in question
   (uuencoded so whitespace, non-ascii characters and so on can be
   unambiguously present in key names).

 - how to deal with generic names vs. mechanism specific names?

   I.e., should an 'exported' GSS name be checked as a 'gss' key name
   type? Or should it be checked against a name type specific to the
   mechanism used to authenticate the client?

   I think this should probably be optional behaviour.


[1] http://www.sxw.org.uk/computing/patches/


Thoughts? Flames?

Nico
--

. 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.