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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
