[20289] in Kerberos_V5_Development
Re: Add support for Access-Challenge response for OTP/RADIUS
daemon@ATHENA.MIT.EDU (Alexander Bokovoy)
Wed Jun 9 03:37:06 2021
Date: Wed, 9 Jun 2021 10:36:15 +0300
From: Alexander Bokovoy <abokovoy@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <YMBvb10Gt2F9iTFj@redhat.com>
MIME-Version: 1.0
In-Reply-To: <b746d225-af5e-8d05-7237-f8f000c15207@mit.edu>
Content-Disposition: inline
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
