keytab - MIT Keytab Binary File Format Encoder / Decoder - Kerberos

This is a discussion on keytab - MIT Keytab Binary File Format Encoder / Decoder - Kerberos ; I have written a small keytab encoder / decoder module in ANSI C. The package can be downloaded here: http://www.ioplex.com/utilities/ Also, inlined below is a brief description of the keytab binary file format. There are a few parts missing that ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: keytab - MIT Keytab Binary File Format Encoder / Decoder

  1. keytab - MIT Keytab Binary File Format Encoder / Decoder

    I have written a small keytab encoder / decoder module in ANSI C. The
    package can be downloaded here:

    http://www.ioplex.com/utilities/

    Also, inlined below is a brief description of the keytab binary file
    format. There are a few parts missing that I wasn't certain about. Perhaps
    someone knows the answer to these questions?

    1) What fields are in host byte order? It seems that everything is big
    endian except the 16 bit vno and and 16 bit keyblock key type?
    2) What codeset are strings? Are they UTF-8 or locale dependant?
    3) Are my assumptions about num_components correct: 1 for no service,
    2 with service?
    4) Have I missed anything?

    If people would like to try this on their keytab files the test1.c test
    decodes, encodes a copy, and then decodes the copy. Please let me know
    what you find.

    Thanks,
    Mike

    --8<--

    The Kerberos Keytab Binary File Format
    Michael B Allen
    Last updated: Tue May 2 20:51:41 EDT 2006

    The MIT keytab binary format is not a standard format, nor is it
    documentated anywhere in detail. It is however understood by several
    Kerberos implementations including Heimdal and of course MIT and keytab
    files are created by the ktpass.exe utility from Windows. So it has
    established itself as the defacto format for storing Kerberos keys.

    The following C-like structure definitions illustrate the MIT keytab
    format.

    keytab {
    uint16_t file_format_version; /* 0x502 */
    keytab_entry entries[*];
    };

    keytab_entry {
    int32_t size;
    uint16_t num_components;
    counted_string realm;
    counted_string service; /* optional */
    counted_string name;
    uint32_t name_type;
    uint32_t timestamp;
    uint16_t vno; /* little endian */
    keyblock key;
    uint32_t vno32; /* big endian */
    };

    counted_string {
    uint16_t length;
    uint8_t data[length];
    };

    keyblock {
    uint16_t type;
    uint8_t length;
    uint8_t data[length];
    };

    The keytab file format begins with the 16 bit file_format_version which
    at the time this document was authored is 0x502.

    The file_format_version is immediately followed by an array of
    keytab_entry structures which are prefixed with a 32 bit size indicating
    the number of bytes that follow in the entry. Note that the size should be
    evaluated as signed. This is because a negative value indicates that the
    entry is in fact empty (e.g. it has been deleted) and that the negative
    value of that negative value (which is of course a positive value) is
    the offset to the next keytab_entry. Based on these size values alone
    the entire keytab file can be traversed.

    The size is followed by a 16 bit num_components field indicating the
    number of string components that follow minus one. In practice this value
    will be either 1 to indicate the realm and name follow or 2 to indicate
    the realm, service, and name follow. Each component is a counted_string.

    The realm, optional service, and name components are counted_strings. A
    counted string is simply an array of bytes prefixed with a 16 bit
    length. With a service principal of HTTP/quark.foo.net@FOO.NET the
    service, name and realm would be "HTTP" "quark.foo.net" and "FOO.NET"
    respectively.

    Following the string components is the name_type. This value is usually
    1 unless ... ?

    The 32 bit timestamp indicates the time the key was established for that
    principal. The value represents the number of seconds since Jan 1, 1970.

    The 16 bit vno field is the version number of the key. This value may
    be overridden by the vno32 field described below.

    The keyblock structure consists of a 16 bit value indicating the keytype
    (e.g. 3 is des-cbc-md5, 23 is arcfour-hmac-md5, 16 is des3-cbc-sha1,
    etc). This is followed by an 8 bit value indicating the length of the
    key data that follows.

    The last field of the keytab_entry struction is optional. If the size of
    the keytab_entry indicates that there are bytes remaining a 32 bit value
    representing the key version number follows. This value superceeds the
    16 bit value preceeding the keyblock.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    Michael B Allen writes:
    ....
    > 1) What fields are in host byte order? It seems that everything is big
    > endian except the 16 bit vno and and 16 bit keyblock key type?


    The IETF term you'd likely see here is "network byte order" = big-endian.
    Everything is big-endian. keytabs have exactly the same representation
    on big-endian and little-endian machines (unlike, *cough*, key stash
    files...). vno is an 8-bit quantity, key type and length
    are 16-bit big-endian quantities, and key length & contents you could
    treat as a counted string.

    > 2) What codeset are strings? Are they UTF-8 or locale dependant?


    I'd guess UTF-8. locale-dependant is almost certainly wrong. There
    was a lot of debate about this on the ietf kerberos list; I'm not
    honestly sure where or if things got settled. All the code I've seen
    that looks at name components thinks of them as an ascii string and
    pays no special attention to the high bit, that's at least consistent
    with UTF-8. Careful about validating UTF-8 strings if you process
    keyblocks using counted string logic.

    > 3) Are my assumptions about num_components correct: 1 for no service,
    > 2 with service?


    You should not make any assumptions in your keytab logic. You might
    have logic elsewhere that cares--hopefully buried way back in your
    application logic, hopefully somewhere where you actually have need
    to care about this like when constructing service names.

    > 4) Have I missed anything?


    Don't see anything else; but like any undocumented data structure
    where the owners reserve the right to break things; there's
    no guarantee. If you're sharing keytabs with MIT application
    logic that might write to the keytab, there's a bunch of logic
    involving file locking & fsync that you might want to take
    into account.

    ....
    > the number of bytes that follow in the entry. Note that the size should be
    > evaluated as signed. This is because a negative value indicates that the
    > entry is in fact empty (e.g. it has been deleted) and that the negative
    > value of that negative value (which is of course a positive value) is
    > the offset to the next keytab_entry. Based on these size values alone
    > the entire keytab file can be traversed.


    negative sizes = deletion? Wow, yup, somehow I missed or forgot that.

    >
    > The size is followed by a 16 bit num_components field indicating the
    > number of string components that follow minus one. In practice this value
    > will be either 1 to indicate the realm and name follow or 2 to indicate
    > the realm, service, and name follow. Each component is a counted_string.


    Count 1 vs. 2 is k4-centric thinking. It's a list of name components;
    the count is whatever it is. The keytab reading logic should neither
    know nor care how many components or what they "mean".

    ....
    >
    > Following the string components is the name_type. This value is usually
    > 1 unless ... ?


    MIT krb5.h sez:
    KRB5_NT_UNKNOWN 0 /* Name type not known */
    KRB5_NT_PRINCIPAL 1 /* users, etc. */
    KRB5_NT_SRV_INST 2 /* service & other uniq inst (krbtgt) */
    KRB5_NT_SRV_HST 3 /* service with hostname as instance */
    KRB5_NT_SRV_XHST 4 /* service with host as components */
    KRB5_NT_UID 5 /* unique id */
    other types in various kerberos standards but not in MIT:
    KRB_NT_X500_PRINCIPAL 6 /* X.500 encoded name RFC2253 */
    KRB_NT_SMTP_NAME 7 /* SMTP mailbox address */
    (what happened to 8, 9?)
    KRB_NT_ENTERPRISE 10 /* enterprise name */

    I'm not convinced you can see anything besides name type 1 = KRB5_NT_PRINCIPAL
    in a keytab.

    There is logic inside the MIT k5 library that does things
    with some of the other name types, particularly KRB5_NT_SRV_HST.

    ....
    > The 16 bit vno field is the version number of the key. This value may
    > be overridden by the vno32 field described below.


    The inline version is not little-endian, it is an 8 bit quantity.
    That's where Jeff Altman gets his "less than a year" figure - 256 days
    for a keytab that's updated once a day. Apparently older logic that
    updated keytabs didn't append the 4 byte quantity, it merely truncated
    and stored inline.

    So, one of the things you miss by not using the MIT .dll is the logic which
    compares only the low order byte of a vno when the high order bits are
    missing out of the keytab. As an library designer using an undocmented
    file format you can afford to do something MIT can't: you can tell
    anybody who misses this feature "upgrade your kdc to mit 1.4X and make
    another keytab." Or even "it broke? Send me a diff when you figure
    out what should be done here." Of course, you should probably try
    using microsoft ktadd with a high kvno first to make sure they don't
    do something inconvenient here.

    >
    > The keyblock structure consists of a 16 bit value indicating the keytype
    > (e.g. 3 is des-cbc-md5, 23 is arcfour-hmac-md5, 16 is des3-cbc-sha1,
    > etc). This is followed by an 8 bit value indicating the length of the
    > key data that follows.


    These are 2 16-bit big-endian quantities. You can treat the
    keyblock length & contents as a counted string if you care.
    In IETF network speak, that would be a "counted octet string".

    >
    > The last field of the keytab_entry struction is optional. If the size of
    > the keytab_entry indicates that there are bytes remaining a 32 bit value
    > representing the key version number follows. This value superceeds the
    > 16 bit value preceeding the keyblock.

    (as per above the inline kvno was an 8 bit quantity).
    ....

    -Marcus Watts
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    I have made significant changes to the text and it's pretty short so
    I'll just inline the whole thing again. Thanks for your feedback.

    Mike

    --8<--

    The Kerberos Keytab Binary File Format
    Michael B Allen
    Last updated: Wed May 3 12:56:26 EDT 2006

    The MIT keytab binary format is not a standard format, nor is it
    documentated anywhere in detail. The format has evolved and may continue
    to. It is however understood by several Kerberos implementations including
    Heimdal and of course MIT and keytab files are created by the ktpass.exe
    utility from Windows. So it has established itself as the defacto format
    for storing Kerberos keys.

    The following C-like structure definitions illustrate the MIT keytab
    file format. All values are in network byte order.

    keytab {
    uint16_t file_format_version;
    keytab_entry entries[*];
    };

    struct keytab_entry {
    int32_t size;
    uint16_t num_components;
    counted_octet_string components[num_components - 1];
    uint32_t name_type;
    uint32_t timestamp;
    uint8_t vno8;
    keyblock key;
    uint32_t vno;
    };

    counted_octet_string {
    uint16_t length;
    uint8_t data[length];
    };

    keyblock {
    uint16_t type;
    counted_octet_string;
    };

    The keytab file format begins with the 16 bit file_format_version which
    at the time this document was authored is 0x502.

    The file_format_version is immediately followed by an array of
    keytab_entry structures which are prefixed with a 32 bit size indicating
    the number of bytes that follow in the entry. Note that the size should be
    evaluated as signed. This is because a negative value indicates that the
    entry is in fact empty (e.g. it has been deleted) and that the negative
    value of that negative value (which is of course a positive value) is
    the offset to the next keytab_entry. Based on these size values alone
    the entire keytab file can be traversed.

    The size is followed by a 16 bit num_components field indicating the
    number of counted_octet_string components *minus one* that constitute
    the name. A counted_octet_string is simply an array of bytes prefixed
    with a 16 bit length. For the name components, the counted_octet_string
    bytes are UTF-8 encoded text (no zero terminator).

    Following the components array is the 32 bit name_type (e.g. 1 is
    KRB5_NT_PRINCIPAL, 2 is KRB5_NT_SRV_INST, 5 is KRB5_NT_UID, etc).

    In practice the name_type is almost certainly 1 meaning
    KRB5_NT_PRINCIPAL. For this type of entry the components array consists
    of the realm, service and name (in that order) although if num_components
    is 1, the service component is not present. For example, the service
    principal HTTP/quark.foo.net@FOO.NET would be encoded with name components
    "FOO.NET" followed by "HTTP" followed by "quark.foo.net".

    The 32 bit timestamp indicates the time the key was established for that
    principal. The value represents the number of seconds since Jan 1, 1970.

    The 8 bit vno8 field is the version number of the key. This value is
    overridden by the vno field if it is present.

    The keyblock structure consists of a 16 bit value indicating the keytype
    (e.g. 3 is des-cbc-md5, 23 is arcfour-hmac-md5, 16 is des3-cbc-sha1,
    etc). This is followed by a counted_octet_string containing the key.

    The last field of the keytab_entry structure is optional. If the size of
    the keytab_entry indicates that there are bytes remaining, a 32 bit value
    representing the key version number is present. This value superceeds
    the 8 bit value preceeding the keyblock.

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    On Wed, 03 May 2006 18:53:12 +0200
    Love Hörnquist Åstrand wrote:

    >
    > Michael B Allen writes:
    >
    > > 2) What codeset are strings? Are they UTF-8 or locale dependant?

    >
    > "kerberos codeset", today, basicly ascii.


    Good. Than it won't hurt to call it UTF-8 :->

    > > 3) Are my assumptions about num_components correct: 1 for no service,
    > > 2 with service?

    >
    > See code in Heimdal, depends on version. Hint, there is no such thing as
    > "name" and "service" in kerberos5, its just a list of
    > components. foo/bar/baz/kaka/cookie@EXAMPLE.ORG is a valid name.


    Ahh, I see. Is the realm always present? So it's:

    struct keytab_entry {
    int32_t size;
    uint16_t num_components;
    counted_octet_string realm;
    counted_octet_string components[num_components];
    uint32_t name_type;
    uint32_t timestamp;
    uint8_t vno8;
    keyblock key;
    uint32_t vno;
    };

    counted_octet_string {
    uint16_t length;
    uint8_t data[length];
    };

    > The "vno32" as you name it, is a heimdal extention, and now adays java


    Interesting. MS ktpass.exe enmits the 32 bit kvno.

    Mike

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (Darwin)

    iQIVAwUARFjf+hZyDLTSep3UAQK9ARAAsSAD5YnTQRKITc7E24 Qa06h7qsyYQRdN
    a+zPWzjbBWCdRVXeQyWyzAGJG5TtFTu5MQhABvXg8/sA5cONoq9FG9EODv1GPw1f
    FswKtQ8pEm4c1IaSCTn2ty3rkIAhjLQfEHYoLatM+GdUoTi668 El6ldeTmheU1JU
    07mjBnqxcC1YvN04ReX4WVUZfeILLavWq5MqFZO4pcdAo45nLz SpQR6wXUeodiPv
    jQ7lRNbMvsYvJ1Tj48wrepmzTFV6gRPtYFj/OGihz3Xs4GXwzzOcK2Ca+e1FnDRC
    74vy1n+foa69/3ds1YOux2eXXXEV4MVOPtV5Rafuab6i9cllRPwLlLgVYIuhke8 Z
    77sZ6r9Z4L7If0p+gTH0IYHA7Fi7fH8P0WLJgMg91S/6ScoLkUKfezUMOtEYvLcN
    3J0Htw0yJ9UE4QjBwBCn4MYvT0qPc4uaFudQcwK5C9dUwUnliC zH6OuiagATEAZY
    pUElTvEgvI60bZMmrKinl9INqlhn6A9t0/+gpAqww9nFDXW+xTiMK4JiXR3ku3sF
    PVz4rjX/u4/M3vHc48ViqJuhTteHfyByRlOer4lu28/Qivcwa5/mI1jS0/byVAaM
    4ZzZ+I0QDV2oDstKyOzjXAFSKenCLsfs3RX7fL/fN1gKGCYKy44pM+byJZX+Qid4
    x30zsZXzFIs=
    =DjlO
    -----END PGP SIGNATURE-----

  6. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (Darwin)

    iQIVAwUARFkJwRZyDLTSep3UAQLDOw//esMhulD/PV25wAKYuHKI9CyMOInk8fai
    YuF92fm0vjMJdGPMX9hOQyB5W9JMF6wGtOEWakHjVYkwv0TKJs o5Z4Mrtzc/wSmu
    Z1Zl1fDkpVxVD/+r7CIMvfQsX7O6pmSl4zD0wdoW5z2IMARZnlE2d/R8c29A0Jjw
    AWs9n5PGaBizNqJnmga+1LVbGYCPgjTCnUB5VX3IMBb3G7Xl7x TwWypjR7A4QkFD
    Ibry6RrowRgqBcrK2j4XiOu6s9fXEjbBMLDUKcRfQuOA/j+hTFxq3xDWuts8J/gy
    F06V8zBr973wThFoeFCQOeJfVZLcVuZfgJ6FyxNI5xdR0KwyXg Efeh5QsI6u6E7T
    baOcDKn+ld2/xf2wAO7I0QjCeFey6t59ti7KqWfha1ODiM90xPKIgE/UamNXXa38
    HB3yYgcK3kZmXQIgrfCqZtp1NoxWEFJds91851z6cmJVBvk+zQ ZhvPggaaSOGSmW
    mQCgR0XDgQ8hOqUMyVSW3jKoQATjRe1HOQc8w0wO0Ly8vKfw8z myAN1zCHQz+bj5
    77urF+Q7Q3zZRTk8k8eHe6ThGO2iWDXeofO39e6k+/eqkE4G7gUPTlQUT0KbQeAJ
    5it2BmdltO/zMnwWB3nIw1ngILiOsJ/nutpEk8qrmPAE5Aaxxt0npP6Y/nJAEqDp
    4e4g2luDUEU=
    =62a+
    -----END PGP SIGNATURE-----

  7. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    On May 3, 2006, at 13:13, Michael B Allen wrote:
    > On Wed, 03 May 2006 18:53:12 +0200
    > Love Hörnquist Åstrand wrote:
    >> Michael B Allen writes:
    >>> 2) What codeset are strings? Are they UTF-8 or locale dependant?

    >> "kerberos codeset", today, basicly ascii.

    > Good. Than it won't hurt to call it UTF-8 :->


    It might if that causes someone to think they can store non-ASCII
    UTF-8 strings there and have it be useful.

    My guess is that eventually we will make it UTF-8, but today, if you
    care at all about portability, it should be considered an ASCII-only
    field.

    Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    On Wed, 03 May 2006 21:51:27 +0200
    Love Hörnquist Åstrand wrote:

    > > counted_octet_string {

    >
    > The "principal" part uses int32 lengths for the strings (int16 for
    > num_components) while the keyblock uses int16 lengths.
    >
    > > uint16_t length;
    > > uint8_t data[length];
    > > };


    My C-like notation is used only to describe the binary file format and not
    an internal representation. In keytabs that I have looked at, the lengths
    for strings are 16 bit and unless there is some significance to a negative
    value (e.g. entry size) I think all integers should be shown unsigned.

    By "version 1" I suppose you mean the file_format_version field would
    be 0x501? At least from looking at the heimdal code it interprets
    a 1 in that second byte to mean "version 1" but it's not clear how
    the major version number is interpreted. Regarding version 1 keytabs,
    can you verify that the comments in the keytab_entry structure and the
    description of version 0x501 keytabs in the last paragraph are correct?

    Also, from looking at the Heimdal code, I've noticed that the 32 bit
    kvno field is only decoded if there are exactly 4 bytes left. Should
    that not be >= 4 bytes in anticipation of further expansion?

    Thanks for your feedback. You're welcome to use the text (or modify it
    however you like) in your documentation although I would appreciate an
    attribution if you keep track of such things.

    Mike

    --8<--

    The Kerberos Keytab Binary File Format
    Michael B Allen
    Last updated: Thu May 4 13:16:23 EDT 2006

    The MIT keytab binary format is not a standard format, nor is it
    documentated anywhere in detail. The format has evolved and may continue
    to. It is however understood by several Kerberos implementations including
    Heimdal and of course MIT and keytab files are created by the ktpass.exe
    utility from Windows. So it has established itself as the defacto format
    for storing Kerberos keys.

    The following C-like structure definitions illustrate the MIT keytab
    file format. All values are in network byte order. All text is ASCII.

    keytab {
    uint16_t file_format_version; /* 0x502 */
    keytab_entry entries[*];
    };

    keytab_entry {
    int32_t size;
    uint16_t num_components; /* subtract 1 if version 0x501 */
    counted_octet_string realm;
    counted_octet_string components[num_components];
    uint32_t name_type; /* not present if version 0x501 */
    uint32_t timestamp;
    uint8_t vno8;
    keyblock key;
    uint32_t vno; /* only present if >= 4 bytes left in entry */
    };

    counted_octet_string {
    uint16_t length;
    uint8_t data[length];
    };

    keyblock {
    uint16_t type;
    counted_octet_string;
    };

    The keytab file format begins with the 16 bit file_format_version which
    at the time this document was authored is 0x502. The format of older
    keytabs is described at the end of this document.

    The file_format_version is immediately followed by an array of
    keytab_entry structures which are prefixed with a 32 bit size indicating
    the number of bytes that follow in the entry. Note that the size should be
    evaluated as signed. This is because a negative value indicates that the
    entry is in fact empty (e.g. it has been deleted) and that the negative
    value of that negative value (which is of course a positive value) is
    the offset to the next keytab_entry. Based on these size values alone
    the entire keytab file can be traversed.

    The size is followed by a 16 bit num_components field indicating the
    number of counted_octet_string components *minus one* that constitute
    the name. A counted_octet_string is simply an array of bytes prefixed
    with a 16 bit length. For the name components, the counted_octet_string
    bytes are ASCII encoded text with no zero terminator.

    Following the components array is the 32 bit name_type (e.g. 1 is
    KRB5_NT_PRINCIPAL, 2 is KRB5_NT_SRV_INST, 5 is KRB5_NT_UID, etc).

    In practice the name_type is almost certainly 1 meaning
    KRB5_NT_PRINCIPAL. For this type of entry the components array consists
    of the realm, service and name (in that order) although if num_components
    is 1, the service component is not present. For example, the service
    principal HTTP/quark.foo.net@FOO.NET would be encoded with name components
    "FOO.NET" followed by "HTTP" followed by "quark.foo.net".

    The 32 bit timestamp indicates the time the key was established for that
    principal. The value represents the number of seconds since Jan 1, 1970.

    The 8 bit vno8 field is the version number of the key. This value is
    overridden by the vno field if it is present.

    The keyblock structure consists of a 16 bit value indicating the keytype
    (e.g. 3 is des-cbc-md5, 23 is arcfour-hmac-md5, 16 is des3-cbc-sha1,
    etc). This is followed by a counted_octet_string containing the key.

    The last field of the keytab_entry structure is optional. If the size of
    the keytab_entry indicates that there are at least 4 bytes remaining,
    a 32 bit value representing the key version number is present. This
    value superceeds the 8 bit value preceeding the keyblock.

    Keytabs with a file_format_version of 0x501 are different in three ways:

    1) All integers are in host byte order [1].
    2) The num_components field is 1 too large (i.e. fter decoding,
    decrement by 1).
    3) The 32 bit name_type field is not present.

    [1] The file_format_version field should really be treated as two
    separate 8 bit quantities representing the major and minor version
    number respectively.


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  9. Re: keytab - MIT Keytab Binary File Format Encoder / Decoder

    Whoops, I forgot to update the part about the components array. I also
    ran ispell on it.

    http://www.ioplex.com/utilities/keytab.txt

    Mike
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread