Subject: Re: [kitten] GSS-only enctypes

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Apr 2015 16:04:58 -0400 (EDT)

On Tue, 31 Mar 2015, Nico Williams wrote:

> I think the consensus at the meeting was that we could indeed reuse
> the Kerberos enctype number space for GSS-only enctypes, since there
> is some precedent for this.  It would be significantly easier, from an
> implementation perspective, to do just that.

I'm not sure that we got enough active input at the meeting on this
question to be able to declare consensus.  Regardless, we should ask the
list if there are objections to (or support for) using the Kerberos
enctype number space for enctypes with restricted usability (i.e., only
for subsession keys, or GSS, etc.).

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Wed, 01 Apr 2015 17:00:03 -0400

> for subsession keys, or GSS, etc.).

I didn't totally understand all of Nico's reasoning about this when he
spoke at the meeting.  In general I think it's fine; it lets us
negotiate AEAD enctypes using RFC 4537 enctype negotation and the
existing subkey fields when mutual auth is used.

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 16:05:53 -0500

> existing subkey fields when mutual auth is used.

Conversely, not reusing the RFC3961 enctype namespace means a) adding
a new extension like RFC4537 to carry the client's/initiator's AEAD
enctype list and sub-keys, b) extending AP-REP to carry the
server's/acceptor's sub-key and choice of AEAD enctype.  That seems
like lots of unnecessary complexity.

That's my reasoning.

Nico
--

---

From: Tom Yu <[email-masked]>
Date: Wed, 01 Apr 2015 17:58:37 -0400

> like lots of unnecessary complexity.

I generally agree with that reasoning.  I think we should clearly
document the security considerations of the "restricted usage enctype"
approach.  We should also require that future specifications of
restricted usage enctypes clearly document the security considerations
of using the restricted enctype outside of the intended scope, e.g.,
compromise of all future authentication if there is nonce reuse of a
long-term AES-GCM key.

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 17:06:03 -0500

> compromise of all future authentication if there is nonce reuse of a

Yes.

I'd rather say that AEAD enctypes are just NOT RFC3961 enctypes, and
they cannot be used in any RFC3961 interfaces.  But that approach does
increase the friction between a Kerberos GSS mechanism implementation
and the libkrb5 underneath (e.g., a krb5_authcontext wouldn't be able
to have GSS-only sub-keys, and extracting them from the Authenticator
and AP-REP might require new internal interfaces).

We might have to settle for simply not permitting use of AEAD in
non-GSS contexts.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Apr 2015 19:04:30 -0400 (EDT)

> We might have to settle for simply not permitting use of AEAD in

It's always nice to have these decisions guided by implementation
experience, if someone (TM) tries out the different approaches and can
attest to their strengths and weaknesses.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 19:17:08 -0500

> attest to their strengths and weaknesses.

Indeed.  I'll try out this approach and see how it goes.  I'll report
my findings when I get there.