OpenSSH Certkey (PKI)

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI)

Stephen Frost
Greetings,

Overall I'd like to see OpenSSH support PKI in addition to the existing
methods.  I'm more keen on it being used for host authentication than
for user certificates, personally.  I did want to comment on this
though:

* Daniel Hartmeier ([hidden email]) wrote:
> +Certkey does not involve online verfication, the CA is not contacted by either
> +client or server. Instead, the CA generates certificates which are (once)
> +distributed to hosts and users. Any subsequent logins take place without the
> +involvment of the CA, based solely on the certificates provided between client
> +and server.

Would you consider adding support for OCSP?  I saw alot of
discussion regarding CRLs (and some of their rather well known
downsides) but only once saw mention of OCSP, and that with no response.
While CRLs are useful in some circumstances I believe OCSP is generally
a better approach.  Ideally, both would be supported.  If I had to pick
one I'd rather see OCSP than CRL support though.

        Thanks,

                Stephen

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI) adding CAL (online verification)

chefren
In reply to this post by Claudio Jeker
On 11/16/06 9:55 PM, Claudio Jeker wrote:

> But for us off-line is a very
> important property. As a network operator, working via ssh while large
> parts of your network is unreachable, is an important part of your
> business.

I do understand that and please don't get me wrong, it was a request,
not a demand and I'm very happy with these new developments. If money
or code is needed for something I believe is necessary I will
seriously consider a serious donation.

+++chefren

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI)

chefren
In reply to this post by Stephen Frost
On 11/16/06 10:50 PM, Stephen Frost wrote:

> Would you consider adding support for OCSP?  I saw alot of
> discussion regarding CRLs (and some of their rather well known
> downsides) but only once saw mention of OCSP, and that with no response.
> While CRLs are useful in some circumstances I believe OCSP is generally
> a better approach.  Ideally, both would be supported.  If I had to pick
> one I'd rather see OCSP than CRL support though.

http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol


With: "Messages communicated via OCSP are encoded in ASN.1"


ASN.1 = yuck because everyone starts his own branches in it, it's very
good to keep peace during communication about new standards in
standards commitees but the results are plain growing shit.

CRL is simple to maintain and thus more secure by default.

+++chefren

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI)

Andre Oppermann-2
In reply to this post by beck-7
Bob Beck wrote:
>
> I would think it would be nice if "CAL" had a way of
> saying "these are the ones to be revoked" so no shutdown, just
> propagate the bad one - but I'm talking to daniel offline about it..

That's easy.  echo "ab:cd:ef..." > /etc/ssh/blacklist

Or use a prediodic rsync to do that.  Every pubkey fingerprint listed in it is
denied access.

--
Andre

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI)

Andre Oppermann-2
In reply to this post by Stephen Frost
Stephen Frost wrote:
> Greetings,
>
> Overall I'd like to see OpenSSH support PKI in addition to the existing
> methods.  I'm more keen on it being used for host authentication than
> for user certificates, personally.  I did want to comment on this
> though:

Like I said in another email the PKI support for host authentication is
separate from accepting certificates for user authentication/authorization.

> * Daniel Hartmeier ([hidden email]) wrote:
>
>>+Certkey does not involve online verfication, the CA is not contacted by either
>>+client or server. Instead, the CA generates certificates which are (once)
>>+distributed to hosts and users. Any subsequent logins take place without the
>>+involvment of the CA, based solely on the certificates provided between client
>>+and server.
>
>
> Would you consider adding support for OCSP?  I saw alot of
> discussion regarding CRLs (and some of their rather well known
> downsides) but only once saw mention of OCSP, and that with no response.
> While CRLs are useful in some circumstances I believe OCSP is generally
> a better approach.  Ideally, both would be supported.  If I had to pick
> one I'd rather see OCSP than CRL support though.

Nothing precludes an OCSP implementation and it can be easily inserted should
someone write it.  We don't do it because the goal of our OpenSSH PKI is to be
completely self-contained w/o any external dependencies.  Working right out of
the box with minimal configuration effort.  Only security that is easy to use
will get used in a safe way.

--
Andre

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI)

Daniel Lang-2
In reply to this post by Wolfgang S. Rupprecht-51
Hi,

Wolfgang S. Rupprecht wrote on Thu, Nov 16, 2006 at 08:43:20AM -0800:
[..]

> Oops. I quoted the wrong section.  I had meant to quote the section
> about the user_certificates.  This is what I meant to cite:
>
>      +A user certificate is an authorization made by the CA that the
>      +holder of a specific private key may login to the server as a
>      +specific user, without the need of an authorized_keys file being
>      +present. The CA gains the power to grant individual users access
>      +to the server, and users do no longer need to maintain
>      +authorized_keys files of their own.
>
> I don't see a problem with the host certificates methodology.  (In
> fact I'd love to see the known_hosts files fade away as more hosts
> transition to using host certificates.)

Ok, I see. A user certificate just means that the user is
authenticated, so I agree that the difference between authentication
and authorisation can be mixed up here and becomes blurred.

In fact, it would mean, that you could abandon the authorized_keys
file, but you would still need an "authorized_users" file, that
would need to contain the DN (or a similar identifier) of the user
that matches the certificate. So not a lot is saved, but things
may become less transparent....

Cheers,
 Daniel

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI)

Wolfgang S. Rupprecht-51
Daniel Lang <[hidden email]> writes:
> In fact, it would mean, that you could abandon the authorized_keys
> file, but you would still need an "authorized_users" file, that
> would need to contain the DN (or a similar identifier) of the user
> that matches the certificate. So not a lot is saved, but things
> may become less transparent....

The advantage of splitting the authorization / authentication is it
opens up the possibility of a single certificate being used to
identify a user over quite a large range of non-cooperating
organizations.  That way a potential user can approach the system
admin with their company-wide (or Internet-wide) certificate and the
system admin can enter that certificate into the a user's list (or
into the user's authorized_keys file etc).

I'd much rather they use the whole certificate as the test instead of
just the DN it contains.  That way, the only aspect of the PKI they
need to trust is that the key is strong enough to resist breaking.
They don't really need to trust that the DN is their true name or that
there won't be a DN name-clash a few months down the road.  They just
need to trust that the PKI works.

-wolfgang
--
Wolfgang S. Rupprecht                http://www.wsrcc.com/wolfgang/

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSH Certkey (PKI)

Joachim Schipper
In reply to this post by Lamont Granquist
On Thu, Nov 16, 2006 at 10:50:53AM -0800, Lamont Granquist wrote:

> On Thu, 16 Nov 2006, Wolfgang S. Rupprecht wrote:
> >    +A user certificate is an authorization made by the CA that the
> >    +holder of a specific private key may login to the server as a
> >    +specific user, without the need of an authorized_keys file being
> >    +present. The CA gains the power to grant individual users access
> >    +to the server, and users do no longer need to maintain
> >    +authorized_keys files of their own.
>
> User-maintained authorized_keys files tend to be SOX auditing violations
> (anyone with access to the account can grant anyone else access with any
> notification or audit trail).  It also lends itself to abuses where
> software/generic accounts tend to accumulate the public keys of all the
> developers desktop accounts.  The kerberos .k5login file is similarly
> problematic.  I would love to see a CA-based approach which would solve
> both the authentication and authorization pieces in a way that could be
> wrapped with proper auditing on the granting of privs, particularly if it
> was simple enough that it was widely adopted instead of authorized_keys
> even at very small sites.

I don't know about Kerberos, but I'm fairly sure you can just chown
root:wheel the ~/.ssh/authenticated_keys file.

Of course, this does not mean that the user cannot just delete it and
replace it with his own, but that will always change ownership. If your
requirements are a bit stronger, AuthorizedKeysFile in sshd_config(8)
might be very useful.

                Joachim

12