Subject: [kitten] draft-perez-krb-wg-gss-preauth

From: Luke Howard <[email-masked]>
Date: Sun, 1 Aug 2021 23:37:57 +1000

I’m working on an implementation of draft-perez-krb-wg-gss-preauth-02.txt for Heimdal.

Is this something the working group would consider adopting?

Luke Howard
web <http://lukehoward.com/> / facebook <https://www.facebook.com/lukehowardmusic> / instagram <http://instagram.com/lukehowardmusic/> / spotify <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Aug 2021 18:46:51 -0700

> Is this something the working group would consider adopting?

It doesn't seem fundamentally like a bad idea, but since we typically
recommend that applications should use the GSS-API rather than Kerberos
directly, it's not entirely clear to me what situations will require
the GSSAPI->Kerberos bridge as opposed to using GSS-API natively.

-Ben

---

From: Luke Howard <[email-masked]>
Date: Mon, 2 Aug 2021 12:07:18 +1000

> the GSSAPI->Kerberos bridge as opposed to using GSS-API natively.

Good point. Our use case is supporting existing applications where it’s not feasible to install a new GSS-API mechanism on the acceptor (for reasons of local policy, platform limitations, etc).

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Aug 2021 19:16:03 -0700

> Good point. Our use case is supporting existing applications where it’s not feasible to install a new GSS-API mechanism on the acceptor (for reasons of local policy, platform limitations, etc).

Thanks, that makes the motivation a bit more clear.

-Ben

---

From: Luke Howard <[email-masked]>
Date: Mon, 2 Aug 2021 19:30:12 +1000

> Thanks, that makes the motivation a bit more clear.

I suppose another use case might be a fast re-authentication mechanism for GSS mechanisms that involve a lot of round trips (such as EAP). Of course this could be handled within the mechanism itself or as a pseudo-mechanism but, in practice, neither have been deployed.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 2 Aug 2021 12:23:24 -0400

On 8/1/21 9:37 AM, Luke Howard wrote:
> I’m working on an implementation
> of draft-perez-krb-wg-gss-preauth-02.txt for Heimdal.
> 

I'm not writing to support adoption, but I did have a note on the draft.
 PA-GSS contains a state object which has similar protections as is
needed for PA-FX-COOKIE (see
https://web.mit.edu/kerberos/krb5-latest/doc/formats/cookie.html
and note the additional binding of the client principal to the cookie
encryption key).  It might facilitate sharing to just handle the state
via PA-FX-COOKIE rather than baking it into the preauth mech.

---

From: Luke Howard <[email-masked]>
Date: Tue, 3 Aug 2021 13:47:38 +1000

Hi Greg,

That sounds like a great idea, although obviously it will require FAST for multiple round-trip GSS mechanisms. I’ve provisionally implemented it in Heimdal, albeit using its existing KDCFastState (below).

-- KDCFastState is stored in FX_COOKIE
KDCFastState ::= SEQUENCE {
        flags [0] KDCFastFlags,
        expiration [1] GeneralizedTime,
        fast-state [2] METHOD-DATA,
        expected-pa-types [3] SEQUENCE OF PADATA-TYPE OPTIONAL
}

Cheers,
Luke

Luke Howard

---

From: Luke Howard <[email-masked]>
Date: Wed, 4 Aug 2021 21:43:56 +1000

Greg, If we make FAST a hard requirement, would you suggest dropping the PA-GSS type and encoding the context token directly?

Alex, is it possible to get the source for the draft? (If you’re amenable to me adding my name to it and progressing it, even as a personal draft.)

---

From: Greg Hudson <[email-masked]>
Date: Wed, 4 Aug 2021 13:11:03 -0400

> Greg, If we make FAST a hard requirement, would you suggest dropping the PA-GSS type and encoding the context token directly?

Note that FAST armor is not required to use the cookie.  SPAKE preauth
requires PA-FX-COOKIE support but not FAST armor.

I have no opinion on whether to encode the context token directly or
give it an ASN.1 wrapper.

---

From: Luke Howard <[email-masked]>
Date: Thu, 5 Aug 2021 08:06:30 +1000

> requires PA-FX-COOKIE support but not FAST armor.

Ah, I didn’t realise that. OK, that sounds like a good approach then.