Re: [kitten] GSS-only enctypes

[Nico Williams <[e-mail]>]

On Wed, Apr 1, 2015 at 4:58 PM, Tom Yu <[e-mail]> wrote:
> Nico Williams <[e-mail]> writes:
>
>> On Wed, Apr 1, 2015 at 4:00 PM, Greg Hudson <[e-mail]> wrote:
>>> On 04/01/2015 04:04 PM, Benjamin Kaduk wrote:
>>>> 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.).
>>>
>>> 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.
>>
>> 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.
>
> 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.

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