Re: [kitten] GSS-only enctypes

[Tom Yu <[e-mail]>]

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.