[SSSD] sssd + pkcs11

Nikos Mavrogiannopoulos nmav at redhat.com
Tue Sep 15 09:03:06 UTC 2015


On Mon, 2015-09-14 at 18:40 +0200, Sumit Bose wrote:
> On Mon, Sep 14, 2015 at 12:10:31PM +0200, Nikos Mavrogiannopoulos
> wrote:
> > On Mon, 2015-09-14 at 11:46 +0200, Sumit Bose wrote:
> > > On Mon, Sep 14, 2015 at 11:25:39AM +0200, Nikos Mavrogiannopoulos
> > > wrote:
> > > > Hello,
> > > >  I've been writing some text to integrate freeipa/sssd with
> > > > openconnect
> > > > server [0], and for single password or OTP that seems to
> > > > integrate
> > > > seamlessly. However, when PAM-SSSD is configured to use smart
> > > > cards,
> > > > that only works with locally inserted cards. That is even if
> > > > one
> > > > uses
> > > > the smart card to establish the channel used for VPN, the PAM
> > > > module
> > > > wouldn't know that. Would it make sense to use a flag (e.g.,
> > > > via 
> > > >  pam_putenv()) and the caller of the PAM functions set the
> > > > information
> > > > provided by the certificate used for the session for SSSD to
> > > > assume 
> > > > a card is present? (*)
> > > I'm not sure I can follow, can you described with a bit more
> > > details 
> > > how it should work?
> > 
> > Hi Sumit,
> > 
> > Let's assume the following scenario. SSSD requires a password +
> > smart
> > card to login.
> > 
> > The openconnect server could require the user to use a certificate
> > to
> > access the VPN, and for that the administrator configures the
> > certificates accepted by ocserv to be the same as the ones accepted
> > by
> > SSSD (same CA). So when the user is remote and connects to the VPN
> > he
> > has already used the smart card. So when the openconnect server
> > calls
> > PAM to authenticate the user, and SSSD is the PAM backend, it may
> > be
> > desirable to allow the user to login, since the smart card was
> > present
> > remotely, even if it was not present on the system login is done.
> > Is
> > the use case clear?
> 
> This sounds similar to the Apache use-case Jan is working on where
> Apache verifies that the certificate is valid and the client knows 
> the private key.

Correct.

> In general this sounds similar to cases where the application is 
> doing the authentication on it's own as e.g. ssh using ssh-keys or 
> general GSSAPI authentication.
> 
> In all cases the application just does not call pam_authenticate() 
> but goes to pam_acct_mgmt() immediately after calling pam_start(). 
> This way the PAM stack is only used for access control (and maybe 
> session setup later on) but the authentication step is skipped.

Well, that way there can be no password or OTP asked from the user,
thus preventing using the certificate as second factor, and the
password as first factor. I think the use-case of having certificates
as single factor only is interesting but is rather a corner case.

What I would like to handle is all use cases involving certificates:
1. password + certificate
2. password + OTP + certificate
3. OTP + certificate
4. certificate only

If pam_authenticate() is skipped only (4) can be handled.

> > About the implementation, I don't have a concrete idea, but we will
> > need to provide out-of-band information to pam_sssd on whether a
> > certificate was used. I saw that pam_putenv() and pam_getenv() were
> > there and they look like a good candidate for such data. For
> > example
> > the server could call:
> > pam_putenv("DN=BASE64(DN)")
> > pam_putenv("ISSUER_DN=BASE64(ISSUER-DN)")
> > pam_putenv("KEY_HASH=HEX(SHA256(SubjectPublicKeyInfo field))")
> > 
> > and pam_sssd() check using pam_getenv("DN"),
> > pam_getenv("ISSUER_DN") or
> > simply KEY_HASH, whether the strings match the expected user key.
> > Is
> > that reasonable?
> In the Apache use case mentioned above Apache calls SSSD via DBus to
> resolves the user with the help of the certificate, please have a 
> look at
> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificat
> e for details. Would this work for you as well?

I think the design document is about a related but different problem.
It is about mapping the certificate user name to the actual user. In
ocserv, that is being done by the administrator configuring the
Distinguished name field that will be used to obtain the username. The
common cases are using the CN(2.5.4.3) or the
UID(0.9.2342.19200300.100.1.1).

The document above tries a different approach (contacting LDAP), but I
think that's not necessary if some conventions are followed.

regards,
Nikos




More information about the sssd-devel mailing list