Subject: perfect forward secrecy and Kerberos

From: Ken Raeburn <[email-masked]>
Date: Mon, 20 Nov 2000 14:59:32 -0500 (EST)

I've seen complaints in the KINK and SECSH working groups about the
lack of perfect forward secrecy in Kerberos.  Rather than fixing it on
a per-application basis, it seems to me that it'd make more sense to
look at fixing or augmenting Kerberos, and put out another RFC.  (It's
not something we should hold up kerberos-revisions for.)

It seems to me that the key (so to speak) would be updating the AP_REQ
and AP_REP messages to yield a subsession key that is never sent over
the wire.  These new AP_REQ_PFS and AP_REP_PFS messages could then be
adopted by KINK, ssh, GSSAPI, etc.

I'm going to keep thinking about this, but won't have time to look
into it much further for a little while.  Anyone else want to give
this a shot?  Or at least make some more concrete suggestions?

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Nov 2000 15:49:28 -0500

I agree. Though you'd need to add _PFS versions of
AS_REQ/TGS_REQ/AS_REP/TGS_REP. And, I think, there may be an extra
round-trip, but I haven't looked at the details of Diffie-Hellmann for
some time now.

In any case, it would, it seems to me, be easier to extend
GSS-API/SPNEGO to support the use of multiple mechanisms for for various
tasks:

 - key exchange
 - authentication
 - session integrity/privacy protection
 - credentials forwarding
 - ...

Then add a GSS flag so clients (and/or administrators!) can request PFS.

A reference GSS-SPI might be nice so mechanisms could be written once.

****

And then add GSS-API support to the KDC so that the AS/TGS are protected
by GSS-API, thus rendering pre-authentication obsolete :^)

****

Then again, maybe it's time to start over; XML might be used instead of
ASN.1 nowadays or an ASN.1 encoding based on XML (XBER and XDER?)...

****

Don't take these last two comments too seriously... unless you want to
go down that route.

:)

Nico

--

---

From: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 18:47:25 -0500

Except not all kerberos protocols use GSS-API.  It would be nice to
have Kerberos support it natively, rather than depend upon some other
protocol (which may not be used by the end systems).

-derek

PS: I think reasonable PFS can be obtained by using Diffie-Hellman to
secure the client<->KDC ticket requests alone.  I don't think we need
DH between the app-client and app-server.  This would at least provide
PFS across tickets, just not for multiple sessions using a single
ticket.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       [email-masked]                        PGP key available

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2000 10:30:57 -0500

> PFS across tickets, just not for multiple sessions using a single

But the point is to protect the sessions. Protecting the client<->KDC
exchanges is not so useful since user keys are not usually stored in
keytabs and all that is being exchanged are tickets. Yes SPNs also get
tickets and their keys are stored in keytabs, but the ability to
decrypt a snooped KDC session (as opposed to the actual ticket) when
you've got the SPN's keytab is not very useful.

The ability to decrypt snooped client<->server sessions
(telnet/ftp/X/whatever) by obtaining access to the server's keytabs is
far more useful to an attacker because they can gather cyphertext now
and decrypt it later when they break the server.

My comment about using GSS-API in the KDC exchanges was tongue in cheek
and made light of the fact that, had GSS-API been conceived together
with Kerberos then there would be no pre-authentication as it is today
(instead there would be GSS-API mechanisms equivalent to today's pre-
auth types). Methinks.

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 21 Nov 2000 10:47:22 -0500

> and decrypt it later when they break the server.

Ahh, you are correct.  I was thinking about protecting service keys
and tickets in a PFS manner, to make sure that someone couldn't see
the tickets as they went to the user (PFS against discovery of the
user's passphrase or ticket).  I wasn't thinking about the second
step.  Serves me right for responding while I'm half asleep.  Thank
you for calling me on that one :)

-derek

---

From: Joe Salowey <[email-masked]>
Date: Fri, 24 Nov 2000 20:25:40 -0800

I'll look at converting key exchange stuff in
http://search.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt
to a more generic form.  I'll probably start with raw kerberos and then
look at GSSAPI issues. I'll try to post something before the meeting in
San Diego.

Joe