You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ka...@apache.org on 2015/04/01 11:53:09 UTC
directory-kerby git commit: moved the keytab spec to resources
Repository: directory-kerby
Updated Branches:
refs/heads/master 6a437e9fa -> 7a4aee736
moved the keytab spec to resources
Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
Commit: http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/7a4aee73
Tree: http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/7a4aee73
Diff: http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/7a4aee73
Branch: refs/heads/master
Commit: 7a4aee736f3cc3fb2deae94c3258bced66de70b6
Parents: 6a437e9
Author: Kiran Ayyagari <db...@myytl.net>
Authored: Wed Apr 1 17:52:26 2015 +0800
Committer: Kiran Ayyagari <db...@myytl.net>
Committed: Wed Apr 1 17:52:26 2015 +0800
----------------------------------------------------------------------
.../kerby/kerberos/kerb/keytab/keytab.txt | 106 -------------------
.../kerb-util/src/main/resources/keytab.txt | 106 +++++++++++++++++++
2 files changed, 106 insertions(+), 106 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/directory-kerby/blob/7a4aee73/kerby-kerb/kerb-util/src/main/java/org/apache/kerby/kerberos/kerb/keytab/keytab.txt
----------------------------------------------------------------------
diff --git a/kerby-kerb/kerb-util/src/main/java/org/apache/kerby/kerberos/kerb/keytab/keytab.txt b/kerby-kerb/kerb-util/src/main/java/org/apache/kerby/kerberos/kerb/keytab/keytab.txt
deleted file mode 100644
index 88a7b46..0000000
--- a/kerby-kerb/kerb-util/src/main/java/org/apache/kerby/kerberos/kerb/keytab/keytab.txt
+++ /dev/null
@@ -1,106 +0,0 @@
-The Kerberos Keytab Binary File Format
-Copyright (C) 2006 Michael B Allen <mba2000 ioplex.com>
-http://www.ioplex.com/utilities/keytab.txt
-Last updated: Fri May 5 13:39:40 EDT 2006
-
-The MIT keytab binary format is not a standard format, nor is it
-documented 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; /* sub 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 in the components array.
-
-The num_components field is followed by a counted_octet_string
-representing the realm of the principal.
-
-A counted_octet_string is simply an array of bytes prefixed with a 16
-bit length. For the realm and name components, the counted_octet_string
-bytes are ASCII encoded text with no zero terminator.
-
-Following the realm is the components array that represents the name of
-the principal. The text of these components may be joined with slashs
-to construct the typical SPN representation. For example, the service
-principal HTTP/www.foo.net@FOO.NET would consist of name components
-"HTTP" followed by "www.foo.net".
-
-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.
-
-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 32 bit 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 supersedes the 8 bit vno8 value preceeding the keyblock.
-
-Older 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. after 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.
-
-Permission to copy, modify, and distribute this document, with or
-without modification, for any purpose and without fee or royalty is
-hereby granted, provided that you include this copyright notice in ALL
-copies of the document or portions thereof, including modifications.
http://git-wip-us.apache.org/repos/asf/directory-kerby/blob/7a4aee73/kerby-kerb/kerb-util/src/main/resources/keytab.txt
----------------------------------------------------------------------
diff --git a/kerby-kerb/kerb-util/src/main/resources/keytab.txt b/kerby-kerb/kerb-util/src/main/resources/keytab.txt
new file mode 100644
index 0000000..88a7b46
--- /dev/null
+++ b/kerby-kerb/kerb-util/src/main/resources/keytab.txt
@@ -0,0 +1,106 @@
+The Kerberos Keytab Binary File Format
+Copyright (C) 2006 Michael B Allen <mba2000 ioplex.com>
+http://www.ioplex.com/utilities/keytab.txt
+Last updated: Fri May 5 13:39:40 EDT 2006
+
+The MIT keytab binary format is not a standard format, nor is it
+documented 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; /* sub 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 in the components array.
+
+The num_components field is followed by a counted_octet_string
+representing the realm of the principal.
+
+A counted_octet_string is simply an array of bytes prefixed with a 16
+bit length. For the realm and name components, the counted_octet_string
+bytes are ASCII encoded text with no zero terminator.
+
+Following the realm is the components array that represents the name of
+the principal. The text of these components may be joined with slashs
+to construct the typical SPN representation. For example, the service
+principal HTTP/www.foo.net@FOO.NET would consist of name components
+"HTTP" followed by "www.foo.net".
+
+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.
+
+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 32 bit 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 supersedes the 8 bit vno8 value preceeding the keyblock.
+
+Older 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. after 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.
+
+Permission to copy, modify, and distribute this document, with or
+without modification, for any purpose and without fee or royalty is
+hereby granted, provided that you include this copyright notice in ALL
+copies of the document or portions thereof, including modifications.