[kitten] Kerberos Preauth Registration for OAuth2 device flow

[Sam Hartman <[e-mail]>]

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