openssh unix dev - Dec 2018 - RFE: OpenSSH Support for PKCS11 Funneling to PAM for Kerberos/PKINIT

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

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.

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.

Regards,
Alon

[1] https://github.com/gpg/scute
[2] https://roumenpetrov.info/secsh/index.html

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
>

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