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

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

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
>

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
>