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

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Nov 2021 15:39:35 -0700

It's been a while.
I recently received a Kerberos preauth expert review request from IANA.
The goal of the padata registration is to provide a way to perform
Kerberos authentication based on the OAuth2 device authorization flow.
Based on the criteria in section 7.1 of RFC 6113, I have determined that
expert review is appropriate for this assignment.
Based on section 3 of RFC 5226, I am seeking input from the relevant
community.
As a reminder, for this type of registration, we're supposed to review
for security and interoperability concerns.

I don't think there is a public spec; I was given a pointer to a Google
doc.
For this registry that is not required, although as part of an
interoperability review, the availability of a spec is something we
could legitimately consider.

I think it is desirable to have such a mechanism, so I'd like to
expediciously get to a place where we can provide any feedback and once
that is addressed, approve the registration.

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.

There was no security considerations section in the document I got.
Again, that's permitted by the registry, although it is also permitted
for us to raise concerns about that in a specific instance.
That does mean I'm stuck figuring out what the security considerations
are.

I think what I'd like to do is to star by making sure the authors are
aware of the security considerations, and see if there are mitigations
that can be applied.
Then see how we feel about the overall security of the system.

Concerns I have:

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.

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

  * 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.

  * If this is a highly trusted KDC, everything might be great.  However
    there are a lot of cases in Kerberos (even with FAST) where you can
    get an untrusted KDC, and the mechanisms for KDC selection are less
    well protected than the rest of the protocol.  (That's particularly
    true given some implementation issues).  Having an armor ticket does
    not mean it is wise to trust a particular KDC.

3) Again, I think the security implications are different if you're
already logged into the OAuth side  vs if you're going to do an initial
authentication flow with your OAuth provider.

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.

I'd appreciate feedback on the following issues:

A) Are there any additional security or interoperability concerns I
should be thinking about?

B) Are there mitigations we should suggest?

C) Where should the bar for approval be?

I'd appreciate comments in the next two weeks.

--Sam

---

From: Luke Howard <[email-masked]>
Date: Wed, 10 Nov 2021 13:11:47 +1100

[resending from subscribed email, sorry Sam/Pavel]

Hi Sam,

> long-term password is not needed.

Talking my own book here (although, I have no commercial interest) – would the vendor consider defining as a GSS-API mechanism that could be used with draft-perez-krb-wg-gss-preauth? (I suppose, if it needs to work with MIT as opposed to Heimdal, this may be a non-starter as the GSS pre-authentication implementation for MIT is experimental and only supports an earlier version of the draft.)

> If you do, you need to verify the KDC's identity elsewhere.

Right, this is also something that came up with GSS pre-authentication. Of course, if FAST isn’t used then you also have the same problem.

Can they use TLS inside the PA exchange to authenticate the KDC?

Cheers,
Luke

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Nov 2021 09:26:57 -0700

>>>>> "Luke" == Luke Howard <lukeh=[email-masked]> writes:

    >> AS far as I can tell, the reply key is never used (it is
    >> replaced) so a long-term password is not needed.

    Luke> Talking my own book here (although, I have no commercial
    Luke> interest) – would the vendor consider defining as a GSS-API
    Luke> mechanism that could be used with
    Luke> draft-perez-krb-wg-gss-preauth?

I think that would add a fair bit of complexity.
The current mechanism
requires you to either simply display a prompt (and let the user deal
with a web browser)
or to embed a web browser widget into your UI.

Your proposal adds  a fair bit of complexity.
If you wanted to support    any facilities like channel bindings, you
need a fair bit more complexity than what is currently being proposed.
If all you support is a GSS-API mechanism without mutual authentication,
per-message tokens or  channel bindings, what's the point?

    >> 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.

    Luke> Right, this is also something that came up with GSS
    Luke> pre-authentication. Of course, if FAST isn’t used then you
    Luke> also have the same problem.

This is a FAST factor.

    Luke> Can they use TLS inside the PA exchange to authenticate the
    Luke> KDC?

What does this give you?
How do you bind that back to something the user knows.
How is this better than a anonymous pkinit armor ticket?