Re: [TLS] Design Alternatives for Kerberos + DH

[Benjamin Kaduk <[e-mail]>]

On 10/16/2015 04:13 PM, Nikos Mavrogiannopoulos wrote:
> ----- Original Message -----
>> Hello,
>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.
>> PRO: Good integration with TLS: Tickets are transported in the
>> ClientCertificate, and an Authenticator is the ClientVerify.  DH is
>> independent and can move to the earlier phase for TLS 1.3.
>> CON: Decision on client credential type must be made in ClientHello, when not
>> all data may be available (namely, the sequence of tickets leading to the
>> TLS-protected service).  Also impacts the cert-type used in the ServerCert.
>
> What messages do you need to transfer for Kerberos? Is it only a ping-pong? In that
> case, do the supplemental data from RFC4680 provide a solution with PSK in TLS 1.2?
>

4680 says "[a]ny such data MUST NOT need to be processed by the TLS
protocol.", which seems to disqualify it from applicability here.

In any case, the messages needed for Kerberos vary somewhat depending on
the desired properties.  When using Kerberos solely for client
authentication, the combination of a Ticket and Authenticator is valid
as essentially a bearer token within the clock skew window of five
minutes and subject to replay.  The client (or server, or both) can pick
a subsession key encrypted by the session key in the Ticket, and if
another message is passed that uses a subsession key for
confidentiality/integrity (such as a response from the server to perform
"mutual" (i.e., server) authentication, then there is less need for a
replay cache.  An additional key-confirmation message to validate the
server-selected subsession key (such as actual application traffic being
encrypted in that key) is helpful for the security analysis, but not
always available depending on the constraints of the application protocol.

-Ben