ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 8974] Patch to support krb FAST PA Data types

Date: Thu, 24 Oct 2013 10:46:32 +0000

changed bug 8974

What Removed Added
CC   [email protected]

Comment # 6 on bug 8974 from
I found myself recently in need of the ability to see what goes on inside a
FAST exchange, so I wrote up the dissectors and decryption code for FAST and
ENCRYPTED CHALLENGE. It is based off the git master branch (wireshark 1.10). It
is a bit of a work in progress, but complete enough that I figure some feedback
might not be a bad idea. 

Things of note: In order to compute the required armor-keys and
encrypted-challenge keys, I've had to introduce a few state flags, the
trns_last_msg* and compute_armorkey stuff. The first to keep track of whether
the FX-FAST being processed contains a request or a reply (since the type does
not reveal this). The second keeps track of when we find sessionkeys inside
FX-FAST, so we may remember them and later use them to make armorkeys.  

The armorkey needs both the sessionkey from a ticket, and the subkey from the
immediately following authenticator. All of the computation therefore goes on
in the subkey dissection. I'm unsure about whether this is the best approach,
but it was the only option that seemed intuitive to me. Input and suggestions
very much welcome.

Computing encrypted challenge keys is a bit messy at the moment, since I end up
making a few assumptions about principal naming schemes. I do this in an effort
to limit the number of keys to, hopefully, only those that might be useful
later. The assumptions are: service principals contain a "/" in their name (so
host/[email protected] f.inst). Clients contain no slash, so once I find an @
without a preceeding slash, I shortcircuit the search and make a key. 

Finally, I suspect I may be leaking a bit of memory around the whole key-making
that goes on in the subkey dissector, but I've not been able to find a way to
free the keyblocks without introducing read errors and crashing  wireshark.

The decryption will need the keys of the client principal and krbtgt service in
a keytab to work.


You are receiving this mail because:
  • You are watching all bug changes.