Re: [kitten] Kerberos Preauth Registration for OAuth2 device flow

[Greg Hudson <[e-mail]>]

On 11/9/21 5:39 PM, Sam Hartman wrote:
> Basic approach.
> The KDC provides the client a URI  and a code (or a URI specific to that
> authentication interaction.)
> The client spawns a web browser, does stuff, and eventually somehow the
> client lets its Kerberos app know that authentication has happened, and
> then the KDC goes off to see if it believes that.
> 
> AS far as I can tell, the reply key is never used (it is replaced) so a
> long-term password is not needed.

Some additional context: this is essentially the same user experience as
one sees when authorizing a set-top box to a video streaming service
using OAuth2.  The initial proposal was to extend MIT krb5's FAST OTP
implementation to support this on the back end.  Although we got to the
point of a working implementation, I decided to recommend a new preauth
type because (1) sending an empty or meaningless otp-value doesn't fit
the spirit of OTP preauth, and (2) displaying a properly localized
prompt would require building a sub-protocol into the otp-challenge field.

Like FAST OTP without must-encrypt-nonce, this mechanism replaces the
reply key with the armor key, so that the mechanism can be used in place
of a long-term password.

> 1) It appears to have the same   issues with anonymous pkinit that OTP
> has.
> You probably do not want to use this FAST factor with a armor ticket you
> got from anonymous pkinit.
> If you do, you need to verify the KDC's identity elsewhere.

Note that MIT krb5's anonymous PKINIT implementation always
authenticates the KDC (via its certificate, which must have a signature
chain leading to an explicitly configured anchor).

If a Kerberos client contains an implementation of unauthenticated
PKINIT, I would expect it to also contain some facility for recognizing
armor tickets that don't authenticate the KDC, and reject the use of
those as armor for FAST OTP (without must-encrypt-nonce) or this mechanism.

> 2) This effectively gives you an arbitrary URI that you have no way to
> validate and encourages the user to go authenticate to that URI.
> 
>   * Appears to be a phishing vector

Potentially, as is FAST OTP.  One hopes that it is at least as difficult
to fool a user into authenticating to a malicious Kerberos realm as it
would be to directly fool the user into authenticating to the malicious
URI.  The user is not being asked to present any additional information
of value to the given URI beyond what is necessary to authenticate,
since the code is presented by the same authority as the URI.

>   * Appears to be a malicious code vector.  I'm particularly concerned
>     about a case where this is part of machine login.  You'd be running
>     potentially attacker supplied  code in a pre-login context.  I hope
>     your sandboxing is good.

I don't think we're expecting the Kerberos client implementation to fire
up its own web browser.  As with a set-top box or similar device, the
URL and code are presented to the user in a prompt.  If this mechanism
were used at login time, the user would probably have to run the browser
on a different device.

> On the interoperability side, the protocol between the KDC  and the
> OAuth provider does not appear to be described at all.
> You get vendor lockin between a KDC and OAuth provider as far as I can
> tell.

Preauth mechs don't generally specify back-end protocols; certainly RFC
6560 does not.  The FreeIPA implementation will (to the best of my
knowledge) use RADIUS, with the URL and code being presented to the KDC
in an Access-Challenge with an accompanying State.  An encrypted
PA-FX-COOKIE can be used to remember the state between the first client
request and the second.  There are some details that would have to be
squared between interoperable implementations, such as the
Access-Challenge format and the cookie format.  (MIT documents its
encrypted PA-FX-COOKIE facility, but there is likely to be some
formatting of the preauth-type-specific cookie contents as well.)

Luke wrote:
> would the vendor consider defining as a GSS-API mechanism that could be used with draft-perez-krb-wg-gss-preauth?

I think that would be a significant hurdle.  Note that for a
single-threaded KDC, this mechanism is ideally implemented with
asynchronous communication between the KDC and the identity provider.  A
generic GSSAPI preauth bridge probably can't do that.