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

[Sam Hartman <[e-mail]>]

>>>>> "Greg" == Greg Hudson <[e-mail]> writes:

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

    Greg> Some additional context: this is essentially the same user
    Greg> experience as one sees when authorizing a set-top box to a
    Greg> video streaming service using OAuth2.  The initial proposal
    Greg> was to extend MIT krb5's FAST OTP implementation to support
    Greg> this on the back end.  
    Greg> Like FAST OTP without must-encrypt-nonce, this mechanism
    Greg> replaces the reply key with the armor key, so that the
    Greg> mechanism can be used in place of a long-term password.

I think you and the person submitting the registration to the IANA are
in the mind set of "This is how we're going to use this," and are
thinking about  the security analysis of that and  of  your intended
usage.

I think my job is to imagine all the ways people might try to use a
protocol like this  and think about those implications.
So, I think my job is to think much more broadly than how you're
thinking.
And some of your responses to me come across  roughly of the form of
"but we weren't going to do that."

If this were an IETF reviewed document, I'd probably say "But someone
probably will; it's the Internet."
For an expert review, though I think it's a lot more relaxed.

I think a couple of things would make me happy to approve this:

1) The registration template submitted to IANA did not actually include
a name for the assigned  value.
I'd like to include Redhat or FreeIPA in the name.
If we do that I think it will make it more clear we're focused on a
specific use case.

2) it sounds like  you eventually plan to release a spec or some
documentation or something.
In most of the cases where I or anyone else brings something up, a fine
response would be to  track that as something to include in eventual
docs.
In effect, to make sure you document restrictions on the scope or
intended use.


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

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

Yes, and I think OTP's security considerations talks about that.
I think agreeing this would be something to mention as a constraint
would resolve this concern.

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

    Greg> Potentially, as is FAST OTP.  One hopes that it is at least as
    Greg> difficult to fool a user into authenticating to a malicious
    Greg> Kerberos realm as it would be to directly fool the user into
    Greg> authenticating to the malicious URI.

I'm not at all sure this is generally true.
In protocol design we've often found that  adding a new mechanism for
redirects has security implications.

In this case, your trust model is at least more complex than the
traditional trust model of Kerberos because you now need to trust
probably the web PKI to authenticate the URI.

I think this is probably safe in a situation where you have a statically
configured realm.  I'm less sure about a situation where this mechanism
is used with clients that can successfully authenticate to a wide
variety of KDCs all with different trust levels.


I suspect you are making some assumptions about how this will be used
under which this is probably safe.
For example in a relatively closed environment with a single realm that
is also closely connected with the OAuth provider this seems safe.

What I'm hoping for here at a minimum is acknowledgement that  when
you're talking about the security of this scheme you will explain the
assumptions under which phishing is not an issue.

The IETF also provides a great place to discuss those assumptions if you
want to get additional feedback on your security analysis.

    Greg> The user is not being
    Greg> asked to present any additional information of value to the
    Greg> given URI beyond what is necessary to authenticate, since the
    Greg> code is presented by the same authority as the URI.

I agree, but that's not the attack I was envisioning.
I was worried about a case where a user gets a URI from a KDC that they
shouldn't have trusted as much as they do
and authenticates to a URI provided by that KDC.
If I have a strong password with Kerberos, particularly with SPAKE,
authenticating to the wrong KDC doesn't hurt me much.

But this mechanism could be used for converting a federated identity of
some kind into a local identity.
In a case where I don't know the realm where I'm getting a new local
identity well, I could be phished if they give me a URI that is an MITM
for some site where I have an account.

I suspect your use cases for this protocol rule out the sort of
deployments I'm thinking about.
For a non-IETF document I think that's fine, I'm just asking you to
think about and confirm it is secure in your use case and write it down
when you get there.


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

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

Okay, sounds like another thing you are ruling out of scope
Would you be willing to track and write down when you do describe
security?

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

    Greg> Preauth mechs don't generally specify back-end protocols;
    Greg> certainly RFC 6560 does not.

I think it's the first preauth mechanism where that was an issue.
My thoughts at the time reading the draft was that the kind of tokens
used for OTP were fairly well understood  and it wasn't a big deal.

I think my answer here is that I personally don't mind the  backend
protocol being out of scope, and no one else in the WG seems to mind
either, so it is okay.


So, in conclusion, if nothing else comes up i propose that:

1) We agree on a name for the preauth constant that makes it clear this
is either Redhat or FreeIPA specific or something like that.

2) You track the security concerns and when you eventually produce
documentation explain the use case in a way that scopes it to a use case
where the protocol is safe

3) Without waiting for 2, I approve the registration.