Valid Sender ? - Re: [Freeipa-users] Using Privacyidea with FreeIPA - part 1/n

Question
1

Martin Basti mbasti@redhat.com writes:

Hello, I have a few comments/questions related to HOTP inline

Sure :slight_smile:

I’ve settled for the following usage of the slots:

  • Slot 1: This is a (reprogrammed) Yubico-AES token, which
    authenticates against Privacyides yubico mode instead of Yubicos
    cloud server.

    Why Yubico and not HOTP or TOTP?

    Here FreeIPA fails for me: Yubikey can’t do TOTP, HOTP token can get
    out of sync, when we use them for local authentication, FreeIPA and
    Kolab (each application has a count, which needs to be “in near
    sync” with the counter in the Yubikey. I wouldn’t trust such a
    setup.)

AFAIK this is security feature to have “Window of allowed tokens” and
counter is essential for HOTP,
RFC 4226 - HOTP: An HMAC-Based One-Time Password Algorithm

Exactly. So it seems essential for me, that only one system can be the
owner of the token (has the secret and counter to check the validity of
an OTP). This is for both HOTP and Yubico-AES (cloud validation). So
at first they look more or less identical, but why did I choose Yubico?
Two usecases for me will work with yubico-AES, but not easily with HOTP
(or maybe as well…).

First is Kolab, my mailserver. With the current (development) release I
can use 2FA with HOTP/TOTP and yubico-AES. Kolab wants to be the owner
of the HOTP/TOTP token, so the Yubikey couldn’t be used for other
applications. Right now there is no external validation for TOTP/HOTP
implemented. But we can ask a yubico validation server
(e.g. privacyidea) which is the owner of my yubico AES token.

Second is pam_yubico, which asks my privacyidea server for validation.
For HOTP is might be possible to use something like
pam_googleauthenticator, but with Kolab I didn’t see a solution.

So, one yubikey is enrolled privacyidea and can be used by multiple
applications with pam_yubico, yubico validation protocol and RADIUS, but
the secret and counter is only stored in privacyidea…

But providing access to a Yubico Token via privacyidea works for all
cases I have in mind.

How they are checking the valid tokes if they don’t use its counter?

Privacyidea is the “owner” of the token and has the secret and the
counter stored. Every other system (e.g. pam_yubico or FreeIPA) is
checking the validation against privacyiadea, either with the yubico
protocol, the privacyidey validation, or RADIUS.

Does this clarify the architecture of my system?

Jochen> On 28.12.2016 13:54, Jochen Hein wrote:

–
The only problem with troubleshooting is that the trouble shoots back.

2

Hi Jochen,

this is a very important point.
Every application is adopting two factor authentication with OTP. This is
great - we always hoped for such a security awareness.
But the important difference is:
The common webapplication that finally will implement TOTP (“this cloudy
algorithm which was invented by the Google Authenticator” :wink: ) manages the
seeds/keys for these tokens. If the user uses a smartphone app the user
will end up with an “OTP token” or “profile” in his App for every
application.

Or he has to share the seeds one seed between all applications. And then he
runs into the troubles mentioned earlier.

You perfectly pointed out, why you need a central authentication system for
managing the second factors.
From a user experience point fo view the applications could also go for
U2F. Then the user again will only have one device, which he needs tor
register with each application…
…but there will be no “syncing” problem.

Kind regards
CorneliusAm Donnerstag, 29. Dezember 2016 20:45:34 UTC+1 schrieb Jochen Hein:

Martin Basti <m...i@redhat.com mbasti@redhat.com> writes:

But providing access to a Yubico Token via privacyidea works for all
cases I have in mind.

How they are checking the valid tokes if they don’t use its counter?

Privacyidea is the “owner” of the token and has the secret and the
counter stored. Every other system (e.g. pam_yubico or FreeIPA) is
checking the validation against privacyiadea, either with the yubico
protocol, the privacyidey validation, or RADIUS.

Does this clarify the architecture of my system?

Jochen

–
The only problem with troubleshooting is that the trouble shoots back.

3

…by the way. This is probably the reason, why Red Hat uses the
predecessor of privacyIDEA as central 2FA authentication system for the OTP
authentication.

Kind regards
CorneliusAm Freitag, 30. Dezember 2016 08:21:36 UTC+1 schrieb Cornelius Kölbel:

Hi Jochen,

this is a very important point.
Every application is adopting two factor authentication with OTP. This is
great - we always hoped for such a security awareness.
But the important difference is:
The common webapplication that finally will implement TOTP (“this cloudy
algorithm which was invented by the Google Authenticator” :wink: ) manages the
seeds/keys for these tokens. If the user uses a smartphone app the user
will end up with an “OTP token” or “profile” in his App for every
application.

Or he has to share the seeds one seed between all applications. And then
he runs into the troubles mentioned earlier.

You perfectly pointed out, why you need a central authentication system
for managing the second factors.
From a user experience point fo view the applications could also go for
U2F. Then the user again will only have one device, which he needs tor
register with each application…
…but there will be no “syncing” problem.

Kind regards
Cornelius

Am Donnerstag, 29. Dezember 2016 20:45:34 UTC+1 schrieb Jochen Hein:

Martin Basti <m...i@redhat.com mbasti@redhat.com> writes:

But providing access to a Yubico Token via privacyidea works for
all
cases I have in mind.

How they are checking the valid tokes if they don’t use its counter?

Privacyidea is the “owner” of the token and has the secret and the
counter stored. Every other system (e.g. pam_yubico or FreeIPA) is
checking the validation against privacyiadea, either with the yubico
protocol, the privacyidey validation, or RADIUS.

Does this clarify the architecture of my system?

Jochen

–
The only problem with troubleshooting is that the trouble shoots back.