RFE: OpenSSH Support for PKCS11 Funneling to PAM for Kerberos/PKINIT

[mailto428496]

Alon,


On 12/18/2018 06:52 PM, Alon Bar-Lev wrote:
> OK... So you have an issue...
>
> First, you need to delegate your smartcard to remote machine, probably
> using unix socket redirection managed by openssh. This can be done in
> many levels...
> 1. Delegate USB device, this will enable only exclusive usage of the
> smartcard by remote machine.
> 2. Delegate PC/SC, this will enable sharing the reader between local
> and remote machines, rdesktop is using this method.
> 3. Delegate PKCS#11, this is the preferred method, however, there is
> no maintained solution to do so.
> 4. Delegate the ssh-agent and implement a minimal PKCS#11 provider on
> top to support PKINIT requirements.
> 5. If your card is gpg supported, use gpg-agent as ssh-gent and
> delegate gpg-agent to remote and use scute[1] as PKCS#11 provider,
> however, scute is unmaintained.

I agree that number 3 would be preferred.  My hope was that maybe this
would be something that the OpenSSH group would be interested in
implementing / supporting as a future feature, but it sounds like there
aren't currently a lot of people waiting in line (Or it could be a
feature that a good number of people would like but just don't realize
it ;) (not everyone realizes/considers that PKINIT is possible for
smartcard auth, at least based on my observations).  I could imagine
this being of interest to anyone with a kerberos/AD infrastructure and
using smartcards (which is probably a good number) and even if they are
not using kerberos tickets for auth (not everyone is) but still have AD
and want to better centralize control of SSH smartcard auth.

> The problem is that non of these methods have a good solution... But
> once you have done that, you can use PKINIT at remote to access your
> local smartcard.
>
> If you choose to implement minimal PKCS#11 on top of ssh-agent you
> should use file based X.509 certificate to perform the signature.
> Actually, it once supported that when Roumen Petrov and I worked on
> the PKCS#11 implementation for OpenSSH which was not merged
> eventually, now I am unsure if the agent is patched to allow that[2],
> you can check this out maybe the patched agent enables you to perform
> access the X.509 certificate as well, so you can implement a nice
> provider on top of the patched ssh-agent.

Having it work with the agent would be nice too.

Anyway, I wanted to toss this out there.  Such functionality would
certainly help us a lot but I know that there would need to be
sufficient interest in order for such a thing to get into the mainstream.


Jim

>
> On Wed, Dec 19, 2018 at 1:31 AM mailto428496 <mailto628496 at cox.net> wrote:
>> Alon,
>>
>> I should have provided more background.  You are assuming that I could
>> perform the PKINIT prior to connecting to the SSH server.  In this case
>> (and others) there is an interest in not exposing the kerberos servers
>> to the world and thus someone connecting remotely would not be able to
>> obtain a TGT or do a PKINIT.  The goal would be for SSH to handle all
>> the auth and only after connecting to the SSH gateway server, and doing
>> a PKINIT as part of the process, then the user would have access to
>> kerberos and could obtain a TGT.
>>
>>
>> Jim
>>
>>
>> On 12/18/2018 06:18 PM, Alon Bar-Lev wrote:
>>> Hi,
>>>
>>> Maybe I am wrong, but I believe you did not get it right.
>>>
>>> You should use PKCS#11 to perform PKINIT in order to authenticate
>>> against the KDC to acquire TGT.
>>> Then ssh can use the TGT in order to issue ticket to access remote
>>> sshd using GSSAPI KEX.
>>>
>>> If you like to use pam_krb5 locally on your system to issue the TGT,
>>> do it... it yet another method to have TGT in your user context. The
>>> ssh command will use the TGT (or available keytab) to interact with
>>> sshd, without requiring any special pam module at the remote side.
>>>
>>> You can delegate your TGT using forwarded TGT into the remote machine
>>> if you need to jump additional hope.
>>>
>>> In other words, kerberos is SSO technology, the PK is used at
>>> authentication phase only and if smartcards are being used this phase
>>> is performed on local machine, once TGT is available, the remaining of
>>> the interaction is kerberos only.
>>>
>>> Regards,
>>> Alon
>>>
>>> On Wed, Dec 19, 2018 at 1:10 AM mailto428496 <mailto628496 at cox.net> wrote:
>>>> I know OpenSSH currently supports PKCS11 devices (such as smartcards)
>>>> for publickey authentication, but I would love to see PKCS11 extended
>>>> further.  It is currently possible to perform PKCS11 certificate
>>>> authentication, via pam_krb5.so (on Linux at least and likely something
>>>> similar on other *NIX) which allows smartcard auth to a Kerberos
>>>> (including AD) server, where a TGT can also be granted.  How difficult
>>>> would it be to add functionality to OpenSSH so that it can funnel PKCS11
>>>> certs from SSH client to server and on to PAM where it could be used by
>>>> Kerberos/PKINIT?  My thought is that this is at least part way there
>>>> with the current PKCS11 support but I won't claim to be an expert
>>>> regarding the internals of what would be needed.  I would think that a
>>>> number of places using smartcards (I currently work for a gov agency
>>>> that uses smartcards) would find this approach to have additional
>>>> security and management features (given real-time validation against a
>>>> kerberos/AD server) over using publickey auth (based on PKCS11) and also
>>>> having the added benefit of granting a TGT on sign-in, enabling SSO
>>>> (GSSAPI) to additional backend servers.
>>>>
>>>> What are thoughts on this functionality being added to OpenSSH?  Am I
>>>> the first to suggest such a thing?
>>>>
>>>>
>>>> Jim
>>>>
>>>> _______________________________________________
>>>> openssh-unix-dev mailing list
>>>> openssh-unix-dev at mindrot.org
>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev