KDC Options and the missing Bit Mask
Hey Folks!
So, a question came up recently about the Ticket Options in security events 4768 & 4769. An example of one, below:
So just what are these "Ticket Options?
Well as it turns out, they are the options defined in the ticket by the KDC. Seems pretty straightforward doesn't it? Well. While those options are defined in the RFC itself and in Microsoft’s own documentation of Kerberos, the translation of the RFC list and the Bit Mask that we use in Windows is missing.
For example, we see in the above example that the Ticket Options are 0x4081000. But, what does this mean? Which options do we have for this ticket? Looking at RFC 1510 (Page 40-41) and our own article How the Kerberos Version 5 Authentication Protocol Works (Key Distribution Center Option Flags Section) we have the Flag Bits for each of the options. Unfortunately, most of us can't translate Flag Bits into Bit Masks in our heads. And that translation is missing from our docs.
So, working with a couple of my colleagues, Wayne McIntyre and Seth Moore (who are a couple of wizards that actually CAN translate this stuff in their head), we came up with a nice easy to read table that hopefully will help if you are trying to figure out what 0x4081000 or, something like 0x608100 actually means. (Forwardable, Forwarded, Renewable and Name Canonicalize, just FYI. For an explanation of each of these, see the aforementioned TechNet Article "How the Kerberos Version 5 Authentication Protocol Works")
| Flag Bit RFC/Technet | Flag Value | Bit Mask |
| KDC_OPTIONS_reserved | 0x80000000 | |
| 1 | KDC_OPTIONS_forwardable | 0x40000000 |
| 2 | KDC_OPTIONS_forwarded | 0x20000000 |
| 3 | KDC_OPTIONS_proxiable | 0x10000000 |
| 4 | KDC_OPTIONS_proxy | 0x08000000 |
| 5 | KDC_OPTIONS_allow_postdate | 0x04000000 |
| 6 | KDC_OPTIONS_postdated | 0x02000000 |
| KDC_OPTIONS_unused7 | 0x01000000 | |
| 8 | KDC_OPTIONS_renewable | 0x00800000 |
| KDC_OPTIONS_unused9 | 0x00400000 | |
| KDC_OPTIONS_unused10 | 0x00200000 | |
| KDC_OPTIONS_opt_hardware_auth | 0x00100000 | |
| KDC_OPTIONS_unused12 | 0x00080000 | |
| KDC_OPTIONS_unused13 | 0x00040000 | |
| 14 | KDC_OPTIONS_cname_in_addl_tkt | 0x00020000 |
| 15 | KDC_OPTIONS_name_canonicalize | 0x00010000 |
| 27 | KDC_OPTIONS_renewable_ok | 0x00000010 |
| 28 | KDC_OPTIONS_enc_tkt_in_skey | 0x00000008 |
| 30 | KDC_OPTIONS_renew | 0x00000002 |
| 31 | KDC_OPTIONS_validate | 0x00000001 |
Comments
- Anonymous
January 01, 2003
There is one bit (pun intended) of DER encoding/decoding that has me puzzled. RFC 4120 (which obsoletes 1510) says that the kdc_options are encoded as a bit string as specified in section 5.2.8. There it says "the DER require that encodings of a bit string using "NamedBit" notation exclude any trailing zero bits." This implies they are sent/encoded from left-to-right. That is, the leftmost bit is the least significant. What puzzles me is why it would be decoded from DER into a machine INT in the same order, which is backwards of the normal machine bit order. Is this because they are indeed not numbers, but rather an array of bits? I guess that is the only way you could have a zero bit with a value of zero and a one bit with a value of one (rather than normal INT bitness where the zero bit has a value of one). I think I've solved my one problem, but I'd love confirmation that I'm not mis-reading the RFC.
Thanks,
Eric