diff options
Diffstat (limited to 'crypto/krb5/doc/html/_sources/formats')
7 files changed, 0 insertions, 884 deletions
diff --git a/crypto/krb5/doc/html/_sources/formats/ccache_file_format.rst.txt b/crypto/krb5/doc/html/_sources/formats/ccache_file_format.rst.txt deleted file mode 100644 index 6138c1b58cdf..000000000000 --- a/crypto/krb5/doc/html/_sources/formats/ccache_file_format.rst.txt +++ /dev/null @@ -1,182 +0,0 @@ -.. _ccache_file_format: - -Credential cache file format -============================ - -There are four versions of the file format used by the FILE credential -cache type. The first byte of the file always has the value 5, and -the value of the second byte contains the version number (1 through -4). Versions 1 and 2 of the file format use native byte order for integer -representations. Versions 3 and 4 always use big-endian byte order. - -After the two-byte version indicator, the file has three parts: the -header (in version 4 only), the default principal name, and a sequence -of credentials. - - -Header format -------------- - -The header appears only in format version 4. It begins with a 16-bit -integer giving the length of the entire header, followed by a sequence -of fields. Each field consists of a 16-bit tag, a 16-bit length, and -a value of the given length. A file format implementation should -ignore fields with unknown tags. - -At this time there is only one defined header field. Its tag value is -1, its length is always 8, and its contents are two 32-bit integers -giving the seconds and microseconds of the time offset of the KDC -relative to the client. Adding this offset to the current time on the -client should give the current time on the KDC, if that offset has not -changed since the initial authentication. - - -.. _cache_principal_format: - -Principal format ----------------- - -The default principal is marshalled using the following informal -grammar:: - - principal ::= - name type (32 bits) [omitted in version 1] - count of components (32 bits) [includes realm in version 1] - realm (data) - component1 (data) - component2 (data) - ... - - data ::= - length (32 bits) - value (length bytes) - -There is no external framing on the default principal, so it must be -parsed according to the above grammar in order to find the sequence of -credentials which follows. - - -.. _ccache_credential_format: - -Credential format ------------------ - -The credential format uses the following informal grammar (referencing -the ``principal`` and ``data`` types from the previous section):: - - credential ::= - client (principal) - server (principal) - keyblock (keyblock) - authtime (32 bits) - starttime (32 bits) - endtime (32 bits) - renew_till (32 bits) - is_skey (1 byte, 0 or 1) - ticket_flags (32 bits) - addresses (addresses) - authdata (authdata) - ticket (data) - second_ticket (data) - - keyblock ::= - enctype (16 bits) [repeated twice in version 3] - data - - addresses ::= - count (32 bits) - address1 - address2 - ... - - address ::= - addrtype (16 bits) - data - - authdata ::= - count (32 bits) - authdata1 - authdata2 - ... - - authdata ::= - ad_type (16 bits) - data - -There is no external framing on a marshalled credential, so it must be -parsed according to the above grammar in order to find the next -credential. There is also no count of credentials or marker at the -end of the sequence of credentials; the sequence ends when the file -ends. - - -Credential cache configuration entries --------------------------------------- - -Configuration entries are encoded as credential entries. The client -principal of the entry is the default principal of the cache. The -server principal has the realm ``X-CACHECONF:`` and two or three -components, the first of which is ``krb5_ccache_conf_data``. The -server principal's second component is the configuration key. The -third component, if it exists, is a principal to which the -configuration key is associated. The configuration value is stored in -the ticket field of the entry. All other entry fields are zeroed. - -Programs using credential caches must be aware of configuration -entries for several reasons: - -* A program which displays the contents of a cache should not - generally display configuration entries. - -* The ticket field of a configuration entry is not (usually) a valid - encoding of a Kerberos ticket. An implementation must not treat the - cache file as malformed if it cannot decode the ticket field. - -* Configuration entries have an endtime field of 0 and might therefore - always be considered expired, but they should not be treated as - unimportant as a result. For instance, a program which copies - credentials from one cache to another should not omit configuration - entries because of the endtime. - -The following configuration keys are currently used in MIT krb5: - -fast_avail - The presence of this key with a non-empty value indicates that the - KDC asserted support for FAST (see :rfc:`6113`) during the initial - authentication, using the negotiation method described in - :rfc:`6806` section 11. This key is not associated with any - principal. - -pa_config_data - The value of this key contains a JSON object representation of - parameters remembered by the preauthentication mechanism used - during the initial authentication. These parameters may be used - when refreshing credentials. This key is associated with the - server principal of the initial authentication (usually the local - krbtgt principal of the client realm). - -pa_type - The value of this key is the ASCII decimal representation of the - preauth type number used during the initial authentication. This - key is associated with the server principal of the initial - authentication. - -proxy_impersonator - The presence of this key indicates that the cache is a synthetic - delegated credential for use with S4U2Proxy. The value is the - name of the intermediate service whose TGT can be used to make - S4U2Proxy requests for target services. This key is not - associated with any principal. - -refresh_time - The presence of this key indicates that the cache was acquired by - the GSS mechanism using a client keytab. The value is the ASCII - decimal representation of a timestamp at which the GSS mechanism - should attempt to refresh the credential cache from the client - keytab. - -start_realm - This key indicates the realm of the ticket-granting ticket to be - used for TGS requests, when making a referrals request or - beginning a cross-realm request. If it is not present, the client - realm is used. diff --git a/crypto/krb5/doc/html/_sources/formats/cookie.rst.txt b/crypto/krb5/doc/html/_sources/formats/cookie.rst.txt deleted file mode 100644 index 3c7d0b03cf3c..000000000000 --- a/crypto/krb5/doc/html/_sources/formats/cookie.rst.txt +++ /dev/null @@ -1,111 +0,0 @@ -.. highlight:: abnf - -KDC cookie format -================= - -:rfc:`6113` section 5.2 specifies a pa-data type PA-FX-COOKIE, which -clients are required to reflect back to the KDC during -pre-authentication. The MIT krb5 KDC uses the following formats for -cookies. - - -Trivial cookie (version 0) --------------------------- - -If there is no pre-authentication mechanism state information to save, -a trivial cookie containing the value "MIT" is used. A trivial cookie -is needed to indicate that the conversation can continue. - - -Secure cookie (version 1) -------------------------- - -In release 1.14 and later, a secure cookie can be sent if there is any -mechanism state to save for the next request. A secure cookie -contains the concatenation of the following: - -* the four bytes "MIT1" -* a four-byte big-endian kvno value -* an :rfc:`3961` ciphertext - -The ciphertext is encrypted in the cookie key with key usage -number 513. The cookie key is derived from a key in the local krbtgt -principal entry for the realm (e.g. ``krbtgt/KRBTEST.COM@KRBTEST.COM`` -if the request is to the ``KRBTEST.COM`` realm). The first krbtgt key -for the indicated kvno value is combined with the client principal as -follows:: - - cookie-key <- random-to-key(PRF+(tgt-key, "COOKIE" | client-princ)) - -where **random-to-key** is the :rfc:`3961` random-to-key operation for -the krbtgt key's encryption type, **PRF+** is defined in :rfc:`6113`, -and ``|`` denotes concatenation. *client-princ* is the request client -principal name with realm, marshalled according to :rfc:`1964` section -2.1.1. - -The plain text of the encrypted part of a cookie is the DER encoding -of the following ASN.1 type: - -.. code-block:: bnf - - SecureCookie ::= SEQUENCE { - time INTEGER, - data SEQUENCE OF PA-DATA, - ... - } - -The time field represents the cookie creation time; for brevity, it is -encoded as an integer giving the POSIX timestamp rather than as an -ASN.1 GeneralizedTime value. The data field contains one element for -each pre-authentication type which requires saved state. For -mechanisms which have separate request and reply types, the request -type is used; this allows the KDC to determine whether a cookie is -relevant to a request by comparing the request pa-data types to the -cookie data types. - -SPAKE cookie format (version 1) -------------------------------- - -Inside the SecureCookie wrapper, a data value of type 151 contains -state for SPAKE pre-authentication. This data has the following -binary format with big-endian integer encoding: - -.. code-block:: bnf - - cookie ::= - version (16 bits) [with the value 1] - stage number (16 bits) - group number (32 bits) - SPAKE value length (32 bits) - SPAKE value - transcript hash length (32 bits) - transcript hash - second factor record 1 (factor-record) - second factor record 2 (factor-record) - ... - - factor-record ::= - second factor type (32 bits) - second factor data length (32 bits) - second factor data - -The stage value is 0 if the cookie was sent with a challenge message. -Otherwise it is 1 for the first encdata message sent by the KDC during -an exchange, 2 for the second, etc.. - -The group value indicates the group number used in the SPAKE challenge. - -For a stage-0 cookie, the SPAKE value is the KDC private key, -represented in the scalar marshalling form of the group. For other -cookies, the SPAKE value is the SPAKE result K, represented in the -group element marshalling form. - -For a stage-0 cookie, the transcript hash is the intermediate hash -after updating with the client support message (if one was sent) and -challenge. For other cookies it is the final hash. - -For a stage-0 cookie, there may be any number of second-factor -records, including none; a second-factor type need not create a state -field if it does not need one, and no record is created for SF-NONE. -For other cookies, there must be exactly one second-factor record -corresponding to the factor type chosen by the client. diff --git a/crypto/krb5/doc/html/_sources/formats/database_formats.rst.txt b/crypto/krb5/doc/html/_sources/formats/database_formats.rst.txt deleted file mode 100644 index fca5979c1f00..000000000000 --- a/crypto/krb5/doc/html/_sources/formats/database_formats.rst.txt +++ /dev/null @@ -1,459 +0,0 @@ -Kerberos Database (KDB) Formats -=============================== - -Dump format ------------ - -Files created with the :ref:`kdb5_util(8)` **dump** command begin with -a versioned header "kdb5_util load_dump version 7". This version has -been in use since MIT krb5 release 1.11; some previous versions are -supported but are not described here. - -Each subsequent line of the dump file contains one or more -tab-separated fields describing either a principal entry or a policy -entry. The fields of a principal entry line are: - -* the word "princ" -* the string "38" (this was originally a length field) -* the length of the principal name in string form -* the decimal number of tag-length data elements -* the decimal number of key-data elements -* the string "0" (this was originally an extension length field) -* the principal name in string form -* the principal attributes as a decimal number; when converted to - binary, the bits from least significant to most significant are: - - - disallow_postdated - - disallow_forwardable - - disallow_tgt_based - - disallow_renewable - - disallow_proxiable - - disallow_dup_skey - - disallow_all_tix - - requires_preauth - - requires_hwauth - - requires_pwchange - - disallow_svr - - pwchange_service - - support_desmd5 - - new_princ - - ok_as_delegate - - ok_to_auth_as_delegate - - no_auth_data_required - - lockdown_keys - -* the maximum ticket lifetime, as a decimal number of seconds -* the maximum renewable ticket lifetime, as a decimal number of seconds -* the principal expiration time, as a decimal POSIX timestamp -* the password expiration time, as a decimal POSIX timestamp -* the last successful authentication time, as a decimal POSIX - timestamp -* the last failed authentication time, as a decimal POSIX timestamp -* the decimal number of failed authentications since the last - successful authentication time -* for each tag-length data value: - - - the tag value in decimal - - the length in decimal - - the data as a lowercase hexadecimal byte string, or "-1" if the length is 0 - -* for each key-data element: - - - the string "2" if this element has non-normal salt type, "1" - otherwise - - the key version number of this element - - the encryption type - - the length of the encrypted key value - - the encrypted key as a lowercase hexadecimal byte string - - if this element has non-normal salt type: - - - the salt type - - the length of the salt data - - the salt data as a lowercase hexadecimal byte string, or the - string "-1" if the salt data length is 0 - -* the string "-1;" (this was originally an extension field) - -The fields of a policy entry line are: - -* the string "policy" -* the policy name -* the minimum password lifetime as a decimal number of seconds -* the maximum password lifetime as a decimal number of seconds -* the minimum password length, in decimal -* the minimum number of character classes, in decimal -* the number of historical keys to be stored, in decimal -* the policy reference count (no longer used) -* the maximum number of failed authentications before lockout -* the time interval after which the failed authentication count is - reset, as a decimal number of seconds -* the lockout duration, as a decimal number of seconds -* the required principal attributes, in decimal (currently unenforced) -* the maximum ticket lifetime as a decimal number of seconds - (currently unenforced) -* the maximum renewable lifetime as a decimal number of seconds - (currently unenforced) -* the allowed key/salt types, or "-" if unrestricted -* the number of tag-length values -* for each tag-length data value: - - - the tag value in decimal - - the length in decimal - - the data as a lowercase hexadecimal byte string, or "-1" if the - length is 0 - - -Tag-length data formats ------------------------ - -The currently defined tag-length data types are: - -* (1) last password change: a four-byte little-endian POSIX timestamp - giving the last password change time -* (2) last modification data: a four-byte little-endian POSIX - timestamp followed by a zero-terminated principal name in string - form, giving the time of the last principal change and the principal - who performed it -* (3) kadmin data: the XDR encoding of a per-principal kadmin data - record (see below) -* (8) master key version: a two-byte little-endian integer containing - the master key version used to encrypt this principal's key data -* (9) active kvno: see below -* (10) master key auxiliary data: see below -* (11) string attributes: one or more iterations of a zero-terminated - string key followed by a zero-terminated string value -* (12) alias target principal: a zero-terminated principal name in - string form -* (255) LDAP object information: see below -* (768) referral padata: a DER-encoded PA-SVR-REFERRAL-DATA to be sent - to a TGS-REQ client within encrypted padata (see Appendix A of - :rfc:`1606`) -* (1792) last admin unlock: a four-byte little-endian POSIX timestamp - giving the time of the last administrative account unlock -* (32767) database arguments: a zero-terminated key=value string (may - appear multiple times); used by the kadmin protocol to - communicate -x arguments to kadmind - -Per-principal kadmin data -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Per-principal kadmin data records use a modified XDR encoding of the -kadmin_data type defined as follows: - -.. code-block:: c - - struct key_data { - int numfields; - unsigned int kvno; - int enctype; - int salttype; - unsigned int keylen; - unsigned int saltlen; - opaque key<>; - opaque salt<>; - }; - - struct hist_entry { - key_data keys<>; - }; - - struct kadmin_data { - int version_number; - nullstring policy; - int aux_attributes; - unsigned int old_key_next; - unsigned int admin_history_kvno; - hist_entry old_keysets<>; - }; - -The type "nullstring" uses a custom string encoder where the length -field is zero or the string length plus one; a length of zero -indicates that no policy object is specified for the principal. The -field "version_number" contains 0x12345C01. The aux_attributes field -contains the bit 0x800 if a policy object is associated with the -principal. - -Within a key_data record, numfields is 2 if the key data has -non-normal salt type, 1 otherwise. - -Active kvno and master key auxiliary data -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -These types only appear in the entry of the master key principal -(K/M). They use little-endian binary integer encoding. - -The active kvno table determines which master key version is active -for a given timestamp. It uses the following binary format: - -.. code-block:: bnf - - active-key-version-table ::= - version (16 bits) [with the value 1] - version entry 1 (key-version-entry) - version entry 2 (key-version-entry) - ... - - key-version-entry ::= - key version (16 bits) - timestamp (32 bits) [when this key version becomes active] - -The master key auxiliary data record contains copies of the current -master key encrypted in each older master key. It uses the following -binary format: - -.. code-block:: bnf - - master-key-aux ::= - version (16 bits) [with the value 1] - key entry 1 (key-entry) - key entry 2 (key-entry) - ... - - key-entry ::= - old master key version (16 bits) - latest master key version (16 bits) - latest master key encryption type (16 bits) - encrypted key length (16 bits) - encrypted key contents - -LDAP object information -~~~~~~~~~~~~~~~~~~~~~~~ - -This type appears in principal entries retrieved with the LDAP KDB -module. The value uses the following binary format, using big-endian -integer encoding: - -.. code-block:: bnf - - ldap-principal-data ::= - record 1 (ldap-tl-data) - record 2 (ldap-tl-data) - ... - - ldap-tl-data ::= - type (8 bits) - length (16 bits) - data - -The currently defined ldap-tl-data types are (all integers are -big-endian): - -* (1) principal type: 16 bits containing the value 1, indicating that - the LDAP object containing the principal entry is a standalone - principal object -* (2) principal count: 16 bits containing the number of - krbPrincipalName values in the LDAP object -* (3) user DN: the string representation of the distinguished name of - the LDAP object -* (5) attribute mask: 16 bits indicating which Kerberos-specific LDAP - attributes are present in the LDAP object (see below) -* (7) link DN: the string representation of the distinguished name of - an LDAP object this object is linked to; may appear multiple times - -When converted to binary, the attribute mask bits, from least -significant to most significant, correspond to the following LDAP -attributes: - -* krbMaxTicketLife -* krbMaxRenewableAge -* krbTicketFlags -* krbPrincipalExpiration -* krbTicketPolicyReference -* krbPrincipalAuthInd -* krbPwdPolicyReference -* krbPasswordExpiration -* krbPrincipalKey -* krbLastPwdChange -* krbExtraData -* krbLastSuccessfulAuth -* krbLastFailedAuth -* krbLoginFailedCount -* krbLastAdminUnlock -* krbPwdHistory - - -Alias principal entries ------------------------ - -To allow aliases to be represented in dump files and within the -incremental update protocol, the krb5 database library supports the -concept of an alias principal entry. An alias principal entry -contains an alias target principal in its tag-length data, has its -attributes set to disallow_all_tix, and has zero or empty values for -all other fields. The database glue library recognizes alias entries -and iteratively looks up the alias target up to a depth of 10 chained -aliases. (Added in release 1.22.) - - -DB2 principal and policy formats --------------------------------- - -The DB2 KDB module uses the string form of a principal name, with zero -terminator, as a lookup key for principal entries. Principal entry -values use the following binary format with little-endian integer -encoding: - -.. code-block:: bnf - - db2-principal-entry ::= - len (16 bits) [always has the value 38] - attributes (32 bits) - max ticket lifetime (32 bits) - max renewable lifetime (32 bits) - principal expiration timestamp (32 bits) - password expiration timestamp (32 bits) - last successful authentication timestamp (32 bits) - last failed authentication timestamp (32 bits) - failed authentication counter (32 bits) - number of tag-length elements (16 bits) - number of key-data elements (16 bits) - length of string-form principal with zero terminator (16 bits) - string-form principal with zero terminator - tag-length entry 1 (tag-length-data) - tag-length entry 2 (tag-length-data) - ... - key-data entry 1 (key-data) - key-data entry 2 (key-data) - ... - - tag-length-data ::= - type tag (16 bits) - data length (16 bits) - data - - key-data ::= - salt indicator (16 bits) [1 for default salt, 2 otherwise] - key version (16 bits) - encryption type (16 bits) - encrypted key length (16 bits) - encrypted key - salt type (16 bits) [omitted if salt indicator is 1] - salt data length (16 bits) [omitted if salt indicator is 1] - salt data [omitted if salt indicator is 1] - -DB2 policy entries reside in a separate database file. The lookup key -is the policy name with zero terminator. Policy entry values use a -modified XDR encoding of the policy type defined as follows: - -.. code-block:: c - - struct tl_data { - int type; - opaque data<>; - tl_data *next; - }; - - struct policy { - int version_number; - unsigned int min_life; - unsigned int max_pw_life; - unsigned int min_length; - unsigned int min_classes; - unsigned int history_num; - unsigned int refcount; - unsigned int max_fail; - unsigned int failcount_interval; - unsigned int lockout_duration; - unsigned int attributes; - unsigned int max_ticket_life; - unsigned int max_renewable_life; - nullstring allowed_keysalts; - int n_tl_data; - tl_data *tag_length_data; - }; - -The type "nullstring" uses the same custom encoder as in the -per-principal kadmin data. - -The field "version_number" contains 0x12345D01, 0x12345D02, or -0x12345D03 for versions 1, 2, and 3 respectively. Versions 1 and 2 -omit the fields "attributes" through "tag_length_data". Version 1 -also omits the fields "max_fail" through "lockout_duration". Encoding -uses the lowest version that can represent the policy entry. - -The field "refcount" is no longer used and its value is ignored. - - -LMDB principal and policy formats ---------------------------------- - -In the LMDB KDB module, principal entries are stored in the -"principal" database within the main LMDB environment (typically named -"principal.mdb"), with the exception of lockout-related fields which -are stored in the "lockout" table of the lockout LMDB environment -(typically named "principal.lockout.mdb"). For both databases the key -is the principal name in string form, with no zero terminator. Values -in the "principal" database use the following binary format with -little-endian integer encoding: - -.. code-block:: bnf - - lmdb-principal-entry ::= - attributes (32 bits) - max ticket lifetime (32 bits) - max renewable lifetime (32 bits) - principal expiration timestamp (32 bits) - password expiration timestamp (32 bits) - number of tag-length elements (16 bits) - number of key-data elements (16 bits) - tag-length entry 1 (tag-length-data) - tag-length entry 2 (tag-length-data) - ... - key-data entry 1 (key-data) - key-data entry 2 (key-data) - ... - - tag-length-data ::= - type tag (16 bits) - data length (16 bits) - data value - - key-data ::= - salt indicator (16 bits) [1 for default salt, 2 otherwise] - key version (16 bits) - encryption type (16 bits) - encrypted key length (16 bits) - encrypted key - salt type (16 bits) [omitted if salt indicator is 1] - salt data length (16 bits) [omitted if salt indicator is 1] - salt data [omitted if salt indicator is 1] - -Values in the "lockout" database have the following binary format with -little-endian integer encoding: - -.. code-block:: bnf - - lmdb-lockout-entry ::= - last successful authentication timestamp (32 bits) - last failed authentication timestamp (32 bits) - failed authentication counter (32 bits) - -In the "policy" database, the lookup key is the policy name with no -zero terminator. Values in this database use the following binary -format with little-endian integer encoding: - -.. code-block:: bnf - - lmdb-policy-entry ::= - minimum password lifetime (32 bits) - maximum password lifetime (32 bits) - minimum password length (32 bits) - minimum character classes (32 bits) - number of historical keys (32 bits) - maximum failed authentications before lockout (32 bits) - time interval to reset failed authentication counter (32 bits) - lockout duration (32 bits) - required principal attributes (32 bits) [currently unenforced] - maximum ticket lifetime (32 bits) [currently unenforced] - maximum renewable lifetime (32 bits) [currently unenforced] - allowed key/salt type specification length [32 bits] - allowed key/salt type specification - number of tag-length values (16 bits) - tag-length entry 1 (tag-length-data) - tag-length entry 2 (tag-length-data) - ... - - tag-length-data ::= - type tag (16 bits) - data length (16 bits) - data value diff --git a/crypto/krb5/doc/html/_sources/formats/freshness_token.rst.txt b/crypto/krb5/doc/html/_sources/formats/freshness_token.rst.txt deleted file mode 100644 index 3127621a9f0b..000000000000 --- a/crypto/krb5/doc/html/_sources/formats/freshness_token.rst.txt +++ /dev/null @@ -1,19 +0,0 @@ -PKINIT freshness tokens -======================= - -:rfc:`8070` specifies a pa-data type PA_AS_FRESHNESS, which clients -should reflect within signed PKINIT data to prove recent access to the -client certificate private key. The contents of a freshness token are -left to the KDC implementation. The MIT krb5 KDC uses the following -format for freshness tokens (starting in release 1.17): - -* a four-byte big-endian POSIX timestamp -* a four-byte big-endian key version number -* an :rfc:`3961` checksum, with no ASN.1 wrapper - -The checksum is computed using the first key in the local krbtgt -principal entry for the realm (e.g. ``krbtgt/KRBTEST.COM@KRBTEST.COM`` -if the request is to the ``KRBTEST.COM`` realm) of the indicated key -version. The checksum type must be the mandatory checksum type for -the encryption type of the krbtgt key. The key usage value for the -checksum is 514. diff --git a/crypto/krb5/doc/html/_sources/formats/index.rst.txt b/crypto/krb5/doc/html/_sources/formats/index.rst.txt deleted file mode 100644 index 819b839de8aa..000000000000 --- a/crypto/krb5/doc/html/_sources/formats/index.rst.txt +++ /dev/null @@ -1,12 +0,0 @@ -Protocols and file formats -========================== - -.. toctree:: - :maxdepth: 1 - - ccache_file_format - keytab_file_format - rcache_file_format - cookie - freshness_token - database_formats diff --git a/crypto/krb5/doc/html/_sources/formats/keytab_file_format.rst.txt b/crypto/krb5/doc/html/_sources/formats/keytab_file_format.rst.txt deleted file mode 100644 index 8424d058ff46..000000000000 --- a/crypto/krb5/doc/html/_sources/formats/keytab_file_format.rst.txt +++ /dev/null @@ -1,51 +0,0 @@ -.. _keytab_file_format: - -Keytab file format -================== - -There are two versions of the file format used by the FILE keytab -type. The first byte of the file always has the value 5, and the -value of the second byte contains the version number (1 or 2). -Version 1 of the file format uses native byte order for integer -representations. Version 2 always uses big-endian byte order. - -After the two-byte version indicator, the file contains a sequence of -signed 32-bit record lengths followed by key records or holes. A -positive record length indicates a valid key entry whose size is equal -to or less than the record length. A negative length indicates a -zero-filled hole whose size is the inverse of the length. A length of -0 indicates the end of the file. - - -Key entry format ----------------- - -A key entry may be smaller in size than the record length which -precedes it, because it may have replaced a hole which is larger than -the key entry. Key entries use the following informal grammar:: - - entry ::= - principal - timestamp (32 bits) - key version (8 bits) - enctype (16 bits) - key length (16 bits) - key contents - key version (32 bits) [in release 1.14 and later] - - principal ::= - count of components (16 bits) [includes realm in version 1] - realm (data) - component1 (data) - component2 (data) - ... - name type (32 bits) [omitted in version 1] - - data ::= - length (16 bits) - value (length bytes) - -The 32-bit key version overrides the 8-bit key version. To determine -if it is present, the implementation must check that at least 4 bytes -remain in the record after the other fields are read, and that the -value of the 32-bit integer contained in those bytes is non-zero. diff --git a/crypto/krb5/doc/html/_sources/formats/rcache_file_format.rst.txt b/crypto/krb5/doc/html/_sources/formats/rcache_file_format.rst.txt deleted file mode 100644 index 42ee82817ac1..000000000000 --- a/crypto/krb5/doc/html/_sources/formats/rcache_file_format.rst.txt +++ /dev/null @@ -1,50 +0,0 @@ -Replay cache file format -======================== - -This section documents the second version of the replay cache file -format, used by the "file2" replay cache type (new in release 1.18). -The first version of the file replay cache format is not documented. - -All accesses to the replay cache file take place under an exclusive -POSIX or Windows file lock, obtained when the file is opened and -released when it is closed. Replay cache files are automatically -created when first accessed. - -For each store operation, a tag is derived from the checksum part of -the :RFC:`3961` ciphertext of the authenticator. The checksum is -coerced to a fixed length of 12 bytes, either through truncation or -right-padding with zero bytes. A four-byte timestamp is appended to -the tag to produce a total record length of 16 bytes. - -Bytes 0 through 15 of the file contain a hash seed for the SipHash-2-4 -algorithm (siphash_); this field is populated with random bytes when -the file is first created. All remaining bytes are divided into a -series of expanding hash tables: - -* Bytes 16-16383: hash table 1 (1023 slots) -* Bytes 16384-49151: hash table 2 (2048 slots) -* Bytes 49152-114687: hash table 3 (4096 slots) -* ... - -Only some hash tables will be present in the file at any specific -time, and the final table may be only partially filled. Replay cache -files may be sparse if the filesystem supports it. - -For each table present in the file, the tag is hashed with SipHash-2-4 -using the seed recorded in the file. The first byte of the seed is -incremented by one (modulo 256) for each table after the first. The -resulting hash value is taken modulo one less than the table size -(1022 for the first hash table, 2047 for the second) to produce the -index. The record may be found at the slot given by the index or at -the next slot. - -All candidate locations for the record must be searched until a slot -is found with a timestamp of zero (indicating a slot which has never -been written to) or an offset is reached at or beyond the end of the -file. Any candidate location with a timestamp value of zero, with a -timestamp value less than the current time minus clockskew, or at or -beyond the end of the file is available for writing. When all -candidate locations have been searched without finding a match, the -new entry is written to the earliest candidate available for writing. - -.. _siphash: https://131002.net/siphash/siphash.pdf |