Subject: [TLS] Design Alternatives for Kerberos + DH

From: Rick van Rein <[email-masked]>
Date: Fri, 16 Oct 2015 18:31:15 +0200

Hello,

Based on the feedback in this WG, I'm now redefining TLS-KDH to keep ECDH and Kerberos orthogonal.  That simplifies matters enormously.  I can now see a few design alternatives.  If you have any response to them, it is kindly appreciated!

1) Continue to use KeyExchange

This variation sends a Ticket + Authenticator in the ClientKeyExchange, but
DH is now mentioned in plaintext instead of encrypted in the Authenticator.

PRO: Prior handshake can be taken into account in an Authenticator hash (a.k.a. "checksum").

CON: Special case for KeyExchange; doesn't integrate automatically with TLS 1.3.

2) Embed the Ticket + Authenticator in a PSK

This uses the binary blurb of the PSK to wrap the Ticket and Authenticator.

PRO: Client authenticates very early, in the ClientHello.

CON: PSK is untyped, so it requires separate agreement on the contents.  It is impossible to incorporate ServerHello information in the exchange.  The server has not indicated if it supports Kerberos, so the client must make a leap of faith.  PSK replies the selected PSK identifier, rather than send a response message; it is not designed for messaging purposes.

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.

4) Define an X.509 embedding for Tickets

Certificates provide an id/key binding with a signature by a trusted party; although the AlgorithmIdentifiers used here are new, they do fit in the X.509 framework.  This is rather out-of-the-box thinking, so I tested the idea, see https://github.com/arpa2/kerberos2pkix

PRO: Minimal changes to TLS, since Kerberos is now a signing algorithm.  The server can independently authenticate using RSA & co (on top of Kerberos' mutual authentication).  Ticket + timestamp-Authenticator go into an X.509 ClientCertificate, and an Authenticator including the hash over prior TLS messages can go into ClientVerify.  CertificateRequest can mix options for Kerberos, RSA, and so on, and client selects whatever it can get to locally, giving the best user experience.  We can also support user-to-user connections and S4U2Proxy a.k.a. "Constrained Delegation".

CON: These certificates are symmetrically keyed, which is uncommon.  Certificates are not readable to anyone, but only to the remote peer.  Certificate owner is ideally read from the embedded ticket, rather than from the subject field.

My money is on the last two, but option 4. really needs feedback because it is a bit wild.  When I get an idea where to go, I will be happy to write a new draft version... a much smaller and simpler one this time!

Cheers,
 -Rick

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Oct 2015 14:48:26 -0400 (EDT)

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

How is this type of TLS connection prevented from being MITM'ed by
someone replaying kerberos tickets (which it cannot read itself)

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Oct 2015 14:48:58 -0500

On 10/16/2015 01:48 PM, Paul Wouters wrote:
>> 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.
>

I think it is not, if the Kerberos and DH parts are completely
orthogonal [and the Kerberos exchange is not mixed into the master
secret other than via the session hash].  Having the authenticator
include the DH public value or mixing the Kerberos session key into the
master secret are two options that come to mind right away.

-Ben

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 16 Oct 2015 17:13:23 -0400 (EDT)

----- Original Message -----

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

regards,
Nikos

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Oct 2015 16:33:43 -0500

> 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

---

From: Rick van Rein <[email-masked]>
Date: Sat, 17 Oct 2015 08:36:22 +0200

Hello Paul,

> someone replaying kerberos tickets (which it cannot read itself)

In Kerberos, the KDC-generated and client-cached Tickets are always sent with an additional Authenticator; this is client-signed message that is generated while sending and holds a timestamp to the ms level.  The combination is rejected when the timestamp is more off than a small clock skew window at the server.  Replay is avoided in Kerberos by observing the Authenticator's uniqueness within that small window.  This however, has scaling problems, for instance in redundant server farms.

An Authenticator can hold a "checksum", which is a hash nowadays.  We can use this field to store a hash of the prior TLS messages, including the ECDH exchange and ServerRandom.  This is already done by default in the ClientVerify, so nothing special needs to be done for that.  The hashes are typed, with an IANA registry; unkeyed hashes are possible, though none beyond SHA1 appears to have been needed for its current uses, but we can expand that.

Finally, the pre-master secret for all four design alternatives consists of the ECDH session key and the session key exchanged by the Ticket.  Replay of ECDH is impossible if the server continually refreshes its offers, at least not to be repeated within the clock skew window, which has been a major focus point in my 00 draft.  Lacking the session key, an attacker that attempts replay of a Ticket will not be able to generate the proper Finished messages.  FWIW, I am proposing to extend the sizes of those hashes.

Thanks,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Sat, 17 Oct 2015 08:48:16 +0200

Hello,

>> What messages do you need to transfer for Kerberos? Is it only a ping-pong?

Yes, the plan is to send a Ticket + Authenticator and since the server cannot send "pong", to use the (elongated) "Finished" message to replace the validating function of the "pong".

> The client (or server, or both) can pick
> a subsession key encrypted by the session key in the Ticket,

Currently, only the client could do this.  We might pile the subsession key into the pre-master secret if we decide that it adds to security.

If we really want the server to send one too, it might send a random string of the right size, and it could be decrypted to a key.  That's possible with symmetric algorithms after all... and after receiving the Ticket, the server can do the same to discover its secret subsession key :)

> if
> replay cache.

The key idea in 00 was to not use a subsession key but instead rely on Diffie-Hellman for the same function, to avoid replay caches.  Because a replay cache would be a devastating part of a TLS infrastructure that could block these CipherSuites from being rolled out.

> An additional key-confirmation message to validate the

It still surprises me, but Kerberos is able to send a message one-way and achieve mutual authentication.  The trick is of course that prior key exchanges have setup links that make this possible.  That's already been taken care of in client apps and libraries, so I'm trying to make good use of it in TLS.

-Rick

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sat, 17 Oct 2015 09:20:55 +0200

> 2) Embed the Ticket + Authenticator in a PSK

I don’t fully understand the constraints of the Kerberos+DH use-case, but using DHE-PSK seems like the best idea.
The planned session resumption mechanism for TLS 1.3 also uses DHE-PSK, and uses a session ticket mechanism
that is not so far from the Kerberos ticket. The Kerberos session key would then get mixed in (as a semi-static secret)
to the ECDHE shared secret and both client and server would obtain mutual authentication (based on the Kerberos key).

It may be best to try and fit Kerberos into this existing mechanism, unless there is some fundamental incompatibility.

Best,
Karthik

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 17 Oct 2015 03:33:37 -0400 (EDT)

> protocol.", which seems to disqualify it from applicability here.

That's interesting and open to interpretation, but I don't think it is applicable.
If you simply use it to derive a key for PSK, it is equivalent to reading a key from
a password file using the username provided.

regards,
Nikos

---

From: Rick van Rein <[email-masked]>
Date: Sat, 17 Oct 2015 10:17:49 +0200

Hi Karthikeyan,

> I don’t fully understand the constraints of the Kerberos+DH use-case, but using DHE-PSK seems like the best idea.

It certainly has some virtue to view Kerberos as a preshared key (on
steroids).  But let me explain what bothers me about that appraoch :-

* PSK was designed to carry "hints", not "wrapped-up keys".  It feels
like we'd not be using it entirely properly.

* To avoid replay without (distributed) replay-protection caches, we
need a ping-pong exchange.  PSK sends back a literal copy of what it got
sent, which means that we cannot send back a cryptographic reply. 
Normally, we would do just that in the Kerberos Application Protocol. 
When we have an Authenticator in a separate ClientVerify message, it
automatically ranges over all past TLS messages, incorporating DH,
server random and the Ticket that is being proposed.  With the PSK
approach, it all gets stuffed into one TLS message and we'll be defining
things that are not in line with generic structures for TLS.

* PSK carries untyped information.  This means that a client and server
need out-of-band agreement on the meaning of the PSK format.  And we
probably agree that educated guesses based on magic numbers are not good
for a security protocol.  This means that use of PSK is limited to
pre-arranged client/server combinations.  Meanwhile, Kerberos is hoping
to expand to make clients and services authenticate even when they have
never met before.

> to the ECDHE shared secret and both client and server would obtain mutual authentication (based on the Kerberos key).

Yes, that is nice and orthogonal.  However, we do need the entropy of
ECDHE and server random to be mixed in with the Authenticator to make
replay undoable.  The best way to do that orthogonally is to rely on a
hash of prior exchanges, which is not possible, at least under 1.2, with
structures that mix Diffie-Hellman and PSK fields.  Combined with this
being a variation of PSK, I would expect it to lead to more exceptional
code than what is being proposed as 3) and 4) -- and exceptional code
often is badly-tested code.

> It may be best to try and fit Kerberos into this existing mechanism, unless there is some fundamental incompatibility.

I follow the same line of thought, but think integration with the
ClientCertificate / ClientVerify is more natural.  Tickets are not just
keys, they also carry identity, and bind them together.  Once again, the
reasoning is that this directs the questions to a TLS stack to the right
place, without a need to bypass it to elsewhere for this one usecase.

Thanks!
 -Rick

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 17 Oct 2015 12:29:33 -0500

On 10/17/2015 01:48 AM, Rick van Rein wrote:
> It still surprises me, but Kerberos is able to send a message one-way
> and achieve mutual authentication. The trick is of course that prior
> key exchanges have setup links that make

No, mutual authentication requires the client to receive a message from
the server.  This could be implicit as part of the first application
message, encrypted in a subsession key, but it does need to happen. 
(The krb5 GSSAPI mechanism sends a token from acceptor to initiator to
effect mutual authentication, in addition to the initial token from
initiator to acceptor.)  Without the additional return message, the
client has sent a message to some other party, and knows that that other
party cannot do something useful with that message unless it is the
party the client is intending to talk to, but the client could well have
been talking to an impostor that does not know the target service's
shared secret with the KDC.

-Ben

---

From: Rick van Rein <[email-masked]>
Date: Mon, 19 Oct 2015 11:12:45 +0200

Hello Benjamin / TLS WG,

I didn't mean to drop the list, so your full response is hereby included.

>>> the server.
>> Yes, I know -- the server needs to handle the session key or the subkey
>> to prove posession of its KDC-stored service key.  By using it, the client
>> can be convinced or server identity.
>
> Good to hear.  Other readers, perhaps, did not.

>>> This could be implicit
>> I think it automatically is with TLS, since the Finished messages won't
>> succeed until both parties have derived the same master secret, which
>> if it involves the session key or subkey proves the server's identity in an
>> implicit manner.
>
> From just your short descriptions, it was unclear to me what exactly
> went into the master secret from the Kerberos side, so I wanted to be sure.

Yes, balancing with terseness.  The master secret is calculated as
always, incorporating the pre-master secret as well as client/server
random and, under RFC 7627, all of the handshake messages up to and
including ClientKeyExchange.

The pre-master is the combination of the ECDH shared secret and the
session key(s) from Kerberos.  For the latter, we can choose one or more
from:
 * The session key generated by the KDC for this client/server
combination session (lasting as long as the service ticket, usually
about a day)
 * A subkey inserted into the Authenticator by the client for this
particular connection (which can avoid replay during ticket life)
 * Possibly: a random byte string from the server, "decrypted" with the
session key, to form a connection-specific key that hinges on
server-side entropy

I think my preference would be a combination of 2nd and 3rd because that
incorporates entropy from both sides; although entropy from both sides
is also incorporated through the ClientHello and ServerHello Random
bytes, these are not encrypted to conceal it from MITM as in the 2nd and
3rd options.  This is a bit paranoid perhaps --the ECDH mechanism
achieves a similar thing already-- but the appeal of 2nd and 3rd as very
light-weight and makes it much more difficult to crack.
>> I do believe a long-enough Finished message is required though.  For
>> the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth
>> to match the required certainty from the message; if we mix Kerberos
>> client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then
>> a client SHOULD negotiate a high-enough value and the server MUST
>> support that.  It requires TLS 1.2 to do these things.
>>
>
> Well, hmm, that's an interesting question.  (Note, of course, that the
> current Kerberos AES enctypes only use 96 bits of HMAC-SHA1 for their
> MIC.)

Keyed hashes such as HMAC-SHA1 don't seem to add much here, and they
would have a grave impact on how the hashes are calculated in TLS stacks
(because the key is only known later in the exchange).  I would suggest
that we follow TLS' hash preferences, since we are going to rely on
those hashes having been computed through the prior exchange of TLS
messages, and add those to the IANA Registry for Kerberos Checksum Type
Numbers; this currently includes SHA1 and I doubt that anyone would
protest to extensions with stronger unkeyed hashes.

> The client can obtain information indicating that the server has
> the correct Kerberos key both from the decrypted contents of the
> Finished message

I assume you meant "by matching the Finished message with one generated
locally".

> and also from the integrity protection of the
> TLSCiphertext, since both use material derived from the master secret. 

Yes, TLSCiphertext is also protected, but my main concern is with
Finished, because I would not like accept a TLS connection under
doubtful circumstances, just to be OK when an application only sets up
TLS as a means of authentication.  With the longer Finished messages,
that would not happen.

> So I guess I'm not yet convinced that the verify_data_length should be
> twice the bitlength of the negotiated symmetric cipher, but perhaps I'm
> missing something obvious.

I'm not sure if it should be 1x or 2x the cipher length.  Most important
to me is that it must be longer than the 12 bytes that were standard up
to TLS 1.1 and default in TLS 1.2.

-RIck