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

From: Greg Hudson <[email-masked]>
Date: Wed, 10 Nov 2021 01:22:07 -0500

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.

---

From: Pavel Březina <[email-masked]>
Date: Wed, 10 Nov 2021 15:08:36 +0100

> generic GSSAPI preauth bridge probably can't do that.

Hi Sam,
thank you for looking into it. I've been collaborating with Greg on this 
for a while now and I see he summarized it well.

We don't have public specification available right now (or not formally 
committed) since it is all work in progress, but we will have one in the 
future. If it is required, we can prioritize this tasks.

The backend use RADIUS (more specifically ipa-otpd from FreeIPA) and 
works very similar to otp implementation in MIT Kerberos. The very first 
implementation actually just extended otp with support of 
Access-Challenge message and Reply-Message and State attributes as Greg 
already explained.

Thank you,
Pavel.

---

From: Pavel Březina <[email-masked]>
Date: Thu, 18 Nov 2021 14:30:19 +0100

Hi Sam,
the discussion has been stalled for over a week. Is there any 
information that is required from me?

Thank you,
Pavel

On 11/10/21 15:08, Pavel Březina wrote:
>>> would the vendor consider defining as a GSS-API mechanism that could 
>>> be used with draft-perez-krb-wg-gss-preauth?
>>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Nov 2021 15:15:22 -0700

>>>>> "Greg" == Greg Hudson <[email-masked]> 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.
    >> 

    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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Nov 2021 17:51:38 -0800

Thanks all for the great discussion so far.

> protocol being out of scope, and no one else in the WG seems to mind

While I personally would prefer to specify the backend protocol, I think
that the current trends in the IETF are that this kind of backend protocol
does not need to be fully specified.

-Ben

---

From: Pavel Březina <[email-masked]>
Date: Fri, 19 Nov 2021 15:41:51 +0100

Hi Sam,

thank you for thorough reply.

> 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

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

---

From: Greg Hudson <[email-masked]>
Date: Sun, 21 Nov 2021 14:19:36 -0500

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

I think this is reasonable, and the name PA-REDHAT-IDP-OAUTH2 proposed
by Pavel seems fine.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Nov 2021 17:24:27 -0700

Do you have thoughts on a value?
167?

--Sam

---

From: Greg Hudson <[email-masked]>
Date: Tue, 23 Nov 2021 01:37:06 -0500

On 11/22/21 7:24 PM, Sam Hartman wrote:> Do you have thoughts on a value?

167 is PA-PAC-OPTIONS (MS-KILE 3.1.5.1).  Given Microsoft's history of
using types without registration, I would avoid anything in the 160-180
space as a practical matter.

I haven't heard of any conflicts with SPAKE being 151, so I think 152
should be safe.  But I would also be fine with picking a somewhat higher
base for registered but non-IETF-standardized types.

---

From: Pavel Březina <[email-masked]>
Date: Fri, 26 Nov 2021 14:01:16 +0100

> base for registered but non-IETF-standardized types.

I'm fine with any number, but using higher for non-standard types sounds 
like a reasonable thing to do.