1. Forum
  2. USENET
  3. comp.protocols.kerberos

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

    From Richard E. Silverman@res@qoxp.net to MIT Kerberos on Sun Mar 17 23:33:30 2024
    From Newsgroup: comp.protocols.kerberos

    Hello,
    I have a patch to libkrb5 which implements a feature similar to the SSLKEYLOGFILE environment variable thatrCOs 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 latterrCOs 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 doesnrCOt 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 itrCOs 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 yourCOd be interested in taking it at all.
    Thanks,
    Richard Silverman
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Richard E. Silverman@res@qoxp.net to MIT Kerberos on Sun Mar 17 23:44:28 2024
    From Newsgroup: comp.protocols.kerberos


    2. A client may not have access to the session keys in its ccache, e.g. if itrCOs using gssproxy.
    Oops, sorry -- thatrCOs a little off the mark. In that case of course session-key logging wonrCOt help the client directly, since it doesnrCOt perform those operations or call libkrb5 itself at all; the gssproxy daemon does. In that case werCOd apply KRB5KEYLOGFILE to the daemon. But there is a second reason nonetheless: itrCOs 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
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Greg Hudson@ghudson@mit.edu to Richard E. Silverman on Tue Mar 19 10:27:51 2024
    From Newsgroup: comp.protocols.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 thatrCOs 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 latterrCOs KRB5 dissector takes a keytab as input.

    I think that would be a reasonable feature to add.

    --- Synchronet 3.21d-Linux NewsLink 1.2