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.
>
>