Subject: [Ietf-krb-wg] Fast VS gss preauth for Kerberos

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 18:00:46 -0400

Nico have had this discussion a couple of times.  I thought I'd write it
down so I can remember it in the future.

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> As you know, while I'm a fan of FAST, I'd rather have gone
    Nicolas> with a GSS-API pre-authentication framework for Kerberos.
    Nicolas> Of course, by now FAST is sufficiently well implemented
    Nicolas> that it's probably easier to plug into it than it would be
    Nicolas> to add a GSS-API pre-auth method to Kerberos...

I've been thinking more about FAST vs  GSS preauth.

As best I can tell they fit together nicely.  For example because we
have FAST, we can use anything with channel bindings as a preauth we
don't need to require gss_wrap.

With sufficiently strong gss_wrap style preauth we could have avoided
the need for armor keys.  However you'd need a fairly strong preauth
mechanism for that.  For example, I'm not sure SCRAM wouldn't be
significantly improved by armor.

If you agree that something like armor is necessary, I think GSS preauth
adds very little complexity over FAST.  You probably could have gotten a
simpler encoding if it wasn't for backward compatibility issues.

So, we may not have gone very far afield with FAST.  From an
implementation standpoint I'm definitely happy I was doing FAST not
gss-preauth.  I avoided the complexity of multi-round-trip state
management.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 17:19:20 -0500

> down so I can remember it in the future.

Heh.  Well, let me present my view as well.

> simpler encoding if it wasn't for backward compatibility issues.

The complexity trade-off ultimately would lie in composition.  FAST
provides a mechanism for that, while the GSS-API doesn't-but-could, so
anyone wishing to design my ideal would have to provide for composition.

The fact that FAST got there first is sufficient that without a need for
mechanism composition elsewhere, it won't happen for the GSS-API.  But a
GSS-API pre-auth mechanism that fits into FAST is certainly feasible,
and probably desirable.

Now, back to my world view...

Ideally the KDC protocol would be like any other application protocol
and not directly deal with "reply keys" or any such thing.  That is, a
client would connect[*], use SASL or GSS-API to mutually authenticate,
and use some security layer[**] to do simplified AS exchanges.  Neither
the AS-REQ nor the AS-REP would contain pre-auth data nor "encrypted
parts" (the Ticket itself, would, as usual, have an encrypted part, of
course).  Here SASL/GSS would provide pre-authentication outside the AS
exchange; an additional message pair for negotiating what mechanism to
use would be needed.  Stackable pseudo-mechanisms would have provided
for mechanism composition.

Note that in my ideal world the strength of keys that SCRAM could output
is irrelevant.  What matters is the strength of the keys provided by the
underlying channel in combination with the strength of the channel
binding.  Of course, the strength of SCRAM's channel binding is
consonant with the strength of SCRAM's PRF and per-message tokens.

[*]  UDP could be supported too.
[**] TLS, if bound to from the SASL or GSS authentication, or SASL
     security layers, or GSS-API wrap tokens with confidentiality
     protection.

But... that's not gonna happen.  It could, but it's too late.

The next ideal case is more or less as you described, with either FAST
or stackable GSS-API pseudo-mechanisms providing composition.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 18:28:08 -0400

Thanks for this write up.  I keep forgetting that stackable mechanisms
play into your model.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 17:35:49 -0500

I would also add that PKIX has something similar to the ideal that I
just described for Kerberos: SACRED.  It uses TLS, it uses SASL.  It
doesn't say anything about channel binding, but easily could.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg