directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kayyag...@apache.org
Subject directory-kerby git commit: moved the keytab spec to resources
Date Wed, 01 Apr 2015 09:53:09 GMT
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 <dbugger@myytl.net>
Authored: Wed Apr 1 17:52:26 2015 +0800
Committer: Kiran Ayyagari <dbugger@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.


Mime
View raw message