Subject: [TLS] I-D: CipherSuites for Kerberos + DH

From: Rick van Rein <[email-masked]>
Date: Sun, 11 Oct 2015 09:25:10 +0200

Hello TLS WG,

I would like to propose new CipherSuites for TLS.  The cryptography is
founded on Kerberos authentication and DH encryption, cryptographically
bound together.  The mechanism uses mutual authentication, although
clients may use anonymous tickets.

Any feedback that you may have (technical, or WG-procedural) is kindly
welcomed.  I will also send this to the Kitten WG.

Thanks,
Rick van Rein
> *From:* [email-masked]
> *Date:* 1 October 2015 18:54
> *To:* "Rick van Rein" <[email-masked]>, "Rick van Rein"
> <[email-masked]>
> *Subject:* New Version Notification for draft-vanrein-tls-kdh-00.txt
> A new version of I-D, draft-vanrein-tls-kdh-00.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:		draft-vanrein-tls-kdh
> Revision:	00
> Title:		TLS-KDH: Kerberos + Diffie-Hellman in TLS
> Document date:	2015-10-01
> Group:		Individual Submission
> Pages:		26
> URL:            https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-tls-kdh-00
>
>
> Abstract:
>    This specification extends TLS with a Kerberos-based method of mutual
>    authentication, and binds in Diffie-Hellman to achieve Perfect
>    Forward Secrecy for the session.

> The IETF Secretariat

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 11 Oct 2015 15:17:01 +0300

> welcomed.  I will also send this to the Kitten WG.

Some quick comments:
- The signed DH share does not look to be bound to anything (crypto
  parameters negotiation, randoms, server key exchange, etc..). I can't
  offhand say what that would lead to, but it looks even worse than
  TLS ServerKeyExchange, which has known vulernabilities due to
  lack of binding to things like ciphersuite.
- The ciphersuite list looks bad: 1) IDEA (bad idea), CBC
  (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2].
- Even use of DH is questionable.

[1] All the current ciphersuites have SHA-256 or SHA-384 prf-hash
(the prf-hash of existing ciphers was grandfathered as SHA-256,
even if the name has _SHA or _MD5).

[2] AFAIK, proving security properties of TLS against active
attack needs assumption that prf-hash is secure. And we know
SHA-1 isn't.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Sun, 11 Oct 2015 09:46:03 -0400

> - Even use of DH is questionable.

I would suggest piggybacking on the PSK mode, using the key Kerberos
provides at both ends as the PSK key. This would address all of these
issues in TLS 1.3

Sincerely,
Watson

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 11 Oct 2015 07:10:33 -0700

This seems like a good approach.

-Ekr

On Sun, Oct 11, 2015 at 6:46 AM, Watson Ladd <[email-masked]> wrote:

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

---

From: Paul Wouters <[email-masked]>
Date: Sun, 11 Oct 2015 15:29:11 -0400

> On Oct 11, 2015, at 09:46, Watson Ladd <[email-masked]> wrote:
> 
> 

Which would also match how Kerberos is used in IKE/IPsec

Paul

---

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 11 Oct 2015 22:33:18 -0400

> provides at both ends as the PSK key. This would address all of these

That's the right solution and this is why we need modular designs with
generic security (generic = not tailored to a specific use case). It allows
you to accommodate cases you did not necessarily think about when designing
the protocol.

Hugo

---

From: Rick van Rein <[email-masked]>
Date: Mon, 12 Oct 2015 07:14:05 +0200

Hello,

Thanks for the feedback.  Responding to it:

Ilari>   - The signed DH share does not look to be bound to anything (crypto
Ilari>   parameters negotiation, randoms, server key exchange, etc..).

This is indeed easy to miss; it relies on Kerberos infra to deliver a
short-lived session key to only the proper TLS client and TLS server.
The ticket is part of this key delivery, and can travel over untrusted
networks.

An Authenticator is built especially for each connection, and encrypted
with the session key by the TLS client.  The only other that can decrypt
it is the TLS server.  With the client DH key only known to TLS client
and TLS server, only they can construct the DH shared secret.

What remains is MITM on the server side.  This is detected when the
Finished messages are off (these have more bytes for TLS-KDH).

A alternative option to fighting MITM could be to include (a hash of)
the server-sent DH offer in the Authenticator.  Only the Kerberos-
authenticated TLS server can decrypt it, making it detect MITM.  Is
that considered benefial?

Ilari>   I can't
Ilari>   offhand say what that would lead to, but it looks even worse than
Ilari>   TLS ServerKeyExchange, which has known vulernabilities due to
Ilari>   lack of binding to things like ciphersuite.

Have I taken away these concerns?  Pointers to the known vulnerabilities
are welcome, of course.  I'm not sure what you would like to bind to
CipherSuites.

Watson>   I would suggest piggybacking on the PSK mode, using the key Kerberos
Watson>   provides at both ends as the PSK key. This would address all of these
Watson>   issues in TLS 1.3

You mean to add the short-lived session key to the pre-master secret, right?

I have a (weak) preference to leave that key behind the API to help
it being better protected.  Also, I don't think it adds much to
the security explained above.

It might be an idea to add protected fields from the Authenticator though,
such as the usec timestamp, seq-number, client name@realm.

Ilari>   - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC
Ilari>   (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2].

Yes, this is a naive/initial list, I knew I would need to interact here
to get it pruned.  Thanks, your suggestions will be taken care of!

Ilari>   - Even use of DH is questionable.

This is mod-exp DH, on account of its need for very large keys, right?

I would love to take it out, and only leave ECDH; I put up mod-exp DH
initially because it might be desired for backward compatibility.  If
I hear no warm-felt desire for mod-exp DH I will gladly remove it.

Thanks!
 -Rick

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 12 Oct 2015 13:36:50 +0300

> that considered benefial?

If I was to do things like the current proposal (as opposed to
overloading DHE-PSK), I would put in hash of entiere client and server
first flights.

Otherwise things get "interesting" when considering tweaking handshake
or replaying the encrypted CKE. And "interesting" in crypto is not good.
 
> are welcome, of course.  I'm not sure what you would like to bind to

The SKE security issue (SKE isn't bound to the ciphersuite) has surfaced
at least three times:

1) The DHE/ECDHE confusion.
2) FREAK
3) Logjam

> the security explained above.

I think he means stuffing the key from kerberos as PSK input in
(EC)DHE-PSK ciphersuite.

The security properties of that are much more straightforward than
properties of present proposal.
 
> I hear no warm-felt desire for mod-exp DH I will gladly remove it.

Backward compatiblity? I don't think you need such thing with proposal
like this.

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Oct 2015 17:53:47 -0500

> provides at both ends as the PSK key. This would address all of these

This would seem to require an application protocol doing some Kerberos
exchanges up front to establish the Kerberos session key before pivoting
into TLS-PSK in a STARTLS-esque fashion.  If that's what the application
protocol would look like, it seems like there's no reason not to go
full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides.

This proposal (as complicated as it is, and I'm not sure that I'm
entirely comfortable with it yet) has the comparative advantage that the
application speaks TLS from the start, with the Kerberos messages
included in the TLS CKE.  In that sense, at least, it is elegant.

This proposal also includes a generic mechanism for the server to
indicate what service type and hostname should be used in constructing
the host-based service principal name for Kerberos, which is useful --
the convention for that would otherwise have to be baked into the
application protocol.  The considerations around client anonymity and a
protocol for the server to convey its expectations are also interesting,
though I'm not sure I would have put it in the -00 if it was my own
document.

There are some nits in the Kerberos bits that I might mention over on
kitten.

-Ben

---

From: Rick van Rein <[email-masked]>
Date: Tue, 13 Oct 2015 05:01:25 +0200

Hello Ilara / Watson / TLS WG,

Thanks again,

Now I see what you mean.  Indeed, the master secret used in Finished
does not take it into account in TLS 1.2, except under RFC 7627.
> 1) The DHE/ECDHE confusion.

Thanks, those are very good reasons indeed :)
> I think he means stuffing the key from kerberos as PSK input in

That is not going to work for this.  PSK communicates untyped blobs,
which makes the server take a leap of faith, and so it is pretty much
limited to internal use.  I'm working on getting Kerberos to crossover
between realms, and TLS-KDH might become the killer app for that.

The key-handling approach of PSK got me thinking though (pre-master =
DH-shared-secret + preshared-key).  It is a strikingly simple method to
make (EC)DH orthogonal to the authentication exchange.  It means all the
DH-specifics can go... perhaps 75% of my text!
> Backward compatiblity? I don't think you need such thing with proposal

I am now preparing a new form, with ClientCertificate := krbTicket and
CertificateVerify := krbAuthenticator.  That seems to integrate really
well with the rest of TLS, also for 1.3.
 * the Authenticator hashes all prior messages and stores them in
"checksum", leading to the requested binding
 * the CertificateRequest can ask for various forms of authentication,
even mixing Kerberos and X.509
 * there will be Kerberos-only CipherSuites (mutual exclusion, so this
authenticates the server) but it can also work with TLS_ECDHE_RSA_ et al
 * the TicketRequirementFlags will be a TLS Extension during ClientHello
/ ServerHello

Rather different -- so a new text is coming up.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Tue, 13 Oct 2015 05:21:58 +0200

Hello Benjamin,

> full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides.

GSSAPI is too general IMHO; it specifies an unpredictable number of exchanges 
and TLS cannot carry that.

An attempt for SASL-in-TLS was made in draft-williams-tls-app-sasl-opt, but it 
ends up piggybacking on TLS but continue afterwards -- loosing the cryptographic 
binding between auth from Kerberos with PFS from (EC)DH.

> included in the TLS CKE. In that sense, at least, it is elegant.

Thanks. The proposed changes greatly simplify the spec, making all DH orthogonal 
to the spec.  Watson convinced me and now I can pull a lot from the I-D, which
is also more complex than I like.

> application protocol.

Actually, I did not specify such a mechanism.
* Client and server assume that the application context knows what protocol it 
  is using. AFAIK that always makes sense -- on top of TLS we're running something 
  like imap, and imap knows that its tickets start with "imap/".
* The hostname is known to the client too, it is usually included in the SNI 
  extension, looked up in DNS, ...
* However, the realm is "supposed to be derived independently" which can be done
  with the DNSSEC-assured _kerberos TXT that we discussed on Kitten.

> The considerations around client anonymity and a

OK :) but this was simpler than the loose end in predecessors -- sending no
ticket and deciding how the server would respond to that.  But it is a new
idea, to have authenticated clients with unknown identities...

> There are some nits in the Kerberos bits that I might mention over on

Great, thanks!

-Rick

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Oct 2015 09:44:03 -0500

> and TLS cannot carry that.

There seems to be some miscommunication going on.  My comment was in
response to the proposal to "just use PSK" with the Kerberos session key
as the "pre-shared" secret -- that is, it would be "pre-shared"
immediately before initiating the TLS exchange.  That would require that
the application protocol send some Kerberos messages (so as to get both
peers the same session key) before starting up TLS and using a PSK mode
with that session key as the shared secret.  If the application protocol
is going to involve doing some "other stuff" before TLS, there's no
reason why that "other stuff" has to be limited to pure Kerberos;
multiple hops for a GSS-API exchange is fine for the "other stuff",
which is *not* part of the TLS exchange.

In your previous message, you (understandably) are resisting that, but I
just wanted to make clear that it's just as feasible to run GSS-API to
get a PSK to use for TLS as it is to run Kerberos to get a PSK, once the
restriction of being part of the TLS exchange is removed.

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Oct 2015 11:06:16 -0400

> included in the TLS CKE.  In that sense, at least, it is elegant.

It would (modulo some work by me, which is unlikely to get done) be
possible to do this with the PSK-ECDH extension: have the first two
messages contain information used to derive the PSK, which is used to
authenticate in the same manner in the second round. The problem here
is that TLS is not a catchall "Transport Layer Security" capable of
taking any sort of desired key exchanges and producing a secure
protocol from them, but instead requires a lot of annoying work to
ensure the proofs go through. Mike Hamburg has presented Keccak based
designs that do do this, and TLS 1.3 by default does a lot better with
this.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.