[234] in Kerberos-V5-bugs
Description of DCE Keytab changes
daemon@ATHENA.MIT.EDU (Joe Pato)
Wed Jul 15 10:02:51 1992
From: pato@apollo.hp.com (Joe Pato)
Date: Wed, 15 Jul 92 09:57:58 EDT
To: tytso@athena.mit.edu
Cc: krb5-bugs@MIT.EDU
#define KRB5_KT_VNO 0x0501 /* krb5, keytab v 1 */
typedef krb5_int16 krb5_kt_vno;
*
* Copyright (c) Hewlett-Packard Company 1991
* Released to the Massachusetts Institute of Technology for inclusion
* in the Kerberos source code distribution.
*
* Copyright 1990,1991 by the Massachusetts Institute of Technology.
* All Rights Reserved.
*
* Export of this software from the United States of America is assumed
* to require a specific license from the United States Government.
* It is the responsibility of any person or organization contemplating
* export to obtain such a license before exporting.
*
* WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
* distribute this software and its documentation for any purpose and
* without fee is hereby granted, provided that the above copyright
* notice appear in all copies and that both that copyright notice and
* this permission notice appear in supporting documentation, and that
* the name of M.I.T. not be used in advertising or publicity pertaining
* to distribution of the software without specific, written prior
* permission. M.I.T. makes no representations about the suitability of
* this software for any purpose. It is provided "as is" without express
* or implied warranty.
*
*
* This function contains utilities for the file based implementation of
* the keytab. There are no public functions in this file.
*
* This file is the only one that has knowledge of the format of a
* keytab file.
*
* The format is as follows:
*
* <file format vno>
* <record length>
* principal timestamp vno key
* <record length>
* principal timestamp vno key
* ....
*
* A length field (sizeof(krb5_int32)) exists between entries. When this
* length is positive it indicates an active entry, when negative a hole.
* The length indicates the size of the block in the file (this may be
* larger than the size of the next record, since we are using a first
* fit algorithm for re-using holes and the first fit may be larger than
* the entry we are writing). Another (compatible) implementation could
* break up holes when allocating them to smaller entries to minimize
* wasted space. (Such an implementation should also coalesce adjacent
* holes to reduce fragmentation). This implementation does neither.
*
* There are no separators between fields of an entry.
* A principal is a length-encoded array of length-encoded strings. The
* length is a krb5_int16 in each case. The specific format, then, is
* multiple entries concatinated with no separators. An entry has this
* exact format:
*
* sizeof(krb5_int16) bytes for number of components in the principal;
* then, each component listed in ordser.
* For each component, sizeof(krb5_int16) bytes for the number of bytes
* in the component, followed by the component.
* sizeof(krb5_timestamp) bytes for the timestamp
* sizeof(krb5_kvno) bytes for the key version number
* sizeof(krb5_keytype) bytes for the keytype
* sizeof(krb5_int32) bytes for the key length, followed by the key
-------
