Add support for Access-Challenge response for OTP/RADIUS
abokovoy at redhat.com
Wed Jun 9 03:36:15 EDT 2021
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:
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
- 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
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
More information about the krbdev