Add support for Access-Challenge response for OTP/RADIUS

[Alexander Bokovoy]

On ti, 08 kesä 2021, Greg Hudson wrote:
>On 6/8/21 7:46 AM, Pavel Březina wrote:
>> At this moment, it accepts Access-Challenge and unconditionaly sends
>> another Access-Request which State attribute set. But I need help with
>> delivering the prompt to the user. Can you give me some hints on how to
>> deliver the prompt to the Kerberos client (e.g. kinit) and then send
>> user's reply back to KDC and RADIUS server.
>
>The RADIUS code in MIT krb5 is not designed to be a general
>RADIUS-to-krb5 bridge.  It's just there as a mechanism to verify a PIN
>sent over FAST OTP.  By the time the KDC makes a RADIUS request,
>interaction with the client (and therefore the user) has already ended,
>except for the delivery of an error or issued ticket.
>
>Can you describe at a higher level what the goal is?

Sure. A goal is to be able to perform OAuth 2.0 Device Authorization
Grant flow (https://www.rfc-editor.org/rfc/rfc8628) over Kerberos.

A draft of our design can be seen here, it is incomplete but gives some
higher level view:
https://github.com/abbra/freeipa/blob/external-idp/doc/designs/external-idp/external-idp.md#use-of-an-integrated-idp-to-verify-external-identities-for-freeipa

We would need to be able to initiate a request from the backend first to
an authorization server, obtain the verification URI and other
properties, then display those to the user and complete the operation by
using a code entered by the user.

Right now KDC side of OTP pre-auth plugin uses a principal's information
to generate an initial response. 

I guess what we are looking at is a way to make it possible for KDC side
of the OTP pre-auth mechanism to issue a request to RADIUS backend in
an edata() callback and then generate a challenge based on that.
otp_edata() right now only looks for a presence of 'otp' config in the
rock object but the token info challenge field is left empty itself.

E.g. we could have this change:

- check if 'otp' string is present in the rock config
   - if it is present, check if it contains a challenge request flag
     - if challenge request flag is present, ask RADIUS server for the
       information and expect it to return Access-Challenge with the
       State attribute.
       - if Access-Challenge is missing, fail OTP processing
       - if Access-Challenge is present, set the challenge of the token
	info into the challenge value from the RADIUS packet

OTP pre-auth on the client side already knows how to display the token
information challenge.

What we also need is to preserve the state from Access-Challenge to be
reused when client response would come back.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland