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

[Pavel Březina <[e-mail]>]

On 11/18/21 23:15, Sam Hartman wrote:
>>>>>> "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:

Hi Sam,

thank you for thorough reply.

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

The proposal write-up contained a name PA-IDP-OAUTH2. If you think it is 
better to show Red Hat/FreeAPI affiliation we can use the name:

PA-REDHAT-IDP-OAUTH2

> 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

I agree.

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

We will prioritize and focus on describing the preauthentication method 
in more detail, including the backend specifics and security analyses in 
a publicly available document. Once the work is finished, this document 
will be presented either in FreeIPA or SSSD documentation.

If you are not comfortable with the approval without this document and 
further discussion, we are certainly willing to wait and provide more 
information.

Thank you,
Pavel.