openssh unix dev - May 2010 - Certificates and authorized principals

Hi,

Users who are interested in certificate authentication might be interested
in this change:
>  - djm at cvs.openbsd.org 2010/05/07 11:30:30
>    [auth-options.c auth-options.h auth.c auth.h auth2-pubkey.c key.c]
>    [servconf.c servconf.h sshd.8 sshd_config.5]
>    add some optional indirection to matching of principal names listed
>    in certificates. Currently, a certificate must include the a user's
name
>    to be accepted for authentication. This change adds the ability to
>    specify a list of certificate principal names that are acceptable.
>    
>    When authenticating using a CA trusted through ~/.ssh/authorized_keys,
>    this adds a new principals="name1[,name2,...]" key option.
>    
>    For CAs listed through sshd_config's TrustedCAKeys option, a new
config
>    option "AuthorizedPrincipalsFile" specifies a per-user file
containing
>    the list of acceptable names.
>    
>    If either option is absent, the current behaviour of requiring the
>    username to appear in principals continues to apply.
>    
>    These options are useful for role accounts, disjoint account namespaces
>    and "user at realm"-style naming policies in certificates.
>    
>    feedback and ok markus@
-d

> On May 9, 2010, at 10:41 PM, Damien Miller <djm at mindrot.org>
wrote:
> 
> Hi,
> 
> Users who are interested in certificate authentication might be interested
> in this change:
> 
>> - djm at cvs.openbsd.org 2010/05/07 11:30:30
>>   [auth-options.c auth-options.h auth.c auth.h auth2-pubkey.c key.c]
>>   [servconf.c servconf.h sshd.8 sshd_config.5]
>>   add some optional indirection to matching of principal names listed
>>   in certificates. Currently, a certificate must include the a
user's name
>>   to be accepted for authentication. This change adds the ability to
>>   specify a list of certificate principal names that are acceptable.
>> 
>>   When authenticating using a CA trusted through
~/.ssh/authorized_keys,
>>   this adds a new principals="name1[,name2,...]" key option.
>> 
>>   For CAs listed through sshd_config's TrustedCAKeys option, a new
config
>>   option "AuthorizedPrincipalsFile" specifies a per-user file
containing
>>   the list of acceptable names.
Has anyone considered somewhat reversing the sense of this?  That is, allowing 
operators to use a "special? AuthorizedPrincipalsFile (call it ?self?) that
would have
a collection of principals in it that would allow users to login as themselves
in the
absence of any other authorization mechanism?

As an example, given a host named ?mirkwood?, the ?self" authorized
principals
file would have a principal in it called ?mirkwood_users? (possibly others). 
Anyone with that principal listed in their (valid) certificate would then be
authorized
to login to mirkwood as the login name they are using on the source system,
provided
that the login name is *also* a valid principal in the certificate.

In this way, users can obtain access to a host without needing to modify
anything
on the host itself or any other external namespace groups.

The specific use case I was thinking about has to do with issuing short-lived 
certificates that allow a user emergency access to a host. The openssh CA could 
then be more of a one-stop-shop for this kind of access, instead of having to 
deal with the host?s pam_access other authorization mechanism to permit the 
user to login.

jd

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2393 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180105/5ca13b86/attachment.p7s>