Hi list.
I have 2FA enabled for many users in my organization, however some of these users work on their own private devices and manually run kinit to obtain the TGT.
I was wondering why does kinit ask to: "Enter OTP Token Value: "
This message is slightly confusing. In fact, the user is supposed to enter password+OTP here.
I've attempted reading RFC 6560. If I understand correctly, OTP is not really supposed to be used as a 2nd factor with Kerberos?
Another minor trouble with BYOD setups is that the OTP user has to manually obtain anonymous ticket for FAST, before being able to run kinit.
Interestingly, FAST is not required for Smart Card PKINIT to work.
None of this is really a big problem, it's just troublesome to explain in one sentence "how does Kerberos authentication work in our organization".
Of course with Linux clients joined to the IPA domain, all of these details are abstracted by sssd and therefore a non-issue from the user's perspective.
Best regards, Radoslaw
On ke, 04 marras 2020, Radoslaw Kujawa via FreeIPA-users wrote:
Hi list.
I have 2FA enabled for many users in my organization, however some of these users work on their own private devices and manually run kinit to obtain the TGT.
I was wondering why does kinit ask to: "Enter OTP Token Value: "
This message is slightly confusing. In fact, the user is supposed to enter password+OTP here.
I've attempted reading RFC 6560. If I understand correctly, OTP is not really supposed to be used as a 2nd factor with Kerberos?
Let's say it is more of a design choice. There are several factors at play here. First, some of OTP methods require sharing the OTP value with the other side to perform validation. These need the value to be sent to KDC and it needs to be sent -- and bound to -- over an encrypted channel. Now, some of those encrypted channels might be subject for a MITM attack. RFC 6560 talks about one attack vector -- when using Anonymous PKINIT and not verifying the identity of the KDC.
If you are able to verify identity of the KDC prior to building your encrypted channel, passing OTP value over it -- and using channel binding to the outer channel -- is fine.
Consider SSSD case: it uses host keytab to establish FAST channel, verifying the KDC identity before the FAST channel is built. This is OK. You actually can use any other existing and valid ticket to create a FAST channel. It is just that there is none right now that would otherwise be used by an unprivileged client -- other than Anonymous PKINIT.
In Anonymous PKINIT as your FAST case you need to verify the identity of the KDC somehow. This is hard as you either have something to trust around it or you simply have to trust. It would be great if a user process could rely on something like GSS-Proxy to involve it in acquiring a ticket to a user based on a FAST channel established by the privileged process (GSS-Proxy). This is not possible right now for a number of reasons, though:
- GSS-Proxy interposes GSSAPI, not raw Kerberos, so kinit as a tool is out of question
- GSSAPI doesn't have means to pass through multipile questions and answers between the client application and the mechanisms wrapped by the GSSAPI
Technically, password+OTP can be given to a tool that uses GSSAPI and then interposed by GSS-Proxy to use host-based keytab as a FAST. There is, however, no way right now to enforce the use of this secret only to happen over a secure channel.
Again, it is all possible to extend. We had discussed somewhat similar line of thoughts on #krbdev some time ago and sure, this all could be done. It just weren't, so far.
Another minor trouble with BYOD setups is that the OTP user has to manually obtain anonymous ticket for FAST, before being able to run kinit.
Interestingly, FAST is not required for Smart Card PKINIT to work.
Smartcard PKINIT uses KDC certificate to build an exchange. You have to trust the certificate presented by KDC and the logic in MIT Kerberos PKINIT preauthentication module implements additional checks before it derives a session key to use. There is CA trust involved on both client and KDC sides, there is verification of the krbtgt/REALM@REALM principal SAN in the KDC-presented certificate or additional EKUs if the latter is missing.
None of this is really a big problem, it's just troublesome to explain in one sentence "how does Kerberos authentication work in our organization".
The 'holy grail' for solving this problem is to get multi-factor part of SPAKE preauthentication method to be finally specified and implemented. Right now we have single factor SPAKE in place, so we don't need to depend on the timestamp encryption as a pre-authentication anymore. With multi-factor SPAKE we wouldn't need to use FAST to establish an outer, encrypted, channel to pass what is essentially a plain-text data between the client and the KDC.
Thank you for the thorough explanation!
Best regards, Radoslaw
On 11/7/20 8:45 PM, Alexander Bokovoy via FreeIPA-users wrote:
On ke, 04 marras 2020, Radoslaw Kujawa via FreeIPA-users wrote:
Hi list.
I have 2FA enabled for many users in my organization, however some of these users work on their own private devices and manually run kinit to obtain the TGT.
I was wondering why does kinit ask to: "Enter OTP Token Value: "
This message is slightly confusing. In fact, the user is supposed to enter password+OTP here.
I've attempted reading RFC 6560. If I understand correctly, OTP is not really supposed to be used as a 2nd factor with Kerberos?
Let's say it is more of a design choice. There are several factors at play here. First, some of OTP methods require sharing the OTP value with the other side to perform validation. These need the value to be sent to KDC and it needs to be sent -- and bound to -- over an encrypted channel. Now, some of those encrypted channels might be subject for a MITM attack. RFC 6560 talks about one attack vector -- when using Anonymous PKINIT and not verifying the identity of the KDC.
If you are able to verify identity of the KDC prior to building your encrypted channel, passing OTP value over it -- and using channel binding to the outer channel -- is fine.
Consider SSSD case: it uses host keytab to establish FAST channel, verifying the KDC identity before the FAST channel is built. This is OK. You actually can use any other existing and valid ticket to create a FAST channel. It is just that there is none right now that would otherwise be used by an unprivileged client -- other than Anonymous PKINIT.
In Anonymous PKINIT as your FAST case you need to verify the identity of the KDC somehow. This is hard as you either have something to trust around it or you simply have to trust. It would be great if a user process could rely on something like GSS-Proxy to involve it in acquiring a ticket to a user based on a FAST channel established by the privileged process (GSS-Proxy). This is not possible right now for a number of reasons, though:
- GSS-Proxy interposes GSSAPI, not raw Kerberos, so kinit as a tool is out of question
- GSSAPI doesn't have means to pass through multipile questions and answers between the client application and the mechanisms wrapped by the GSSAPI
Technically, password+OTP can be given to a tool that uses GSSAPI and then interposed by GSS-Proxy to use host-based keytab as a FAST. There is, however, no way right now to enforce the use of this secret only to happen over a secure channel.
Again, it is all possible to extend. We had discussed somewhat similar line of thoughts on #krbdev some time ago and sure, this all could be done. It just weren't, so far.
Another minor trouble with BYOD setups is that the OTP user has to manually obtain anonymous ticket for FAST, before being able to run kinit.
Interestingly, FAST is not required for Smart Card PKINIT to work.
Smartcard PKINIT uses KDC certificate to build an exchange. You have to trust the certificate presented by KDC and the logic in MIT Kerberos PKINIT preauthentication module implements additional checks before it derives a session key to use. There is CA trust involved on both client and KDC sides, there is verification of the krbtgt/REALM@REALM principal SAN in the KDC-presented certificate or additional EKUs if the latter is missing.
None of this is really a big problem, it's just troublesome to explain in one sentence "how does Kerberos authentication work in our organization".
The 'holy grail' for solving this problem is to get multi-factor part of SPAKE preauthentication method to be finally specified and implemented. Right now we have single factor SPAKE in place, so we don't need to depend on the timestamp encryption as a pre-authentication anymore. With multi-factor SPAKE we wouldn't need to use FAST to establish an outer, encrypted, channel to pass what is essentially a plain-text data between the client and the KDC.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Radoslaw Kujawa