• Re: query about a possible "KRB5KEYLOGFILE" feature, to log session key

    From Richard E. Silverman@21:1/5 to MIT Kerberos on Sun Mar 17 23:44:28 2024
    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.

    --
    Richard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Richard E. Silverman on Tue Mar 19 10:27:51 2024
    To: kerberos@mit.edu (MIT Kerberos)

    On 3/17/24 23:33, Richard E. Silverman wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)