[39392] in Kerberos

home help back first fref pref prev next nref lref last post

query about a possible "KRB5KEYLOGFILE" feature, to log session keys

daemon@ATHENA.MIT.EDU (Richard E. Silverman)
Sun Mar 17 23:33:51 2024

Date: Sun, 17 Mar 2024 23:33:30 -0400 (EDT)
From: "Richard E. Silverman" <res@qoxp.net>
To: MIT Kerberos <kerberos@mit.edu>
Message-ID: <08dd4568-38a3-0137-35c7-4ea43647dad6@qoxp.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

Hello,

I have a patch to libkrb5 which implements a feature similar to the SSLKEYLOGFILE environment variable that’s now in pretty wide use for TLS: it logs session keys to a keytab named by KRB5KEYLOGFILE. The main use for this, just as with the TLS version, is to decrypt packet captures with Wireshark; the latter’s KRB5 dissector takes a keytab as input.

Prior to making this patch I would just export session keys from the client ccache using a little program I wrote to do that. But there are two situations motivating KRB5KEYLOGFILE for which that method doesn’t work:

1. Newer public-key based Kerberos extensions such as PKINIT and SPAKE produce session keys which never end up in the ccache or on the wire at all, and (deliberately) cannot be derived by a passive observer; and

2. A client may not have access to the session keys in its ccache, e.g. if it’s using gssproxy.

The patch is in a primitive state right now, just a hack I keep in an MIT Kerberos build I use for debugging, or for producing sample packet captures for study. I have thought about cleaning it up to contribute it, but first wanted to check whether you’d be interested in taking it at all.

Thanks,

Richard Silverman
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


home help back first fref pref prev next nref lref last post