Authentication flow for OAuth2 proxying over Kerberos protocol

MIT Kerberos implements a mechanism for one-time password (OTP) pre-authentication, as described in RFC 6560. The implementation in MIT Kerberos allows a KDC to ask an external RADIUS server for the authentication decision for a specific Kerberos principal. MIT Kerberos client, upon receiving a pre-authentication mechanism response from the KDC, interacts with a user by asking individual questions for OTP factors and further communicating back with KDC.

FreeIPA implements a shim RADIUS proxy, called ipa-otpd, which listens on a UNIX domain socket configured by default for KDC. If OTP pre-authentication method is allowed for the requested Kerberos principal, KDC queries a RADIUS server.

ipa-otpd implements two authentication flows:
- TOTP/HOTP token authentication, performed against FreeIPA LDAP server as an LDAP BIND operation;
- proxying RADIUS request to a remote RADIUS server

In either flow, ipa-otpd responds to a KDC request with a RADIUS packet constructed out of the result of authentication. KDC then performs the remaining communication as defined in RFC 6560.

This mechanism can be used to implement other authentication flows that can fit into a RADIUS exchange with Accept-Request and Accept-Response messages. An example of this approach is an Azure AD multi-factor authentication (MFA) extension to Microsoft's RADIUS server, NPS. The detailed flow is described Azure AD Multi-factor authentication how-to guide.

OTP pre-authentication mechanism drawbacks

Current implementations of OTP pre-authentication mechanism in MIT Kerberos and FreeIPA have one issue. Neither MIT Kerberos library and KDC nor ipa-otpd daemon support RADIUS flows where multiple messages per communication are required. RADIUS protocol defines Access-Challenge message that allows RADIUS server to request a continuation of a state processing between the server and the client. ipa-otpd does translate any response from a RADIUS server that is not Access-Accept into Access-Reject response. On its side, MIT Kerberos OTP pre-authentication implementation only handles Access-Accept and Access-Reject responses.

For OAuth 2.0 Device Authorization Grant flow ipa-otpd would need first to communicate to the integrated IdP. This step will produce a User Code and a Verification URI that will need to be sent back to the RADIUS client (KDC) and communicated further to Kerberos client side of OTP pre-authentication mechanism.

Thus, both ipa-otpd and MIT Kerberos need to be extended to handle Access-Challenge message.

MIT Kerberos needs to be extended to enable back/forth messaging between MIT Kerberos OTP pre-authentication mechanism on the client side and ipa-otpd to exchange information a Kerberos client has to show to the user.