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

[Richard E. Silverman]

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

[Richard E. Silverman]

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

Oops, sorry -- that’s a little off the mark. In that case of course session-key logging won’t help the client directly, since it doesn’t perform those operations or call libkrb5 itself at all; the gssproxy daemon does. In that case we’d apply KRB5KEYLOGFILE to the daemon. But there is a second reason nonetheless: it’s easier for debugging. A long-lived client process under observation could have its ccache flushed by ticket renewal or similar management, losing the needed session keys (and a mechanism like gssproxy could in fact have several ccaches it manages) -- whereas setting KRB5KEYLOGFILE would reliably capture them all without extra work.

[Greg Hudson]

Post by Richard E. Silverman
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.

I think that would be a reasonable feature to add.