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

[mailto428496]

Thomas, Alon,

Thanks for the suggestions!  I will look into these and see if it looks
like they could work for what I am trying to do.


Jim


On 12/19/2018 04:50 AM, Thomas Calderon wrote:
> As one of the dev of it, I can also recommend Caml Crush, a PKCS#11
> filtering proxy [1] as a solution that works well under both tcp and unix
> domain sockets, it is packaged for Debian.
> I have tested this approach in the past, redirecting the server socket
> through SSH and using our client library through the tunnel worked fine.
>
> Cheers,
>
> Thomas
>
> [1]: https://github.com/caml-pkcs11/caml-crush
>
>
>
> On Wed, 19 Dec 2018, 06:32 Alon Bar-Lev <alon.barlev at gmail.com wrote:
>
>> On Wed, Dec 19, 2018 at 3:03 AM mailto428496 <mailto628496 at cox.net> wrote:
>>> 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.
>> Check this[1] out, openssh now supports redirecting unix domain socket.
>>
>> [1]
>> https://ludovicrousseau.blogspot.com/2010/11/pcsc-client-and-server-on-two-different.html
>>
>>>> 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.
>> This belongs to device remote access and not directly to openssh. The
>> softhsm[1] project or the  p11-kit[2] to implement remote access to
>> PKCS#11, as it is the best software based PKCS#11 implementation. What
>> you seek is a PKCS#11 proxy module that serialized everything via a
>> socket and a stub that reads socket and call a real PKCS#11
>> implementation.
>>
>> Please look if [3] helps.
>>
>> [1] https://www.opendnssec.org/softhsm/
>> [2] https://p11-glue.github.io/p11-glue/p11-kit.html
>> [3] https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html
>>
>>>> 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
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>