From 1a3ae3ec618f57d96aed406ed3a67133cbc09b0d Mon Sep 17 00:00:00 2001 From: Tom Yu Date: Wed, 4 May 2016 20:34:39 -0400 Subject: [PATCH] Remove non-DFSG documentation Also remove obsolete kadmin and kpasswd documentation. ticket: 8404 (new) --- doc/kadmin/README | 46 - .../draft-ietf-cat-kerb-chg-password-02.txt | 311 - doc/kadmin/kadmin.protocol | 382 - doc/kadmin/kpasswd.protocol | 303 - .../draft-ietf-cat-kerberos-pk-init-09.txt | 908 -- .../draft-jaganathan-rc4-hmac-03.txt | 1013 --- doc/krb5-protocol/krb5.constants | 156 - doc/krb5-protocol/rfc3961.txt | 2803 ------ doc/krb5-protocol/rfc3962.txt | 899 -- doc/krb5-protocol/rfc4120.txt | 7731 ----------------- doc/krb5-protocol/rfc4121.txt | 1123 --- doc/krb5-protocol/rfc4557.txt | 339 - 12 files changed, 16014 deletions(-) delete mode 100644 doc/kadmin/README delete mode 100644 doc/kadmin/draft-ietf-cat-kerb-chg-password-02.txt delete mode 100644 doc/kadmin/kadmin.protocol delete mode 100644 doc/kadmin/kpasswd.protocol delete mode 100644 doc/krb5-protocol/draft-ietf-cat-kerberos-pk-init-09.txt delete mode 100755 doc/krb5-protocol/draft-jaganathan-rc4-hmac-03.txt delete mode 100644 doc/krb5-protocol/krb5.constants delete mode 100644 doc/krb5-protocol/rfc3961.txt delete mode 100644 doc/krb5-protocol/rfc3962.txt delete mode 100644 doc/krb5-protocol/rfc4120.txt delete mode 100644 doc/krb5-protocol/rfc4121.txt delete mode 100644 doc/krb5-protocol/rfc4557.txt diff --git a/doc/kadmin/README b/doc/kadmin/README deleted file mode 100644 index f3e6dfdf10..0000000000 --- a/doc/kadmin/README +++ /dev/null @@ -1,46 +0,0 @@ -There are several different admin protocols in our source tree. - -a) V4 server protocol - not documented - -b) Old kadmin protocol - which was in the beta code (kadmin/v5passwdd) - -c) Newer kadm5 gssrpc based code (kadmin/server) - -d) Simple password changing protocol implemented in our kadmin server -with client in clients/kpasswd. - - - -This file will attempt to link the files in this directory with where -the code is used in the source tree. - - -- kpasswd.protocol: Describes the password changing protocol in - src/kadmin/v5passwdd. - include/adm.h has some definitions. - - Client and server provided - -- kadmin.protocol: Describes other administrative protocol options that - src/kadmin/v5passwdd supports - - No client in the source tree uses it. - -- draft-ietf-cat-kerb-chg-password-02.txt: Describes the - password changing service that - clients/kpasswd uses through krb5_change_password() - located in lib/krb5/os/changepw.c - - kadmin/server/schpw.c implements this as part of - the kadmin server. - - This is version 1 of the protocol. Version 2 is - in the IETF draft stage and is very different. - - Currently: Version 1 is supported - but we may not - be implementing the TCP handling aspects. - -- ../doc/kadm5: Describes the current protocol. - - kadmin/passwd (which is not installed) uses - the kadm5 protocol for password changing. diff --git a/doc/kadmin/draft-ietf-cat-kerb-chg-password-02.txt b/doc/kadmin/draft-ietf-cat-kerb-chg-password-02.txt deleted file mode 100644 index e235bec58c..0000000000 --- a/doc/kadmin/draft-ietf-cat-kerb-chg-password-02.txt +++ /dev/null @@ -1,311 +0,0 @@ - - - - -Network Working Group M. Horowitz - Stonecast, Inc. -Internet-Draft August, 1998 - - Kerberos Change Password Protocol - -Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow - Directories on ftp.ietf.org (US East Coast), nic.nordu.net - (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific - Rim). - - Distribution of this memo is unlimited. Please send comments to the - mailing list. - -Abstract - - The Kerberos V5 protocol [RFC1510] does not describe any mechanism - for users to change their own passwords. In order to promote - interoperability between workstations, personal computers, terminal - servers, routers, and KDC's from multiple vendors, a common password - changing protocol is required. - - - -Overview - - When a user wishes to change his own password, or is required to by - local policy, a simple request of a password changing service is - necessary. This service must be implemented on at least one host for - each Kerberos realm, probably on one of the kdc's for that realm. - The service must accept requests on UDP port 464 (kpasswd), and may - accept requests on TCP port 464 as well. - - The protocol itself consists of a single request message followed by - a single reply message. For UDP transport, each message must be - fully contained in a single UDP packet. - - - - - - - - -Horowitz [Page 1] - -Internet Draft Kerberos Change Password Protocol August, 1998 - - -Request Message - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | message length | protocol version number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | AP_REQ length | AP-REQ data / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / KRB-PRIV message / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - message length (16 bits) - Contains the length of the message, including this field, in bytes - (big-endian integer) - protocol version number (16 bits) - Contains the hex constant 0x0001 (big-endian integer) - AP-REQ length (16 bits) - length (big-endian integer) of AP-REQ data, in bytes. - AP-REQ data, as described in RFC1510 (variable length) - This AP-REQ must be for the service principal - kadmin/changepw@REALM, where REALM is the REALM of the user who - wishes to change his password. The Ticket in the AP-REQ must be - derived from an AS request (thus having the INITIAL flag set), and - must include a subkey in the Authenticator. - KRB-PRIV message, as described in RFC1510 (variable length) - This KRB-PRIV message must be generated using the subkey in the - Authenticator in the AP-REQ data. The user-data component of the - message must consist of the user's new password. - - The server must verify the AP-REQ message, decrypt the new password, - perform any local policy checks (such as password quality, history, - authorization, etc.) required, then set the password to the new value - specified. - - The principal whose password is to be changed is the principal which - authenticated to the password changing service. This protocol does - not address administrators who want to change passwords of principal - besides their own. - - -Reply Message - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | message length | protocol version number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | AP_REP length | AP-REP data / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / KRB-PRIV or KRB-ERROR message / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - message length (16 bits) - - - -Horowitz [Page 2] - -Internet Draft Kerberos Change Password Protocol August, 1998 - - - Contains the length of the message, including this field, in bytes - (big-endian integer), - protocol version number (16 bits) - Contains the hex constant 0x0001 (big-endian integer) - AP-REP length (16 bits) - length of AP-REP data, in bytes. If the the length is zero, then - the last field will contain a KRB-ERROR message instead of a KRB- - PRIV message. - AP-REP data, as described in RFC1510 (variable length) - The AP-REP corresponding to the AP-REQ in the request packet. - KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable - length) - If the AP-REP length is zero, then this field contains a KRB-ERROR - message. Otherwise, it contains a KRB-PRIV message. This KRB- - PRIV message must be generated using the subkey in the - Authenticator in the AP-REQ data. - - The user-data component of the KRB-PRIV message, or e-data - component of the KRB-ERROR message, must consist of the following - data: - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | result code | result string / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - result code (16 bits) - The result code must have one of the following values (big- - endian integer): - 0x0000 if the request succeeds. (This value is not permitted - in a KRB-ERROR message.) - 0x0001 if the request fails due to being malformed - 0x0002 if the request fails due to a "hard" error processing - the request (for example, there is a resource or other - problem causing the request to fail) - 0x0003 if the request fails due to an error in authentication - processing - 0x0004 if the request fails due to a "soft" error processing - the request (for example, some policy or other similar - consideration is causing the request to be rejected). - 0xFFFF if the request fails for some other reason. - Although only a few non-zero result codes are specified here, - the client should accept any non-zero result code as indicating - failure. - result string (variable length) - This field should contain information which the server thinks - might be useful to the user, such as feedback about policy - failures. The string must be encoded in UTF-8. It may be - omitted if the server does not wish to include it. If it is - present, the client should display the string to the user. - This field is analogous to the string which follows the numeric - code in SMTP, FTP, and similar protocols. - - - - -Horowitz [Page 3] - -Internet Draft Kerberos Change Password Protocol August, 1998 - - -Dropped and Modified Messages - - An attacker (or simply a lossy network) could cause either the - request or reply to be dropped, or modified by substituting a KRB- - ERROR message in the reply. - - If a request is dropped, no modification of the password/key database - will take place. If a reply is dropped, the server will (assuming a - valid request) make the password change. However, the client cannot - distinguish between these two cases. - - In this situation, the client should construct a new authenticator, - re-encrypt the request, and retransmit. If the original request was - lost, the server will treat this as a valid request, and the password - will be changed normally. If the reply was lost, then the server - should take care to notice that the request was a duplicate of the - prior request, because the "new" password is the current password, - and the password change time is within some implementation-defined - replay time window. The server should then return a success reply - (an AP-REP message with result code == 0x0000) without actually - changing the password or any other information (such as modification - timestamps). - - If a success reply was replaced with an error reply, then the - application performing the request would return an error to the user. - In this state, the user's password has been changed, but the user - believes that it has not. If the user attempts to change the - password again, this will probably fail, because the user cannot - successfully provide the old password to get an INITIAL ticket to - make the request. This situation requires administrative - intervention as if a password was lost. This situation is, - unfortunately, impossible to prevent. - - -Security Considerations - - This document deals with changing passwords for Kerberos. Because - Kerberos is used for authentication and key distribution, it is - important that this protocol use the highest level of security - services available to a particular installation. Mutual - authentication is performed, so that the server knows the request is - valid, and the client knows that the request has been received and - processed by the server. - - There are also security issues relating to dropped or modified - messages which are addressed explicitly. - - -References - - [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network - Authentication Service (V5)", RFC 1510, September 1993. - - - - - -Horowitz [Page 4] - -Internet Draft Kerberos Change Password Protocol August, 1998 - - -Author's Address - - Marc Horowitz - Stonecast, Inc. - 108 Stow Road - Harvard, MA 01451 - - Phone: +1 978 456 9103 - Email: marc@stonecast.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Horowitz [Page 5] - diff --git a/doc/kadmin/kadmin.protocol b/doc/kadmin/kadmin.protocol deleted file mode 100644 index 5e48945f69..0000000000 --- a/doc/kadmin/kadmin.protocol +++ /dev/null @@ -1,382 +0,0 @@ - -This document references, accompanies and extends the password changing -protocol document, "A Proposal for a Standardized Kerberos Password -Changing Protocol" by Theodore Ts'o. - -Administrative Command Extensions to the Password Changing Protocol -=================================================================== -The following commands and their accompanying definitions are an -extension to the password changing protocol which allow remote -administrative clients to perform functions analogous to those which -are performed using the local database editing utility. These -commands are encoded in the "command request" PDU described in the -password changing protocol, and the server's responses to these -commands are encoded in the "command reply" PDU. - -These commands are (optional commands are marked with an asterisk, new -or changed commands are marked with a plus sign): - ADD-PRINCIPAL - DELETE-PRINCIPAL - RENAME-PRINCIPAL - MODIFY-PRINCIPAL - OTHER-CHANGEPW - OTHER-RANDOM-CHANGEPW - INQUIRE-PRINCIPAL - EXTRACT-KEY (*+) - ADD-KEY (+) - DELETE-KEY (+) - -In order to support these additional commands, the following additional -status codes are also defined: - -Number Symbolic Name Meaning -64 P_ALREADY_EXISTS The specified principal already exists. -65 P_DOES_NOT_EXIST The specified principal does not exist. -66 NOT_AUTHORIZED The access control list on the server prevents - this operation. -67 BAD_OPTION Either: 1) A bad option was specified; 2) A - conflicting set of options would result from - this operation; or 3) Existing options prevent - this type of operation. -68 VALUE_REQUIRED The specified option requires a value. -69 SYSTEM_ERROR A system error occurred while processing a - request. -70(+) KEY_ALREADY_EXISTS The specified key already exists. -71(+) KEY_DOES_NOT_EXIST The specified key does not exist. - -The add principal operation ---------------------------- -o Command String "ADD-PRINCIPAL" -o Arguments - - name of new principal - - either "KEYWORD=value" or "KEYWORD". - . - . - . -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_ALREADY_EXISTS - new principal already exists - BAD_OPTION - bad option supplied - VALUE_REQUIRED - value required with keyword -o Supplemental Returns - NONE - if successful - error message text - if failure -o Description - If the specified principal does not exist, the arguments parse - correctly, and the arguments when combined with defaulted values - do not produce a conflicting set of options then add the specified - principal with the specified attributes. See below for the list of - settable attributes. -o Access Required - Client principal must have ADD_PRINCIPAL permission. - -The delete principal operation ------------------------------- -o Command String "DELETE-PRINCIPAL" -o Argument - - principal to delete -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_DOES_NOT_EXIST - old principal does not exist -o Supplemental returns - NONE - if successful - error message text - if failure -o Description - If the specified principal exists, then delete it from the database. -o Access Required - Client principal must have DELETE_PRINCIPAL permission. - -The rename principal operation ------------------------------- -o Command String "RENAME-PRINCIPAL" -o Arguments - - original name - - new name -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_DOES_NOT_EXIST - old principal does not exist - P_ALREADY_EXISTS - new principal already exists -o Supplemental Returns - NONE - if successful - error message text - if failure -o Description - If the original principal exists and the new principal name does not - exist, rename the original principal to the specified name. -o Access Required - Client principal must have ADD_PRINCIPAL and DELETE_PRINCIPAL - permission. - -The modify principal operation ------------------------------- -o Command String "MODIFY-PRINCIPAL" -o Arguments - - name of principal - - either KEYWORD=value or KEYWORD. - . - . - . -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_DOES_NOT_EXIST - principal doesn't exist - BAD_OPTION - bad option supplied - VALUE_REQUIRED - value required with keyword -o Supplemental returns - NONE - if successful - error message text - if failure -o Description - If the specified principal exists, the arguments parse correctly, and - the arguments when combined with existing values do not produce a - conflicting set of options, then modify the specified principal with - the specified attributes. See below for the list of settable - attributes. -o Access Required - Client principal must have MODIFY_PRINCIPAL permission. - -The change password operation ------------------------------ -o Command String "OTHER-CHANGEPW" -o Arguments - - principal to change password for - - new password -o Returns - SUCCESS - operation successful - PW_UNACCEPT - specified password is bad - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_DOES_NOT_EXIST - old principal does not exist - BAD_OPTION - principal has a random key -o Supplemental returns - NONE - if successful - error message text - if failure -o Description - If the specified principal exists, and does not have a random key, - then change the password to the specified password. The original - password is NOT required. -o Access Required - Client principal must have CHANGEPW permission. - -The change random password command ----------------------------------- -o Command String "OTHER-RANDOM-CHANGEPW" -o Argument - - principal to change password for -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_DOES_NOT_EXIST - old principal does not exist - BAD_OPTION - principal does not have a random key -o Supplemental Returns - NONE - if successful - error message text - if failure -o Description - If the specified principal exists, and has a random key, then - generate a new random password. The original password is NOT - required. -o Access Required - Client principal must have CHANGEPW permission. - -The inquire principal command ------------------------------ -o Command String "INQUIRE-PRINCIPAL" -o Argument - - name of principal or null argument -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_DOES_NOT_EXIST - principal doesn't exist -o Supplemental Returns - If the return is SUCCESS - - name of next principal in database - - KEYWORD=value list - . - . - . - Otherwise - error message text - if failure -o Description - If a principal is specified, then the database is searched for that - particular principal and its attributes are returned as keyword-value - pairs. If no principal is specified, then the first database entry - is returned. The name of the next principal in the database is always - returned to allow for scanning. See below for the list of attributes - that can be returned. -o Access Required - Client principal must have INQUIRE_PRINCIPAL permission. - -The OPTIONAL extract service key table entry command ----------------------------------------------------- -o Command String "EXTRACT-KEY" -o Arguments - - instance to extract for - - name to extract for -o Returns - SUCCESS - operation successful - CMD_UNKNOWN - operation not supported by server - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not allowed to perform this - P_DOES_NOT_EXIST - principal does not exist -o Supplemental Returns - - if successful - error message text - if failure -o Description - If the specified name/instance exists in the database, then - extract the service key entry and return it in . - The description of follows below. -o Access Required - Client principal must have EXTRACT permission. - -The add key operation ---------------------- -o Command String "ADD-KEY" -o Arguments - - name of the principal - - current password value - - name of the key in the form - :. - . - . - . -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not authorized to perform this - KEY_ALREADY_EXISTS - one or more of the specified - keytypes already exist. - BAD_OPTION - bad keytype:saltype specified - BAD_PW - supplied password is incorrect -o Supplemental Returns - NONE - if successful - error message text - if failure -o Description - If the specified principal exists, the keyname(s) parse - correctly the specified password is successfully verified - against the existing key(s), and the specified keyname(s) do - not exist, then these keytype(s) are added to the principal. -o Access Required - Client principal must have MODIFY_PRINCIPAL permission. - -The delete key operation ------------------------- -o Command String "DELETE-KEY" -o Arguments - - name of the principal - - current password value - - name of the key in the form - :, or name of the - key in the form :: - - . - . - . -o Returns - SUCCESS - operation successful - SYSTEM_ERROR - system error - NOT_AUTHORIZED - not authorized to perform this - KEY_DOES_NOT_EXIST - one or more of the specified - keytypes do not exist. - BAD_OPTION - bad keytype:saltype specified - BAD_PW - supplied password is incorrect -o Supplemental Returns - NONE - if successful - error message text - if failure -o Description - If the specified principal exists, the keyname(s) parse - correctly the specified password is successfully verified - against the existing key(s), and the specified keyname(s) - exist, then they are deleted from the principal. -o Access Required - Client principal must have MODIFY_PRINCIPAL permission. - -Keywords --------- -The following list of keywords are used for the ADD-PRINCIPAL and -MODIFY-PRINCIPAL commands and are returned from the -INQUIRE-PRINCIPAL command. - -Valid Keyword Value Type Value -------- --------------- --------------- -------------------------------------- - (S) PASSWORD New password. - (SR) MAXLIFE The maximum lifetime of tickets for - this principal in seconds. - (SR) MAXRENEWLIFE The maximum renewable lifetime of - tickets for this principal in seconds. - (SR) EXPIRATION When the new principal expires. - (SR) PWEXPIRATION When the password expires for this - principal. - (SR) RANDOMKEY Specifies that this is to have a - random key generated for it. - (SR) FLAGS Specifies flag value for this - principal's attributes field in the - database. - (R) LASTSUCCESS Last successful password entry. - (R) LASTFAILED Last failed password attempt. - (R) FAILCOUNT Number of failed password attempts. - (SR) AUXDATA Tagged auxiliary value (see below) - (R) KEYDATA Key value (see below) - (SR) EXTRADATA Extra data (see below) - -The valid field indicates whether an attribute is Settable (e.g. appropriate -for use with ADD-PRINCIPAL, et. al.; Returnable (e.g. returned by -INQUIRE-PRINCIPAL); or both Settable and Returnable. - -o -The type denotes data which is stored in the database as a -tagged value. The protocol representation consists of a 4-byte network order -integer to denote the tag with the remaining data providing the value. If -encoded data is to be encapsulated, it must be in network order. In summary: - AUXDATA= -For example, to encode the value for tag 1 with a 4-byte value of 32 71 1e 30 -in network order, the encoding would be: - AUXDATA=00 00 00 01 32 71 1e 30 - -o -The type denotes data which is stored in the database on a per-key -basis. The protocol representation is consists of a 4-byte network order -integer to denote a particular key. This integer is implementation dependent -and is only used to correlate different entries. This integer -is followed by a 4-byte network order integer which denotes the attribute type. -Currently, only three are supported: -1 denotes the key version; 1 denotes the -key type and 2 denotes the salt type. This attribute type integer is followed -by the attribute value and an optional per-attribute value. In summary: - KEYDATA=[] -For example, to encode the value of a key with keytype 3, salttype 5, with key -version number 32, key data of 12 34 56 78 90 ab cd ef and salt data of f0 e1 -d2 c3 b4 a5 96 87, the encoding would be (using key-tag de ad be ef): - (key version number 32) - KEYDATA=de ad be ef ff ff ff ff 00 00 00 20 - (key keytype 3, value 1234567890abcdef) - KEYDATA=de ad be ef 00 00 00 01 00 00 00 03 12 34 56 78 90 ab cd ef - (key salttype 5, value f0e1d2c3b4a59687) - KEYDATA=de ad be ef 00 00 00 02 00 00 00 05 f0 e1 d2 c3 b4 a5 96 87 - -o -The type is exactly that. Unspecified. Any data may be encoded -here without restriction. - -Keytab Entry ------------- -If the EXTRACT SERVICE KEY function is supported, then the successful -response to this command is the key entry. This is a series of 6 -reply components as follows: - -component type value ---------- --------------- ----------------------------------------- - 1 Principal name - 2 Key entry timestamp - 3 Key's version number. - 4 Key's keytype. - 5 Key's encryption type. - 6 Key's key value. - -All of these components are mandatory. - diff --git a/doc/kadmin/kpasswd.protocol b/doc/kadmin/kpasswd.protocol deleted file mode 100644 index 7d77a2183a..0000000000 --- a/doc/kadmin/kpasswd.protocol +++ /dev/null @@ -1,303 +0,0 @@ - - - - A Proposal for a Standardized - Kerberos Password Changing Protocol - - **DRAFT** **DRAFT** **DRAFT** - - by Theodore Ts'o - September 7, 1995 - -Rationale -========= - -Currently, the Kerberos administration server which is being shipped -with the Beta Kerberos V5 distributions from MIT has not been of -sufficient quality for vendors to ship it in their products. Hence, -many vendors are creating and deploying proprietary administration -servers. In general, this is not a big problem --- relatively few -users are Kerberos administrators and thus the Kerberos administration -clients are used by relatively few users. - -There is a big exception to this, however, which is the functionality of -a user being able to change his or her own password. Application -programs may want to include this functionality in their programs; it -would be desireable for there to be a standardized protocol for doing -this. Standardized Kerberos desktop management programs (such as -Cornell's Authman) would also benefit from a standardized protocol; this -way, they will do not need to implement many vendor-specific Kerberos -administration protocols. Similarily, at least one terminal server -vendor has come to expressing their concern that there was not a -standardized password changing protocol, since they wanted their product -to offer this functionality. - -This protocol is designed to address these concerns. - - -Protocol Description -==================== - -The protocol used by the password changing protocol is intentionally -very simple. This is to encourage its widespread implementation, even -in cases where there are size constraints (i.e., in a terminal server). - -The protocol will use a TCP stream connection using port 464. The -symbolic name of this port is kpasswd: - - kpasswd 464/tcp - - -The following encoding standards are used throughout. - -Integers are sent as 4 byte objects, where the most significant byte -is sent first, and the least signifcant byte is sent last. (i.e., -standard Internet network byte order.) - -Protocol data units (PDU's) are sent across using the following -encoding. First, the size of the PDU is sent as a 4 byte integer, -followed by the PDU itself. PDU's used by the protocol will be either a -KRB_AP_REQ message, a KRB_AP_REP message, a "command request" PDU, or a -"command response" PDU. (The last two PDU's are encoded using a -KRB_PRIV message. For definitions of the KRB_AP_REQ, KRB_AP_REP, and -KRB_PRIV message, see the Kerberos V5 protocol specification found in -RFC 1510.) - -The PDU's which are encoded using the KRB_PRIV message must include the -sequence number field --- the client and server must fill in each -successive PDU that it sends with a monotonically increasing sequence -number. The initial sequence number in each direction are negotiated in -the KRB_AP_REQ and KRB_AP_REP messages. - -The size of a Protoocl Data Unit SHOULD not exceed 16,384 bytes. If an -implementation receives a PDU which is larger that 16,384 bytes, the -implementation MAY consider this a fatal error and terminate the TCP -connection. An implementation MUST be able to receive PDU's of at least -16,384 bytes. - -The "command request" PDU -------------------------- - -The "command request" PDU is sent from the client to server. This PDU -uses the following structure: First, the number of arguments, sent -across as an integer. The number of arguments MUST be greater than -zero. It is then followed by the arguments themselves, which are -encoded as an integer length followed by the value of the argument. - -The first argument is "command name". The command name is a NETASCII -string, and it may not contain an ASCII null. Command names are case -insentive. Valid command names are defined below; any site-, or vendor- -specific extensions to this protocol should use command names which -begin with the letter 'X'. - -The other arguments (if any) are dependent on the command specified by -the first argument. - -In other words: - - Number of Arguments (integer, must be greater than zero) - Arg size 1 (integer) - Arg data 1 (octet string, command name) - ... - Arg size N (integer) - Arg data N (octet string) - -This structure is then encrypted using the Kerberos V5 KRB_PRIV message. - -The "command reply" PDU ------------------------ - -In response to a "command request" PDU, the server will send to the -client a "command reply" PDU. The structure of a "command reply" PDU is -as follows: - - status code (integer) - Number of reply components (integer, may be zero) - Arg size 1 (integer) - Arg data 1 (octet string) - ... - Arg size N (integer) - Arg data N (octet string) - -This structure is then encrypted using the Kerberos V5 KRB_PRIV message. - -The status code may be one of the following values: - -# Symbolic name Meaning - -0 SUCCESS The command was executed without any errors -1 CMD_UNKNOWN Command not recognized -2 PW_UNACCEPT The password chosen by the user is unnacceptable. -3 BAD_PW The old password furnished by the user is not correct. -4 NOT_IN_TKT The ticket used to authenticate to the server - did not have the TKT_FLAG_INITIAL flag set. -5 CANT_CHANGE The server is not able to change the password - due to no fault of the user. (For - example, the database may be in - read-only mode for maintance reasons.) -6 LANG_NOT_SUPPORTED The requested language is not supported. - -The error codes below 127, and above 256 are reserved for future -expansion. Local extensions of this protocol should use error codes -between 128 and 255. - -The user text in the reply message is generally some sort of -explanatory text, which should be displayed to the user. - - -Connection Establishment -======================== - -When a connection is made the password changing client exchanges the -following PDU's: - -Client Server ------- ------ - -KRB_AP_REQ -------> - - <------- KRB_AP_REP - -KRB_AP_REQ and KRB_AP_REP are the respective Kerberos V5 messages. The -client will autenticate to the server using the service name -changepw/@, where should be -substituted with the name of the Kerberos realm of the password changing -server. The client MUST set the MUTUAL-REQUIRED flag in the KRB_AP_REQ -message, which indicates that server shall send a KRB_AP_REP message for -the purposes of establishing mutual authentication between the client -and the server. - -Protocol Commands -================== - -After the connection is established, the client may then send any -number of "command request" PDUs; after each command request PDU is -sent, the client should wait for a "command reply" PDU from the -server. - -If after 30 seconds inactivity, the client does not send a "command -request" PDU, the server MAY elect to terminate the TCP connection. - -The following commands defined in this standard: - - QUIT - CHECKPW - CHANGEPW - MOTD (*) - MIME (*) - LANGUAGE (*) - -The commands marked with a (*) are optional; servers may or may not -elect to support these commands. If the commands are not supported, the -server shall return a status code of CMD_UNKNOWN. - -The quit command ----------------- - -The name of this command is "QUIT", and it takes no arguments. The -response to this command must be the error code "NO_ERROR". There may -be an optional reply component, which will consist of user text which -should be displayed to the user. After processing this command, the -server will terminate the connection. - -Kerberos password changing servers MUST implement this command. - - -The check password command ---------------------------- - -The name of this command is "CHECKPW", and it takes one argument, -which is a proposed password. The server will evaluate this password -according to its criteria and return either an NO_ERROR or PW_UNACCEPT -error code. - -There may be an optional reply component which consists of user text -which should be displayed to the user. It will typically explain why -the password was unacceptable. - -Kerberos password changing servers MUST implement this command. - - -The change password command ---------------------------- - -The name of this command is "CHANGEPW", and it takes two arguments. The -first argument is the old password, and the second password is the new -password. The response from this command will generally be one of the -following error codes: NO_ERROR, PW_UNACCEPT, BAD_PW, NOT_IN_TKT, -CANT_CHANGE. - -This command changes the password of the Kerberos principal which the -client used to authenticate to the server. For security reasons, the -server should check to make sure that the ticket used to authenticate to -the server had the TKT_FLG_INITIAL flag set; if this flag is not set in -the ticket, then when the client attempts to use the "CHANGEPW" command, -the server should return the NOT_IN_TKT error. - -There may be an optional reply component which consists of user text -which should be displayed to the user, explaining why the password was -unacceptable or why the user's password could not be changed. - -Kerberos password changing servers MUST implement this command. - - -The Message of the Day command ------------------------------- - -The name of this command is "MOTD", and it takes zero or one additional -arguments. The optional argument is a magic token passed back from a -previous MOTD command. If this magic token is sent, the server MAY use -it to determine use it to determine what (if any) messages should be -displayed to the user. - -This command returns one or two reply components. The first reply -component is a magic token; the magic token shall be a NETASCII string -which may not contain an ASCII null character, and its length shall be -less than 64 characters. A client MAY store this magic token between -invocations of the client, and send it to the server the next time the -MOTD command is requested. - -The second (optional) reply component contains text which should be -displayed to the user. - -Kerberos password changing servers MAY optionally implement this command. - - -The MIME command ----------------- - -The name of this command is "MIME", and it takes zero additional -arguments. - -This command indicates that the client is willing to accept -MIME-enhanced textual messages in place of the standard NETASCII textual -messages. - -If this command is not sent, the server MUST send all textual messages -using NETASCII, with used as a line breaks, and line lengths no -more than 80 characters. If this command is sent, and the server -returns a status code of SUCCESS, the server MUST send textual messages -as MIME-enhanced textual messages. The server may refuse to send MIME -messages by sending a status code of CMD_UNKNOWN. - -Kerberos password changing servers MAY optionally implement this command. - - -The Language Command ---------------------- - -The name of this command is "LANGUAGE", and it takes one additional -argument, which indicates the language that the textual messages should -be sent back in. This additional argument must be consist of NETASCII -characters, with ASCII nulls not allowed. The argument shall be case -insensitive. What constitute valid arguments to this command are a -local matter. [Since ISO apparently doesn't have a standard way of -referring to different languages or dialects.] - -This command indicates that the client would prefer that textual -messages be sent back using the requested language. If the server does -not support the requested language, the server may refuse the request by -sending the error code LANG_NOT_SUPPORTED. - -Kerberos password changing servers MAY optionally implement this command. - diff --git a/doc/krb5-protocol/draft-ietf-cat-kerberos-pk-init-09.txt b/doc/krb5-protocol/draft-ietf-cat-kerberos-pk-init-09.txt deleted file mode 100644 index 748f08954b..0000000000 --- a/doc/krb5-protocol/draft-ietf-cat-kerberos-pk-init-09.txt +++ /dev/null @@ -1,908 +0,0 @@ -INTERNET-DRAFT Brian Tung -draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman -Updates: RFC 1510 ISI -expires December 1, 1999 Matthew Hur - CyberSafe Corporation - Ari Medvinsky - Excite - Sasha Medvinsky - General Instrument - John Wray - Iris Associates, Inc. - Jonathan Trostle - Cisco - - Public Key Cryptography for Initial Authentication in Kerberos - -0. Status Of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. Internet-Drafts are - working documents of the Internet Engineering Task Force (IETF), - its areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - To learn the current status of any Internet-Draft, please check - the "1id-abstracts.txt" listing contained in the Internet-Drafts - Shadow Directories on ftp.ietf.org (US East Coast), - nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or - munnari.oz.au (Pacific Rim). - - The distribution of this memo is unlimited. It is filed as - draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1, - 1999. Please send comments to the authors. - -1. Abstract - - This document defines extensions (PKINIT) to the Kerberos protocol - specification (RFC 1510 [1]) to provide a method for using public - key cryptography during initial authentication. The methods - defined specify the ways in which preauthentication data fields and - error data fields in Kerberos messages are to be used to transport - public key data. - -2. Introduction - - The popularity of public key cryptography has produced a desire for - its support in Kerberos [2]. The advantages provided by public key - cryptography include simplified key management (from the Kerberos - perspective) and the ability to leverage existing and developing - public key certification infrastructures. - - Public key cryptography can be integrated into Kerberos in a number - of ways. One is to associate a key pair with each realm, which can - then be used to facilitate cross-realm authentication; this is the - topic of another draft proposal. Another way is to allow users with - public key certificates to use them in initial authentication. This - is the concern of the current document. - - PKINIT utilizes Diffie-Hellman keys in combination with digital - signature keys as the primary, required mechanism. It also allows - for the use of RSA keys. Note that PKINIT supports the use of - separate signature and encryption keys. - - PKINIT enables access to Kerberos-secured services based on initial - authentication utilizing public key cryptography. PKINIT utilizes - standard public key signature and encryption data formats within the - standard Kerberos messages. The basic mechanism is as follows: The - user sends a request to the KDC as before, except that if that user - is to use public key cryptography in the initial authentication - step, his certificate and a signature accompany the initial request - in the preauthentication fields. Upon receipt of this request, the - KDC verifies the certificate and issues a ticket granting ticket - (TGT) as before, except that the encPart from the AS-REP message - carrying the TGT is now encrypted utilizing either a Diffie-Hellman - derived key or the user's public key. This message is authenticated - utilizing the public key signature of the KDC. - - The PKINIT specification may also be used as a building block for - other specifications. PKCROSS [3] utilizes PKINIT for establishing - the inter-realm key and associated inter-realm policy to be applied - in issuing cross realm service tickets. As specified in [4], - anonymous Kerberos tickets can be issued by applying a NULL - signature in combination with Diffie-Hellman in the PKINIT exchange. - Additionally, the PKINIT specification may be used for direct peer - to peer authentication without contacting a central KDC. This - application of PKINIT is described in PKTAPP [5] and is based on - concepts introduced in [6, 7]. For direct client-to-server - authentication, the client uses PKINIT to authenticate to the end - server (instead of a central KDC), which then issues a ticket for - itself. This approach has an advantage over TLS [8] in that the - server does not need to save state (cache session keys). - Furthermore, an additional benefit is that Kerberos tickets can - facilitate delegation (see [9]). - -3. Proposed Extensions - - This section describes extensions to RFC 1510 for supporting the - use of public key cryptography in the initial request for a ticket - granting ticket (TGT). - - In summary, the following change to RFC 1510 is proposed: - - * Users may authenticate using either a public key pair or a - conventional (symmetric) key. If public key cryptography is - used, public key data is transported in preauthentication - data fields to help establish identity. The user presents - a public key certificate and obtains an ordinary TGT that may - be used for subsequent authentication, with such - authentication using only conventional cryptography. - - Section 3.1 provides definitions to help specify message formats. - Section 3.2 describes the extensions for the initial authentication - method. - -3.1. Definitions - - The extensions involve new preauthentication fields; we introduce - the following preauthentication types: - - PA-PK-AS-REQ 14 - PA-PK-AS-REP 15 - - The extensions also involve new error types; we introduce the - following types: - - KDC_ERR_CLIENT_NOT_TRUSTED 62 - KDC_ERR_KDC_NOT_TRUSTED 63 - KDC_ERR_INVALID_SIG 64 - KDC_ERR_KEY_TOO_WEAK 65 - KDC_ERR_CERTIFICATE_MISMATCH 66 - KDC_ERR_CANT_VERIFY_CERTIFICATE 70 - KDC_ERR_INVALID_CERTIFICATE 71 - KDC_ERR_REVOKED_CERTIFICATE 72 - KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 - KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 - KDC_ERR_CLIENT_NAME_MISMATCH 75 - KDC_ERR_KDC_NAME_MISMATCH 76 - - We utilize the following typed data for errors: - - TD-PKINIT-CMS-CERTIFICATES 101 - TD-KRB-PRINCIPAL 102 - TD-KRB-REALM 103 - TD-TRUSTED-CERTIFIERS 104 - TD-CERTIFICATE-INDEX 105 - - We utilize the following encryption types (which map directly to - OIDs): - - dsaWithSHA1-CmsOID 9 - md5WithRSAEncryption-CmsOID 10 - sha1WithRSAEncryption-CmsOID 11 - rc2CBC-EnvOID 12 - rsaEncryption-EnvOID (PKCS#1 v1.5) 13 - rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 - des-ede3-cbc-Env-OID 15 - - These mappings are provided so that a client may send the - appropriate enctypes in the AS-REQ message in order to indicate - support for the corresponding OIDs (for performing PKINIT). - - In many cases, PKINIT requires the encoding of an X.500 name as a - Realm. In these cases, the realm will be represented using a - different style, specified in RFC 1510 with the following example: - - NAMETYPE:rest/of.name=without-restrictions - - For a realm derived from an X.500 name, NAMETYPE will have the value - X500-RFC2253. The full realm name will appear as follows: - - X500-RFC2253:RFC2253Encode(DistinguishedName) - - where DistinguishedName is an X.500 name, and RFC2253Encode is a - readable UTF encoding of an X.500 name, as defined by - RFC 2253 [14] (part of LDAPv3). - - To ensure that this encoding is unique, we add the following rule - to those specified by RFC 2253: - - The order in which the attributes appear in the RFC 2253 - encoding must be the reverse of the order in the ASN.1 - encoding of the X.500 name that appears in the public key - certificate. The order of the relative distinguished names - (RDNs), as well as the order of the AttributeTypeAndValues - within each RDN, will be reversed. (This is despite the fact - that an RDN is defined as a SET of AttributeTypeAndValues, where - an order is normally not important.) - - Similarly, PKINIT may require the encoding of an X.500 name as a - PrincipalName. In these cases, the name-type of the principal name - shall be set to KRB_NT-X500-PRINCIPAL. This new name type is - defined as: - - KRB_NT_X500_PRINCIPAL 6 - - The name-string shall be set as follows: - - RFC2253Encode(DistinguishedName) - - as described above. - - RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: - - PrincipalName ::= SEQUENCE { - name-type[0] INTEGER, - name-string[1] SEQUENCE OF GeneralString - } - - For the purposes of encoding an X.500 name within this structure, - the name-string shall be encoded as a single GeneralString. - - Note that name mapping may be required or optional based on - policy. - -3.1.1. Encryption and Key Formats - - In the exposition below, we use the terms public key and private - key generically. It should be understood that the term "public - key" may be used to refer to either a public encryption key or a - signature verification key, and that the term "private key" may be - used to refer to either a private decryption key or a signature - generation key. The fact that these are logically distinct does - not preclude the assignment of bitwise identical keys. - - In the case of Diffie-Hellman, the key shall be produced from the - agreed bit string as follows: - - * Truncate the bit string to the appropriate length. - * Rectify parity in each byte (if necessary) to obtain the key. - - For instance, in the case of a DES key, we take the first eight - bytes of the bit stream, and then adjust the least significant bit - of each byte to ensure that each byte has odd parity. - -3.1.2. Algorithm Identifiers - - PKINIT does not define, but does permit, the algorithm identifiers - listed below. - -3.1.2.1. Signature Algorithm Identifiers - - The following signature algorithm identifiers specified in [11] and - in [15] shall be used with PKINIT: - - id-dsa-with-sha1 (DSA with SHA1) - md5WithRSAEncryption (RSA with MD5) - sha-1WithRSAEncryption (RSA with SHA1) - -3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier - - The following algorithm identifier shall be used within the - SubjectPublicKeyInfo data structure: dhpublicnumber - - This identifier and the associated algorithm parameters are - specified in RFC 2459 [15]. - -3.1.2.3. Algorithm Identifiers for RSA Encryption - - These algorithm identifiers are used inside the EnvelopedData data - structure, for encrypting the temporary key with a public key: - - rsaEncryption (RSA encryption, PKCS#1 v1.5) - id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) - - Both of the above RSA encryption schemes are specified in [16]. - Currently, only PKCS#1 v1.5 is specified by CMS [11], although the - CMS specification says that it will likely include PKCS#1 v2.0 in - the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext - vulnerability discovered in PKCS#1 v1.5.) - -3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys - - These algorithm identifiers are used inside the EnvelopedData data - structure in the PKINIT Reply, for encrypting the reply key with the - temporary key: - des-ede3-cbc (3-key 3-DES, CBC mode) - rc2-cbc (RC2, CBC mode) - - The full definition of the above algorithm identifiers and their - corresponding parameters (an IV for block chaining) is provided in - the CMS specification [11]. - -3.2. Public Key Authentication - - Implementation of the changes in this section is REQUIRED for - compliance with PKINIT. - - It is assumed that all public keys are signed by some certification - authority (CA). The initial authentication request is sent as per - RFC 1510, except that a preauthentication field containing data - signed by the user's private key accompanies the request: - - PA-PK-AS-REQ ::= SEQUENCE { - -- PA TYPE 14 - signedAuthPack [0] SignedData - -- defined in CMS [11] - -- AuthPack (below) defines the data - -- that is signed - trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, - -- CAs that the client trusts - kdcCert [2] IssuerAndSerialNumber OPTIONAL - -- as defined in CMS [11] - -- specifies a particular KDC - -- certificate if the client - -- already has it; - -- must be accompanied by - -- a single trustedCertifier - encryptionCert [3] IssuerAndSerialNumber OPTIONAL - -- For example, this may be the - -- client's Diffie-Hellman - -- certificate, or it may be the - -- client's RSA encryption - -- certificate. - } - - TrustedCas ::= CHOICE { - principalName [0] KerberosName, - -- as defined below - caName [1] Name - -- fully qualified X.500 name - -- as defined by X.509 - issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL - -- Since a CA may have a number of - -- certificates, only one of which - -- a client trusts - } - - Usage of SignedData: - The SignedData data type is specified in the Cryptographic - Message Syntax, a product of the S/MIME working group of the IETF. - - The encapContentInfo field must contain the PKAuthenticator - and, optionally, the client's Diffie Hellman public value. - - The eContentType field shall contain the OID value for - id-data: iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs7(7) data(1) - - The eContent field is data of the type AuthPack (below). - - The signerInfos field contains the signature of AuthPack. - - The Certificates field, when non-empty, contains the client's - certificate chain. If present, the KDC uses the public key from - the client's certificate to verify the signature in the request. - Note that the client may pass different certificates that are used - for signing or for encrypting. Thus, the KDC may utilize a - different client certificate for signature verification than the - one it uses to encrypt the reply to the client. For example, the - client may place a Diffie-Hellman certificate in this field in - order to convey its static Diffie Hellman certificate to the KDC - enable static-ephemeral Diffie-Hellman mode for the reply. As - another example, the client may place an RSA encryption - certificate in this field. - - AuthPack ::= SEQUENCE { - pkAuthenticator [0] PKAuthenticator, - clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL - -- if client is using Diffie-Hellman - } - - PKAuthenticator ::= SEQUENCE { - kdcName [0] PrincipalName, - kdcRealm [1] Realm, - cusec [2] INTEGER, - -- for replay prevention - ctime [3] KerberosTime, - -- for replay prevention - nonce [4] INTEGER - } - - SubjectPublicKeyInfo ::= SEQUENCE { - algorithm AlgorithmIdentifier, - -- dhKeyAgreement - subjectPublicKey BIT STRING - -- for DH, equals - -- public exponent (INTEGER encoded - -- as payload of BIT STRING) - } -- as specified by the X.509 recommendation [10] - - AlgorithmIdentifier ::= SEQUENCE { - algorithm ALGORITHM.&id, - parameters ALGORITHM.&type - } -- as specified by the X.509 recommendation [10] - - If the client passes an issuer and serial number in the request, - the KDC is requested to use the referred-to certificate. If none - exists, then the KDC returns an error of type - KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the - other hand, the client does not pass any trustedCertifiers, - believing that it has the KDC's certificate, but the KDC has more - than one certificate. The KDC should include information in the - KRB-ERROR message that indicates the KDC certificate(s) that a - client may utilize. This data is specified in the e-data, which - is defined in RFC 1510 revisions as a SEQUENCE of TypedData: - - TypedData ::= SEQUENCE { - data-type [0] INTEGER, - data-value [1] OCTET STRING, - } -- per Kerberos RFC 1510 revisions - - where: - data-type = TD-PKINIT-CMS-CERTIFICATES = 101 - data-value = CertificateSet // as specified by CMS [11] - - The PKAuthenticator carries information to foil replay attacks, - to bind the request and response. The PKAuthenticator is signed - with the private key corresponding to the public key in the - certificate found in userCert (or cached by the KDC). - - The trustedCertifiers field contains a list of certification - authorities trusted by the client, in the case that the client does - not possess the KDC's public key certificate. If the KDC has no - certificate signed by any of the trustedCertifiers, then it returns - an error of type KDC_ERR_KDC_NOT_TRUSTED. - - KDCs should try to (in order of preference): - 1. Use the KDC certificate identified by the serialNumber included - in the client's request. - 2. Use a certificate issued to the KDC by the client's CA (if in the - middle of a CA key roll-over, use the KDC cert issued under same - CA key as user cert used to verify request). - 3. Use a certificate issued to the KDC by one of the client's - trustedCertifier(s); - If the KDC is unable to comply with any of these options, then the - KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the - client. - - Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication - type, the KDC attempts to verify the user's certificate chain - (userCert), if one is provided in the request. This is done by - verifying the certification path against the KDC's policy of - legitimate certifiers. This may be based on a certification - hierarchy, or it may be simply a list of recognized certifiers in a - system like PGP. - - If the client's certificate chain contains no certificate signed by - a CA trusted by the KDC, then the KDC sends back an error message - of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data - is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) - whose data-value is an OCTET STRING which is the DER encoding of - - TrustedCertifiers ::= SEQUENCE OF PrincipalName - -- X.500 name encoded as a principal name - -- see Section 3.1 - - If the signature on one of the certificates in the client's chain - fails verification, then the KDC returns an error of type - KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE - of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose - data-value is an OCTET STRING which is the DER encoding of - - CertificateIndex ::= INTEGER - -- 0 = 1st certificate, - -- (in order of encoding) - -- 1 = 2nd certificate, etc - - The KDC may also check whether any of the certificates in the - client's chain has been revoked. If one of the certificates has - been revoked, then the KDC returns an error of type - KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the - certificate's revocation status is unknown, the KDC returns an - error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation - status is unavailable, the KDC returns an error of type - KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three - cases, the affected certificate is identified by the accompanying - e-data, which contains a CertificateIndex as described for - KDC_ERR_INVALID_CERTIFICATE. - - If the certificate chain can be verified, but the name of the - client in the certificate does not match the client's name in the - request, then the KDC returns an error of type - KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data - field in this case. - - Finally, if the certificate chain is verified, but the KDC's name - or realm as given in the PKAuthenticator does not match the KDC's - actual principal name, then the KDC returns an error of type - KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again - a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or - TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET - STRING whose data-value is the DER encoding of a PrincipalName or - Realm as defined in RFC 1510 revisions. - - Even if all succeeds, the KDC may--for policy reasons--decide not - to trust the client. In this case, the KDC returns an error message - of type KDC_ERR_CLIENT_NOT_TRUSTED. - - If a trust relationship exists, the KDC then verifies the client's - signature on AuthPack. If that fails, the KDC returns an error - message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the - timestamp (ctime and cusec) in the PKAuthenticator to assure that - the request is not a replay. The KDC also verifies that its name - is specified in the PKAuthenticator. - - If the clientPublicValue field is filled in, indicating that the - client wishes to use Diffie-Hellman key agreement, then the KDC - checks to see that the parameters satisfy its policy. If they do - not (e.g., the prime size is insufficient for the expected - encryption type), then the KDC sends back an error message of type - KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and - private values for the response. - - The KDC also checks that the timestamp in the PKAuthenticator is - within the allowable window and that the principal name and realm - are correct. If the local (server) time and the client time in the - authenticator differ by more than the allowable clock skew, then the - KDC returns an error message of type KRB_AP_ERR_SKEW. - - Assuming no errors, the KDC replies as per RFC 1510, except as - follows. The user's name in the ticket is determined by the - following decision algorithm: - - 1. If the KDC has a mapping from the name in the certificate - to a Kerberos name, then use that name. - Else - 2. If the certificate contains a Kerberos name in an extension - field, and local KDC policy allows, then use that name. - Else - 3. Use the name as represented in the certificate, mapping - as necessary (e.g., as per RFC 2253 for X.500 names). In - this case the realm in the ticket shall be the name of the - certification authority that issued the user's certificate. - - The KDC encrypts the reply not with the user's long-term key, but - with a random key generated only for this particular response. This - random key is sealed in the preauthentication field: - - PA-PK-AS-REP ::= CHOICE { - -- PA TYPE 15 - dhSignedData [0] SignedData, - -- Defined in CMS and used only with - -- Diffie-Helman key exchange - -- This choice MUST be supported - -- by compliant implementations. - encKeyPack [1] EnvelopedData, - -- Defined in CMS - -- The temporary key is encrypted - -- using the client public key - -- key - -- SignedReplyKeyPack, encrypted - -- with the temporary key, is also - -- included. - } - - Usage of SignedData: - If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP - provides authenticated Diffie-Hellman parameters of the KDC. The - reply key used to encrypt part of the KDC reply message is derived - from the Diffie-Hellman exchange: - - Both the KDC and the client calculate a secret value (g^ab mod p), - where a is the client's private exponent and b is the KDC's - private exponent. - - Both the KDC and the client take the first N bits of this secret - value and convert it into a reply key. N depends on the reply key - type. - - If the reply key is DES, N=64 bits, where some of the bits are - replaced with parity bits, according to FIPS PUB 74. - - If the reply key is (3-key) 3-DES, N=192 bits, where some of the - bits are replaced with parity bits, according to FIPS PUB 74. - - The encapContentInfo field must contain the KdcDHKeyInfo as - defined below. - - The eContentType field shall contain the OID value for - id-data: iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs7(7) data(1) - - The certificates field must contain the certificates necessary - for the client to establish trust in the KDC's certificate - based on the list of trusted certifiers sent by the client in - the PA-PK-AS-REQ. This field may be empty if the client did - not send to the KDC a list of trusted certifiers (the - trustedCertifiers field was empty, meaning that the client - already possesses the KDC's certificate). - - The signerInfos field is a SET that must contain at least one - member, since it contains the actual signature. - - Usage of EnvelopedData: - The EnvelopedData data type is specified in the Cryptographic - Message Syntax, a product of the S/MIME working group of the IETF. - It contains an temporary key encrypted with the PKINIT - client's public key. It also contains a signed and encrypted - reply key. - - The originatorInfo field is not required, since that information - may be presented in the signedData structure that is encrypted - within the encryptedContentInfo field. - - The optional unprotectedAttrs field is not required for PKINIT. - - The recipientInfos field is a SET which must contain exactly one - member of the KeyTransRecipientInfo type for encryption - with an RSA public key. - - The encryptedKey field (in KeyTransRecipientInfo) contains - the temporary key which is encrypted with the PKINIT client's - public key. - - The encryptedContentInfo field contains the signed and encrypted - reply key. - - The contentType field shall contain the OID value for - id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs7(7) signedData(2) - - The encryptedContent field is encrypted data of the CMS type - signedData as specified below. - - The encapContentInfo field must contains the ReplyKeyPack. - - The eContentType field shall contain the OID value for - id-data: iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs7(7) data(1) - - The eContent field is data of the type ReplyKeyPack (below). - - The certificates field must contain the certificates necessary - for the client to establish trust in the KDC's certificate - based on the list of trusted certifiers sent by the client in - the PA-PK-AS-REQ. This field may be empty if the client did - not send to the KDC a list of trusted certifiers (the - trustedCertifiers field was empty, meaning that the client - already possesses the KDC's certificate). - - The signerInfos field is a SET that must contain at least one - member, since it contains the actual signature. - - KdcDHKeyInfo ::= SEQUENCE { - -- used only when utilizing Diffie-Hellman - nonce [0] INTEGER, - -- binds responce to the request - subjectPublicKey [2] BIT STRING - -- Equals public exponent (g^a mod p) - -- INTEGER encoded as payload of - -- BIT STRING - } - - ReplyKeyPack ::= SEQUENCE { - -- not used for Diffie-Hellman - replyKey [0] EncryptionKey, - -- used to encrypt main reply - -- ENCTYPE is at least as strong as - -- ENCTYPE of session key - nonce [1] INTEGER, - -- binds response to the request - -- must be same as the nonce - -- passed in the PKAuthenticator - } - - - Since each certifier in the certification path of a user's - certificate is essentially a separate realm, the name of each - certifier must be added to the transited field of the ticket. The - format of these realm names is defined in Section 3.1 of this - document. If applicable, the transit-policy-checked flag should be - set in the issued ticket. - - The KDC's certificate must bind the public key to a name derivable - from the name of the realm for that KDC. X.509 certificates shall - contain the principal name of the KDC as the SubjectAltName version - 3 extension. Below is the definition of this version 3 extension, as - specified by the X.509 standard: - - subjectAltName EXTENSION ::= { - SYNTAX GeneralNames - IDENTIFIED BY id-ce-subjectAltName - } - - GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName - - GeneralName ::= CHOICE { - otherName [0] INSTANCE OF OTHER-NAME, - ... - } - - OTHER-NAME ::= TYPE-IDENTIFIER - - In this definition, otherName is a name of any form defined as an - instance of the OTHER-NAME information object class. For the purpose - of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will - be chosen and replaced by the type KerberosName: - - KerberosName ::= SEQUENCE { - realm [0] Realm, - -- as define in RFC 1510 - principalName [1] PrincipalName, - -- as define in RFC 1510 - } - - This specific syntax is identified within subjectAltName by setting - the OID id-ce-subjectAltName to krb5PrincipalName, where (from the - Kerberos specification) we have - - krb5 OBJECT IDENTIFIER ::= { iso (1) - org (3) - dod (6) - internet (1) - security (5) - kerberosv5 (2) } - - krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } - - This specification may also be used to specify a Kerberos name - within the user's certificate. - - If a non-KDC X.509 certificate contains the principal name within - the subjectAltName version 3 extension , that name may utilize - KerberosName as defined below, or, in the case of an S/MIME - certificate [17], may utilize the email address. If the KDC - is presented with as S/MIME certificate, then the email address - within subjectAltName will be interpreted as a principal and realm - separated by the "@" sign, or as a name that needs to be - canonicalized. If the resulting name does not correspond to a - registered principal name, then the principal name is formed as - defined in section 3.1. - - The client then extracts the random key used to encrypt the main - reply. This random key (in encPaReply) is encrypted with either the - client's public key or with a key derived from the DH values - exchanged between the client and the KDC. - -3.2.2. Required Algorithms - - Not all of the algorithms in the PKINIT protocol specification have - to be implemented in order to comply with the proposed standard. - Below is a list of the required algorithms: - - - Diffie-Hellman public/private key pairs - - utilizing Diffie-Hellman ephemeral-ephemeral mode - - SHA1 digest and DSA for signatures - - 3-key triple DES keys derived from the Diffie-Hellman Exchange - - 3-key triple DES Temporary and Reply keys - -4. Logistics and Policy - - This section describes a way to define the policy on the use of - PKINIT for each principal and request. - - The KDC is not required to contain a database record for users - who use public key authentication. However, if these users are - registered with the KDC, it is recommended that the database record - for these users be modified to an additional flag in the attributes - field to indicate that the user should authenticate using PKINIT. - If this flag is set and a request message does not contain the - PKINIT preauthentication field, then the KDC sends back as error of - type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication - field of type PA-PK-AS-REQ must be included in the request. - -5. Security Considerations - - PKINIT raises a few security considerations, which we will address - in this section. - - First of all, PKINIT introduces a new trust model, where KDCs do not - (necessarily) certify the identity of those for whom they issue - tickets. PKINIT does allow KDCs to act as their own CAs, in order - to simplify key management, but one of the additional benefits is to - align Kerberos authentication with a global public key - infrastructure. Anyone using PKINIT in this way must be aware of - how the certification infrastructure they are linking to works. - - Secondly, PKINIT also introduces the possibility of interactions - between different cryptosystems, which may be of widely varying - strengths. Many systems, for instance, allow the use of 512-bit - public keys. Using such keys to wrap data encrypted under strong - conventional cryptosystems, such as triple-DES, is inappropriate; - it adds a weak link to a strong one at extra cost. Implementors - and administrators should take care to avoid such wasteful and - deceptive interactions. - - Lastly, PKINIT calls for randomly generated keys for conventional - cryptosystems. Many such systems contain systematically "weak" - keys. PKINIT implementations MUST avoid use of these keys, either - by discarding those keys when they are generated, or by fixing them - in some way (e.g., by XORing them with a given mask). These - precautions vary from system to system; it is not our intention to - give an explicit recipe for them here. - -6. Transport Issues - - Certificate chains can potentially grow quite large and span several - UDP packets; this in turn increases the probability that a Kerberos - message involving PKINIT extensions will be broken in transit. In - light of the possibility that the Kerberos specification will - require KDCs to accept requests using TCP as a transport mechanism, - we make the same recommendation with respect to the PKINIT - extensions as well. - -7. Bibliography - - [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service - (V5). Request for Comments 1510. - - [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service - for Computer Networks, IEEE Communications, 32(9):33-38. September - 1994. - - [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, - A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm - Authentication in Kerberos. - draft-ietf-cat-kerberos-pk-cross-04.txt - - [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in - Kerberos. - draft-ietf-cat-kerberos-anoncred-00.txt - - [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing - Tickets for Application Servers (PKTAPP). - draft-ietf-cat-pktapp-00.txt - - [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos - Using Public Key Cryptography. Symposium On Network and Distributed - System Security, 1997. - - [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction - Protocol. In Proceedings of the USENIX Workshop on Electronic - Commerce, July 1995. - - [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 - Request for Comments 2246, January 1999. - - [9] B.C. Neuman, Proxy-Based Authorization and Accounting for - Distributed Systems. In Proceedings of the 13th International - Conference on Distributed Computing Systems, May 1993. - - [10] ITU-T (formerly CCITT) Information technology - Open Systems - Interconnection - The Directory: Authentication Framework - Recommendation X.509 ISO/IEC 9594-8 - - [11] R. Housley. Cryptographic Message Syntax. - draft-ietf-smime-cms-13.txt, April 1999. - - [12] PKCS #7: Cryptographic Message Syntax Standard, - An RSA Laboratories Technical Note Version 1.5 - Revised November 1, 1993 - - [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data - Security, Inc. A Description of the RC2(r) Encryption Algorithm - March 1998. - Request for Comments 2268. - - [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access - Protocol (v3): UTF-8 String Representation of Distinguished Names. - Request for Comments 2253. - - [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public - Key Infrastructure, Certificate and CRL Profile, January 1999. - Request for Comments 2459. - - [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography - Specifications, October 1998. - Request for Comments 2437. - - [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. - S/MIME Version 2 Certificate Handling, March 1998. - Request for Comments 2312 - -8. Acknowledgements - - Some of the ideas on which this proposal is based arose during - discussions over several years between members of the SAAG, the IETF - CAT working group, and the PSRG, regarding integration of Kerberos - and SPX. Some ideas have also been drawn from the DASS system. - These changes are by no means endorsed by these groups. This is an - attempt to revive some of the goals of those groups, and this - proposal approaches those goals primarily from the Kerberos - perspective. Lastly, comments from groups working on similar ideas - in DCE have been invaluable. - -9. Expiration Date - - This draft expires December 1, 1999. - -10. Authors - - Brian Tung - Clifford Neuman - USC Information Sciences Institute - 4676 Admiralty Way Suite 1001 - Marina del Rey CA 90292-6695 - Phone: +1 310 822 1511 - E-mail: {brian, bcn}@isi.edu - - Matthew Hur - CyberSafe Corporation - 1605 NW Sammamish Road - Issaquah WA 98027-5378 - Phone: +1 425 391 6000 - E-mail: matt.hur@cybersafe.com - - Ari Medvinsky - Excite - 555 Broadway - Redwood City, CA 94063 - Phone +1 650 569 2119 - E-mail: amedvins@excitecorp.com - - Sasha Medvinsky - General Instrument - 6450 Sequence Drive - San Diego, CA 92121 - Phone +1 619 404 2825 - E-mail: smedvinsky@gi.com - - John Wray - Iris Associates, Inc. - 5 Technology Park Dr. - Westford, MA 01886 - E-mail: John_Wray@iris.com - - Jonathan Trostle - 170 W. Tasman Dr. - San Jose, CA 95134 - E-mail: jtrostle@cisco.com diff --git a/doc/krb5-protocol/draft-jaganathan-rc4-hmac-03.txt b/doc/krb5-protocol/draft-jaganathan-rc4-hmac-03.txt deleted file mode 100755 index 1304ae2bcc..0000000000 --- a/doc/krb5-protocol/draft-jaganathan-rc4-hmac-03.txt +++ /dev/null @@ -1,1013 +0,0 @@ - - - -Internet Engineering Task Force K. Jaganathan -Internet-Draft L. Zhu -Intended status: Informational J. Brezak -Expires: January 31, 2007 Microsoft Corporation - July 30, 2006 - - - The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows - draft-jaganathan-rc4-hmac-03.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 31, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The Microsoft Windows 2000 implementation of Kerberos introduces a - new encryption type based on the RC4 encryption algorithm and using - an MD5 HMAC for checksum. This is offered as an alternative to using - the existing DES based encryption types. - - The RC4-HMAC encryption types are used to ease upgrade of existing - Windows NT environments, provide strong crypto (128-bit key lengths), - - - -Jaganathan, et al. Expires January 31, 2007 [Page 1] - -Internet-Draft RC4-HMAC July 2006 - - - and provide exportable (meet United States government export - restriction requirements) encryption. This document describes the - implementation of those encryption types. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Checksum Types . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Encryption Types . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 8 - 7. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 8 - 7.1. Mechanism Specific Changes . . . . . . . . . . . . . . . . 8 - 7.2. GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 10 - 7.3. GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 18 - - - - - - - - - - - - - - - - - - - - - - - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 2] - -Internet-Draft RC4-HMAC July 2006 - - -1. Introduction - - The Microsoft Windows 2000 implementation of Kerberos contains new - encryption and checksum types for two reasons: for export reasons - early in the development process, 56 bit DES encryption could not be - exported, and because upon upgrade from Windows NT 4.0 to Windows - 2000, accounts will not have the appropriate DES keying material to - do the standard DES encryption. Furthermore, 3DES is not available - for export, and there was a desire to use a single flavor of - encryption in the product for both US and international products. - - As a result, there are two new encryption types and one new checksum - type introduced in Microsoft Windows 2000. - - Note that these cryptosystems aren't intended to be complete, - general-purpose Kerberos encryption or checksum systems as defined in - [RFC3961]: there is no one-one mapping between the operations in this - documents and the primitives described in [RFC3961]. - - -2. Key Generation - - On upgrade from existing Windows NT domains, the user accounts would - not have a DES based key available to enable the use of DES base - encryption types specified in [RFC4120] [RFC3961]. The key used for - RC4-HMAC is the same as the existing Windows NT key (NT Password - Hash) for compatibility reasons. Once the account password is - changed, the DES based keys are created and maintained. Once the DES - keys are available DES based encryption types can be used with - Kerberos. - - The RC4-HMAC String to key function is defined as follow: - - String2Key(password) - - K = MD4(UNICODE(password)) - - The RC4-HMAC keys are generated by using the Windows UNICODE version - of the password. Each Windows UNICODE character is encoded in - little-endian format of 2 octets each. Then performing an MD4 - [RFC1320] hash operation on just the UNICODE characters of the - password (not including the terminating zero octets). - - For an account with a password of "foo", this String2Key("foo") will - return: - - 0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, - 0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc - - - -Jaganathan, et al. Expires January 31, 2007 [Page 3] - -Internet-Draft RC4-HMAC July 2006 - - -3. Basic Operations - - The MD5 HMAC function is defined in [RFC2104]. It is used in this - encryption type for checksum operations. Refer to [RFC2104] for - details on its operation. In this document this function is referred - to as HMAC(Key, Data) returning the checksum using the specified key - on the data. - - The basic MD5 hash operation is used in this encryption type and - defined in [RFC1321]. In this document this function is referred to - as MD5(Data) returning the checksum of the data. - - RC4 is a stream cipher licensed by RSA Data Security . In this - document the function is referred to as RC4(Key, Data) returning the - encrypted data using the specified key on the data. - - These encryption types use key derivation. With each message, the - message type (T) is used as a component of the keying material. This - table summarizes the different key derivation values used in the - various operations. Note that these differ from the key derivations - used in other Kerberos encryption types. T = the message type, - encoded as a little-endian four byte integer. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 4] - -Internet-Draft RC4-HMAC July 2006 - - - 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with - the client key (T=1) - 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key - or application session key), encrypted with the service key - (T=2) - 3. AS-REP encrypted part (includes TGS session key or - application session key), encrypted with the client key (T=8) - 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the - TGS session key (T=4) - 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the - TGS authenticator subkey (T=5) - 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, - keyed with the TGS session key (T=6) - 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes - TGS authenticator subkey), encrypted with the TGS session key - T=7) - 8. TGS-REP encrypted part (includes application session key), - encrypted with the TGS session key (T=8) - 9. TGS-REP encrypted part (includes application session key), - encrypted with the TGS authenticator subkey (T=8) - 10. AP-REQ Authenticator cksum, keyed with the application - session key (T=10) - 11. AP-REQ Authenticator (includes application authenticator - subkey), encrypted with the application session key (T=11) - 12. AP-REP encrypted part (includes application session - subkey), encrypted with the application session key (T=12) - 13. KRB-PRIV encrypted part, encrypted with a key chosen by - the application. Also for data encrypted with GSS Wrap (T=13) - 14. KRB-CRED encrypted part, encrypted with a key chosen by - the application (T=14) - 15. KRB-SAFE cksum, keyed with a key chosen by the - application. Also for data signed in GSS MIC (T=15) - - Relative to RFC-1964 key uses: - - T = 0 in the generation of sequence number for the MIC token - T = 0 in the generation of sequence number for the WRAP token - T = 0 in the generation of encrypted data for the WRAPPED token - - All strings in this document are ASCII unless otherwise specified. - The lengths of ASCII encoded character strings include the trailing - terminator character (0). The concat(a,b,c,...) function will return - the logical concatenation (left to right) of the values of the - arguments. The nonce(n) function returns a pseudo-random number of - "n" octets. - - - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 5] - -Internet-Draft RC4-HMAC July 2006 - - -4. Checksum Types - - There is one checksum type used in this encryption type. The - Kerberos constant for this type is: - - #define KERB_CHECKSUM_HMAC_MD5 (-138) - - The function is defined as follows: - - K - is the Key - T - the message type, encoded as a little-endian four byte integer - - CHKSUM(K, T, data) - - Ksign = HMAC(K, "signaturekey") //includes zero octet at end - tmp = MD5(concat(T, data)) - CHKSUM = HMAC(Ksign, tmp) - - -5. Encryption Types - - There are two encryption types used in these encryption types. The - Kerberos constants for these types are: - - #define KERB_ETYPE_RC4_HMAC 23 - #define KERB_ETYPE_RC4_HMAC_EXP 24 - - The basic encryption function is defined as follow: - - T = the message type, encoded as a little-endian four byte integer. - - OCTET L40[14] = "fortybits"; - - The header field on the encrypted data in KDC messages is: - - typedef struct _RC4_MDx_HEADER { - OCTET Checksum[16]; - OCTET Confounder[8]; - } RC4_MDx_HEADER, *PRC4_MDx_HEADER; - - - ENCRYPT (K, export, T, data) - { - struct EDATA { - struct HEADER { - OCTET Checksum[16]; - OCTET Confounder[8]; - } Header; - - - -Jaganathan, et al. Expires January 31, 2007 [Page 6] - -Internet-Draft RC4-HMAC July 2006 - - - OCTET Data[0]; - } edata; - - if (export){ - *((DWORD *)(L40+10)) = T; - HMAC (K, L40, 10 + 4, K1); - } - else - { - HMAC (K, &T, 4, K1); - } - memcpy (K2, K1, 16); - if (export) memset (K1+7, 0xAB, 9); - - nonce (edata.Confounder, 8); - memcpy (edata.Data, data); - - edata.Checksum = HMAC (K2, edata); - K3 = HMAC (K1, edata.Checksum); - - RC4 (K3, edata.Confounder); - RC4 (K3, data.Data); - } - - DECRYPT (K, export, T, edata) - { - // edata looks like - struct EDATA { - struct HEADER { - OCTET Checksum[16]; - OCTET Confounder[8]; - } Header; - OCTET Data[0]; - } edata; - - if (export){ - *((DWORD *)(L40+10)) = T; - HMAC (K, L40, 14, K1); - } - else - { - HMAC (K, &T, 4, K1); - } - memcpy (K2, K1, 16); - if (export) memset (K1+7, 0xAB, 9); - - K3 = HMAC (K1, edata.Checksum); - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 7] - -Internet-Draft RC4-HMAC July 2006 - - - RC4 (K3, edata.Confounder); - RC4 (K3, edata.Data); - - - // verify generated and received checksums - checksum = HMAC (K2, concat(edata.Confounder, edata.Data)); - if (checksum != edata.Checksum) - printf("CHECKSUM ERROR !!!!!!\n"); - } - - The KDC message is encrypted using the ENCRYPT function not including - the Checksum in the RC4_MDx_HEADER. - - The character constant "fortybits" evolved from the time when a 40- - bit key length was all that was exportable from the United States. - It is now used to recognize that the key length is of "exportable" - length. In this description, the key size is actually 56-bits. - - The pseudo-random operation [RFC3961] for both enctypes above is - defined as follows: - - pseudo-random(K, S) = HMAC-SHA1(K, S) - - where K is the protocol key and S is the input octet string. HMAC- - SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20- - octet digest. - - -6. Key Strength Negotiation - - A Kerberos client and server can negotiate over key length if they - are using mutual authentication. If the client is unable to perform - full strength encryption, it may propose a key in the "subkey" field - of the authenticator, using a weaker encryption type. The server - must then either return the same key or suggest its own key in the - subkey field of the AP reply message. The key used to encrypt data - is derived from the key returned by the server. If the client is - able to perform strong encryption but the server is not, it may - propose a subkey in the AP reply without first being sent a subkey in - the authenticator. - - -7. GSSAPI Kerberos V5 Mechanism Type - -7.1. Mechanism Specific Changes - - The GSSAPI per-message tokens also require new checksum and - encryption types. The GSS-API per-message tokens are adapted to - - - -Jaganathan, et al. Expires January 31, 2007 [Page 8] - -Internet-Draft RC4-HMAC July 2006 - - - support these new encryption types. See [RFC1964] Section 1.2.2. - - The only support quality of protection is: - - #define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0 - - When using this RC4 based encryption type, the sequence number is - always sent in big-endian rather than little-endian order. - - The Windows 2000 implementation also defines new GSSAPI flags in the - initial token passed when initializing a security context. These - flags are passed in the checksum field of the authenticator. See - [RFC1964] Section 1.1.1. - - GSS_C_DCE_STYLE - This flag was added for use with Microsoft's - implementation of DCE RPC, which initially expected three legs of - authentication. Setting this flag causes an extra AP reply to be - sent from the client back to the server after receiving the server's - AP reply. In addition, the context negotiation tokens do not have - GSSAPI per message tokens - they are raw AP messages that do not - include object identifiers. - - #define GSS_C_DCE_STYLE 0x1000 - - GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the - server that it should only allow the server application to identify - the client by name and ID, but not to impersonate the client. - - #define GSS_C_IDENTIFY_FLAG 0x2000 - - GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the - client wants to be informed of extended error information. In - particular, Windows 2000 status codes may be returned in the data - field of a Kerberos error message. This allows the client to - understand a server failure more precisely. In addition, the server - may return errors to the client that are normally handled at the - application layer in the server, in order to let the client try to - recover. After receiving an error message, the client may attempt to - resubmit an AP request. - - #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 - - These flags are only used if a client is aware of these conventions - when using the SSPI on the Windows platform; they are not generally - used by default. - - When NetBIOS addresses are used in the GSSAPI, they are identified by - the GSS_C_AF_NETBIOS value. This value is defined as: - - - -Jaganathan, et al. Expires January 31, 2007 [Page 9] - -Internet-Draft RC4-HMAC July 2006 - - - #define GSS_C_AF_NETBIOS 0x14 - - NetBios addresses are 16-octet addresses typically composed of 1 to - 15 characters, trailing blank (ASCII char 20) filled, with a 16-th - octet of 0x0. - -7.2. GSSAPI MIC Semantics - - The GSSAPI checksum type and algorithm is defined in Section 5. Only - the first 8 octets of the checksum are used. The resulting checksum - is stored in the SGN_CKSUM field . See [RFC1964] Section 1.2 for - GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). - - The GSS_GetMIC token has the following format: - - Byte no Name Description - 0..1 TOK_ID Identification field. - Tokens emitted by GSS_GetMIC() contain - the hex value 01 01 in this field. - 2..3 SGN_ALG Integrity algorithm indicator. - 11 00 - HMAC - 4..7 Filler Contains ff ff ff ff - 8..15 SND_SEQ Sequence number field. - 16..23 SGN_CKSUM Checksum of "to-be-signed data", - calculated according to algorithm - specified in SGN_ALG field. - - The MIC mechanism used for GSS MIC based messages is as follow: - - GetMIC(Kss, direction, export, seq_num, data) - { - struct Token { - struct Header { - OCTET TOK_ID[2]; - OCTET SGN_ALG[2]; - OCTET Filler[4]; - }; - OCTET SND_SEQ[8]; - OCTET SGN_CKSUM[8]; - } Token; - - - Token.TOK_ID = 01 01; - Token.SGN_SLG = 11 00; - Token.Filler = ff ff ff ff; - - // Create the sequence number - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 10] - -Internet-Draft RC4-HMAC July 2006 - - - if (direction == sender_is_initiator) - { - memset(Token.SEND_SEQ+4, 0xff, 4) - } - else if (direction == sender_is_acceptor) - { - memset(Token.SEND_SEQ+4, 0, 4) - } - Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; - Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; - Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; - Token.SEND_SEQ[3] = (seq_num & 0x000000ff); - - // Derive signing key from session key - - Ksign = HMAC(Kss, "signaturekey"); - // length includes terminating null - - // Generate checksum of message - SGN_CKSUM - // Key derivation salt = 15 - - Sgn_Cksum = MD5((int32)15, Token.Header, data); - - // Save first 8 octets of HMAC Sgn_Cksum - - Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); - memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); - - // Encrypt the sequence number - - // Derive encryption key for the sequence number - // Key derivation salt = 0 - - if (exportable) - { - Kseq = HMAC(Kss, "fortybits", (int32)0); - // len includes terminating null - memset(Kseq+7, 0xab, 7) - } - else - { - Kseq = HMAC(Kss, (int32)0); - } - Kseq = HMAC(Kseq, Token.SGN_CKSUM); - - // Encrypt the sequence number - - RC4(Kseq, Token.SND_SEQ); - - - -Jaganathan, et al. Expires January 31, 2007 [Page 11] - -Internet-Draft RC4-HMAC July 2006 - - - } - -7.3. GSSAPI WRAP Semantics - - There are two encryption keys for GSSAPI message tokens, one that is - 128 bits in strength, and one that is 56 bits in strength as defined - in Section 6. - - All padding is rounded up to 1 byte. One byte is needed to say that - there is 1 byte of padding. The DES based mechanism type uses 8 byte - padding. See [RFC1964] Section 1.2.2.3. - - The RC4-HMAC GSS_Wrap() token has the following format: - - - Byte no Name Description - 0..1 TOK_ID Identification field. - Tokens emitted by GSS_Wrap() contain - the hex value 02 01 in this field. - 2..3 SGN_ALG Checksum algorithm indicator. - 11 00 - HMAC - 4..5 SEAL_ALG ff ff - none - 00 00 - DES-CBC - 10 00 - RC4 - 6..7 Filler Contains ff ff - 8..15 SND_SEQ Encrypted sequence number field. - 16..23 SGN_CKSUM Checksum of plaintext padded data, - calculated according to algorithm - specified in SGN_ALG field. - 24..31 Confounder Random confounder - 32..last Data encrypted or plaintext padded data - - The encryption mechanism used for GSS wrap based messages is as - follow: - - - WRAP(Kss, encrypt, direction, export, seq_num, data) - { - struct Token { // 32 octets - struct Header { - OCTET TOK_ID[2]; - OCTET SGN_ALG[2]; - OCTET SEAL_ALG[2]; - OCTET Filler[2]; - }; - OCTET SND_SEQ[8]; - OCTET SGN_CKSUM[8]; - OCTET Confounder[8]; - - - -Jaganathan, et al. Expires January 31, 2007 [Page 12] - -Internet-Draft RC4-HMAC July 2006 - - - } Token; - - - Token.TOK_ID = 02 01; - Token.SGN_SLG = 11 00; - Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00; - Token.Filler = ff ff; - - // Create the sequence number - - if (direction == sender_is_initiator) - { - memset(&Token.SEND_SEQ[4], 0xff, 4) - } - else if (direction == sender_is_acceptor) - { - memset(&Token.SEND_SEQ[4], 0, 4) - } - Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; - Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; - Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; - Token.SEND_SEQ[3] = (seq_num & 0x000000ff); - - // Generate random confounder - - nonce(&Token.Confounder, 8); - - // Derive signing key from session key - - Ksign = HMAC(Kss, "signaturekey"); - - // Generate checksum of message - - // SGN_CKSUM + Token.Confounder - // Key derivation salt = 15 - - Sgn_Cksum = MD5((int32)15, Token.Header, - Token.Confounder); - - // Derive encryption key for data - // Key derivation salt = 0 - - for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0; - // XOR - if (exportable) - { - Kcrypt = HMAC(Klocal, "fortybits", (int32)0); - // len includes terminating null - memset(Kcrypt+7, 0xab, 7); - - - -Jaganathan, et al. Expires January 31, 2007 [Page 13] - -Internet-Draft RC4-HMAC July 2006 - - - } - else - { - Kcrypt = HMAC(Klocal, (int32)0); - } - - // new encryption key salted with seq - - Kcrypt = HMAC(Kcrypt, (int32)seq); - - // Encrypt confounder (if encrypting) - - if (encrypt) - RC4(Kcrypt, Token.Confounder); - - // Sum the data buffer - - Sgn_Cksum += MD5(data); // Append to checksum - - // Encrypt the data (if encrypting) - - if (encrypt) - RC4(Kcrypt, data); - - // Save first 8 octets of HMAC Sgn_Cksum - - Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); - memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); - - // Derive encryption key for the sequence number - // Key derivation salt = 0 - - if (exportable) - { - Kseq = HMAC(Kss, "fortybits", (int32)0); - // len includes terminating null - memset(Kseq+7, 0xab, 7) - } - else - { - Kseq = HMAC(Kss, (int32)0); - } - Kseq = HMAC(Kseq, Token.SGN_CKSUM); - - // Encrypt the sequence number - - RC4(Kseq, Token.SND_SEQ); - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 14] - -Internet-Draft RC4-HMAC July 2006 - - - // Encrypted message = Token + Data - } - - The character constant "fortybits" evolved from the time when a 40- - bit key length was all that was exportable from the United States. - It is now used to recognize that the key length is of "exportable" - length. In this description, the key size is actually 56-bits. - - -8. Security Considerations - - Care must be taken in implementing these encryption types because - they use a stream cipher. If a different IV is not used in each - direction when using a session key, the encryption is weak. By using - the sequence number as an IV, this is avoided. - - There are two classes of attack on RC4 described in [MIRONOV]. - Strong distinguishers distinguish an RC4 keystream from randomness at - the start of the stream. Weak distinguishers can operate on any part - of the keystream, and the best ones, described in [FMcG] and - [MANTIN05], can exploit data from multiple, different keystreams. A - consequence of these is that encrypting the same data (for instance, - a password) sufficiently many times in separate RC4 keystreams can be - sufficient to leak information to an adversary. The encryption types - defined in this document defend against these by constructing a new - key stream for every message. However, it is RECOMMENDED not to use - the RC4 encryption types defined in this document for high-volume - connections. - - Weaknesses in MD4 [BOER91] were demonstrated by Den Boer and - Bosselaers in 1991. In August 2004, Xiaoyun Wang et al reported MD4 - collisions generated using hand calculation [WANG04]. - Implementations based on Wang's algorithm can find collisions in real - time. However, the intended usage of MD4 described in this document - does not rely on the collision-resistant property of MD4. - Futhermore, MD4 is always used in the context of a keyed hash in this - document. Although no evidence has suggested keyed MD4 hashes are - vulnerable to collision-based attacks, no study has directly proved - that the HMAC-MD4 is secure: the existing study simply assumed that - the hash function used in HMAC is collision proof. It is thus - RECOMMENDED not to use the RC4 encryption types defined in this - document if alternative stronger encryption types, such as aes256- - cts-hmac-sha1-96 [RFC3962], are available. - - -9. Acknowledgements - - The authors wish to thank Sam Hartman, Ken Raeburn and Qunli Li for - - - -Jaganathan, et al. Expires January 31, 2007 [Page 15] - -Internet-Draft RC4-HMAC July 2006 - - - their insightful comments. - - -10. IANA Considerations - - This document has no actions for IANA. - - -11. References - -11.1. Normative References - - [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, - April 1992. - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", - RFC 1964, June 1996. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for - Kerberos 5", RFC 3961, February 2005. - - [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) - Encryption for Kerberos 5", RFC 3962, February 2005. - - [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", RFC 4120, - July 2005. - -11.2. Informative References - - -Jaganathan, et al. Expires January 31, 2007 [Page 16] - -Internet-Draft RC4-HMAC July 2006 - - - [BOER91] Boer, D. and A. Bosselaers, "An Attack on the Last Two - Rounds of MD4", - http://citeseer.ist.psu.edu/denboer91attack.html, 1991. - - [FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the - Alleged RC4 Keystream Generator", Fast Software - Encryption: 7th International Workshop, FSE 2000, April - 2000, . - - [MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc. - Thesis, Weizmann Institute of Science, 2001, . - - [MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances - in Cryptology -- CRYPTO 2002: 22nd Annual International - Cryptology Conference, August 2002, - . - - [MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4 - Keystream Generator", Advances in Cryptology -- EUROCRYPT - 2005: 24th Annual International Conference on the Theory - and Applications of Cryptographic Techniques, May 2005. - - [WANG04] Wang, X., Lai, X., Feng, D., Chen H., and X. Yu, - "Cryptanalysis of Hash functions MD4 and RIPEMD", - http://www.infosec.sdu.edu.cn/paper/md4-ripemd-attck.pdf, - Augest, 2004. - - - -Authors' Addresses - - Karthik Jaganathan - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - Email: karthikj@microsoft.com - - - Larry Zhu - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - Email: lzhu@microsoft.com - - - John Brezak - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - Email: jbrezak@microsoft.com - - - - - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 17] - -Internet-Draft RC4-HMAC July 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Jaganathan, et al. Expires January 31, 2007 [Page 18] - - diff --git a/doc/krb5-protocol/krb5.constants b/doc/krb5-protocol/krb5.constants deleted file mode 100644 index f03e1cb456..0000000000 --- a/doc/krb5-protocol/krb5.constants +++ /dev/null @@ -1,156 +0,0 @@ -8.3. Protocol constants and associated values - - The following tables list constants used in the protocol and defines - their meanings. - - ----------------+-----------+----------+----------------+--------------- -Encryption type|etype value|block size|minimum pad size|confounder size ----------------+-----------+----------+----------------+--------------- -NULL 0 1 0 0 -des-cbc-crc 1 8 4 8 -des-cbc-md4 2 8 0 8 -des-cbc-md5 3 8 0 8 - 4 -des3-cbc-md5 5 8 0 8 - 6 -des3-cbc-sha1 7 8 0 8 - 0x8003 - --------------------------------+-------------------+------------- -Checksum type |sumtype value |checksum size --------------------------------+-------------------+------------- -CRC32 1 4 -rsa-md4 2 16 -rsa-md4-des 3 24 -des-mac 4 16 -des-mac-k 5 8 -rsa-md4-des-k 6 16 -rsa-md5 7 16 -rsa-md5-des 8 24 - 9 - 10 -nist-sha1 11 20 -hmac-sha1-des3 12 20 - --------------------------------+----------------- -padata type |padata-type value --------------------------------+----------------- -PA-TGS-REQ 1 -PA-ENC-TIMESTAMP 2 -PA-PW-SALT 3 - 4 -PA-ENC-UNIX-TIME 5 -PA-SANDIA-SECUREID 6 -PA-SESAME 7 -PA-OSF-DCE 8 -PA-CYBERSAFE-SECUREID 9 -PA-AFS3-SALT 10 -PA-ETYPE-INFO 11 -PAM-SAM-CHALLENGE 12 -PAM-SAM-RESPONSE 13 - --------------------------------+------------- -authorization data type |ad-type value --------------------------------+------------- -reserved values 0-63 -AD-OSF-DCE 64 -AD-SESAME 65 - --------------------------------+----------------- -alternate authentication type |method-type value --------------------------------+----------------- -reserved values 0-63 -ATT-CHALLENGE-RESPONSE 64 - --------------------------------+------------- -transited encoding type |tr-type value --------------------------------+------------- -DOMAIN-X500-COMPRESS 1 -reserved values all others - - ---------------+-------+----------------------------------------- -Label |Value |Meaning or MIT code ---------------+-------+----------------------------------------- - -pvno 5 current Kerberos protocol version number - -message types - -KRB_AS_REQ 10 Request for initial authentication -KRB_AS_REP 11 Response to KRB_AS_REQ request -KRB_TGS_REQ 12 Request for authentication based on TGT -KRB_TGS_REP 13 Response to KRB_TGS_REQ request -KRB_AP_REQ 14 application request to server -KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL -KRB_SAFE 20 Safe (checksummed) application message -KRB_PRIV 21 Private (encrypted) application message -KRB_CRED 22 Private (encrypted) message to forward credentials -KRB_ERROR 30 Error response - -name types - -KRB_NT_UNKNOWN 0 Name type not known -KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users -KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) -KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) -KRB_NT_SRV_XHST 4 Service with host as remaining components -KRB_NT_UID 5 Unique ID - -error codes - -KDC_ERR_NONE 0 No error -KDC_ERR_NAME_EXP 1 Client's entry in database has expired -KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired -KDC_ERR_BAD_PVNO 3 Requested protocol version # not supported -KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key -KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key -KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database -KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database -KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database -KDC_ERR_NULL_KEY 9 The client or server has a null key -KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating -KDC_ERR_NEVER_VALID 11 Requested start time is later than end time -KDC_ERR_POLICY 12 KDC policy rejects request -KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option -KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type -KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type -KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type -KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type -KDC_ERR_CLIENT_REVOKED 18 Client's credentials have been revoked -KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked -KDC_ERR_TGT_REVOKED 20 TGT has been revoked -KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later -KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later -KDC_ERR_KEY_EXPIRED 23 Password has expired - change to reset -KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid -KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication required* -KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match -KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only -KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed -KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired -KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid -KRB_AP_ERR_REPEAT 34 Request is a replay -KRB_AP_ERR_NOT_US 35 The ticket isn't for us -KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match -KRB_AP_ERR_SKEW 37 Clock skew too great -KRB_AP_ERR_BADADDR 38 Incorrect net address -KRB_AP_ERR_BADVERSION 39 Protocol version mismatch -KRB_AP_ERR_MSG_TYPE 40 Invalid msg type -KRB_AP_ERR_MODIFIED 41 Message stream modified -KRB_AP_ERR_BADORDER 42 Message out of order -KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available -KRB_AP_ERR_NOKEY 45 Service key not available -KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed -KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction -KRB_AP_ERR_METHOD 48 Alternative authentication method required* -KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message -KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message -KRB_ERR_GENERIC 60 Generic error (description in e-text) -KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation - - *This error carries additional information in the e-data field. The - contents of the e-data field for this message is described in section - 5.9.1. - diff --git a/doc/krb5-protocol/rfc3961.txt b/doc/krb5-protocol/rfc3961.txt deleted file mode 100644 index 0ac50b9590..0000000000 --- a/doc/krb5-protocol/rfc3961.txt +++ /dev/null @@ -1,2803 +0,0 @@ - - - - - - -Network Working Group K. Raeburn -Request for Comments: 3961 MIT -Category: Standards Track February 2005 - - - Encryption and Checksum Specifications - for Kerberos 5 - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes a framework for defining encryption and - checksum mechanisms for use with the Kerberos protocol, defining an - abstraction layer between the Kerberos protocol and related - protocols, and the actual mechanisms themselves. The document also - defines several mechanisms. Some are taken from RFC 1510, modified - in form to fit this new framework and occasionally modified in - content when the old specification was incorrect. New mechanisms are - presented here as well. This document does NOT indicate which - mechanisms may be considered "required to implement". - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4 - 4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9 - 5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10 - 5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10 - 5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12 - 5.3. Cryptosystem Profile Based on Simplified Profile . . . 13 - 5.4. Checksum Profiles Based on Simplified Profile . . . . . 16 - 6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16 - 6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17 - 6.2. DES-based Encryption and Checksum Types . . . . . . . . 18 - 6.3. Triple-DES Based Encryption and Checksum Types . . . . 28 - 7. Use of Kerberos Encryption Outside This Specification . . . . 30 - - - -Raeburn Standards Track [Page 1] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31 - 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 - 12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36 - A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38 - A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38 - A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39 - A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43 - A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44 - A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44 - B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45 - Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 - Normative References. . . . . . . . . . . . . . . . . . . . . . . 47 - Informative References. . . . . . . . . . . . . . . . . . . . . . 48 - Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49 - Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50 - -1. Introduction - - The Kerberos protocols [Kerb] are designed to encrypt messages of - arbitrary sizes, using block encryption ciphers or, less commonly, - stream encryption ciphers. Encryption is used to prove the - identities of the network entities participating in message - exchanges. However, nothing in the Kerberos protocol requires that - any specific encryption algorithm be used, as long as the algorithm - includes certain operations. - - The following sections specify the encryption and checksum mechanisms - currently defined for Kerberos, as well as a framework for defining - future mechanisms. The encoding, chaining, padding, and other - requirements for each are described. Appendix A gives test vectors - for several functions. - -2. Concepts - - Both encryption and checksum mechanisms are profiled in later - sections. Each profile specifies a collection of operations and - attributes that must be defined for a mechanism. A Kerberos - encryption or checksum mechanism specification is not complete if it - does not define all of these operations and attributes. - - An encryption mechanism must provide for confidentiality and - integrity of the original plaintext. (Incorporating a checksum may - permit integrity checking, if the encryption mode does not provide an - integrity check itself.) It must also provide non-malleability - - - - - -Raeburn Standards Track [Page 2] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - [Bellare98] [Dolev91]. Use of a random confounder prepended to the - plaintext is recommended. It should not be possible to determine if - two ciphertexts correspond to the same plaintext without the key. - - A checksum mechanism [1] must provide proof of the integrity of the - associated message and must preserve the confidentiality of the - message in case it is not sent in the clear. Finding two plaintexts - with the same checksum should be infeasible. It is NOT required that - an eavesdropper be unable to determine whether two checksums are for - the same message, as the messages themselves would presumably be - visible to any such eavesdropper. - - Due to advances in cryptography, some cryptographers consider using - the same key for multiple purposes unwise. Since keys are used in - performing a number of different functions in Kerberos, it is - desirable to use different keys for each of these purposes, even - though we start with a single long-term or session key. - - We do this by enumerating the different uses of keys within Kerberos - and by making the "usage number" an input to the encryption or - checksum mechanisms; such enumeration is outside the scope of this - document. Later sections define simplified profile templates for - encryption and checksum mechanisms that use a key derivation function - applied to a CBC mode (or similar) cipher and a checksum or hash - algorithm. - - We distinguish the "base key" specified by other documents from the - "specific key" for a specific encryption or checksum operation. It - is expected but not required that the specific key be one or more - separate keys derived from the original protocol key and the key - usage number. The specific key should not be explicitly referenced - outside of this document. The typical language used in other - documents should be something like, "encrypt this octet string using - this key and this usage number"; generation of the specific key and - cipher state (described in the next section) are implicit. The - creation of a new cipher-state object, or the re-use of one from a - previous encryption operation, may also be explicit. - - New protocols defined in terms of the Kerberos encryption and - checksum types should use their own key usage values. Key usages are - unsigned 32-bit integers; zero is not permitted. - - All data is assumed to be in the form of strings of octets or eight- - bit bytes. Environments with other byte sizes will have to emulate - this behavior in order to get correct results. - - - - - - -Raeburn Standards Track [Page 3] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - Each algorithm is assigned an encryption type (or "etype") or - checksum type number, for algorithm identification within the - Kerberos protocol. The full list of current type number assignments - is given in section 8. - -3. Encryption Algorithm Profile - - An encryption mechanism profile must define the following attributes - and operations. The operations must be defined as functions in the - mathematical sense. No additional or implicit inputs (such as - Kerberos principal names or message sequence numbers) are permitted. - - protocol key format - This describes which octet string values represent valid keys. - For encryption mechanisms that don't have perfectly dense key - spaces, this will describe the representation used for encoding - keys. It need not describe invalid specific values; all key - generation routines should avoid such values. - - specific key structure - This is not a protocol format at all, but a description of the - keying material derived from the chosen key and used to encrypt or - decrypt data or compute or verify a checksum. It may, for - example, be a single key, a set of keys, or a combination of the - original key with additional data. The authors recommend using - one or more keys derived from the original key via one-way key - derivation functions. - - required checksum mechanism - This indicates a checksum mechanism that must be available when - this encryption mechanism is used. Since Kerberos has no built in - mechanism for negotiating checksum mechanisms, once an encryption - mechanism is decided, the corresponding checksum mechanism can be - used. - - key-generation seed length, K - This is the length of the random bitstring needed to generate a - key with the encryption scheme's random-to-key function (described - below). This must be a fixed value so that various techniques for - producing a random bitstring of a given length may be used with - key generation functions. - - key generation functions - Keys must be generated in a number of cases, from different types - of inputs. All function specifications must indicate how to - generate keys in the proper wire format and must avoid generating - keys that significantly compromise the confidentiality of - encrypted data, if the cryptosystem has such. Entropy from each - - - -Raeburn Standards Track [Page 4] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - source should be preserved as much as possible. Many of the - inputs, although unknown, may be at least partly predictable - (e.g., a password string is likely to be entirely in the ASCII - subset and of fairly short length in many environments; a semi- - random string may include time stamps). The benefit of such - predictability to an attacker must be minimized. - - string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) - This function generates a key from two UTF-8 strings and an opaque - octet string. One of the strings is usually the principal's pass - phrase, but generally it is merely a secret string. The other - string is a "salt" string intended to produce different keys from - the same password for different users or realms. Although the - strings provided will use UTF-8 encoding, no specific version of - Unicode should be assumed; all valid UTF-8 strings should be - allowed. Strings provided in other encodings MUST first be - converted to UTF-8 before applying this function. - - The third argument, the octet string, may be used to pass - mechanism-specific parameters into this function. Since doing so - implies knowledge of the specific encryption system, generating - non-default parameter values should be an uncommon operation, and - normal Kerberos applications should be able to treat this - parameter block as an opaque object supplied by the Key - Distribution Center or defaulted to some mechanism-specific - constant value. - - The string-to-key function should be a one-way function so that - compromising a user's key in one realm does not compromise it in - another, even if the same password (but a different salt) is used. - - random-to-key (bitstring[K])->(protocol-key) - This function generates a key from a random bitstring of a - specific size. All the bits of the input string are assumed to be - equally random, even though the entropy present in the random - source may be limited. - - key-derivation (protocol-key, integer)->(specific-key) - In this function, the integer input is the key usage value, as - described above. An attacker is assumed to know the usage values. - The specific-key output value was described in section 2. - - string-to-key parameter format - This describes the format of the block of data that can be passed - to the string-to-key function above to configure additional - parameters for that function. Along with the mechanism of - encoding parameter values, bounds on the allowed parameters should - also be described to avoid allowing a spoofed KDC to compromise - - - -Raeburn Standards Track [Page 5] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - the user's password. If practical it may be desirable to - construct the encoding so that values unacceptably weakening the - resulting key cannot be encoded. - - Local security policy might permit tighter bounds to avoid excess - resource consumption. If so, the specification should recommended - defaults for these bounds. The description should also outline - possible weaknesses if bounds checks or other validations are not - applied to a parameter string received from the network. - - As mentioned above, this should be considered opaque to most - normal applications. - - default string-to-key parameters (octet string) - This default value for the "params" argument to the string-to-key - function should be used when the application protocol (Kerberos or - other) does not explicitly set the parameter value. As indicated - above, in most cases this parameter block should be treated as an - opaque object. - - cipher state - This describes any information that can be carried over from one - encryption or decryption operation to the next, for use with a - given specific key. For example, a block cipher used in CBC mode - may put an initial vector of one block in the cipher state. Other - encryption modes may track nonces or other data. - - This state must be non-empty and must influence encryption so that - messages are decrypted in the same order they were a encrypted, if - the cipher state is carried over from one encryption to the next. - Distinguishing out-of-order or missing messages from corrupted - messages is not required. If desired, this can be done at a - higher level by including sequence numbers and not "chaining" the - cipher state between encryption operations. - - The cipher state may not be reused in multiple encryption or - decryption operations. These operations all generate a new cipher - state that may be used for following operations using the same key - and operation. - - The contents of the cipher state must be treated as opaque outside - of encryption system specifications. - - initial cipher state (specific-key, direction)->(state) - This describes the generation of the initial value for the cipher - state if it is not being carried over from a previous encryption - or decryption operation. - - - - -Raeburn Standards Track [Page 6] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - This describes any initial state setup needed before encrypting - arbitrary amounts of data with a given specific key. The specific - key and the direction of operations to be performed (encrypt - versus decrypt) must be the only input needed for this - initialization. - - This state should be treated as opaque in any uses outside of an - encryption algorithm definition. - - IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what - degree an application protocol could exercise control over the - initial vector used in DES CBC operations. Some existing - implementations permit setting the initial vector. This framework - does not provide for application control of the cipher state - (beyond "initialize" and "carry over from previous encryption"), - as the form and content of the initial cipher state can vary - between encryption systems and may not always be a single block of - random data. - - New Kerberos application protocols should not assume control over - the initial vector, or that one even exists. However, a general- - purpose implementation may wish to provide the capability, in case - applications explicitly setting it are encountered. - - encrypt (specific-key, state, octet string)->(state, octet string) - This function takes the specific key, cipher state, and a non- - empty plaintext string as input and generates ciphertext and a new - cipher state as outputs. If the basic encryption algorithm itself - does not provide for integrity protection (e.g., DES in CBC mode), - then some form of verifiable MAC or checksum must be included. - Some random factor such as a confounder should be included so that - an observer cannot know if two messages contain the same - plaintext, even if the cipher state and specific keys are the - same. The exact length of the plaintext need not be encoded, but - if it is not and if padding is required, the padding must be added - at the end of the string so that the decrypted version may be - parsed from the beginning. - - The specification of the encryption function must indicate not - only the precise contents of the output octet string, but also the - output cipher state. The application protocol may carry the - output cipher state forward from one encryption with a given - specific key to another; the effect of this "chaining" must be - defined [2]. - - Assuming that values for the specific key and cipher state are - correctly-produced, no input octet string may result in an error - indication. - - - -Raeburn Standards Track [Page 7] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - decrypt (specific-key, state, octet string)->(state, octet string) - This function takes the specific key, cipher state, and ciphertext - as inputs and verifies the integrity of the supplied ciphertext. - If the ciphertext's integrity is intact, this function produces - the plaintext and a new cipher state as outputs; otherwise, an - error indication must be returned, and the data discarded. - - The result of the decryption may be longer than the original - plaintext, as, for example, when the encryption mode adds padding - to reach a multiple of a block size. If this is the case, any - extra octets must come after the decoded plaintext. An - application protocol that needs to know the exact length of the - message must encode a length or recognizable "end of message" - marker within the plaintext [3]. - - As with the encryption function, a correct specification for this - function must indicate not only the contents of the output octet - string, but also the resulting cipher state. - - pseudo-random (protocol-key, octet-string)->(octet-string) - This pseudo-random function should generate an octet string of - some size that is independent of the octet string input. The PRF - output string should be suitable for use in key generation, even - if the octet string input is public. It should not reveal the - input key, even if the output is made public. - - These operations and attributes are all that is required to support - Kerberos and various proposed preauthentication schemes. - - For convenience of certain application protocols that may wish to use - the encryption profile, we add the constraint that, for any given - plaintext input size, a message size must exist between that given - size and that size plus 65,535 such that the length of the decrypted - version of the ciphertext will never have extra octets at the end. - - Expressed mathematically, for every message length L1, there exists a - message size L2 such that - - L2 >= L1 - L2 < L1 + 65,536 - for every message M with |M| = L2, decrypt(encrypt(M)) = M - - A document defining a new encryption type should also describe known - weaknesses or attacks, so that its security may be fairly assessed, - and should include test vectors or other validation procedures for - the operations defined. Specific references to information that is - readily available elsewhere are sufficient. - - - - -Raeburn Standards Track [Page 8] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - -4. Checksum Algorithm Profile - - A checksum mechanism profile must define the following attributes and - operations: - - associated encryption algorithm(s) - This indicates the types of encryption keys this checksum - mechanism can be used with. - - A keyed checksum mechanism may have more than one associated - encryption algorithm if they share the same wire-key format, - string-to-key function, default string-to-key-parameters, and key - derivation function. (This combination means that, for example, a - checksum type, key usage value, and password are adequate to get - the specific key used to compute a checksum.) - - An unkeyed checksum mechanism can be used with any encryption - type, as the key is ignored, but its use must be limited to cases - where the checksum itself is protected, to avoid trivial attacks. - - get_mic function - This function generates a MIC token for a given specific key (see - section 3) and message (represented as an octet string) that may - be used to verify the integrity of the associated message. This - function is not required to return the same deterministic result - for each use; it need only generate a token that the verify_mic - routine can check. - - The output of this function will also dictate the size of the - checksum. It must be no larger than 65,535 octets. - - verify_mic function - Given a specific key, message, and MIC token, this function - ascertains whether the message integrity has been compromised. - For a deterministic get_mic routine, the corresponding verify_mic - may simply generate another checksum and compare the two. - - The get_mic and verify_mic operations must allow inputs of arbitrary - length; if any padding is needed, the padding scheme must be - specified as part of these functions. - - These operations and attributes are all that should be required to - support Kerberos and various proposed preauthentication schemes. - - As with encryption mechanism definition documents, documents defining - new checksum mechanisms should indicate validation processes and - known weaknesses. - - - - -Raeburn Standards Track [Page 9] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - -5. Simplified Profile for CBC Ciphers with Key Derivation - - The profile outlined in sections 3 and 4 describes a large number of - operations that must be defined for encryption and checksum - algorithms to be used with Kerberos. Here we describe a simpler - profile that can generate both encryption and checksum mechanism - definitions, filling in uses of key derivation in appropriate places, - providing integrity protection, and defining multiple operations for - the cryptosystem profile based on a smaller set of operations. Not - all of the existing cryptosystems for Kerberos fit into this - simplified profile, but we recommend that future cryptosystems use it - or something based on it [4]. - - Not all the operations in the complete profiles are defined through - this mechanism; several must still be defined for each new algorithm - pair. - -5.1. A Key Derivation Function - - Rather than define some scheme by which a "protocol key" is composed - of a large number of encryption keys, we use keys derived from a base - key to perform cryptographic operations. The base key must be used - only for generating the derived keys, and this derivation must be - non-invertible and entropy preserving. Given these restrictions, - compromise of one derived key does not compromise others. Attack of - the base key is limited, as it is only used for derivation and is not - exposed to any user data. - - To generate a derived key from a base key, we generate a pseudorandom - octet string by using an algorithm DR, described below, and generate - a key from that octet string by using a function dependent on the - encryption algorithm. The input length needed for that function, - which is also dependent on the encryption algorithm, dictates the - length of the string to be generated by the DR algorithm (the value - "k" below). These procedures are based on the key derivation in - [Blumenthal96]. - - Derived Key = DK(Base Key, Well-Known Constant) - - DK(Key, Constant) = random-to-key(DR(Key, Constant)) - - DR(Key, Constant) = k-truncate(E(Key, Constant, - initial-cipher-state)) - - Here DR is the random-octet generation function described below, and - DK is the key-derivation function produced from it. In this - construction, E(Key, Plaintext, CipherState) is a cipher, Constant is - a well-known constant determined by the specific usage of this - - - -Raeburn Standards Track [Page 10] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - function, and k-truncate truncates its argument by taking the first k - bits. Here, k is the key generation seed length needed for the - encryption system. - - The output of the DR function is a string of bits; the actual key is - produced by applying the cryptosystem's random-to-key operation on - this bitstring. - - If the Constant is smaller than the cipher block size of E, then it - must be expanded with n-fold() so it can be encrypted. If the output - of E is shorter than k bits, it is fed back into the encryption as - many times as necessary. The construct is as follows (where | - indicates concatentation): - - K1 = E(Key, n-fold(Constant), initial-cipher-state) - K2 = E(Key, K1, initial-cipher-state) - K3 = E(Key, K2, initial-cipher-state) - K4 = ... - - DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) - - n-fold is an algorithm that takes m input bits and "stretches" them - to form n output bits with equal contribution from each input bit to - the output, as described in [Blumenthal96]: - - We first define a primitive called n-folding, which takes a - variable-length input block and produces a fixed-length output - sequence. The intent is to give each input bit approximately - equal weight in determining the value of each output bit. Note - that whenever we need to treat a string of octets as a number, the - assumed representation is Big-Endian -- Most Significant Byte - first. - - To n-fold a number X, replicate the input value to a length that - is the least common multiple of n and the length of X. Before - each repetition, the input is rotated to the right by 13 bit - positions. The successive n-bit chunks are added together using - 1's-complement addition (that is, with end-around carry) to yield - a n-bit result.... - - Test vectors for n-fold are supplied in appendix A [5]. - - In this section, n-fold is always used to produce c bits of output, - where c is the cipher block size of E. - - The size of the Constant must not be larger than c, because reducing - the length of the Constant by n-folding can cause collisions. - - - - -Raeburn Standards Track [Page 11] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - If the size of the Constant is smaller than c, then the Constant must - be n-folded to length c. This string is used as input to E. If the - block size of E is less than the random-to-key input size, then the - output from E is taken as input to a second invocation of E. This - process is repeated until the number of bits accumulated is greater - than or equal to the random-to-key input size. When enough bits have - been computed, the first k are taken as the random data used to - create the key with the algorithm-dependent random-to-key function. - - As the derived key is the result of one or more encryptions in the - base key, deriving the base key from the derived key is equivalent to - determining the key from a very small number of plaintext/ciphertext - pairs. Thus, this construction is as strong as the cryptosystem - itself. - -5.2. Simplified Profile Parameters - - These are the operations and attributes that must be defined: - - protocol key format - string-to-key function - default string-to-key parameters - key-generation seed length, k - random-to-key function - As above for the normal encryption mechanism profile. - - unkeyed hash algorithm, H - This should be a collision-resistant hash algorithm with fixed- - size output, suitable for use in an HMAC [HMAC]. It must support - inputs of arbitrary length. Its output must be at least the - message block size (below). - - HMAC output size, h - This indicates the size of the leading substring output by the - HMAC function that should be used in transmitted messages. It - should be at least half the output size of the hash function H, - and at least 80 bits; it need not match the output size. - - message block size, m - This is the size of the smallest units the cipher can handle in - the mode in which it is being used. Messages will be padded to a - multiple of this size. If a block cipher is used in a mode that - - - - - - - - - -Raeburn Standards Track [Page 12] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - can handle messages that are not multiples of the cipher block - size, such as CBC mode with cipher text stealing (CTS, see [RC5]), - this value would be one octet. For traditional CBC mode with - padding, it would be the underlying cipher's block size. - - This value must be a multiple of eight bits (one octet). - - encryption/decryption functions, E and D - These are basic encryption and decryption functions for messages - of sizes that are multiples of the message block size. No - integrity checking or confounder should be included here. For - inputs these functions take the IV or similar data, a protocol- - format key, and an octet string, returning a new IV and octet - string. - - The encryption function is not required to use CBC mode but is - assumed to be using something with similar properties. In - particular, prepending a cipher block-size confounder to the - plaintext should alter the entire ciphertext (comparable to - choosing and including a random initial vector for CBC mode). - - The result of encrypting one cipher block (of size c, above) must - be deterministic for the random octet generation function DR in - the previous section to work. For best security, it should also - be no larger than c. - - cipher block size, c - This is the block size of the block cipher underlying the - encryption and decryption functions indicated above, used for key - derivation and for the size of the message confounder and initial - vector. (If a block cipher is not in use, some comparable - parameter should be determined.) It must be at least 5 octets. - - This is not actually an independent parameter; rather, it is a - property of the functions E and D. It is listed here to clarify - the distinction between it and the message block size, m. - - Although there are still a number of properties to specify, they are - fewer and simpler than in the full profile. - -5.3. Cryptosystem Profile Based on Simplified Profile - - The above key derivation function is used to produce three - intermediate keys. One is used for computing checksums of - unencrypted data. The other two are used for encrypting and - checksumming plaintext to be sent encrypted. - - - - - -Raeburn Standards Track [Page 13] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - The ciphertext output is the concatenation of the output of the basic - encryption function E and a (possibly truncated) HMAC using the - specified hash function H, both applied to the plaintext with a - random confounder prefix and sufficient padding to bring it to a - multiple of the message block size. When the HMAC is computed, the - key is used in the protocol key form. - - Decryption is performed by removing the (partial) HMAC, decrypting - the remainder, and verifying the HMAC. The cipher state is an - initial vector, initialized to zero. - - The substring notation "[1..h]" in the following table should be read - as using 1-based indexing; leading substrings are used. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Raeburn Standards Track [Page 14] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - Cryptosystem from Simplified Profile ------------------------------------------------------------------------- -protocol key format As given. - -specific key structure Three protocol-format keys: { Kc, Ke, Ki }. - -key-generation seed As given. -length - -required checksum As defined below in section 5.4. -mechanism - -cipher state Initial vector (usually of length c) - -initial cipher state All bits zero - -encryption function conf = Random string of length c - pad = Shortest string to bring confounder - and plaintext to a length that's a - multiple of m. - (C1, newIV) = E(Ke, conf | plaintext | pad, - oldstate.ivec) - H1 = HMAC(Ki, conf | plaintext | pad) - ciphertext = C1 | H1[1..h] - newstate.ivec = newIV - -decryption function (C1,H1) = ciphertext - (P1, newIV) = D(Ke, C1, oldstate.ivec) - if (H1 != HMAC(Ki, P1)[1..h]) - report error - newstate.ivec = newIV - -default string-to-key As given. -params - -pseudo-random function tmp1 = H(octet-string) - tmp2 = truncate tmp1 to multiple of m - PRF = E(DK(protocol-key, prfconstant), - tmp2, initial-cipher-state) - - The "prfconstant" used in the PRF operation is the three-octet string - "prf". - - - - - - - - - -Raeburn Standards Track [Page 15] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - Cryptosystem from Simplified Profile ------------------------------------------------------------------------- -key generation functions: - -string-to-key function As given. - -random-to-key function As given. - -key-derivation function The "well-known constant" used for the DK - function is the key usage number, expressed as - four octets in big-endian order, followed by - one octet indicated below. - - Kc = DK(base-key, usage | 0x99); - Ke = DK(base-key, usage | 0xAA); - Ki = DK(base-key, usage | 0x55); - -5.4. Checksum Profiles Based on Simplified Profile - - When an encryption system is defined with the simplified profile - given in section 5.2, a checksum algorithm may be defined for it as - follows: - - Checksum Mechanism from Simplified Profile - -------------------------------------------------- - associated cryptosystem As defined above. - - get_mic HMAC(Kc, message)[1..h] - - verify_mic get_mic and compare - - The HMAC function and key Kc are as described in section 5.3. - -6. Profiles for Kerberos Encryption and Checksum Algorithms - - These profiles describe the encryption and checksum systems defined - for Kerberos. The astute reader will notice that some of them do not - fulfill all the requirements outlined in previous sections. These - systems are defined for backward compatibility; newer implementations - should (whenever possible) attempt to utilize encryption systems that - satisfy all the profile requirements. - - The full list of current encryption and checksum type number - assignments, including values currently reserved but not defined in - this document, is given in section 8. - - - - - - -Raeburn Standards Track [Page 16] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - -6.1. Unkeyed Checksums - - These checksum types use no encryption keys and thus can be used in - combination with any encryption type, but they may only be used with - caution, in limited circumstances where the lack of a key does not - provide a window for an attack, preferably as part of an encrypted - message [6]. Keyed checksum algorithms are recommended. - -6.1.1. The RSA MD5 Checksum - - The RSA-MD5 checksum calculates a checksum by using the RSA MD5 - algorithm [MD5-92]. The algorithm takes as input an input message of - arbitrary length and produces as output a 128-bit (sixteen octet) - checksum. - - rsa-md5 - ---------------------------------------------- - associated cryptosystem any - - get_mic rsa-md5(msg) - - verify_mic get_mic and compare - - The rsa-md5 checksum algorithm is assigned a checksum type number of - seven (7). - -6.1.2. The RSA MD4 Checksum - - The RSA-MD4 checksum calculates a checksum using the RSA MD4 - algorithm [MD4-92]. The algorithm takes as input an input message of - arbitrary length and produces as output a 128-bit (sixteen octet) - checksum. - - rsa-md4 - ---------------------------------------------- - associated cryptosystem any - - get_mic md4(msg) - - verify_mic get_mic and compare - - The rsa-md4 checksum algorithm is assigned a checksum type number of - two (2). - - - - - - - - -Raeburn Standards Track [Page 17] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - -6.1.3. CRC-32 Checksum - - This CRC-32 checksum calculates a checksum based on a cyclic - redundancy check as described in ISO 3309 [CRC] but modified as - described below. The resulting checksum is four (4) octets in - length. The CRC-32 is neither keyed nor collision-proof; thus, the - use of this checksum is not recommended. An attacker using a - probabilistic chosen-plaintext attack as described in [SG92] might be - able to generate an alternative message that satisfies the checksum. - - The CRC-32 checksum used in the des-cbc-crc encryption mode is - identical to the 32-bit FCS described in ISO 3309 with two - exceptions: The sum with the all-ones polynomial times x**k is - omitted, and the final remainder is not ones-complemented. ISO 3309 - describes the FCS in terms of bits, whereas this document describes - the Kerberos protocol in terms of octets. To clarify the ISO 3309 - definition for the purpose of computing the CRC-32 in the des-cbc-crc - encryption mode, the ordering of bits in each octet shall be assumed - to be LSB first. Given this assumed ordering of bits within an - octet, the mapping of bits to polynomial coefficients shall be - identical to that specified in ISO 3309. - - Test values for this modified CRC function are included in appendix - A.5. - - crc32 - ---------------------------------------------- - associated cryptosystem any - - get_mic crc32(msg) - - verify_mic get_mic and compare - - The crc32 checksum algorithm is assigned a checksum type number of - one (1). - -6.2. DES-Based Encryption and Checksum Types - - These encryption systems encrypt information under the Data - Encryption Standard [DES77] by using the cipher block chaining mode - [DESM80]. A checksum is computed as described below and placed in - the cksum field. DES blocks are eight bytes. As a result, the data - to be encrypted (the concatenation of confounder, checksum, and - message) must be padded to an eight byte boundary before encryption. - The values of the padding bytes are unspecified. - - - - - - -Raeburn Standards Track [Page 18] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - Plaintext and DES ciphertext are encoded as blocks of eight octets, - which are concatenated to make the 64-bit inputs for the DES - algorithms. The first octet supplies the eight most significant bits - (with the octet's MSB used as the DES input block's MSB, etc.), the - second octet the next eight bits, and so on. The eighth octet - supplies the 8 least significant bits. - - Encryption under DES using cipher block chaining requires an - additional input in the form of an initialization vector; this vector - is specified below for each encryption system. - - The DES specifications [DESI81] identify four 'weak' and twelve - 'semi-weak' keys; these keys SHALL NOT be used for encrypting - messages for use in Kerberos. The "variant keys" generated for the - RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an - eXclusive-OR of a DES key with a constant are not checked for this - property. - - A DES key is eight octets of data. This consists of 56 bits of - actual key data, and eight parity bits, one per octet. The key is - encoded as a series of eight octets written in MSB-first order. The - bits within the key are also encoded in MSB order. For example, if - the encryption key is - (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where - B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the - parity bits, the first octet of the key would be B1,B2,...,B7,P1 - (with B1 as the most significant bit). See the [DESM80] introduction - for reference. - - Encryption Data Format - - The format for the data to be encrypted includes a one-block - confounder, a checksum, the encoded plaintext, and any necessary - padding, as described in the following diagram. The msg-seq field - contains the part of the protocol message to be encrypted. - - +-----------+----------+---------+-----+ - |confounder | checksum | msg-seq | pad | - +-----------+----------+---------+-----+ - - One generates a random confounder of one block, placing it in - 'confounder'; zeros out the 'checksum' field (of length appropriate - to exactly hold the checksum to be computed); adds the necessary - padding; calculates the appropriate checksum over the whole sequence, - placing the result in 'checksum'; and then encrypts using the - specified encryption type and the appropriate key. - - - - - -Raeburn Standards Track [Page 19] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - String or Random-Data to Key Transformation - - To generate a DES key from two UTF-8 text strings (password and - salt), the two strings are concatenated, password first, and the - result is then padded with zero-valued octets to a multiple of eight - octets. - - The top bit of each octet (always zero if the password is plain - ASCII, as was assumed when the original specification was written) is - discarded, and the remaining seven bits of each octet form a - bitstring. This is then fan-folded and eXclusive-ORed with itself to - produce a 56-bit string. An eight-octet key is formed from this - string, each octet using seven bits from the bitstring, leaving the - least significant bit unassigned. The key is then "corrected" by - correcting the parity on the key, and if the key matches a 'weak' or - 'semi-weak' key as described in the DES specification, it is - eXclusive-ORed with the constant 0x00000000000000F0. This key is - then used to generate a DES CBC checksum on the initial string with - the salt appended. The result of the CBC checksum is then - "corrected" as described above to form the result, which is returned - as the key. - - For purposes of the string-to-key function, the DES CBC checksum is - calculated by CBC encrypting a string using the key as IV and the - final eight byte block as the checksum. - - Pseudocode follows: - - removeMSBits(8byteblock) { - /* Treats a 64 bit block as 8 octets and removes the MSB in - each octet (in big endian mode) and concatenates the - result. E.g., the input octet string: - 01110000 01100001 11110011 01110011 11110111 01101111 - 11110010 01100100 - results in the output bitstring: - 1110000 1100001 1110011 1110011 1110111 1101111 - 1110010 1100100 */ - } - - reverse(56bitblock) { - /* Treats a 56-bit block as a binary string and reverses it. - E.g., the input string: - 1000001 1010100 1001000 1000101 1001110 1000001 - 0101110 1001101 - results in the output string: - 1011001 0111010 1000001 0111001 1010001 0001001 - 0010101 1000001 */ - } - - - -Raeburn Standards Track [Page 20] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - add_parity_bits(56bitblock) { - /* Copies a 56-bit block into a 64-bit block, left shifts - content in each octet, and add DES parity bit. - E.g., the input string: - 1100000 0001111 0011100 0110100 1000101 1100100 - 0110110 0010111 - results in the output string: - 11000001 00011111 00111000 01101000 10001010 11001000 - 01101101 00101111 */ - } - - key_correction(key) { - fixparity(key); - if (is_weak_key(key)) - key = key XOR 0xF0; - return(key); - } - - mit_des_string_to_key(string,salt) { - odd = 1; - s = string | salt; - tempstring = 0; /* 56-bit string */ - pad(s); /* with nulls to 8 byte boundary */ - for (8byteblock in s) { - 56bitstring = removeMSBits(8byteblock); - if (odd == 0) reverse(56bitstring); - odd = ! odd; - tempstring = tempstring XOR 56bitstring; - } - tempkey = key_correction(add_parity_bits(tempstring)); - key = key_correction(DES-CBC-check(s,tempkey)); - return(key); - } - - des_string_to_key(string,salt,params) { - if (length(params) == 0) - type = 0; - else if (length(params) == 1) - type = params[0]; - else - error("invalid params"); - if (type == 0) - mit_des_string_to_key(string,salt); - else - error("invalid params"); - } - - - - - -Raeburn Standards Track [Page 21] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - One common extension is to support the "AFS string-to-key" algorithm, - which is not defined here, if the type value above is one (1). - - For generation of a key from a random bitstring, we start with a 56- - bit string and, as with the string-to-key operation above, insert - parity bits. If the result is a weak or semi-weak key, we modify it - by eXclusive-OR with the constant 0x00000000000000F0: - - des_random_to_key(bitstring) { - return key_correction(add_parity_bits(bitstring)); - } - -6.2.1. DES with MD5 - - The des-cbc-md5 encryption mode encrypts information under DES in CBC - mode with an all-zero initial vector and with an MD5 checksum - (described in [MD5-92]) computed and placed in the checksum field. - - The encryption system parameters for des-cbc-md5 are as follows: - - des-cbc-md5 - -------------------------------------------------------------------- - protocol key format 8 bytes, parity in low bit of each - - specific key structure copy of original key - - required checksum rsa-md5-des - mechanism - - key-generation seed 8 bytes - length - - cipher state 8 bytes (CBC initial vector) - - initial cipher state all-zero - - encryption function des-cbc(confounder | checksum | msg | pad, - ivec=oldstate) - where - checksum = md5(confounder | 0000... - | msg | pad) - - newstate = last block of des-cbc output - - decryption function decrypt encrypted text and verify checksum - - newstate = last block of ciphertext - - - - -Raeburn Standards Track [Page 22] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - des-cbc-md5 - -------------------------------------------------------------------- - default string-to-key empty string - params - - pseudo-random function des-cbc(md5(input-string), ivec=0) - - key generation functions: - - string-to-key des_string_to_key - - random-to-key des_random_to_key - - key-derivation identity - - The des-cbc-md5 encryption type is assigned the etype value three - (3). - -6.2.2. DES with MD4 - - The des-cbc-md4 encryption mode also encrypts information under DES - in CBC mode, with an all-zero initial vector. An MD4 checksum - (described in [MD4-92]) is computed and placed in the checksum field. - - des-cbc-md4 - -------------------------------------------------------------------- - protocol key format 8 bytes, parity in low bit of each - - specific key structure copy of original key - - required checksum rsa-md4-des - mechanism - - key-generation seed 8 bytes - length - - cipher state 8 bytes (CBC initial vector) - - initial cipher state all-zero - - encryption function des-cbc(confounder | checksum | msg | pad, - ivec=oldstate) - where - checksum = md4(confounder | 0000... - | msg | pad) - - newstate = last block of des-cbc output - - - - -Raeburn Standards Track [Page 23] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - des-cbc-md4 - -------------------------------------------------------------------- - - decryption function decrypt encrypted text and verify checksum - - newstate = last block of ciphertext - - default string-to-key empty string - params - - pseudo-random function des-cbc(md5(input-string), ivec=0) - - key generation functions: - - string-to-key des_string_to_key - - random-to-key copy input, then fix parity bits - - key-derivation identity - - Note that des-cbc-md4 uses md5, not md4, in the PRF definition. - - The des-cbc-md4 encryption algorithm is assigned the etype value two - (2). - -6.2.3. DES with CRC - - The des-cbc-crc encryption type uses DES in CBC mode with the key - used as the initialization vector, with a four-octet CRC-based - checksum computed as described in section 6.1.3. Note that this is - not a standard CRC-32 checksum, but a slightly modified one. - - des-cbc-crc - -------------------------------------------------------------------- - protocol key format 8 bytes, parity in low bit of each - - specific key structure copy of original key - - required checksum rsa-md5-des - mechanism - - key-generation seed 8 bytes - length - - cipher state 8 bytes (CBC initial vector) - - - - - - -Raeburn Standards Track [Page 24] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - des-cbc-crc - -------------------------------------------------------------------- - initial cipher state copy of original key - - encryption function des-cbc(confounder | checksum | msg | pad, - ivec=oldstate) - where - checksum = crc(confounder | 00000000 - | msg | pad) - - newstate = last block of des-cbc output - - decryption function decrypt encrypted text and verify checksum - - newstate = last block of ciphertext - - default string-to-key empty string - params - - pseudo-random function des-cbc(md5(input-string), ivec=0) - - key generation functions: - - string-to-key des_string_to_key - - random-to-key copy input, then fix parity bits - - key-derivation identity - - The des-cbc-crc encryption algorithm is assigned the etype value one - (1). - -6.2.4. RSA MD5 Cryptographic Checksum Using DES - - The RSA-MD5-DES checksum calculates a keyed collision-proof checksum - by prepending an eight octet confounder before the text, applying the - RSA MD5 checksum algorithm, and encrypting the confounder and the - checksum by using DES in cipher-block-chaining (CBC) mode with a - variant of the key, where the variant is computed by eXclusive-ORing - the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The - initialization vector should be zero. The resulting checksum is 24 - octets long. - - - - - - - - - -Raeburn Standards Track [Page 25] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - rsa-md5-des - ---------------------------------------------------------------- - associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc - - get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, - conf | rsa-md5(conf | msg)) - - verify_mic decrypt and verify rsa-md5 checksum - - The rsa-md5-des checksum algorithm is assigned a checksum type number - of eight (8). - -6.2.5. RSA MD4 Cryptographic Checksum Using DES - - The RSA-MD4-DES checksum calculates a keyed collision-proof checksum - by prepending an eight octet confounder before the text, applying the - RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder - and the checksum using DES in cipher-block-chaining (CBC) mode with a - variant of the key, where the variant is computed by eXclusive-ORing - the key with the constant 0xF0F0F0F0F0F0F0F0 [7]. The initialization - vector should be zero. The resulting checksum is 24 octets long. - - rsa-md4-des - ---------------------------------------------------------------- - associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc - - get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, - conf | rsa-md4(conf | msg), - ivec=0) - - verify_mic decrypt and verify rsa-md4 checksum - - The rsa-md4-des checksum algorithm is assigned a checksum type number - of three (3). - -6.2.6. RSA MD4 Cryptographic Checksum Using DES Alternative - - The RSA-MD4-DES-K checksum calculates a keyed collision-proof - checksum by applying the RSA MD4 checksum algorithm and encrypting - the results by using DES in cipher block chaining (CBC) mode with a - DES key as both key and initialization vector. The resulting - checksum is 16 octets long. This checksum is tamper-proof and - believed to be collision-proof. Note that this checksum type is the - old method for encoding the RSA-MD4-DES checksum; it is no longer - recommended. - - - - - - -Raeburn Standards Track [Page 26] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - rsa-md4-des-k - ---------------------------------------------------------------- - associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc - - get_mic des-cbc(key, md4(msg), ivec=key) - - verify_mic decrypt, compute checksum and compare - - The rsa-md4-des-k checksum algorithm is assigned a checksum type - number of six (6). - -6.2.7. DES CBC Checksum - - The DES-MAC checksum is computed by prepending an eight octet - confounder to the plaintext, padding with zero-valued octets if - necessary to bring the length to a multiple of eight octets, - performing a DES CBC-mode encryption on the result by using the key - and an initialization vector of zero, taking the last block of the - ciphertext, prepending the same confounder, and encrypting the pair - by using DES in cipher-block-chaining (CBC) mode with a variant of - the key, where the variant is computed by eXclusive-ORing the key - with the constant 0xF0F0F0F0F0F0F0F0. The initialization vector - should be zero. The resulting checksum is 128 bits (sixteen octets) - long, 64 bits of which are redundant. This checksum is tamper-proof - and collision-proof. - - des-mac - --------------------------------------------------------------------- - associated des-cbc-md5, des-cbc-md4, des-cbc-crc - cryptosystem - - get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, - conf | des-mac(key, conf | msg | pad, ivec=0), - ivec=0) - - verify_mic decrypt, compute DES MAC using confounder, compare - - The des-mac checksum algorithm is assigned a checksum type number of - four (4). - -6.2.8. DES CBC Checksum Alternative - - The DES-MAC-K checksum is computed by performing a DES CBC-mode - encryption of the plaintext, with zero-valued padding bytes if - necessary to bring the length to a multiple of eight octets, and by - using the last block of the ciphertext as the checksum value. It is - keyed with an encryption key that is also used as the initialization - vector. The resulting checksum is 64 bits (eight octets) long. This - - - -Raeburn Standards Track [Page 27] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - checksum is tamper-proof and collision-proof. Note that this - checksum type is the old method for encoding the DESMAC checksum; it - is no longer recommended. - - des-mac-k - ---------------------------------------------------------------- - associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc - - get_mic des-mac(key, msg | pad, ivec=key) - - verify_mic compute MAC and compare - - The des-mac-k checksum algorithm is assigned a checksum type number - of five (5). - -6.3. Triple-DES Based Encryption and Checksum Types - - This encryption and checksum type pair is based on the Triple DES - cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message - authentication algorithm. - - A Triple DES key is the concatenation of three DES keys as described - above for des-cbc-md5. A Triple DES key is generated from random - data by creating three DES keys from separate sequences of random - data. - - Encrypted data using this type must be generated as described in - section 5.3. If the length of the input data is not a multiple of - the block size, zero-valued octets must be used to pad the plaintext - to the next eight-octet boundary. The confounder must be eight - random octets (one block). - - The simplified profile for Triple DES, with key derivation as defined - in section 5, is as follows: - - des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd - ------------------------------------------------ - protocol key format 24 bytes, parity in low - bit of each - - key-generation seed 21 bytes - length - - - - - - - - - -Raeburn Standards Track [Page 28] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd - ------------------------------------------------ - hash function SHA-1 - - HMAC output size 160 bits - - message block size 8 bytes - - default string-to-key empty string - params - - encryption and triple-DES encrypt and - decryption functions decrypt, in outer-CBC - mode (cipher block size - 8 octets) - - key generation functions: - - random-to-key DES3random-to-key (see - below) - - string-to-key DES3string-to-key (see - below) - - The des3-cbc-hmac-sha1-kd encryption type is assigned the value - sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a - checksum type number of twelve (12). - -6.3.1. Triple DES Key Production (random-to-key, string-to-key) - - The 168 bits of random key data are converted to a protocol key value - as follows. First, the 168 bits are divided into three groups of 56 - bits, which are expanded individually into 64 bits as follows: - - DES3random-to-key: - 1 2 3 4 5 6 7 p - 9 10 11 12 13 14 15 p - 17 18 19 20 21 22 23 p - 25 26 27 28 29 30 31 p - 33 34 35 36 37 38 39 p - 41 42 43 44 45 46 47 p - 49 50 51 52 53 54 55 p - 56 48 40 32 24 16 8 p - - The "p" bits are parity bits computed over the data bits. The output - of the three expansions, each corrected to avoid "weak" and "semi- - weak" keys as in section 6.2, are concatenated to form the protocol - key value. - - - -Raeburn Standards Track [Page 29] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - The string-to-key function is used to transform UTF-8 passwords into - DES3 keys. The DES3 string-to-key function relies on the "N-fold" - algorithm and DK function, described in section 5. - - The n-fold algorithm is applied to the password string concatenated - with a salt value. For 3-key triple DES, the operation will involve - a 168-fold of the input password string, to generate an intermediate - key, from which the user's long-term key will be derived with the DK - function. The DES3 string-to-key function is shown here in - pseudocode: - - DES3string-to-key(passwordString, salt, params) - if (params != emptyString) - error("invalid params"); - s = passwordString + salt - tmpKey = random-to-key(168-fold(s)) - key = DK (tmpKey, KerberosConstant) - - Weak key checking is performed in the random-to-key and DK - operations. The KerberosConstant value is the byte string {0x6b 0x65 - 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII - encoding for the string "kerberos". - -7. Use of Kerberos Encryption Outside This Specification - - Several Kerberos-based application protocols and preauthentication - systems have been designed and deployed that perform encryption and - message integrity checks in various ways. Although in some cases - there may be good reason for specifying these protocols in terms of - specific encryption or checksum algorithms, we anticipate that in - many cases this will not be true, and more generic approaches - independent of particular algorithms will be desirable. Rather than - have each protocol designer reinvent schemes for protecting data, - using multiple keys, etc., we have attempted to present in this - section a general framework that should be sufficient not only for - the Kerberos protocol itself but also for many preauthentication - systems and application protocols, while trying to avoid some of the - assumptions that can work their way into such protocol designs. - - Some problematic assumptions we've seen (and sometimes made) include - the following: a random bitstring is always valid as a key (not true - for DES keys with parity); the basic block encryption chaining mode - provides no integrity checking, or can easily be separated from such - checking (not true for many modes in development that do both - simultaneously); a checksum for a message always results in the same - value (not true if a confounder is incorporated); an initial vector - is used (may not be true if a block cipher in CBC mode is not in - use). - - - -Raeburn Standards Track [Page 30] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - Although such assumptions the may hold for any given set of - encryption and checksum algorithms, they may not be true of the next - algorithms to be defined, leaving the application protocol unable to - make use of those algorithms without updates to its specification. - - The Kerberos protocol uses only the attributes and operations - described in sections 3 and 4. Preauthentication systems and - application protocols making use of Kerberos are encouraged to use - them as well. The specific key and string-to-key parameters should - generally be treated as opaque. Although the string-to-key - parameters are manipulated as an octet string, the representation for - the specific key structure is implementation defined; it may not even - be a single object. - - We don't recommend doing so, but some application protocols will - undoubtedly continue to use the key data directly, even if only in - some of the currently existing protocol specifications. An - implementation intended to support general Kerberos applications may - therefore need to make the key data available, as well as the - attributes and operations described in sections 3 and 4 [8]. - -8. Assigned Numbers - - The following encryption-type numbers are already assigned or - reserved for use in Kerberos and related protocols. - - encryption type etype section or comment - ----------------------------------------------------------------- - des-cbc-crc 1 6.2.3 - des-cbc-md4 2 6.2.2 - des-cbc-md5 3 6.2.1 - [reserved] 4 - des3-cbc-md5 5 - [reserved] 6 - des3-cbc-sha1 7 - dsaWithSHA1-CmsOID 9 (pkinit) - md5WithRSAEncryption-CmsOID 10 (pkinit) - sha1WithRSAEncryption-CmsOID 11 (pkinit) - rc2CBC-EnvOID 12 (pkinit) - rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) - rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) - des-ede3-cbc-Env-OID 15 (pkinit) - des3-cbc-sha1-kd 16 6.3 - aes128-cts-hmac-sha1-96 17 [KRB5-AES] - aes256-cts-hmac-sha1-96 18 [KRB5-AES] - rc4-hmac 23 (Microsoft) - rc4-hmac-exp 24 (Microsoft) - subkey-keymaterial 65 (opaque; PacketCable) - - - -Raeburn Standards Track [Page 31] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - (The "des3-cbc-sha1" assignment is a deprecated version using no key - derivation. It should not be confused with des3-cbc-sha1-kd.) - - Several numbers have been reserved for use in encryption systems not - defined here. Encryption-type numbers have unfortunately been - overloaded on occasion in Kerberos-related protocols, so some of the - reserved numbers do not and will not correspond to encryption systems - fitting the profile presented here. - - The following checksum-type numbers are assigned or reserved. As - with encryption-type numbers, some overloading of checksum numbers - has occurred. - - Checksum type sumtype checksum section or - value size reference - --------------------------------------------------------------------- - CRC32 1 4 6.1.3 - rsa-md4 2 16 6.1.2 - rsa-md4-des 3 24 6.2.5 - des-mac 4 16 6.2.7 - des-mac-k 5 8 6.2.8 - rsa-md4-des-k 6 16 6.2.6 - rsa-md5 7 16 6.1.1 - rsa-md5-des 8 24 6.2.4 - rsa-md5-des3 9 24 ?? - sha1 (unkeyed) 10 20 ?? - hmac-sha1-des3-kd 12 20 6.3 - hmac-sha1-des3 13 20 ?? - sha1 (unkeyed) 14 20 ?? - hmac-sha1-96-aes128 15 20 [KRB5-AES] - hmac-sha1-96-aes256 16 20 [KRB5-AES] - [reserved] 0x8003 ? [GSS-KRB5] - - Encryption and checksum-type numbers are signed 32-bit values. Zero - is invalid, and negative numbers are reserved for local use. All - standardized values must be positive. - -9. Implementation Notes - - The "interface" described here is the minimal information that must - be defined to make a cryptosystem useful within Kerberos in an - interoperable fashion. The use of functional notation used in some - places is not an attempt to define an API for cryptographic - functionality within Kerberos. Actual implementations providing - clean APIs will probably make additional information available, that - could be derived from a specification written to the framework given - here. For example, an application designer may wish to determine the - largest number of bytes that can be encrypted without overflowing a - - - -Raeburn Standards Track [Page 32] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - certain size output buffer or conversely, the maximum number of bytes - that might be obtained by decrypting a ciphertext message of a given - size. (In fact, an implementation of the GSS-API Kerberos mechanism - [GSS-KRB5] will require some of these.) - - The presence of a mechanism in this document should not be taken to - indicate that it must be implemented for compliance with any - specification; required mechanisms will be specified elsewhere. - Indeed, some of the mechanisms described here for backward - compatibility are now considered rather weak for protecting critical - data. - -10. Security Considerations - - Recent years have brought so many advancements in large-scale attacks - capability against DES that it is no longer considered a strong - encryption mechanism. Triple-DES is generally preferred in its - place, despite its poorer performance. See [ESP-DES] for a summary - of some of the potential attacks and [EFF-DES] for a detailed - discussion of the implementation of particular attacks. However, - most Kerberos implementations still have DES as their primary - interoperable encryption type. - - DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of - single-DES here avoids them. However, DES also has 48 'possibly- - weak' keys [Schneier96] (note that the tables in many editions of the - reference contains errors) that are not avoided. - - DES weak keys have the property that E1(E1(P)) = P (where E1 denotes - encryption of a single block with key 1). DES semi-weak keys, or - "dual" keys, are pairs of keys with the property that E1(P) = D2(P), - and thus E2(E1(P)) = P. Because of the use of CBC mode and the - leading random confounder, however, these properties are unlikely to - present a security problem. - - Many of the choices concerning when to perform weak-key corrections - relate more to compatibility with existing implementations than to - any risk analysis. - - Although checks are also done for the component DES keys in a - triple-DES key, the nature of the weak keys make it extremely - unlikely that they will weaken the triple-DES encryption. It is only - slightly more likely than having the middle of the three sub-keys - match one of the other two, which effectively converts the encryption - to single-DES - a case we make no effort to avoid. - - - - - - -Raeburn Standards Track [Page 33] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - The true CRC-32 checksum is not collision-proof; an attacker could - use a probabilistic chosen-plaintext attack to generate a valid - message even if a confounder is used [SG92]. The use of collision- - proof checksums is of course recommended for environments where such - attacks represent a significant threat. The "simplifications" (read: - bugs) introduced when CRC-32 was implemented for Kerberos cause - leading zeros effectively to be ignored, so messages differing only - in leading zero bits will have the same checksum. - - [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. - Unlike [IPSEC-HMAC], the triple-DES specification here does not use - the suggested truncation of the HMAC output. As pointed out in - [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash - function, which is a criterion of HMAC. [HMAC-TEST] contains test - vectors for HMAC-SHA-1. - - The mit_des_string_to_key function was originally constructed with - the assumption that all input would be ASCII; it ignores the top bit - of each input byte. Folding with XOR is also not an especially good - mixing mechanism for preserving randomness. - - The n-fold function used in the string-to-key operation for des3- - cbc-hmac-sha1-kd was designed to cause each bit of input to - contribute equally to the output. It was not designed to maximize or - equally distribute randomness in the input, and conceivably - randomness may be lost in cases of partially structured input. This - should only be an issue for highly structured passwords, however. - - [RFC1851] discusses the relative strength of triple-DES encryption. - The relatively slow speed of triple-DES encryption may also be an - issue for some applications. - - [Bellovin91] suggests that analyses of encryption schemes include a - model of an attacker capable of submitting known plaintexts to be - encrypted with an unknown key, as well as be able to perform many - types of operations on known protocol messages. Recent experiences - with the chosen-plaintext attacks on Kerberos version 4 bear out the - value of this suggestion. - - The use of unkeyed encrypted checksums, such as those used in the - single-DES cryptosystems specified in [Kerb1510], allows for cut- - and-paste attacks, especially if a confounder is not used. In - addition, unkeyed encrypted checksums are vulnerable to chosen- - plaintext attacks: An attacker with access to an encryption oracle - can easily encrypt the required unkeyed checksum along with the - - - - - - -Raeburn Standards Track [Page 34] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - chosen plaintext. [Bellovin99] These weaknesses, combined with a - common implementation design choice described below, allow for a - cross-protocol attack from version 4 to version 5. - - The use of a random confounder is an important means to prevent an - attacker from making effective use of protocol exchanges as an - encryption oracle. In Kerberos version 4, the encryption of constant - plaintext to constant ciphertext makes an effective encryption oracle - for an attacker. The use of random confounders in [Kerb1510] - frustrates this sort of chosen-plaintext attack. - - Using the same key for multiple purposes can enable or increase the - scope of chosen-plaintext attacks. Some software that implements - both versions 4 and 5 of the Kerberos protocol uses the same keys for - both versions. This enables the encryption oracle of version 4 to be - used to attack version 5. Vulnerabilities to attacks such as this - cross-protocol attack make it unwise to use a key for multiple - purposes. - - This document, like the Kerberos protocol, does not address limiting - the amount of data a key may be used with to a quantity based on the - robustness of the algorithm or size of the key. It is assumed that - any defined algorithms and key sizes will be strong enough to support - very large amounts of data, or they will be deprecated once - significant attacks are known. - - This document also places no bounds on the amount of data that can be - handled in various operations. To avoid denial of service attacks, - implementations will probably seek to restrict message sizes at some - higher level. - -11. IANA Considerations - - Two registries for numeric values have been created: Kerberos - Encryption Type Numbers and Kerberos Checksum Type Numbers. These - are signed values ranging from -2147483648 to 2147483647. Positive - values should be assigned only for algorithms specified in accordance - with this specification for use with Kerberos or related protocols. - Negative values are for private use; local and experimental - algorithms should use these values. Zero is reserved and may not be - assigned. - - Positive encryption- and checksum-type numbers may be assigned - following either of two policies described in [BCP26]. - - Standards-track specifications may be assigned values under the - Standards Action policy. - - - - -Raeburn Standards Track [Page 35] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - Specifications in non-standards track RFCs may be assigned values - after Expert Review. A non-IETF specification may be assigned values - by publishing an Informational or standards-track RFC referencing the - external specification; that specification must be public and - published in some permanent record, much like the IETF RFCs. It is - highly desirable, though not required, that the full specification be - published as an IETF RFC. - - Smaller encryption type values should be used for IETF standards- - track mechanisms, and much higher values (16777216 and above) for - other mechanisms. (Rationale: In the Kerberos ASN.1 encoding, - smaller numbers encode to smaller octet sequences, so this favors - standards-track mechanisms with slightly smaller messages.) Aside - from that guideline, IANA may choose numbers as it sees fit. - - Internet-Draft specifications should not include values for - encryption- and checksum-type numbers. Instead, they should indicate - that values would be assigned by IANA when the document is approved - as an RFC. For development and interoperability testing, values in - the private-use range (negative values) may be used but should not be - included in the draft specification. - - Each registered value should have an associated unique reference - name. The lists given in section 8 were used to create the initial - registry; they include reservations for specifications in progress in - parallel with this document, and certain other values believed to - already be in use. - -12. Acknowledgements - - This document is an extension of the encryption specification - included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much - of the text of the background, concepts, and DES specifications is - drawn directly from that document. - - The abstract framework presented in this document was put together by - Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, - and Tom Yu, and the details were refined several times based on - comments from John Brezak and others. - - Marc Horowitz wrote the original specification of triple-DES and key - derivation in a pair of Internet-Drafts (under the names draft- - horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that - were later folded into a draft revision of [Kerb1510], from which - this document was later split off. - - - - - - -Raeburn Standards Track [Page 36] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - Tom Yu provided the text describing the modifications to the standard - CRC algorithm as Kerberos implementations actually use it, and some - of the text in the Security Considerations section. - - Miroslav Jurisic provided information for one of the UTF-8 test cases - for the string-to-key functions. - - Marcus Watts noticed some errors in earlier versions and pointed out - that the simplified profile could easily be modified to support - cipher text stealing modes. - - Simon Josefsson contributed some clarifications to the DES "CBC - checksum" and string-to-key and weak key descriptions, and some test - vectors. - - Simon Josefsson, Louis LeVay, and others also caught some errors in - earlier versions of this document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Raeburn Standards Track [Page 37] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - -A. Test Vectors - - This section provides test vectors for various functions defined or - described in this document. For convenience, most inputs are ASCII - strings, though some UTF-8 samples are provided for string-to-key - functions. Keys and other binary data are specified as hexadecimal - strings. - -A.1. n-fold - - The n-fold function is defined in section 5.1. As noted there, the - sample vector in the original paper defining the algorithm appears to - be incorrect. Here are some test cases provided by Marc Horowitz and - Simon Josefsson: - - 64-fold("012345") = - 64-fold(303132333435) = be072631276b1955 - - 56-fold("password") = - 56-fold(70617373776f7264) = 78a07b6caf85fa - - 64-fold("Rough Consensus, and Running Code") = - 64-fold(526f75676820436f6e73656e7375732c20616e642052756e - 6e696e6720436f6465) = bb6ed30870b7f0e0 - - 168-fold("password") = - 168-fold(70617373776f7264) = - 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e - - 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") - 192-fold(4d41535341434856534554545320494e5354495456544520 - 4f4620544543484e4f4c4f4759) = - db3b0d8f0b061e603282b308a50841229ad798fab9540c1b - - 168-fold("Q") = - 168-fold(51) = - 518a54a2 15a8452a 518a54a2 15a8452a - 518a54a2 15 - - 168-fold("ba") = - 168-fold(6261) = - fb25d531 ae897449 9f52fd92 ea9857c4 - ba24cf29 7e - - Here are some additional values corresponding to folded values of the - string "kerberos"; the 64-bit form is used in the des3 string-to-key - (section 6.3.1). - - - - -Raeburn Standards Track [Page 38] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - 64-fold("kerberos") = - 6b657262 65726f73 - 128-fold("kerberos") = - 6b657262 65726f73 7b9b5b2b 93132b93 - 168-fold("kerberos") = - 8372c236 344e5f15 50cd0747 e15d62ca - 7a5a3bce a4 - 256-fold("kerberos") = - 6b657262 65726f73 7b9b5b2b 93132b93 - 5c9bdcda d95c9899 c4cae4de e6d6cae4 - - Note that the initial octets exactly match the input string when the - output length is a multiple of the input length. - -A.2. mit_des_string_to_key - - The function mit_des_string_to_key is defined in section 6.2. We - present here several test values, with some of the intermediate - results. The fourth test demonstrates the use of UTF-8 with three - characters. The last two tests are specifically constructed so as to - trigger the weak-key fixups for the intermediate key produced by - fan-folding; we have no test cases that cause such fixups for the - final key. - -UTF-8 encodings used in test vector: -eszett U+00DF C3 9F s-caron U+0161 C5 A1 -c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E - -Test vector: - -salt: "ATHENA.MIT.EDUraeburn" - 415448454e412e4d49542e4544557261656275726e -password: "password" 70617373776f7264 -fan-fold result: c01e38688ac86c2e -intermediate key: c11f38688ac86d2f -DES key: cbc22fae235298e3 - -salt: "WHITEHOUSE.GOVdanny" - 5748495445484f5553452e474f5664616e6e79 -password: "potatoe" 706f7461746f65 -fan-fold result: a028944ee63c0416 -intermediate key: a129944fe63d0416 -DES key: df3d32a74fd92a01 - -salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 -password: g-clef (U+1011E) f09d849e -fan-fold result: 3c4a262c18fab090 -intermediate key: 3d4a262c19fbb091 - - - -Raeburn Standards Track [Page 39] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - -DES key: 4ffb26bab0cd9413 - -salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107) - 415448454e412e4d49542e4544554a757269c5a169c487 -password: eszett(U+00DF) - c39f -fan-fold result:b8f6c40e305afc9e -intermediate key: b9f7c40e315bfd9e -DES key: 62c81a5232b5e69d - -salt: "AAAAAAAA" 4141414141414141 -password: "11119999" 3131313139393939 -fan-fold result: e0e0e0e0f0f0f0f0 -intermediate key: e0e0e0e0f1f1f101 -DES key: 984054d0f1a73e31 - -salt: "FFFFAAAA" 4646464641414141 -password: "NNNN6666" 4e4e4e4e36363636 -fan-fold result: 1e1e1e1e0e0e0e0e -intermediate key: 1f1f1f1f0e0e0efe -DES key: c4bf6b25adf7a4f8 - - This trace provided by Simon Josefsson shows the intermediate - processing stages of one of the test inputs: - - string_to_key (des-cbc-md5, string, salt) - ;; string: - ;; `password' (length 8 bytes) - ;; 70 61 73 73 77 6f 72 64 - ;; salt: - ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) - ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 - ;; 65 62 75 72 6e - des_string_to_key (string, salt) - ;; String: - ;; `password' (length 8 bytes) - ;; 70 61 73 73 77 6f 72 64 - ;; Salt: - ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) - ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 - ;; 65 62 75 72 6e - odd = 1; - s = string | salt; - tempstring = 0; /* 56-bit string */ - pad(s); /* with nulls to 8 byte boundary */ - ;; s = pad(string|salt): - ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00' - ;; (length 32 bytes) - - - -Raeburn Standards Track [Page 40] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d - ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00 - for (8byteblock in s) { - ;; loop iteration 0 - ;; 8byteblock: - ;; `password' (length 8 bytes) - ;; 70 61 73 73 77 6f 72 64 - ;; 01110000 01100001 01110011 01110011 01110111 01101111 - ;; 01110010 01100100 - 56bitstring = removeMSBits(8byteblock); - ;; 56bitstring: - ;; 1110000 1100001 1110011 1110011 1110111 1101111 - ;; 1110010 1100100 - if (odd == 0) reverse(56bitstring); ;; odd=1 - odd = ! odd - tempstring = tempstring XOR 56bitstring; - ;; tempstring - ;; 1110000 1100001 1110011 1110011 1110111 1101111 - ;; 1110010 1100100 - - for (8byteblock in s) { - ;; loop iteration 1 - ;; 8byteblock: - ;; `ATHENA.M' (length 8 bytes) - ;; 41 54 48 45 4e 41 2e 4d - ;; 01000001 01010100 01001000 01000101 01001110 01000001 - ;; 00101110 01001101 - 56bitstring = removeMSBits(8byteblock); - ;; 56bitstring: - ;; 1000001 1010100 1001000 1000101 1001110 1000001 - ;; 0101110 1001101 - if (odd == 0) reverse(56bitstring); ;; odd=0 - reverse(56bitstring) - ;; 56bitstring after reverse - ;; 1011001 0111010 1000001 0111001 1010001 0001001 - ;; 0010101 1000001 - odd = ! odd - tempstring = tempstring XOR 56bitstring; - ;; tempstring - ;; 0101001 1011011 0110010 1001010 0100110 1100110 - ;; 1100111 0100101 - - for (8byteblock in s) { - ;; loop iteration 2 - ;; 8byteblock: - ;; `IT.EDUra' (length 8 bytes) - ;; 49 54 2e 45 44 55 72 61 - ;; 01001001 01010100 00101110 01000101 01000100 01010101 - - - -Raeburn Standards Track [Page 41] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - ;; 01110010 01100001 - 56bitstring = removeMSBits(8byteblock); - ;; 56bitstring: - ;; 1001001 1010100 0101110 1000101 1000100 1010101 - ;; 1110010 1100001 - if (odd == 0) reverse(56bitstring); ;; odd=1 - odd = ! odd - tempstring = tempstring XOR 56bitstring; - ;; tempstring - ;; 1100000 0001111 0011100 0001111 1100010 0110011 - ;; 0010101 1000100 - - for (8byteblock in s) { - ;; loop iteration 3 - ;; 8byteblock: - ;; `eburn\x00\x00\x00' (length 8 bytes) - ;; 65 62 75 72 6e 00 00 00 - ;; 01100101 01100010 01110101 01110010 01101110 00000000 - ;; 00000000 00000000 - 56bitstring = removeMSBits(8byteblock); - ;; 56bitstring: - ;; 1100101 1100010 1110101 1110010 1101110 0000000 - ;; 0000000 0000000 - if (odd == 0) reverse(56bitstring); ;; odd=0 - reverse(56bitstring) - ;; 56bitstring after reverse - ;; 0000000 0000000 0000000 0111011 0100111 1010111 - ;; 0100011 1010011 - odd = ! odd - tempstring = tempstring XOR 56bitstring; - ;; tempstring - ;; 1100000 0001111 0011100 0110100 1000101 1100100 - ;; 0110110 0010111 - - for (8byteblock in s) { - } - ;; for loop terminated - - tempkey = key_correction(add_parity_bits(tempstring)); - ;; tempkey - ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) - ;; c1 1f 38 68 8a c8 6d 2f - ;; 11000001 00011111 00111000 01101000 10001010 11001000 - ;; 01101101 00101111 - - key = key_correction(DES-CBC-check(s,tempkey)); - ;; key - ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) - - - -Raeburn Standards Track [Page 42] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - ;; cb c2 2f ae 23 52 98 e3 - ;; 11001011 11000010 00101111 10101110 00100011 01010010 - ;; 10011000 11100011 - - ;; string_to_key key: - ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) - ;; cb c2 2f ae 23 52 98 e3 - -A.3. DES3 DR and DK - - These tests show the derived-random and derived-key values for the - des3-hmac-sha1-kd encryption scheme, using the DR and DK functions - defined in section 6.3.1. The input keys were randomly generated; - the usage values are from this specification. - - key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 - usage: 0000000155 - DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 - DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd - - key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 - usage: 00000001aa - DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 - DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 - - key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc - usage: 0000000155 - DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb - DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf - - key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 - usage: 00000001aa - DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 - DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e - - key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb - usage: 6b65726265726f73 ("kerberos") - DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da - DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 - - key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da - usage: 0000000155 - DR: 348056ec98fcc517171d2b4d7a9493af482d999175 - DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 - - key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c - usage: 00000001aa - DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 - - - -Raeburn Standards Track [Page 43] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 - - key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 - usage: 0000000155 - DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a - DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 - - key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 - usage: 00000001aa - DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec - DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d - -A.4. DES3string_to_key - - These are the keys generated for some of the above input strings for - triple-DES with key derivation as defined in section 6.3.1. - - salt: "ATHENA.MIT.EDUraeburn" - passwd: "password" - key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e - - salt: "WHITEHOUSE.GOVdanny" - passwd: "potatoe" - key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a - - salt: "EXAMPLE.COMbuckaroo" - passwd: "penny" - key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a - - salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" - + c-acute(U+0107) - passwd: eszett(U+00DF) - key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 - - salt: "EXAMPLE.COMpianist" - passwd: g-clef(U+1011E) - key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 - -A.5. Modified CRC-32 - - Below are modified-CRC32 values for various ASCII and octet strings. - Only the printable ASCII characters are checksummed, without a C- - style trailing zero-valued octet. The 32-bit modified CRC and the - sequence of output bytes as used in Kerberos are shown. (The octet - values are separated here to emphasize that they are octet values and - not 32-bit numbers, which will be the most convenient form for - manipulation in some implementations. The bit and byte order used - - - - -Raeburn Standards Track [Page 44] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - internally for such a number is irrelevant; the octet sequence - generated is what is important.) - - mod-crc-32("foo") = 33 bc 32 73 - mod-crc-32("test0123456789") = d6 88 3e b8 - mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 - mod-crc-32(8000) = 4b 98 83 3b - mod-crc-32(0008) = 32 88 db 0e - mod-crc-32(0080) = 20 83 b8 ed - mod-crc-32(80) = 20 83 b8 ed - mod-crc-32(80000000) = 3b b6 59 ed - mod-crc-32(00000001) = 96 30 07 77 - -B. Significant Changes from RFC 1510 - - The encryption and checksum mechanism profiles are new. The old - specification defined a few operations for various mechanisms but - didn't outline what abstract properties should be required of new - mechanisms, or how to ensure that a mechanism specification is - complete enough for interoperability between implementations. The - new profiles differ from the old specification in a few ways: - - Some message definitions in [Kerb1510] could be read as permitting - the initial vector to be specified by the application; the text - was too vague. It is explicitly not permitted in this - specification. Some encryption algorithms may not use - initialization vectors, so relying on chosen, secret - initialization vectors for security is unwise. Also, the - prepended confounder in the existing algorithms is roughly - equivalent to a per-message initialization vector that is revealed - in encrypted form. However, carrying state across from one - encryption to another is explicitly permitted through the opaque - "cipher state" object. - - The use of key derivation is new. - - Several new methods are introduced, including generation of a key - in wire-protocol format from random input data. - - The means for influencing the string-to-key algorithm are laid out - more clearly. - - Triple-DES support is new. - - The pseudo-random function is new. - - The des-cbc-crc, DES string-to-key and CRC descriptions have been - updated to align them with existing implementations. - - - -Raeburn Standards Track [Page 45] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - [Kerb1510] did not indicate what character set or encoding might be - used for pass phrases and salts. - - In [Kerb1510], key types, encryption algorithms, and checksum - algorithms were only loosely associated, and the association was not - well described. In this specification, key types and encryption - algorithms have a one-to-one correspondence, and associations between - encryption and checksum algorithms are described so that checksums - can be computed given negotiated keys, without requiring further - negotiation for checksum types. - -Notes - - [1] Although Message Authentication Code (MAC) or Message Integrity - Check (MIC) would be more appropriate terms for many of the uses - in this document, we continue to use the term checksum for - historical reasons. - - [2] Extending CBC mode across messages would be one obvious example - of this chaining. Another might be the use of counter mode, with - a counter randomly initialized and attached to the ciphertext; a - second message could continue incrementing the counter when - chaining the cipher state, thus avoiding having to transmit - another counter value. However, this chaining is only useful for - uninterrupted, ordered sequences of messages. - - [3] In the case of Kerberos, the encrypted objects will generally be - ASN.1 DER encodings, which contain indications of their length in - the first few octets. - - [4] As of the time of this writing, new modes of operation have been - proposed, some of which may permit encryption and integrity - protection simultaneously. After some of these proposals have - been subjected to adequate analysis, we may wish to formulate a - new simplified profile based on one of them. - - [5] It should be noted that the sample vector in appendix B.2 of the - original paper appears to be incorrect. Two independent - implementations from the specification (one in C by Marc - Horowitz, and another in Scheme by Bill Sommerfeld) agree on a - value different from that in [Blumenthal96]. - - [6] For example, in MIT's implementation of [Kerb1510], the rsa-md5 - unkeyed checksum of application data may be included in an - authenticator encrypted in a service's key. - - [7] Using a variant of the key limits the use of a key to a - particular function, separating the functions of generating a - - - -Raeburn Standards Track [Page 46] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - checksum from other encryption performed using the session key. - The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains - key parity. The properties of DES precluded the use of the - complement. The same constant is used for similar purpose in the - Message Integrity Check in the Privacy Enhanced Mail standard. - - [8] Perhaps one of the more common reasons for directly performing - encryption is direct control over the negotiation and to select a - "sufficiently strong" encryption algorithm (whatever that means - in the context of a given application). Although Kerberos - directly provides no direct facility for negotiating encryption - types between the application client and server, there are other - means to accomplish similar goals (for example, requesting only - "strong" session key types from the KDC, and assuming that the - type actually returned by the KDC will be understood and - supported by the application server). - -Normative References - - [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing - an IANA Considerations Section in RFCs", BCP 26, RFC - 2434, October 1998. - - [Bellare98] Bellare, M., Desai, A., Pointcheval, D., and P. - Rogaway, "Relations Among Notions of Security for - Public-Key Encryption Schemes". Extended abstract - published in Advances in Cryptology-Crypto 98 - Proceedings, Lecture Notes in Computer Science Vol. - 1462, H. Krawcyzk ed., Springer-Verlag, 1998. - - [Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule - for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96, - 1996. - - [CRC] International Organization for Standardization, "ISO - Information Processing Systems - Data Communication - - High-Level Data Link Control Procedure - Frame - Structure," IS 3309, 3rd Edition, October 1984. - - [DES77] National Bureau of Standards, U.S. Department of - Commerce, "Data Encryption Standard," Federal - Information Processing Standards Publication 46, - Washington, DC, 1977. - - - - - - - - -Raeburn Standards Track [Page 47] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - [DESI81] National Bureau of Standards, U.S. Department of - Commerce, "Guidelines for implementing and using NBS - Data Encryption Standard," Federal Information - Processing Standards Publication 74, Washington, DC, - 1981. - - [DESM80] National Bureau of Standards, U.S. Department of - Commerce, "DES Modes of Operation," Federal - Information Processing Standards Publication 81, - Springfield, VA, December 1980. - - [Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable - cryptography", Proceedings of the 23rd Annual - Symposium on Theory of Computing, ACM, 1991. - - [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES) - Encryption for Kerberos 5", RFC 3962, February 2005. - - [MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC - 1320, April 1992. - - [MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC - 1321, April 1992. - - [SG92] Stubblebine, S. and V. D. Gligor, "On Message - Integrity in Cryptographic Protocols," in Proceedings - of the IEEE Symposium on Research in Security and - Privacy, Oakland, California, May 1992. - -Informative References - - [Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the - Kerberos Authentication System", in Proceedings of the - Winter 1991 Usenix Security Conference, January, 1991. - - [Bellovin99] Bellovin, S. M. and D. Atkins, private communications, - 1999. - - [EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets - of Encryption Research, Wiretap Politics, and Chip - Design", O'Reilly & Associates, Inc., May 1998. - - [ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher - Algorithm With Explicit IV", RFC 2405, November 1998. - - - -Raeburn Standards Track [Page 48] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - - [GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", - RFC 1964, June 1996. - - [HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and - HMAC-SHA-1", RFC 2202, September 1997. - - [IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 - within ESP and AH", RFC 2404, November 1998. - - [Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", Work in - Progress, September 2004. - - [Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network - Authentication Service (V5)", RFC 1510, September - 1993. - - [RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5- - CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October - 1996. - - [RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple - DES Transform", RFC 1851, September 1995. - - [Schneier96] Schneier, B., "Applied Cryptography Second Edition", - John Wiley & Sons, New York, NY, 1996. ISBN 0-471- - 12845-7. - -Editor's Address - - Kenneth Raeburn - Massachusetts Institute of Technology - 77 Massachusetts Avenue - Cambridge, MA 02139 - - EMail: raeburn@mit.edu - - - - - - - - - - - - - - - -Raeburn Standards Track [Page 49] - -RFC 3961 Encryption and Checksum Specifications February 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Raeburn Standards Track [Page 50] - diff --git a/doc/krb5-protocol/rfc3962.txt b/doc/krb5-protocol/rfc3962.txt deleted file mode 100644 index 762beedbdb..0000000000 --- a/doc/krb5-protocol/rfc3962.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group K. Raeburn -Request for Comments: 3962 MIT -Category: Standards Track February 2005 - - - Advanced Encryption Standard (AES) Encryption for Kerberos 5 - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - The United States National Institute of Standards and Technology - (NIST) has chosen a new Advanced Encryption Standard (AES), which is - significantly faster and (it is believed) more secure than the old - Data Encryption Standard (DES) algorithm. This document is a - specification for the addition of this algorithm to the Kerberos - cryptosystem suite. - -1. Introduction - - This document defines encryption key and checksum types for Kerberos - 5 using the AES algorithm recently chosen by NIST. These new types - support 128-bit block encryption and key sizes of 128 or 256 bits. - - Using the "simplified profile" of [KCRYPTO], we can define a pair of - encryption and checksum schemes. AES is used with ciphertext - stealing to avoid message expansion, and SHA-1 [SHA1] is the - associated checksum function. - -2. Conventions used in this Document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, RFC 2119 - [KEYWORDS]. - - - - - - -Raeburn Standards Track [Page 1] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - -3. Protocol Key Representation - - The profile in [KCRYPTO] treats keys and random octet strings as - conceptually different. But since the AES key space is dense, we can - use any bit string of appropriate length as a key. We use the byte - representation for the key described in [AES], where the first bit of - the bit string is the high bit of the first byte of the byte string - (octet string) representation. - -4. Key Generation from Pass Phrases or Random Data - - Given the above format for keys, we can generate keys from the - appropriate amounts of random data (128 or 256 bits) by simply - copying the input string. - - To generate an encryption key from a pass phrase and salt string, we - use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters - indicated below, to generate an intermediate key (of the same length - as the desired final key), which is then passed into the DK function - with the 8-octet ASCII string "kerberos" as is done for des3-cbc- - hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function - produces a "random octet string", hence the application of the - random-to-key function even though it's effectively a simple identity - operation.) The resulting key is the user's long-term key for use - with the encryption algorithm in question. - - tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) - key = DK(tkey, "kerberos") - - The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the - passphrase and salt, as described in Appendix B.1 to PKCS#5. - - The number of iterations is specified by the string-to-key parameters - supplied. The parameter string is four octets indicating an unsigned - number in big-endian order. This is the number of iterations to be - performed. If the value is 00 00 00 00, the number of iterations to - be performed is 4,294,967,296 (2**32). (Thus the minimum expressible - iteration count is 1.) - - For environments where slower hardware is the norm, implementations - of protocols such as Kerberos may wish to limit the number of - iterations to prevent a spoofed response supplied by an attacker from - consuming lots of client-side CPU time; if such a limit is - implemented, it SHOULD be no less than 50,000. Even for environments - with fast hardware, 4 billion iterations is likely to take a fairly - long time; much larger bounds might still be enforced, and it might - be wise for implementations to permit interruption of this operation - by the user if the environment allows for it. - - - -Raeburn Standards Track [Page 2] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - If the string-to-key parameters are not supplied, the value used is - 00 00 10 00 (decimal 4,096, indicating 4,096 iterations). - - Note that this is not a requirement, nor even a recommendation, for - this value to be used in "optimistic preauthentication" (e.g., - attempting timestamp-based preauthentication using the user's long- - term key without having first communicated with the KDC) in the - absence of additional information, or as a default value for sites to - use for their principals' long-term keys in their Kerberos database. - It is simply the interpretation of the absence of the string-to-key - parameter field when the KDC has had an opportunity to provide it. - - Sample test vectors are given in Appendix B. - -5. Ciphertext Stealing - - Cipher block chaining is used to encrypt messages, with the initial - vector stored in the cipher state. Unlike previous Kerberos - cryptosystems, we use ciphertext stealing to handle the possibly - partial final block of the message. - - Ciphertext stealing is described on pages 195-196 of [AC], and - section 8 of [RC5]; it has the advantage that no message expansion is - done during encryption of messages of arbitrary sizes as is typically - done in CBC mode with padding. Some errata for [RC5] are listed in - Appendix A and are considered part of the ciphertext stealing - technique as used here. - - Ciphertext stealing, as defined in [RC5], assumes that more than one - block of plain text is available. If exactly one block is to be - encrypted, that block is simply encrypted with AES (also known as ECB - mode). Input smaller than one block is padded at the end to one - block; the values of the padding bits are unspecified. - (Implementations MAY use all-zero padding, but protocols MUST NOT - rely on the result being deterministic. Implementations MAY use - random padding, but protocols MUST NOT rely on the result not being - deterministic. Note that in most cases, the Kerberos encryption - profile will add a random confounder independent of this padding.) - - For consistency, ciphertext stealing is always used for the last two - blocks of the data to be encrypted, as in [RC5]. If the data length - is a multiple of the block size, this is equivalent to plain CBC mode - with the last two ciphertext blocks swapped. - - A test vector is given in Appendix B. - - - - - - -Raeburn Standards Track [Page 3] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - The initial vector carried out from one encryption for use in a - subsequent encryption is the next-to-last block of the encryption - output; this is the encrypted form of the last plaintext block. When - decrypting, the next-to-last block of the supplied ciphertext is - carried forward as the next initial vector. If only one ciphertext - block is available (decrypting one block, or encrypting one block or - less), then that one block is carried out instead. - -6. Kerberos Algorithm Profile Parameters - - This is a summary of the parameters to be used with the simplified - algorithm profile described in [KCRYPTO]: - - +--------------------------------------------------------------------+ - | protocol key format 128- or 256-bit string | - | | - | string-to-key function PBKDF2+DK with variable | - | iteration count (see | - | above) | - | | - | default string-to-key parameters 00 00 10 00 | - | | - | key-generation seed length key size | - | | - | random-to-key function identity function | - | | - | hash function, H SHA-1 | - | | - | HMAC output size, h 12 octets (96 bits) | - | | - | message block size, m 1 octet | - | | - | encryption/decryption functions, AES in CBC-CTS mode | - | E and D (cipher block size 16 | - | octets), with next-to- | - | last block (last block | - | if only one) as CBC-style | - | ivec | - +--------------------------------------------------------------------+ - - Using this profile with each key size gives us two each of encryption - and checksum algorithm definitions. - - - - - - - - - -Raeburn Standards Track [Page 4] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - -7. Assigned Numbers - - The following encryption type numbers are assigned: - - +--------------------------------------------------------------------+ - | encryption types | - +--------------------------------------------------------------------+ - | type name etype value key size | - +--------------------------------------------------------------------+ - | aes128-cts-hmac-sha1-96 17 128 | - | aes256-cts-hmac-sha1-96 18 256 | - +--------------------------------------------------------------------+ - - The following checksum type numbers are assigned: - - +--------------------------------------------------------------------+ - | checksum types | - +--------------------------------------------------------------------+ - | type name sumtype value length | - +--------------------------------------------------------------------+ - | hmac-sha1-96-aes128 15 96 | - | hmac-sha1-96-aes256 16 96 | - +--------------------------------------------------------------------+ - - These checksum types will be used with the corresponding encryption - types defined above. - -8. Security Considerations - - This new algorithm has not been around long enough to receive the - decades of intense analysis that DES has received. It is possible - that some weakness exists that has not been found by the - cryptographers analyzing these algorithms before and during the AES - selection process. - - The use of the HMAC function has drawbacks for certain pass phrase - lengths. For example, a pass phrase longer than the hash function - block size (64 bytes, for SHA-1) is hashed to a smaller size (20 - bytes) before applying the main HMAC algorithm. However, entropy is - generally sparse in pass phrases, especially in long ones, so this - may not be a problem in the rare cases of users with long pass - phrases. - - Also, generating a 256-bit key from a pass phrase of any length may - be deceptive, as the effective entropy in pass-phrase-derived key - cannot be nearly that large given the properties of the string-to-key - function described here. - - - - -Raeburn Standards Track [Page 5] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - The iteration count in PBKDF2 appears to be useful primarily as a - constant multiplier for the amount of work required for an attacker - using brute-force methods. Unfortunately, it also multiplies, by the - same amount, the work needed by a legitimate user with a valid - password. Thus the work factor imposed on an attacker (who may have - many powerful workstations at his disposal) must be balanced against - the work factor imposed on the legitimate user (who may have a PDA or - cell phone); the available computing power on either side increases - as time goes on, as well. A better way to deal with the brute-force - attack is through preauthentication mechanisms that provide better - protection of the user's long-term key. Use of such mechanisms is - out of the scope of this document. - - If a site does wish to use this means of protection against a brute- - force attack, the iteration count should be chosen based on the - facilities available to both attacker and legitimate user, and the - amount of work the attacker should be required to perform to acquire - the key or password. - - As an example: - - The author's tests on a 2GHz Pentium 4 system indicated that in - one second, nearly 90,000 iterations could be done, producing a - 256-bit key. This was using the SHA-1 assembly implementation - from OpenSSL, and a pre-release version of the PBKDF2 code for - MIT's Kerberos package, on a single system. No attempt was made - to do multiple hashes in parallel, so we assume an attacker doing - so can probably do at least 100,000 iterations per second -- - rounded up to 2**17, for ease of calculation. For simplicity, we - also assume the final AES encryption step costs nothing. - - Paul Leach estimates [LEACH] that a password-cracking dictionary - may have on the order of 2**21 entries, with capitalization, - punctuation, and other variations contributing perhaps a factor of - 2**11, giving a ballpark estimate of 2**32. - - Thus, for a known iteration count N and a known salt string, an - attacker with some number of computers comparable to the author's - would need roughly N*2**15 CPU seconds to convert the entire - dictionary plus variations into keys. - - An attacker using a dozen such computers for a month would have - roughly 2**25 CPU seconds available. So using 2**12 (4,096) - iterations would mean an attacker with a dozen such computers - dedicated to a brute-force attack against a single key (actually, - any password-derived keys sharing the same salt and iteration - - - - - -Raeburn Standards Track [Page 6] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - count) would process all the variations of the dictionary entries - in four months and, on average, would likely find the user's - password in two months. - - Thus, if this form of attack is of concern, users should be - required to change their passwords every few months, and an - iteration count a few orders of magnitude higher should be chosen. - Perhaps several orders of magnitude, as many users will tend to - use the shorter and simpler passwords (to the extent they can, - given a site's password quality checks) that the attacker would - likely try first. - - Since this estimate is based on currently available CPU power, the - iteration counts used for this mode of defense should be increased - over time, at perhaps 40%-60% each year or so. - - Note that if the attacker has a large amount of storage available, - intermediate results could be cached, saving a lot of work for the - next attack with the same salt and a greater number of iterations - than had been run at the point where the intermediate results were - saved. Thus, it would be wise to generate a new random salt - string when passwords are changed. The default salt string, - derived from the principal name, only protects against the use of - one dictionary of keys against multiple users. - - If the PBKDF2 iteration count can be spoofed by an intruder on the - network, and the limit on the accepted iteration count is very high, - the intruder may be able to introduce a form of denial of service - attack against the client by sending a very high iteration count, - causing the client to spend a great deal of CPU time computing an - incorrect key. - - An intruder spoofing the KDC reply, providing a low iteration count - and reading the client's reply from the network, may be able to - reduce the work needed in the brute-force attack outlined above. - Thus, implementations may seek to enforce lower bounds on the number - of iterations that will be used. - - Since threat models and typical end-user equipment will vary widely - from site to site, allowing site-specific configuration of such - bounds is recommended. - - Any benefit against other attacks specific to the HMAC or SHA-1 - algorithms is probably achieved with a fairly small number of - iterations. - - - - - - -Raeburn Standards Track [Page 7] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - In the "optimistic preauthentication" case mentioned in section 3, - the client may attempt to produce a key without first communicating - with the KDC. If the client has no additional information, it can - only guess as to the iteration count to be used. Even such - heuristics as "iteration count X was used to acquire tickets for the - same principal only N hours ago" can be wrong. Given the - recommendation above for increasing the iteration counts used over - time, it is impossible to recommend any specific default value for - this case; allowing site-local configuration is recommended. (If the - lower and upper bound checks described above are implemented, the - default count for optimistic preauthentication should be between - those bounds.) - - Ciphertext stealing mode, as it requires no additional padding in - most cases, will reveal the exact length of each message being - encrypted rather than merely bounding it to a small range of possible - lengths as in CBC mode. Such obfuscation should not be relied upon - at higher levels in any case; if the length must be obscured from an - outside observer, this should be done by intentionally varying the - length of the message to be encrypted. - -9. IANA Considerations - - Kerberos encryption and checksum type values used in section 7 were - previously reserved in [KCRYPTO] for the mechanisms defined in this - document. The registries have been updated to list this document as - the reference. - -10. Acknowledgements - - Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul - Leach, Marcus Watts, Larry Zhu, and others for feedback on earlier - versions of this document. - - - - - - - - - - - - - - - - - - -Raeburn Standards Track [Page 8] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - -A. Errata for RFC 2040 Section 8 - - (Copied from the RFC Editor's errata web site on July 8, 2004.) - - Reported By: Bob Baldwin; baldwin@plusfive.com - Date: Fri, 26 Mar 2004 06:49:02 -0800 - - In Section 8, Description of RC5-CTS, of the encryption method, - it says: - - 1. Exclusive-or Pn-1 with the previous ciphertext - block, Cn-2, to create Xn-1. - - It should say: - - 1. Exclusive-or Pn-1 with the previous ciphertext - block, Cn-2, to create Xn-1. For short messages where - Cn-2 does not exist, use IV. - - Reported By: Bob Baldwin; baldwin@plusfive.com - Date: Mon, 22 Mar 2004 20:26:40 -0800 - - In Section 8, first paragraph, second sentence says: - - This mode handles any length of plaintext and produces ciphertext - whose length matches the plaintext length. - - In Section 8, first paragraph, second sentence should read: - - This mode handles any length of plaintext longer than one - block and produces ciphertext whose length matches the - plaintext length. - - In Section 8, step 6 of the decryption method says: - - 6. Decrypt En to create Pn-1. - - In Section 8, step 6 of the decryption method should read: - - 6. Decrypt En and exclusive-or with Cn-2 to create Pn-1. - For short messages where Cn-2 does not exist, use the IV. - - - - - - - - - - -Raeburn Standards Track [Page 9] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - -B. Sample Test Vectors - - Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are - included below. - - Iteration count = 1 - Pass phrase = "password" - Salt = "ATHENA.MIT.EDUraeburn" - 128-bit PBKDF2 output: - cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 - 128-bit AES key: - 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 - 256-bit PBKDF2 output: - cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 - 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 - 256-bit AES key: - fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b - bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61 - - Iteration count = 2 - Pass phrase = "password" - Salt="ATHENA.MIT.EDUraeburn" - 128-bit PBKDF2 output: - 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d - 128-bit AES key: - c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 - 256-bit PBKDF2 output: - 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d - a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 - 256-bit AES key: - a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 - 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff - - Iteration count = 1200 - Pass phrase = "password" - Salt = "ATHENA.MIT.EDUraeburn" - 128-bit PBKDF2 output: - 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b - 128-bit AES key: - 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a - 256-bit PBKDF2 output: - 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b - a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 - 256-bit AES key: - 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 - 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a - - - - - -Raeburn Standards Track [Page 10] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - Iteration count = 5 - Pass phrase = "password" - Salt=0x1234567878563412 - 128-bit PBKDF2 output: - d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 - 128-bit AES key: - e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e - 256-bit PBKDF2 output: - d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 - 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee - 256-bit AES key: - 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c - ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 - (This test is based on values given in [PECMS].) - - Iteration count = 1200 - Pass phrase = (64 characters) - "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" - Salt="pass phrase equals block size" - 128-bit PBKDF2 output: - 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 - 128-bit AES key: - 59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed - 256-bit PBKDF2 output: - 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 - c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1 - 256-bit AES key: - 89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0 - 56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34 - - Iteration count = 1200 - Pass phrase = (65 characters) - "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" - Salt = "pass phrase exceeds block size" - 128-bit PBKDF2 output: - 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 - 128-bit AES key: - cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d - 256-bit PBKDF2 output: - 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 - 1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a - 256-bit AES key: - d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2 - 14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b - - - - - - - -Raeburn Standards Track [Page 11] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - Iteration count = 50 - Pass phrase = g-clef (0xf09d849e) - Salt = "EXAMPLE.COMpianist" - 128-bit PBKDF2 output: - 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 - 128-bit AES key: - f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 - 256-bit PBKDF2 output: - 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 - e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 - 256-bit AES key: - 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c - 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e - - Some test vectors for CBC with ciphertext stealing, using an initial - vector of all-zero. - - AES 128-bit key: - 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69 - - IV: - 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Input: - 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 - 0010: 20 - Output: - 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f - 0010: 97 - Next IV: - 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f - - IV: - 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Input: - 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 - 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 - Output: - 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 - 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 - Next IV: - 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 - - - - - - - - - - -Raeburn Standards Track [Page 12] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - IV: - 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Input: - 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 - 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 - Output: - 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 - 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 - Next IV: - 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 - - IV: - 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Input: - 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 - 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 - 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c - Output: - 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 - 0010: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e - 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 - Next IV: - 0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e - - IV: - 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Input: - 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 - 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 - 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 - Output: - 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 - 0010: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 - 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 - Next IV: - 0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 - - - - - - - - - - - - - - - -Raeburn Standards Track [Page 13] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - - IV: - 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - Input: - 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 - 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 - 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 - 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e - Output: - 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 - 0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 - 0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 - 0030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 - Next IV: - 0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 - -Normative References - - [AC] Schneier, B., "Applied Cryptography", second edition, John - Wiley and Sons, New York, 1996. - - [AES] National Institute of Standards and Technology, U.S. - Department of Commerce, "Advanced Encryption Standard", - Federal Information Processing Standards Publication 197, - Washington, DC, November 2001. - - [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for - Kerberos 5", RFC 3961, February 2005. - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography - Specification Version 2.0", RFC 2898, September 2000. - - [RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, - and RC5-CTS Algorithms", RFC 2040, October 1996. - - [SHA1] National Institute of Standards and Technology, U.S. - Department of Commerce, "Secure Hash Standard", Federal - Information Processing Standards Publication 180-1, - Washington, DC, April 1995. - - - - - - - - - - -Raeburn Standards Track [Page 14] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - -Informative References - - [LEACH] Leach, P., email to IETF Kerberos working group mailing - list, 5 May 2003, ftp://ftp.ietf.org/ietf-mail- - archive/krb-wg/2003-05.mail. - - [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC - 3211, December 2001. - -Author's Address - - Kenneth Raeburn - Massachusetts Institute of Technology - 77 Massachusetts Avenue - Cambridge, MA 02139 - - EMail: raeburn@mit.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Raeburn Standards Track [Page 15] - -RFC 3962 AES Encryption for Kerberos 5 February 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Raeburn Standards Track [Page 16] - diff --git a/doc/krb5-protocol/rfc4120.txt b/doc/krb5-protocol/rfc4120.txt deleted file mode 100644 index e2816aff21..0000000000 --- a/doc/krb5-protocol/rfc4120.txt +++ /dev/null @@ -1,7731 +0,0 @@ - - - - - - -Network Working Group C. Neuman -Request for Comments: 4120 USC-ISI -Obsoletes: 1510 T. Yu -Category: Standards Track S. Hartman - K. Raeburn - MIT - July 2005 - - - The Kerberos Network Authentication Service (V5) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document provides an overview and specification of Version 5 of - the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects - of the protocol and its intended use that require more detailed or - clearer explanation than was provided in RFC 1510. This document is - intended to provide a detailed description of the protocol, suitable - for implementation, together with descriptions of the appropriate use - of protocol messages and fields within those messages. - - - - - - - - - - - - - - - - - - - -Neuman, et al. Standards Track [Page 1] - -RFC 4120 Kerberos V5 July 2005 - - -Table of Contents - - 1. Introduction ....................................................5 - 1.1. The Kerberos Protocol ......................................6 - 1.2. Cross-Realm Operation ......................................8 - 1.3. Choosing a Principal with Which to Communicate .............9 - 1.4. Authorization .............................................10 - 1.5. Extending Kerberos without Breaking Interoperability ......11 - 1.5.1. Compatibility with RFC 1510 ........................11 - 1.5.2. Sending Extensible Messages ........................12 - 1.6. Environmental Assumptions .................................12 - 1.7. Glossary of Terms .........................................13 - 2. Ticket Flag Uses and Requests ..................................16 - 2.1. Initial, Pre-authenticated, and - Hardware-Authenticated Tickets ............................17 - 2.2. Invalid Tickets ...........................................17 - 2.3. Renewable Tickets .........................................17 - 2.4. Postdated Tickets .........................................18 - 2.5. Proxiable and Proxy Tickets ...............................19 - 2.6. Forwardable Tickets .......................................19 - 2.7. Transited Policy Checking .................................20 - 2.8. OK as Delegate ............................................21 - 2.9. Other KDC Options .........................................21 - 2.9.1. Renewable-OK .......................................21 - 2.9.2. ENC-TKT-IN-SKEY ....................................22 - 2.9.3. Passwordless Hardware Authentication ...............22 - 3. Message Exchanges ..............................................22 - 3.1. The Authentication Service Exchange .......................22 - 3.1.1. Generation of KRB_AS_REQ Message ...................24 - 3.1.2. Receipt of KRB_AS_REQ Message ......................24 - 3.1.3. Generation of KRB_AS_REP Message ...................24 - 3.1.4. Generation of KRB_ERROR Message ....................27 - 3.1.5. Receipt of KRB_AS_REP Message ......................27 - 3.1.6. Receipt of KRB_ERROR Message .......................28 - 3.2. The Client/Server Authentication Exchange .................29 - 3.2.1. The KRB_AP_REQ Message .............................29 - 3.2.2. Generation of a KRB_AP_REQ Message .................29 - 3.2.3. Receipt of KRB_AP_REQ Message ......................30 - 3.2.4. Generation of a KRB_AP_REP Message .................33 - 3.2.5. Receipt of KRB_AP_REP Message ......................33 - 3.2.6. Using the Encryption Key ...........................33 - 3.3. The Ticket-Granting Service (TGS) Exchange ................34 - 3.3.1. Generation of KRB_TGS_REQ Message ..................35 - 3.3.2. Receipt of KRB_TGS_REQ Message .....................37 - 3.3.3. Generation of KRB_TGS_REP Message ..................38 - 3.3.4. Receipt of KRB_TGS_REP Message .....................42 - - - - - -Neuman, et al. Standards Track [Page 2] - -RFC 4120 Kerberos V5 July 2005 - - - 3.4. The KRB_SAFE Exchange .....................................42 - 3.4.1. Generation of a KRB_SAFE Message ...................42 - 3.4.2. Receipt of KRB_SAFE Message ........................43 - 3.5. The KRB_PRIV Exchange .....................................44 - 3.5.1. Generation of a KRB_PRIV Message ...................44 - 3.5.2. Receipt of KRB_PRIV Message ........................44 - 3.6. The KRB_CRED Exchange .....................................45 - 3.6.1. Generation of a KRB_CRED Message ...................45 - 3.6.2. Receipt of KRB_CRED Message ........................46 - 3.7. User-to-User Authentication Exchanges .....................47 - 4. Encryption and Checksum Specifications .........................48 - 5. Message Specifications .........................................50 - 5.1. Specific Compatibility Notes on ASN.1 .....................51 - 5.1.1. ASN.1 Distinguished Encoding Rules .................51 - 5.1.2. Optional Integer Fields ............................52 - 5.1.3. Empty SEQUENCE OF Types ............................52 - 5.1.4. Unrecognized Tag Numbers ...........................52 - 5.1.5. Tag Numbers Greater Than 30 ........................53 - 5.2. Basic Kerberos Types ......................................53 - 5.2.1. KerberosString .....................................53 - 5.2.2. Realm and PrincipalName ............................55 - 5.2.3. KerberosTime .......................................55 - 5.2.4. Constrained Integer Types ..........................55 - 5.2.5. HostAddress and HostAddresses ......................56 - 5.2.6. AuthorizationData ..................................57 - 5.2.7. PA-DATA ............................................60 - 5.2.8. KerberosFlags ......................................64 - 5.2.9. Cryptosystem-Related Types .........................65 - 5.3. Tickets ...................................................66 - 5.4. Specifications for the AS and TGS Exchanges ...............73 - 5.4.1. KRB_KDC_REQ Definition .............................73 - 5.4.2. KRB_KDC_REP Definition .............................81 - 5.5. Client/Server (CS) Message Specifications .................84 - 5.5.1. KRB_AP_REQ Definition ..............................84 - 5.5.2. KRB_AP_REP Definition ..............................88 - 5.5.3. Error Message Reply ................................89 - 5.6. KRB_SAFE Message Specification ............................89 - 5.6.1. KRB_SAFE definition ................................89 - 5.7. KRB_PRIV Message Specification ............................91 - 5.7.1. KRB_PRIV Definition ................................91 - 5.8. KRB_CRED Message Specification ............................92 - 5.8.1. KRB_CRED Definition ................................92 - 5.9. Error Message Specification ...............................94 - 5.9.1. KRB_ERROR Definition ...............................94 - 5.10. Application Tag Numbers ..................................96 - - - - - - -Neuman, et al. Standards Track [Page 3] - -RFC 4120 Kerberos V5 July 2005 - - - 6. Naming Constraints .............................................97 - 6.1. Realm Names ...............................................97 - 6.2. Principal Names .......................................... 99 - 6.2.1. Name of Server Principals .........................100 - 7. Constants and Other Defined Values ............................101 - 7.1. Host Address Types .......................................101 - 7.2. KDC Messaging: IP Transports .............................102 - 7.2.1. UDP/IP transport ..................................102 - 7.2.2. TCP/IP Transport ..................................103 - 7.2.3. KDC Discovery on IP Networks ......................104 - 7.3. Name of the TGS ..........................................105 - 7.4. OID Arc for KerberosV5 ...................................106 - 7.5. Protocol Constants and Associated Values .................106 - 7.5.1. Key Usage Numbers .................................106 - 7.5.2. PreAuthentication Data Types ......................108 - 7.5.3. Address Types .....................................109 - 7.5.4. Authorization Data Types ..........................109 - 7.5.5. Transited Encoding Types ..........................109 - 7.5.6. Protocol Version Number ...........................109 - 7.5.7. Kerberos Message Types ............................110 - 7.5.8. Name Types ........................................110 - 7.5.9. Error Codes .......................................110 - 8. Interoperability Requirements .................................113 - 8.1. Specification 2 ..........................................113 - 8.2. Recommended KDC Values ...................................116 - 9. IANA Considerations ...........................................116 - 10. Security Considerations ......................................117 - 11. Acknowledgements .............................................121 - A. ASN.1 Module ..................................................123 - B. Changes since RFC 1510 ........................................131 - Normative References .............................................134 - Informative References ...........................................135 - - - - - - - - - - - - - - - - - - - -Neuman, et al. Standards Track [Page 4] - -RFC 4120 Kerberos V5 July 2005 - - -1. Introduction - - This document describes the concepts and model upon which the - Kerberos network authentication system is based. It also specifies - Version 5 of the Kerberos protocol. The motivations, goals, - assumptions, and rationale behind most design decisions are treated - cursorily; they are more fully described in a paper available in IEEE - communications [NT94] and earlier in the Kerberos portion of the - Athena Technical Plan [MNSS87]. - - This document is not intended to describe Kerberos to the end user, - system administrator, or application developer. Higher-level papers - describing Version 5 of the Kerberos system [NT94] and documenting - version 4 [SNS88] are available elsewhere. - - The Kerberos model is based in part on Needham and Schroeder's - trusted third-party authentication protocol [NS78] and on - modifications suggested by Denning and Sacco [DS81]. The original - design and implementation of Kerberos Versions 1 through 4 was the - work of two former Project Athena staff members, Steve Miller of - Digital Equipment Corporation and Clifford Neuman (now at the - Information Sciences Institute of the University of Southern - California), along with Jerome Saltzer, Technical Director of Project - Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other - members of Project Athena have also contributed to the work on - Kerberos. - - Version 5 of the Kerberos protocol (described in this document) has - evolved because of new requirements and desires for features not - available in Version 4. The design of Version 5 was led by Clifford - Neuman and John Kohl with much input from the community. The - development of the MIT reference implementation was led at MIT by - John Kohl and Theodore Ts'o, with help and contributed code from many - others. Since RFC 1510 was issued, many individuals have proposed - extensions and revisions to the protocol. This document reflects - some of these proposals. Where such changes involved significant - effort, the document cites the contribution of the proposer. - - Reference implementations of both Version 4 and Version 5 of Kerberos - are publicly available, and commercial implementations have been - developed and are widely used. Details on the differences between - Versions 4 and 5 can be found in [KNT94]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - -Neuman, et al. Standards Track [Page 5] - -RFC 4120 Kerberos V5 July 2005 - - -1.1. The Kerberos Protocol - - Kerberos provides a means of verifying the identities of principals, - (e.g., a workstation user or a network server) on an open - (unprotected) network. This is accomplished without relying on - assertions by the host operating system, without basing trust on host - addresses, without requiring physical security of all the hosts on - the network, and under the assumption that packets traveling along - the network can be read, modified, and inserted at will. Kerberos - performs authentication under these conditions as a trusted third- - party authentication service by using conventional (shared secret - key) cryptography. Extensions to Kerberos (outside the scope of this - document) can provide for the use of public key cryptography during - certain phases of the authentication protocol. Such extensions - support Kerberos authentication for users registered with public key - certification authorities and provide certain benefits of public key - cryptography in situations where they are needed. - - The basic Kerberos authentication process proceeds as follows: A - client sends a request to the authentication server (AS) for - "credentials" for a given server. The AS responds with these - credentials, encrypted in the client's key. The credentials consist - of a "ticket" for the server and a temporary encryption key (often - called a "session key"). The client transmits the ticket (which - contains the client's identity and a copy of the session key, all - encrypted in the server's key) to the server. The session key (now - shared by the client and server) is used to authenticate the client - and may optionally be used to authenticate the server. It may also - be used to encrypt further communication between the two parties or - to exchange a separate sub-session key to be used to encrypt further - communication. Note that many applications use Kerberos' functions - only upon the initiation of a stream-based network connection. - Unless an application performs encryption or integrity protection for - the data stream, the identity verification applies only to the - initiation of the connection, and it does not guarantee that - subsequent messages on the connection originate from the same - principal. - - Implementation of the basic protocol consists of one or more - authentication servers running on physically secure hosts. The - authentication servers maintain a database of principals (i.e., users - and servers) and their secret keys. Code libraries provide - encryption and implement the Kerberos protocol. In order to add - authentication to its transactions, a typical network application - adds calls to the Kerberos library directly or through the Generic - Security Services Application Programming Interface (GSS-API) - described in a separate document [RFC4121]. These calls result in - the transmission of the messages necessary to achieve authentication. - - - -Neuman, et al. Standards Track [Page 6] - -RFC 4120 Kerberos V5 July 2005 - - - The Kerberos protocol consists of several sub-protocols (or - exchanges). There are two basic methods by which a client can ask a - Kerberos server for credentials. In the first approach, the client - sends a cleartext request for a ticket for the desired server to the - AS. The reply is sent encrypted in the client's secret key. Usually - this request is for a ticket-granting ticket (TGT), which can later - be used with the ticket-granting server (TGS). In the second method, - the client sends a request to the TGS. The client uses the TGT to - authenticate itself to the TGS in the same manner as if it were - contacting any other application server that requires Kerberos - authentication. The reply is encrypted in the session key from the - TGT. Though the protocol specification describes the AS and the TGS - as separate servers, in practice they are implemented as different - protocol entry points within a single Kerberos server. - - Once obtained, credentials may be used to verify the identity of the - principals in a transaction, to ensure the integrity of messages - exchanged between them, or to preserve privacy of the messages. The - application is free to choose whatever protection may be necessary. - - To verify the identities of the principals in a transaction, the - client transmits the ticket to the application server. Because the - ticket is sent "in the clear" (parts of it are encrypted, but this - encryption doesn't thwart replay) and might be intercepted and reused - by an attacker, additional information is sent to prove that the - message originated with the principal to whom the ticket was issued. - This information (called the authenticator) is encrypted in the - session key and includes a timestamp. The timestamp proves that the - message was recently generated and is not a replay. Encrypting the - authenticator in the session key proves that it was generated by a - party possessing the session key. Since no one except the requesting - principal and the server know the session key (it is never sent over - the network in the clear), this guarantees the identity of the - client. - - The integrity of the messages exchanged between principals can also - be guaranteed by using the session key (passed in the ticket and - contained in the credentials). This approach provides detection of - both replay attacks and message stream modification attacks. It is - accomplished by generating and transmitting a collision-proof - checksum (elsewhere called a hash or digest function) of the client's - message, keyed with the session key. Privacy and integrity of the - messages exchanged between principals can be secured by encrypting - the data to be passed by using the session key contained in the - ticket or the sub-session key found in the authenticator. - - - - - - -Neuman, et al. Standards Track [Page 7] - -RFC 4120 Kerberos V5 July 2005 - - - The authentication exchanges mentioned above require read-only access - to the Kerberos database. Sometimes, however, the entries in the - database must be modified, such as when adding new principals or - changing a principal's key. This is done using a protocol between a - client and a third Kerberos server, the Kerberos Administration - Server (KADM). There is also a protocol for maintaining multiple - copies of the Kerberos database. Neither of these protocols are - described in this document. - -1.2. Cross-Realm Operation - - The Kerberos protocol is designed to operate across organizational - boundaries. A client in one organization can be authenticated to a - server in another. Each organization wishing to run a Kerberos - server establishes its own "realm". The name of the realm in which a - client is registered is part of the client's name and can be used by - the end-service to decide whether to honor a request. - - By establishing "inter-realm" keys, the administrators of two realms - can allow a client authenticated in the local realm to prove its - identity to servers in other realms. The exchange of inter-realm - keys (a separate key may be used for each direction) registers the - ticket-granting service of each realm as a principal in the other - realm. A client is then able to obtain a TGT for the remote realm's - ticket-granting service from its local realm. When that TGT is used, - the remote ticket-granting service uses the inter-realm key (which - usually differs from its own normal TGS key) to decrypt the TGT; thus - it is certain that the ticket was issued by the client's own TGS. - Tickets issued by the remote ticket-granting service will indicate to - the end-service that the client was authenticated from another realm. - - Without cross-realm operation, and with appropriate permission, the - client can arrange registration of a separately-named principal in a - remote realm and engage in normal exchanges with that realm's - services. However, for even small numbers of clients this becomes - cumbersome, and more automatic methods as described here are - necessary. - - A realm is said to communicate with another realm if the two realms - share an inter-realm key, or if the local realm shares an inter-realm - key with an intermediate realm that communicates with the remote - realm. An authentication path is the sequence of intermediate realms - that are transited in communicating from one realm to another. - - Realms may be organized hierarchically. Each realm shares a key with - its parent and a different key with each child. If an inter-realm - key is not directly shared by two realms, the hierarchical - organization allows an authentication path to be easily constructed. - - - -Neuman, et al. Standards Track [Page 8] - -RFC 4120 Kerberos V5 July 2005 - - - If a hierarchical organization is not used, it may be necessary to - consult a database in order to construct an authentication path - between realms. - - Although realms are typically hierarchical, intermediate realms may - be bypassed to achieve cross-realm authentication through alternate - authentication paths. (These might be established to make - communication between two realms more efficient.) It is important - for the end-service to know which realms were transited when deciding - how much faith to place in the authentication process. To facilitate - this decision, a field in each ticket contains the names of the - realms that were involved in authenticating the client. - - The application server is ultimately responsible for accepting or - rejecting authentication and SHOULD check the transited field. The - application server may choose to rely on the Key Distribution Center - (KDC) for the application server's realm to check the transited - field. The application server's KDC will set the - TRANSITED-POLICY-CHECKED flag in this case. The KDCs for - intermediate realms may also check the transited field as they issue - TGTs for other realms, but they are encouraged not to do so. A - client may request that the KDCs not check the transited field by - setting the DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this - flag. - -1.3. Choosing a Principal with Which to Communicate - - The Kerberos protocol provides the means for verifying (subject to - the assumptions in Section 1.6) that the entity with which one - communicates is the same entity that was registered with the KDC - using the claimed identity (principal name). It is still necessary - to determine whether that identity corresponds to the entity with - which one intends to communicate. - - When appropriate data has been exchanged in advance, the application - may perform this determination syntactically based on the application - protocol specification, information provided by the user, and - configuration files. For example, the server principal name - (including realm) for a telnet server might be derived from the - user-specified host name (from the telnet command line), the "host/" - prefix specified in the application protocol specification, and a - mapping to a Kerberos realm derived syntactically from the domain - part of the specified hostname and information from the local - Kerberos realms database. - - One can also rely on trusted third parties to make this - determination, but only when the data obtained from the third party - is suitably integrity-protected while resident on the third-party - - - -Neuman, et al. Standards Track [Page 9] - -RFC 4120 Kerberos V5 July 2005 - - - server and when transmitted. Thus, for example, one should not rely - on an unprotected DNS record to map a host alias to the primary name - of a server, accepting the primary name as the party that one intends - to contact, since an attacker can modify the mapping and impersonate - the party. - - Implementations of Kerberos and protocols based on Kerberos MUST NOT - use insecure DNS queries to canonicalize the hostname components of - the service principal names (i.e., they MUST NOT use insecure DNS - queries to map one name to another to determine the host part of the - principal name with which one is to communicate). In an environment - without secure name service, application authors MAY append a - statically configured domain name to unqualified hostnames before - passing the name to the security mechanisms, but they should do no - more than that. Secure name service facilities, if available, might - be trusted for hostname canonicalization, but such canonicalization - by the client SHOULD NOT be required by KDC implementations. - - Implementation note: Many current implementations do some degree of - canonicalization of the provided service name, often using DNS even - though it creates security problems. However, there is no - consistency among implementations as to whether the service name is - case folded to lowercase or whether reverse resolution is used. To - maximize interoperability and security, applications SHOULD provide - security mechanisms with names that result from folding the user- - entered name to lowercase without performing any other modifications - or canonicalization. - -1.4. Authorization - - As an authentication service, Kerberos provides a means of verifying - the identity of principals on a network. Authentication is usually - useful primarily as a first step in the process of authorization, - determining whether a client may use a service, which objects the - client is allowed to access, and the type of access allowed for each. - Kerberos does not, by itself, provide authorization. Possession of a - client ticket for a service provides only for authentication of the - client to that service, and in the absence of a separate - authorization procedure, an application should not consider it to - authorize the use of that service. - - Separate authorization methods MAY be implemented as application- - specific access control functions and may utilize files on the - application server, on separately issued authorization credentials - such as those based on proxies [Neu93], or on other authorization - services. Separately authenticated authorization credentials MAY be - embedded in a ticket's authorization data when encapsulated by the - KDC-issued authorization data element. - - - -Neuman, et al. Standards Track [Page 10] - -RFC 4120 Kerberos V5 July 2005 - - - Applications should not accept the mere issuance of a service ticket - by the Kerberos server (even by a modified Kerberos server) as - granting authority to use the service, since such applications may - become vulnerable to the bypass of this authorization check in an - environment where other options for application authentication are - provided, or if they interoperate with other KDCs. - -1.5. Extending Kerberos without Breaking Interoperability - - As the deployed base of Kerberos implementations grows, extending - Kerberos becomes more important. Unfortunately, some extensions to - the existing Kerberos protocol create interoperability issues because - of uncertainty regarding the treatment of certain extensibility - options by some implementations. This section includes guidelines - that will enable future implementations to maintain interoperability. - - Kerberos provides a general mechanism for protocol extensibility. - Some protocol messages contain typed holes -- sub-messages that - contain an octet-string along with an integer that defines how to - interpret the octet-string. The integer types are registered - centrally, but they can be used both for vendor extensions and for - extensions standardized through the IETF. - - In this document, the word "extension" refers to extension by - defining a new type to insert into an existing typed hole in a - protocol message. It does not refer to extension by addition of new - fields to ASN.1 types, unless the text explicitly indicates - otherwise. - -1.5.1. Compatibility with RFC 1510 - - Note that existing Kerberos message formats cannot readily be - extended by adding fields to the ASN.1 types. Sending additional - fields often results in the entire message being discarded without an - error indication. Future versions of this specification will provide - guidelines to ensure that ASN.1 fields can be added without creating - an interoperability problem. - - In the meantime, all new or modified implementations of Kerberos that - receive an unknown message extension SHOULD preserve the encoding of - the extension but otherwise ignore its presence. Recipients MUST NOT - decline a request simply because an extension is present. - - There is one exception to this rule. If an unknown authorization - data element type is received by a server other than the ticket- - granting service either in an AP-REQ or in a ticket contained in an - AP-REQ, then authentication MUST fail. One of the primary uses of - authorization data is to restrict the use of the ticket. If the - - - -Neuman, et al. Standards Track [Page 11] - -RFC 4120 Kerberos V5 July 2005 - - - service cannot determine whether the restriction applies to that - service, then a security weakness may result if the ticket can be - used for that service. Authorization elements that are optional - SHOULD be enclosed in the AD-IF-RELEVANT element. - - The ticket-granting service MUST ignore but propagate to derivative - tickets any unknown authorization data types, unless those data types - are embedded in a MANDATORY-FOR-KDC element, in which case the - request will be rejected. This behavior is appropriate because - requiring that the ticket-granting service understand unknown - authorization data types would require that KDC software be upgraded - to understand new application-level restrictions before applications - used these restrictions, decreasing the utility of authorization data - as a mechanism for restricting the use of tickets. No security - problem is created because services to which the tickets are issued - will verify the authorization data. - - Implementation note: Many RFC 1510 implementations ignore unknown - authorization data elements. Depending on these implementations to - honor authorization data restrictions may create a security weakness. - -1.5.2. Sending Extensible Messages - - Care must be taken to ensure that old implementations can understand - messages sent to them, even if they do not understand an extension - that is used. Unless the sender knows that an extension is - supported, the extension cannot change the semantics of the core - message or previously defined extensions. - - For example, an extension including key information necessary to - decrypt the encrypted part of a KDC-REP could only be used in - situations where the recipient was known to support the extension. - Thus when designing such extensions it is important to provide a way - for the recipient to notify the sender of support for the extension. - For example in the case of an extension that changes the KDC-REP - reply key, the client could indicate support for the extension by - including a padata element in the AS-REQ sequence. The KDC should - only use the extension if this padata element is present in the - AS-REQ. Even if policy requires the use of the extension, it is - better to return an error indicating that the extension is required - than to use the extension when the recipient may not support it. - Debugging implementations that do not interoperate is easier when - errors are returned. - -1.6. Environmental Assumptions - - Kerberos imposes a few assumptions on the environment in which it can - properly function, including the following: - - - -Neuman, et al. Standards Track [Page 12] - -RFC 4120 Kerberos V5 July 2005 - - - * "Denial of service" attacks are not solved with Kerberos. There - are places in the protocols where an intruder can prevent an - application from participating in the proper authentication steps. - Detection and solution of such attacks (some of which can appear - to be not-uncommon "normal" failure modes for the system) are - usually best left to the human administrators and users. - - * Principals MUST keep their secret keys secret. If an intruder - somehow steals a principal's key, it will be able to masquerade as - that principal or to impersonate any server to the legitimate - principal. - - * "Password guessing" attacks are not solved by Kerberos. If a user - chooses a poor password, it is possible for an attacker to - successfully mount an offline dictionary attack by repeatedly - attempting to decrypt, with successive entries from a dictionary, - messages obtained which are encrypted under a key derived from the - user's password. - - * Each host on the network MUST have a clock which is "loosely - synchronized" to the time of the other hosts; this synchronization - is used to reduce the bookkeeping needs of application servers - when they do replay detection. The degree of "looseness" can be - configured on a per-server basis, but it is typically on the order - of 5 minutes. If the clocks are synchronized over the network, - the clock synchronization protocol MUST itself be secured from - network attackers. - - * Principal identifiers are not recycled on a short-term basis. A - typical mode of access control will use access control lists - (ACLs) to grant permissions to particular principals. If a stale - ACL entry remains for a deleted principal and the principal - identifier is reused, the new principal will inherit rights - specified in the stale ACL entry. By not re-using principal - identifiers, the danger of inadvertent access is removed. - -1.7. Glossary of Terms - - Below is a list of terms used throughout this document. - - Authentication - Verifying the claimed identity of a principal. - - Authentication header - A record containing a Ticket and an Authenticator to be presented - to a server as part of the authentication process. - - - - - -Neuman, et al. Standards Track [Page 13] - -RFC 4120 Kerberos V5 July 2005 - - - Authentication path - A sequence of intermediate realms transited in the authentication - process when communicating from one realm to another. - - Authenticator - A record containing information that can be shown to have been - recently generated using the session key known only by the client - and server. - - Authorization - The process of determining whether a client may use a service, - which objects the client is allowed to access, and the type of - access allowed for each. - - Capability - A token that grants the bearer permission to access an object or - service. In Kerberos, this might be a ticket whose use is - restricted by the contents of the authorization data field, but - which lists no network addresses, together with the session key - necessary to use the ticket. - - Ciphertext - The output of an encryption function. Encryption transforms - plaintext into ciphertext. - - Client - A process that makes use of a network service on behalf of a user. - Note that in some cases a Server may itself be a client of some - other server (e.g., a print server may be a client of a file - server). - - Credentials - A ticket plus the secret session key necessary to use that ticket - successfully in an authentication exchange. - - Encryption Type (etype) - When associated with encrypted data, an encryption type identifies - the algorithm used to encrypt the data and is used to select the - appropriate algorithm for decrypting the data. Encryption type - tags are communicated in other messages to enumerate algorithms - that are desired, supported, preferred, or allowed to be used for - encryption of data between parties. This preference is combined - with local information and policy to select an algorithm to be - used. - - KDC - Key Distribution Center. A network service that supplies tickets - and temporary session keys; or an instance of that service or the - - - -Neuman, et al. Standards Track [Page 14] - -RFC 4120 Kerberos V5 July 2005 - - - host on which it runs. The KDC services both initial ticket and - ticket-granting ticket requests. The initial ticket portion is - sometimes referred to as the Authentication Server (or service). - The ticket-granting ticket portion is sometimes referred to as the - ticket-granting server (or service). - - Kerberos - The name given to the Project Athena's authentication service, the - protocol used by that service, or the code used to implement the - authentication service. The name is adopted from the three-headed - dog that guards Hades. - - Key Version Number (kvno) - A tag associated with encrypted data identifies which key was used - for encryption when a long-lived key associated with a principal - changes over time. It is used during the transition to a new key - so that the party decrypting a message can tell whether the data - was encrypted with the old or the new key. - - Plaintext - The input to an encryption function or the output of a decryption - function. Decryption transforms ciphertext into plaintext. - - Principal - A named client or server entity that participates in a network - communication, with one name that is considered canonical. - - Principal identifier - The canonical name used to identify each different principal - uniquely. - - Seal - To encipher a record containing several fields in such a way that - the fields cannot be individually replaced without knowledge of - the encryption key or leaving evidence of tampering. - - Secret key - An encryption key shared by a principal and the KDC, distributed - outside the bounds of the system, with a long lifetime. In the - case of a human user's principal, the secret key MAY be derived - from a password. - - Server - A particular Principal that provides a resource to network - clients. The server is sometimes referred to as the Application - Server. - - - - - -Neuman, et al. Standards Track [Page 15] - -RFC 4120 Kerberos V5 July 2005 - - - Service - A resource provided to network clients; often provided by more - than one server (for example, remote file service). - - Session key - A temporary encryption key used between two principals, with a - lifetime limited to the duration of a single login "session". In - the Kerberos system, a session key is generated by the KDC. The - session key is distinct from the sub-session key, described next. - - Sub-session key - A temporary encryption key used between two principals, selected - and exchanged by the principals using the session key, and with a - lifetime limited to the duration of a single association. The - sub-session key is also referred to as the subkey. - - Ticket - A record that helps a client authenticate itself to a server; it - contains the client's identity, a session key, a timestamp, and - other information, all sealed using the server's secret key. It - only serves to authenticate a client when presented along with a - fresh Authenticator. - -2. Ticket Flag Uses and Requests - - Each Kerberos ticket contains a set of flags that are used to - indicate attributes of that ticket. Most flags may be requested by a - client when the ticket is obtained; some are automatically turned on - and off by a Kerberos server as required. The following sections - explain what the various flags mean and give examples of reasons to - use them. With the exception of the INVALID flag, clients MUST - ignore ticket flags that are not recognized. KDCs MUST ignore KDC - options that are not recognized. Some implementations of RFC 1510 - are known to reject unknown KDC options, so clients may need to - resend a request without new KDC options if the request was rejected - when sent with options added since RFC 1510. Because new KDCs will - ignore unknown options, clients MUST confirm that the ticket returned - by the KDC meets their needs. - - Note that it is not, in general, possible to determine whether an - option was not honored because it was not understood or because it - was rejected through either configuration or policy. When adding a - new option to the Kerberos protocol, designers should consider - whether the distinction is important for their option. If it is, a - mechanism for the KDC to return an indication that the option was - understood but rejected needs to be provided in the specification of - the option. Often in such cases, the mechanism needs to be broad - enough to permit an error or reason to be returned. - - - -Neuman, et al. Standards Track [Page 16] - -RFC 4120 Kerberos V5 July 2005 - - -2.1. Initial, Pre-authenticated, and Hardware-Authenticated Tickets - - The INITIAL flag indicates that a ticket was issued using the AS - protocol, rather than issued based on a TGT. Application servers - that want to require the demonstrated knowledge of a client's secret - key (e.g., a password-changing program) can insist that this flag be - set in any tickets they accept, and can thus be assured that the - client's key was recently presented to the authentication server. - - The PRE-AUTHENT and HW-AUTHENT flags provide additional information - about the initial authentication, regardless of whether the current - ticket was issued directly (in which case INITIAL will also be set) - or issued on the basis of a TGT (in which case the INITIAL flag is - clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward - from the TGT). - -2.2. Invalid Tickets - - The INVALID flag indicates that a ticket is invalid. Application - servers MUST reject tickets that have this flag set. A postdated - ticket will be issued in this form. Invalid tickets MUST be - validated by the KDC before use, by being presented to the KDC in a - TGS request with the VALIDATE option specified. The KDC will only - validate tickets after their starttime has passed. The validation is - required so that postdated tickets that have been stolen before their - starttime can be rendered permanently invalid (through a hot-list - mechanism) (see Section 3.3.3.1). - -2.3. Renewable Tickets - - Applications may desire to hold tickets that can be valid for long - periods of time. However, this can expose their credentials to - potential theft for equally long periods, and those stolen - credentials would be valid until the expiration time of the - ticket(s). Simply using short-lived tickets and obtaining new ones - periodically would require the client to have long-term access to its - secret key, an even greater risk. Renewable tickets can be used to - mitigate the consequences of theft. Renewable tickets have two - "expiration times": the first is when the current instance of the - ticket expires, and the second is the latest permissible value for an - individual expiration time. An application client must periodically - (i.e., before it expires) present a renewable ticket to the KDC, with - the RENEW option set in the KDC request. The KDC will issue a new - ticket with a new session key and a later expiration time. All other - fields of the ticket are left unmodified by the renewal process. - When the latest permissible expiration time arrives, the ticket - expires permanently. At each renewal, the KDC MAY consult a hot-list - to determine whether the ticket had been reported stolen since its - - - -Neuman, et al. Standards Track [Page 17] - -RFC 4120 Kerberos V5 July 2005 - - - last renewal; it will refuse to renew stolen tickets, and thus the - usable lifetime of stolen tickets is reduced. - - The RENEWABLE flag in a ticket is normally only interpreted by the - ticket-granting service (discussed below in Section 3.3). It can - usually be ignored by application servers. However, some - particularly careful application servers MAY disallow renewable - tickets. - - If a renewable ticket is not renewed by its expiration time, the KDC - will not renew the ticket. The RENEWABLE flag is reset by default, - but a client MAY request it be set by setting the RENEWABLE option in - the KRB_AS_REQ message. If it is set, then the renew-till field in - the ticket contains the time after which the ticket may not be - renewed. - -2.4. Postdated Tickets - - Applications may occasionally need to obtain tickets for use much - later; e.g., a batch submission system would need tickets to be valid - at the time the batch job is serviced. However, it is dangerous to - hold valid tickets in a batch queue, since they will be on-line - longer and more prone to theft. Postdated tickets provide a way to - obtain these tickets from the KDC at job submission time, but to - leave them "dormant" until they are activated and validated by a - further request of the KDC. If a ticket theft were reported in the - interim, the KDC would refuse to validate the ticket, and the thief - would be foiled. - - The MAY-POSTDATE flag in a ticket is normally only interpreted by the - ticket-granting service. It can be ignored by application servers. - This flag MUST be set in a TGT in order to issue a postdated ticket - based on the presented ticket. It is reset by default; a client MAY - request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ - message. This flag does not allow a client to obtain a postdated - TGT; postdated TGTs can only be obtained by requesting the postdating - in the KRB_AS_REQ message. The life (endtime-starttime) of a - postdated ticket will be the remaining life of the TGT at the time of - the request, unless the RENEWABLE option is also set, in which case - it can be the full life (endtime-starttime) of the TGT. The KDC MAY - limit how far in the future a ticket may be postdated. - - The POSTDATED flag indicates that a ticket has been postdated. The - application server can check the authtime field in the ticket to see - when the original authentication occurred. Some services MAY choose - to reject postdated tickets, or they may only accept them within a - certain period after the original authentication. When the KDC - issues a POSTDATED ticket, it will also be marked as INVALID, so that - - - -Neuman, et al. Standards Track [Page 18] - -RFC 4120 Kerberos V5 July 2005 - - - the application client MUST present the ticket to the KDC to be - validated before use. - -2.5. Proxiable and Proxy Tickets - - At times it may be necessary for a principal to allow a service to - perform an operation on its behalf. The service must be able to take - on the identity of the client, but only for a particular purpose. A - principal can allow a service to do this by granting it a proxy. - - The process of granting a proxy by using the proxy and proxiable - flags is used to provide credentials for use with specific services. - Though conceptually also a proxy, users wishing to delegate their - identity in a form usable for all purposes MUST use the ticket - forwarding mechanism described in the next section to forward a TGT. - - The PROXIABLE flag in a ticket is normally only interpreted by the - ticket-granting service. It can be ignored by application servers. - When set, this flag tells the ticket-granting server that it is OK to - issue a new ticket (but not a TGT) with a different network address - based on this ticket. This flag is set if requested by the client on - initial authentication. By default, the client will request that it - be set when requesting a TGT, and that it be reset when requesting - any other ticket. - - This flag allows a client to pass a proxy to a server to perform a - remote request on its behalf (e.g., a print service client can give - the print server a proxy to access the client's files on a particular - file server in order to satisfy a print request). - - In order to complicate the use of stolen credentials, Kerberos - tickets are often valid only from those network addresses - specifically included in the ticket, but it is permissible as a - policy option to allow requests and to issue tickets with no network - addresses specified. When granting a proxy, the client MUST specify - the new network address from which the proxy is to be used or - indicate that the proxy is to be issued for use from any address. - - The PROXY flag is set in a ticket by the TGS when it issues a proxy - ticket. Application servers MAY check this flag; and at their option - they MAY require additional authentication from the agent presenting - the proxy in order to provide an audit trail. - -2.6. Forwardable Tickets - - Authentication forwarding is an instance of a proxy where the service - that is granted is complete use of the client's identity. An example - of where it might be used is when a user logs in to a remote system - - - -Neuman, et al. Standards Track [Page 19] - -RFC 4120 Kerberos V5 July 2005 - - - and wants authentication to work from that system as if the login - were local. - - The FORWARDABLE flag in a ticket is normally only interpreted by the - ticket-granting service. It can be ignored by application servers. - The FORWARDABLE flag has an interpretation similar to that of the - PROXIABLE flag, except TGTs may also be issued with different network - addresses. This flag is reset by default, but users MAY request that - it be set by setting the FORWARDABLE option in the AS request when - they request their initial TGT. - - This flag allows for authentication forwarding without requiring the - user to enter a password again. If the flag is not set, then - authentication forwarding is not permitted, but the same result can - still be achieved if the user engages in the AS exchange, specifies - the requested network addresses, and supplies a password. - - The FORWARDED flag is set by the TGS when a client presents a ticket - with the FORWARDABLE flag set and requests a forwarded ticket by - specifying the FORWARDED KDC option and supplying a set of addresses - for the new ticket. It is also set in all tickets issued based on - tickets with the FORWARDED flag set. Application servers may choose - to process FORWARDED tickets differently than non-FORWARDED tickets. - - If addressless tickets are forwarded from one system to another, - clients SHOULD still use this option to obtain a new TGT in order to - have different session keys on the different systems. - -2.7. Transited Policy Checking - - In Kerberos, the application server is ultimately responsible for - accepting or rejecting authentication, and it SHOULD check that only - suitably trusted KDCs are relied upon to authenticate a principal. - The transited field in the ticket identifies which realms (and thus - which KDCs) were involved in the authentication process, and an - application server would normally check this field. If any of these - are untrusted to authenticate the indicated client principal - (probably determined by a realm-based policy), the authentication - attempt MUST be rejected. The presence of trusted KDCs in this list - does not provide any guarantee; an untrusted KDC may have fabricated - the list. - - Although the end server ultimately decides whether authentication is - valid, the KDC for the end server's realm MAY apply a realm-specific - policy for validating the transited field and accepting credentials - for cross-realm authentication. When the KDC applies such checks and - accepts such cross-realm authentication, it will set the - TRANSITED-POLICY-CHECKED flag in the service tickets it issues based - - - -Neuman, et al. Standards Track [Page 20] - -RFC 4120 Kerberos V5 July 2005 - - - on the cross-realm TGT. A client MAY request that the KDCs not check - the transited field by setting the DISABLE-TRANSITED-CHECK flag. - KDCs are encouraged but not required to honor this flag. - - Application servers MUST either do the transited-realm checks - themselves or reject cross-realm tickets without - TRANSITED-POLICY-CHECKED set. - -2.8. OK as Delegate - - For some applications, a client may need to delegate authority to a - server to act on its behalf in contacting other services. This - requires that the client forward credentials to an intermediate - server. The ability for a client to obtain a service ticket to a - server conveys no information to the client about whether the server - should be trusted to accept delegated credentials. The - OK-AS-DELEGATE provides a way for a KDC to communicate local realm - policy to a client regarding whether an intermediate server is - trusted to accept such credentials. - - The copy of the ticket flags in the encrypted part of the KDC reply - may have the OK-AS-DELEGATE flag set to indicate to the client that - the server specified in the ticket has been determined by the policy - of the realm to be a suitable recipient of delegation. A client can - use the presence of this flag to help it decide whether to delegate - credentials (grant either a proxy or a forwarded TGT) to this server. - It is acceptable to ignore the value of this flag. When setting this - flag, an administrator should consider the security and placement of - the server on which the service will run, as well as whether the - service requires the use of delegated credentials. - -2.9. Other KDC Options - - There are three additional options that MAY be set in a client's - request of the KDC. - -2.9.1. Renewable-OK - - The RENEWABLE-OK option indicates that the client will accept a - renewable ticket if a ticket with the requested life cannot otherwise - be provided. If a ticket with the requested life cannot be provided, - then the KDC MAY issue a renewable ticket with a renew-till equal to - the requested endtime. The value of the renew-till field MAY still - be adjusted by site-determined limits or limits imposed by the - individual principal or server. - - - - - - -Neuman, et al. Standards Track [Page 21] - -RFC 4120 Kerberos V5 July 2005 - - -2.9.2. ENC-TKT-IN-SKEY - - In its basic form, the Kerberos protocol supports authentication in a - client-server setting and is not well suited to authentication in a - peer-to-peer environment because the long-term key of the user does - not remain on the workstation after initial login. Authentication of - such peers may be supported by Kerberos in its user-to-user variant. - The ENC-TKT-IN-SKEY option supports user-to-user authentication by - allowing the KDC to issue a service ticket encrypted using the - session key from another TGT issued to another user. The - ENC-TKT-IN-SKEY option is honored only by the ticket-granting - service. It indicates that the ticket to be issued for the end - server is to be encrypted in the session key from the additional - second TGT provided with the request. See Section 3.3.3 for specific - details. - -2.9.3. Passwordless Hardware Authentication - - The OPT-HARDWARE-AUTH option indicates that the client wishes to use - some form of hardware authentication instead of or in addition to the - client's password or other long-lived encryption key. - OPT-HARDWARE-AUTH is honored only by the authentication service. If - supported and allowed by policy, the KDC will return an error code of - KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to - perform such authentication. - -3. Message Exchanges - - The following sections describe the interactions between network - clients and servers and the messages involved in those exchanges. - -3.1. The Authentication Service Exchange - - Summary - - Message direction Message type Section - 1. Client to Kerberos KRB_AS_REQ 5.4.1 - 2. Kerberos to client KRB_AS_REP or 5.4.2 - KRB_ERROR 5.9.1 - - The Authentication Service (AS) Exchange between the client and the - Kerberos Authentication Server is initiated by a client when it - wishes to obtain authentication credentials for a given server but - currently holds no credentials. In its basic form, the client's - secret key is used for encryption and decryption. This exchange is - typically used at the initiation of a login session to obtain - credentials for a Ticket-Granting Server, which will subsequently be - used to obtain credentials for other servers (see Section 3.3) - - - -Neuman, et al. Standards Track [Page 22] - -RFC 4120 Kerberos V5 July 2005 - - - without requiring further use of the client's secret key. This - exchange is also used to request credentials for services that must - not be mediated through the Ticket-Granting Service, but rather - require knowledge of a principal's secret key, such as the password- - changing service (the password-changing service denies requests - unless the requester can demonstrate knowledge of the user's old - password; requiring this knowledge prevents unauthorized password - changes by someone walking up to an unattended session). - - This exchange does not by itself provide any assurance of the - identity of the user. To authenticate a user logging on to a local - system, the credentials obtained in the AS exchange may first be used - in a TGS exchange to obtain credentials for a local server; those - credentials must then be verified by a local server through - successful completion of the Client/Server exchange. - - The AS exchange consists of two messages: KRB_AS_REQ from the client - to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for - these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1. - - In the request, the client sends (in cleartext) its own identity and - the identity of the server for which it is requesting credentials, - other information about the credentials it is requesting, and a - randomly generated nonce, which can be used to detect replays and to - associate replies with the matching requests. This nonce MUST be - generated randomly by the client and remembered for checking against - the nonce in the expected reply. The response, KRB_AS_REP, contains - a ticket for the client to present to the server, and a session key - that will be shared by the client and the server. The session key - and additional information are encrypted in the client's secret key. - The encrypted part of the KRB_AS_REP message also contains the nonce - that MUST be matched with the nonce from the KRB_AS_REQ message. - - Without pre-authentication, the authentication server does not know - whether the client is actually the principal named in the request. - It simply sends a reply without knowing or caring whether they are - the same. This is acceptable because nobody but the principal whose - identity was given in the request will be able to use the reply. Its - critical information is encrypted in that principal's key. However, - an attacker can send a KRB_AS_REQ message to get known plaintext in - order to attack the principal's key. Especially if the key is based - on a password, this may create a security exposure. So the initial - request supports an optional field that can be used to pass - additional information that might be needed for the initial exchange. - This field SHOULD be used for pre-authentication as described in - sections 3.1.1 and 5.2.7. - - - - - -Neuman, et al. Standards Track [Page 23] - -RFC 4120 Kerberos V5 July 2005 - - - Various errors can occur; these are indicated by an error response - (KRB_ERROR) instead of the KRB_AS_REP response. The error message is - not encrypted. The KRB_ERROR message contains information that can - be used to associate it with the message to which it replies. The - contents of the KRB_ERROR message are not integrity-protected. As - such, the client cannot detect replays, fabrications, or - modifications. A solution to this problem will be included in a - future version of the protocol. - -3.1.1. Generation of KRB_AS_REQ Message - - The client may specify a number of options in the initial request. - Among these options are whether pre-authentication is to be - performed; whether the requested ticket is to be renewable, - proxiable, or forwardable; whether it should be postdated or allow - postdating of derivative tickets; and whether a renewable ticket will - be accepted in lieu of a non-renewable ticket if the requested ticket - expiration date cannot be satisfied by a non-renewable ticket (due to - configuration constraints). - - The client prepares the KRB_AS_REQ message and sends it to the KDC. - -3.1.2. Receipt of KRB_AS_REQ Message - - If all goes well, processing the KRB_AS_REQ message will result in - the creation of a ticket for the client to present to the server. - The format for the ticket is described in Section 5.3. - - Because Kerberos can run over unreliable transports such as UDP, the - KDC MUST be prepared to retransmit responses in case they are lost. - If a KDC receives a request identical to one it has recently - processed successfully, the KDC MUST respond with a KRB_AS_REP - message rather than a replay error. In order to reduce ciphertext - given to a potential attacker, KDCs MAY send the same response - generated when the request was first handled. KDCs MUST obey this - replay behavior even if the actual transport in use is reliable. - -3.1.3. Generation of KRB_AS_REP Message - - The authentication server looks up the client and server principals - named in the KRB_AS_REQ in its database, extracting their respective - keys. If the requested client principal named in the request is - unknown because it doesn't exist in the KDC's principal database, - then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. - - If required to do so, the server pre-authenticates the request, and - if the pre-authentication check fails, an error message with the code - KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is - - - -Neuman, et al. Standards Track [Page 24] - -RFC 4120 Kerberos V5 July 2005 - - - required, but was not present in the request, an error message with - the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA - object will be stored in the e-data field of the KRB-ERROR message to - specify which pre-authentication mechanisms are acceptable. Usually - this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as - described below. If the server cannot accommodate any encryption - type requested by the client, an error message with code - KDC_ERR_ETYPE_NOSUPP is returned. Otherwise, the KDC generates a - 'random' session key, meaning that, among other things, it should be - impossible to guess the next session key based on knowledge of past - session keys. Although this can be achieved in a pseudo-random - number generator if it is based on cryptographic principles, it is - more desirable to use a truly random number generator, such as one - based on measurements of random physical phenomena. See [RFC4086] - for an in-depth discussion of randomness. - - In response to an AS request, if there are multiple encryption keys - registered for a client in the Kerberos database, then the etype - field from the AS request is used by the KDC to select the encryption - method to be used to protect the encrypted part of the KRB_AS_REP - message that is sent to the client. If there is more than one - supported strong encryption type in the etype list, the KDC SHOULD - use the first valid strong etype for which an encryption key is - available. - - When the user's key is generated from a password or pass phrase, the - string-to-key function for the particular encryption key type is - used, as specified in [RFC3961]. The salt value and additional - parameters for the string-to-key function have default values - (specified by Section 4 and by the encryption mechanism - specification, respectively) that may be overridden by - pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, - PA-ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of - the resulting key only, these values should not be changed for - password-based keys except when changing the principal's key. - - When the AS server is to include pre-authentication data in a - KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE- - INFO, if the etype field of the client's AS-REQ lists at least one - "newer" encryption type. Otherwise (when the etype field of the - client's AS-REQ does not list any "newer" encryption types), it MUST - send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for - each enctype). A "newer" enctype is any enctype first officially - specified concurrently with or subsequent to the issue of this RFC. - The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not - "newer" enctypes. - - - - - -Neuman, et al. Standards Track [Page 25] - -RFC 4120 Kerberos V5 July 2005 - - - It is not possible to generate a user's key reliably given a pass - phrase without contacting the KDC, since it will not be known whether - alternate salt or parameter values are required. - - The KDC will attempt to assign the type of the random session key - from the list of methods in the etype field. The KDC will select the - appropriate type using the list of methods provided and information - from the Kerberos database indicating acceptable encryption methods - for the application server. The KDC will not issue tickets with a - weak session key encryption type. - - If the requested starttime is absent, indicates a time in the past, - or is within the window of acceptable clock skew for the KDC and the - POSTDATE option has not been specified, then the starttime of the - ticket is set to the authentication server's current time. If it - indicates a time in the future beyond the acceptable clock skew, but - the POSTDATED option has not been specified, then the error - KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested - starttime is checked against the policy of the local realm (the - administrator might decide to prohibit certain types or ranges of - postdated tickets), and if the ticket's starttime is acceptable, it - is set as requested, and the INVALID flag is set in the new ticket. - The postdated ticket MUST be validated before use by presenting it to - the KDC after the starttime has been reached. - - The expiration time of the ticket will be set to the earlier of the - requested endtime and a time determined by local policy, possibly by - using realm- or principal-specific factors. For example, the - expiration time MAY be set to the earliest of the following: - - * The expiration time (endtime) requested in the KRB_AS_REQ - message. - - * The ticket's starttime plus the maximum allowable lifetime - associated with the client principal from the authentication - server's database. - - * The ticket's starttime plus the maximum allowable lifetime - associated with the server principal. - - * The ticket's starttime plus the maximum lifetime set by the - policy of the local realm. - - If the requested expiration time minus the starttime (as determined - above) is less than a site-determined minimum lifetime, an error - message with code KDC_ERR_NEVER_VALID is returned. If the requested - expiration time for the ticket exceeds what was determined as above, - and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' - - - -Neuman, et al. Standards Track [Page 26] - -RFC 4120 Kerberos V5 July 2005 - - - flag is set in the new ticket, and the renew-till value is set as if - the 'RENEWABLE' option were requested (the field and option names are - described fully in Section 5.4.1). - - If the RENEWABLE option has been requested or if the RENEWABLE-OK - option has been set and a renewable ticket is to be issued, then the - renew-till field MAY be set to the earliest of: - - * Its requested value. - - * The starttime of the ticket plus the minimum of the two maximum - renewable lifetimes associated with the principals' database - entries. - - * The starttime of the ticket plus the maximum renewable lifetime - set by the policy of the local realm. - - The flags field of the new ticket will have the following options set - if they have been requested and if the policy of the local realm - allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. - If the new ticket is postdated (the starttime is in the future), its - INVALID flag will also be set. - - If all of the above succeed, the server will encrypt the ciphertext - part of the ticket using the encryption key extracted from the server - principal's record in the Kerberos database using the encryption type - associated with the server principal's key. (This choice is NOT - affected by the etype field in the request.) It then formats a - KRB_AS_REP message (see Section 5.4.2), copying the addresses in the - request into the caddr of the response, placing any required pre- - authentication data into the padata of the response, and encrypts the - ciphertext part in the client's key using an acceptable encryption - method requested in the etype field of the request, or in some key - specified by pre-authentication mechanisms being used. - -3.1.4. Generation of KRB_ERROR Message - - Several errors can occur, and the Authentication Server responds by - returning an error message, KRB_ERROR, to the client, with the - error-code and e-text fields set to appropriate values. The error - message contents and details are described in Section 5.9.1. - -3.1.5. Receipt of KRB_AS_REP Message - - If the reply message type is KRB_AS_REP, then the client verifies - that the cname and crealm fields in the cleartext portion of the - reply match what it requested. If any padata fields are present, - they may be used to derive the proper secret key to decrypt the - - - -Neuman, et al. Standards Track [Page 27] - -RFC 4120 Kerberos V5 July 2005 - - - message. The client decrypts the encrypted part of the response - using its secret key and verifies that the nonce in the encrypted - part matches the nonce it supplied in its request (to detect - replays). It also verifies that the sname and srealm in the response - match those in the request (or are otherwise expected values), and - that the host address field is also correct. It then stores the - ticket, session key, start and expiration times, and other - information for later use. The last-req field (and the deprecated - key-expiration field) from the encrypted part of the response MAY be - checked to notify the user of impending key expiration. This enables - the client program to suggest remedial action, such as a password - change. - - Upon validation of the KRB_AS_REP message (by checking the returned - nonce against that sent in the KRB_AS_REQ message), the client knows - that the current time on the KDC is that read from the authtime field - of the encrypted part of the reply. The client can optionally use - this value for clock synchronization in subsequent messages by - recording with the ticket the difference (offset) between the - authtime value and the local clock. This offset can then be used by - the same user to adjust the time read from the system clock when - generating messages [DGT96]. - - This technique MUST be used when adjusting for clock skew instead of - directly changing the system clock, because the KDC reply is only - authenticated to the user whose secret key was used, but not to the - system or workstation. If the clock were adjusted, an attacker - colluding with a user logging into a workstation could agree on a - password, resulting in a KDC reply that would be correctly validated - even though it did not originate from a KDC trusted by the - workstation. - - Proper decryption of the KRB_AS_REP message is not sufficient for the - host to verify the identity of the user; the user and an attacker - could cooperate to generate a KRB_AS_REP format message that decrypts - properly but is not from the proper KDC. If the host wishes to - verify the identity of the user, it MUST require the user to present - application credentials that can be verified using a securely-stored - secret key for the host. If those credentials can be verified, then - the identity of the user can be assured. - -3.1.6. Receipt of KRB_ERROR Message - - If the reply message type is KRB_ERROR, then the client interprets it - as an error and performs whatever application-specific tasks are - necessary for recovery. - - - - - -Neuman, et al. Standards Track [Page 28] - -RFC 4120 Kerberos V5 July 2005 - - -3.2. The Client/Server Authentication Exchange - - Summary - - Message direction Message type Section - Client to Application server KRB_AP_REQ 5.5.1 - [optional] Application server to client KRB_AP_REP or 5.5.2 - KRB_ERROR 5.9.1 - - The client/server authentication (CS) exchange is used by network - applications to authenticate the client to the server and vice versa. - The client MUST have already acquired credentials for the server - using the AS or TGS exchange. - -3.2.1. The KRB_AP_REQ Message - - The KRB_AP_REQ contains authentication information that SHOULD be - part of the first message in an authenticated transaction. It - contains a ticket, an authenticator, and some additional bookkeeping - information (see Section 5.5.1 for the exact format). The ticket by - itself is insufficient to authenticate a client, since tickets are - passed across the network in cleartext (tickets contain both an - encrypted and unencrypted portion, so cleartext here refers to the - entire unit, which can be copied from one message and replayed in - another without any cryptographic skill). The authenticator is used - to prevent invalid replay of tickets by proving to the server that - the client knows the session key of the ticket and thus is entitled - to use the ticket. The KRB_AP_REQ message is referred to elsewhere - as the 'authentication header'. - -3.2.2. Generation of a KRB_AP_REQ Message - - When a client wishes to initiate authentication to a server, it - obtains (either through a credentials cache, the AS exchange, or the - TGS exchange) a ticket and session key for the desired service. The - client MAY re-use any tickets it holds until they expire. To use a - ticket, the client constructs a new Authenticator from the system - time and its name, and optionally from an application-specific - checksum, an initial sequence number to be used in KRB_SAFE or - KRB_PRIV messages, and/or a session subkey to be used in negotiations - for a session key unique to this particular session. Authenticators - MUST NOT be re-used and SHOULD be rejected if replayed to a server. - Note that this can make applications based on unreliable transports - difficult to code correctly. If the transport might deliver - duplicated messages, either a new authenticator MUST be generated for - each retry, or the application server MUST match requests and replies - and replay the first reply in response to a detected duplicate. - - - - -Neuman, et al. Standards Track [Page 29] - -RFC 4120 Kerberos V5 July 2005 - - - If a sequence number is to be included, it SHOULD be randomly chosen - so that even after many messages have been exchanged it is not likely - to collide with other sequence numbers in use. - - The client MAY indicate a requirement of mutual authentication or the - use of a session-key based ticket (for user-to-user authentication, - see section 3.7) by setting the appropriate flag(s) in the ap-options - field of the message. - - The Authenticator is encrypted in the session key and combined with - the ticket to form the KRB_AP_REQ message, which is then sent to the - end server along with any additional application-specific - information. - -3.2.3. Receipt of KRB_AP_REQ Message - - Authentication is based on the server's current time of day (clocks - MUST be loosely synchronized), the authenticator, and the ticket. - Several errors are possible. If an error occurs, the server is - expected to reply to the client with a KRB_ERROR message. This - message MAY be encapsulated in the application protocol if its raw - form is not acceptable to the protocol. The format of error messages - is described in Section 5.9.1. - - The algorithm for verifying authentication information is as follows. - If the message type is not KRB_AP_REQ, the server returns the - KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the - Ticket in the KRB_AP_REQ is not one the server can use (e.g., it - indicates an old key, and the server no longer possesses a copy of - the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the - USE-SESSION-KEY flag is set in the ap-options field, it indicates to - the server that user-to-user authentication is in use, and that the - ticket is encrypted in the session key from the server's TGT rather - than in the server's secret key. See Section 3.7 for a more complete - description of the effect of user-to-user authentication on all - messages in the Kerberos protocol. - - Because it is possible for the server to be registered in multiple - realms, with different keys in each, the srealm field in the - unencrypted portion of the ticket in the KRB_AP_REQ is used to - specify which secret key the server should use to decrypt that - ticket. The KRB_AP_ERR_NOKEY error code is returned if the server - doesn't have the proper key to decipher the ticket. - - The ticket is decrypted using the version of the server's key - specified by the ticket. If the decryption routines detect a - modification of the ticket (each encryption system MUST provide - safeguards to detect modified ciphertext), the - - - -Neuman, et al. Standards Track [Page 30] - -RFC 4120 Kerberos V5 July 2005 - - - KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that - different keys were used to encrypt and decrypt). - - The authenticator is decrypted using the session key extracted from - the decrypted ticket. If decryption shows that is has been modified, - the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm - of the client from the ticket are compared against the same fields in - the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH - error is returned; normally this is caused by a client error or an - attempted attack. The addresses in the ticket (if any) are then - searched for an address matching the operating-system reported - address of the client. If no match is found or the server insists on - ticket addresses but none are present in the ticket, the - KRB_AP_ERR_BADADDR error is returned. If the local (server) time and - the client time in the authenticator differ by more than the - allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is - returned. - - Unless the application server provides its own suitable means to - protect against replay (for example, a challenge-response sequence - initiated by the server after authentication, or use of a server- - generated encryption subkey), the server MUST utilize a replay cache - to remember any authenticator presented within the allowable clock - skew. Careful analysis of the application protocol and - implementation is recommended before eliminating this cache. The - replay cache will store at least the server name, along with the - client name, time, and microsecond fields from the recently-seen - authenticators, and if a matching tuple is found, the - KRB_AP_ERR_REPEAT error is returned. Note that the rejection here is - restricted to authenticators from the same principal to the same - server. Other client principals communicating with the same server - principal should not have their authenticators rejected if the time - and microsecond fields happen to match some other client's - authenticator. - - If a server loses track of authenticators presented within the - allowable clock skew, it MUST reject all requests until the clock - skew interval has passed, providing assurance that any lost or - replayed authenticators will fall outside the allowable clock skew - and can no longer be successfully replayed. If this were not done, - an attacker could subvert the authentication by recording the ticket - and authenticator sent over the network to a server and replaying - them following an event that caused the server to lose track of - recently seen authenticators. - - Implementation note: If a client generates multiple requests to the - KDC with the same timestamp, including the microsecond field, all but - the first of the requests received will be rejected as replays. This - - - -Neuman, et al. Standards Track [Page 31] - -RFC 4120 Kerberos V5 July 2005 - - - might happen, for example, if the resolution of the client's clock is - too coarse. Client implementations SHOULD ensure that the timestamps - are not reused, possibly by incrementing the microseconds field in - the time stamp when the clock returns the same time for multiple - requests. - - If multiple servers (for example, different services on one machine, - or a single service implemented on multiple machines) share a service - principal (a practice that we do not recommend in general, but that - we acknowledge will be used in some cases), either they MUST share - this replay cache, or the application protocol MUST be designed so as - to eliminate the need for it. Note that this applies to all of the - services. If any of the application protocols does not have replay - protection built in, an authenticator used with such a service could - later be replayed to a different service with the same service - principal but no replay protection, if the former doesn't record the - authenticator information in the common replay cache. - - If a sequence number is provided in the authenticator, the server - saves it for later use in processing KRB_SAFE and/or KRB_PRIV - messages. If a subkey is present, the server either saves it for - later use or uses it to help generate its own choice for a subkey to - be returned in a KRB_AP_REP message. - - The server computes the age of the ticket: local (server) time minus - the starttime inside the Ticket. If the starttime is later than the - current time by more than the allowable clock skew, or if the INVALID - flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. - Otherwise, if the current time is later than end time by more than - the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is - returned. - - If all these checks succeed without an error, the server is assured - that the client possesses the credentials of the principal named in - the ticket, and thus, that the client has been authenticated to the - server. - - Passing these checks provides only authentication of the named - principal; it does not imply authorization to use the named service. - Applications MUST make a separate authorization decision based upon - the authenticated name of the user, the requested operation, local - access control information such as that contained in a .k5login or - .k5users file, and possibly a separate distributed authorization - service. - - - - - - - -Neuman, et al. Standards Track [Page 32] - -RFC 4120 Kerberos V5 July 2005 - - -3.2.4. Generation of a KRB_AP_REP Message - - Typically, a client's request will include both the authentication - information and its initial request in the same message, and the - server need not explicitly reply to the KRB_AP_REQ. However, if - mutual authentication (authenticating not only the client to the - server, but also the server to the client) is being performed, the - KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options - field, and a KRB_AP_REP message is required in response. As with the - error message, this message MAY be encapsulated in the application - protocol if its "raw" form is not acceptable to the application's - protocol. The timestamp and microsecond field used in the reply MUST - be the client's timestamp and microsecond field (as provided in the - authenticator). If a sequence number is to be included, it SHOULD be - randomly chosen as described above for the authenticator. A subkey - MAY be included if the server desires to negotiate a different - subkey. The KRB_AP_REP message is encrypted in the session key - extracted from the ticket. - - Note that in the Kerberos Version 4 protocol, the timestamp in the - reply was the client's timestamp plus one. This is not necessary in - Version 5 because Version 5 messages are formatted in such a way that - it is not possible to create the reply by judicious message surgery - (even in encrypted form) without knowledge of the appropriate - encryption keys. - -3.2.5. Receipt of KRB_AP_REP Message - - If a KRB_AP_REP message is returned, the client uses the session key - from the credentials obtained for the server to decrypt the message - and verifies that the timestamp and microsecond fields match those in - the Authenticator it sent to the server. If they match, then the - client is assured that the server is genuine. The sequence number - and subkey (if present) are retained for later use. (Note that for - encrypting the KRB_AP_REP message, the sub-session key is not used, - even if it is present in the Authentication.) - -3.2.6. Using the Encryption Key - - After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and - server share an encryption key that can be used by the application. - In some cases, the use of this session key will be implicit in the - protocol; in others the method of use must be chosen from several - alternatives. The application MAY choose the actual encryption key - to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses - based on the session key from the ticket and subkeys in the - KRB_AP_REP message and the authenticator. Implementations of the - protocol MAY provide routines to choose subkeys based on session keys - - - -Neuman, et al. Standards Track [Page 33] - -RFC 4120 Kerberos V5 July 2005 - - - and random numbers and to generate a negotiated key to be returned in - the KRB_AP_REP message. - - To mitigate the effect of failures in random number generation on the - client, it is strongly encouraged that any key derived by an - application for subsequent use include the full key entropy derived - from the KDC-generated session key carried in the ticket. We leave - the protocol negotiations of how to use the key (e.g., for selecting - an encryption or checksum type) to the application programmer. The - Kerberos protocol does not constrain the implementation options, but - an example of how this might be done follows. - - One way that an application may choose to negotiate a key to be used - for subsequent integrity and privacy protection is for the client to - propose a key in the subkey field of the authenticator. The server - can then choose a key using the key proposed by the client as input, - returning the new subkey in the subkey field of the application - reply. This key could then be used for subsequent communication. - - With both the one-way and mutual authentication exchanges, the peers - should take care not to send sensitive information to each other - without proper assurances. In particular, applications that require - privacy or integrity SHOULD use the KRB_AP_REP response from the - server to the client to assure both client and server of their peer's - identity. If an application protocol requires privacy of its - messages, it can use the KRB_PRIV message (section 3.5). The - KRB_SAFE message (Section 3.4) can be used to ensure integrity. - -3.3. The Ticket-Granting Service (TGS) Exchange - - Summary - - Message direction Message type Section - 1. Client to Kerberos KRB_TGS_REQ 5.4.1 - 2. Kerberos to client KRB_TGS_REP or 5.4.2 - KRB_ERROR 5.9.1 - - The TGS exchange between a client and the Kerberos TGS is initiated - by a client when it seeks to obtain authentication credentials for a - given server (which might be registered in a remote realm), when it - seeks to renew or validate an existing ticket, or when it seeks to - obtain a proxy ticket. In the first case, the client must already - have acquired a ticket for the Ticket-Granting Service using the AS - exchange (the TGT is usually obtained when a client initially - authenticates to the system, such as when a user logs in). The - message format for the TGS exchange is almost identical to that for - the AS exchange. The primary difference is that encryption and - decryption in the TGS exchange does not take place under the client's - - - -Neuman, et al. Standards Track [Page 34] - -RFC 4120 Kerberos V5 July 2005 - - - key. Instead, the session key from the TGT or renewable ticket, or - sub-session key from an Authenticator is used. As is the case for - all application servers, expired tickets are not accepted by the TGS, - so once a renewable or TGT expires, the client must use a separate - exchange to obtain valid tickets. - - The TGS exchange consists of two messages: a request (KRB_TGS_REQ) - from the client to the Kerberos Ticket-Granting Server, and a reply - (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes - information authenticating the client plus a request for credentials. - The authentication information consists of the authentication header - (KRB_AP_REQ), which includes the client's previously obtained - ticket-granting, renewable, or invalid ticket. In the TGT and proxy - cases, the request MAY include one or more of the following: a list - of network addresses, a collection of typed authorization data to be - sealed in the ticket for authorization use by the application server, - or additional tickets (the use of which are described later). The - TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted - in the session key from the TGT or renewable ticket, or, if present, - in the sub-session key from the Authenticator (part of the - authentication header). The KRB_ERROR message contains an error code - and text explaining what went wrong. The KRB_ERROR message is not - encrypted. The KRB_TGS_REP message contains information that can be - used to detect replays, and to associate it with the message to which - it replies. The KRB_ERROR message also contains information that can - be used to associate it with the message to which it replies. The - same comments about integrity protection of KRB_ERROR messages - mentioned in Section 3.1 apply to the TGS exchange. - -3.3.1. Generation of KRB_TGS_REQ Message - - Before sending a request to the ticket-granting service, the client - MUST determine in which realm the application server is believed to - be registered. This can be accomplished in several ways. It might - be known beforehand (since the realm is part of the principal - identifier), it might be stored in a nameserver, or it might be - obtained from a configuration file. If the realm to be used is - obtained from a nameserver, there is a danger of being spoofed if the - nameservice providing the realm name is not authenticated. This - might result in the use of a realm that has been compromised, which - would result in an attacker's ability to compromise the - authentication of the application server to the client. - - If the client knows the service principal name and realm and it does - not already possess a TGT for the appropriate realm, then one must be - obtained. This is first attempted by requesting a TGT for the - destination realm from a Kerberos server for which the client - possesses a TGT (by using the KRB_TGS_REQ message recursively). The - - - -Neuman, et al. Standards Track [Page 35] - -RFC 4120 Kerberos V5 July 2005 - - - Kerberos server MAY return a TGT for the desired realm, in which case - one can proceed. Alternatively, the Kerberos server MAY return a TGT - for a realm that is 'closer' to the desired realm (further along the - standard hierarchical path between the client's realm and the - requested realm server's realm). Note that in this case - misconfiguration of the Kerberos servers may cause loops in the - resulting authentication path, which the client should be careful to - detect and avoid. - - If the Kerberos server returns a TGT for a realm 'closer' than the - desired realm, the client MAY use local policy configuration to - verify that the authentication path used is an acceptable one. - Alternatively, a client MAY choose its own authentication path, - rather than rely on the Kerberos server to select one. In either - case, any policy or configuration information used to choose or - validate authentication paths, whether by the Kerberos server or by - the client, MUST be obtained from a trusted source. - - When a client obtains a TGT that is 'closer' to the destination - realm, the client MAY cache this ticket and reuse it in future - KRB-TGS exchanges with services in the 'closer' realm. However, if - the client were to obtain a TGT for the 'closer' realm by starting at - the initial KDC rather than as part of obtaining another ticket, then - a shorter path to the 'closer' realm might be used. This shorter - path may be desirable because fewer intermediate KDCs would know the - session key of the ticket involved. For this reason, clients SHOULD - evaluate whether they trust the realms transited in obtaining the - 'closer' ticket when making a decision to use the ticket in future. - - Once the client obtains a TGT for the appropriate realm, it - determines which Kerberos servers serve that realm and contacts one - of them. The list might be obtained through a configuration file or - network service, or it MAY be generated from the name of the realm. - As long as the secret keys exchanged by realms are kept secret, only - denial of service results from using a false Kerberos server. - - As in the AS exchange, the client MAY specify a number of options in - the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY - option used for user-to-user authentication. An overview of user- - to-user authentication can be found in Section 3.7. When generating - the KRB_TGS_REQ message, this option indicates that the client is - including a TGT obtained from the application server in the - additional tickets field of the request and that the KDC SHOULD - encrypt the ticket for the application server using the session key - from this additional ticket, instead of a server key from the - principal database. - - - - - -Neuman, et al. Standards Track [Page 36] - -RFC 4120 Kerberos V5 July 2005 - - - The client prepares the KRB_TGS_REQ message, providing an - authentication header as an element of the padata field, and - including the same fields as used in the KRB_AS_REQ message along - with several optional fields: the enc-authorizatfion-data field for - application server use and additional tickets required by some - options. - - In preparing the authentication header, the client can select a sub- - session key under which the response from the Kerberos server will be - encrypted. If the client selects a sub-session key, care must be - taken to ensure the randomness of the selected sub-session key. - - If the sub-session key is not specified, the session key from the TGT - will be used. If the enc-authorization-data is present, it MUST be - encrypted in the sub-session key, if present, from the authenticator - portion of the authentication header, or, if not present, by using - the session key from the TGT. - - Once prepared, the message is sent to a Kerberos server for the - destination realm. - -3.3.2. Receipt of KRB_TGS_REQ Message - - The KRB_TGS_REQ message is processed in a manner similar to the - KRB_AS_REQ message, but there are many additional checks to be - performed. First, the Kerberos server MUST determine which server - the accompanying ticket is for, and it MUST select the appropriate - key to decrypt it. For a normal KRB_TGS_REQ message, it will be for - the ticket-granting service, and the TGS's key will be used. If the - TGT was issued by another realm, then the appropriate inter-realm key - MUST be used. If (a) the accompanying ticket is not a TGT for the - current realm, but is for an application server in the current realm, - (b) the RENEW, VALIDATE, or PROXY options are specified in the - request, and (c) the server for which a ticket is requested is the - server named in the accompanying ticket, then the KDC will decrypt - the ticket in the authentication header using the key of the server - for which it was issued. If no ticket can be found in the padata - field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. - - Once the accompanying ticket has been decrypted, the user-supplied - checksum in the Authenticator MUST be verified against the contents - of the request, and the message MUST be rejected if the checksums do - not match (with an error code of KRB_AP_ERR_MODIFIED) or if the - checksum is not collision-proof (with an error code of - KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the - KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data - are present, they are decrypted using the sub-session key from the - Authenticator. - - - -Neuman, et al. Standards Track [Page 37] - -RFC 4120 Kerberos V5 July 2005 - - - If any of the decryptions indicate failed integrity checks, the - KRB_AP_ERR_BAD_INTEGRITY error is returned. - - As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP - message if it receives a KRB_TGS_REQ message identical to one it has - recently processed. However, if the authenticator is a replay, but - the rest of the request is not identical, then the KDC SHOULD return - KRB_AP_ERR_REPEAT. - -3.3.3. Generation of KRB_TGS_REP Message - - The KRB_TGS_REP message shares its format with the KRB_AS_REP - (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The - detailed specification is in Section 5.4.2. - - The response will include a ticket for the requested server or for a - ticket granting server of an intermediate KDC to be contacted to - obtain the requested ticket. The Kerberos database is queried to - retrieve the record for the appropriate server (including the key - with which the ticket will be encrypted). If the request is for a - TGT for a remote realm, and if no key is shared with the requested - realm, then the Kerberos server will select the realm 'closest' to - the requested realm with which it does share a key and use that realm - instead. This is the only case where the response for the KDC will - be for a different server than that requested by the client. - - By default, the address field, the client's name and realm, the list - of transited realms, the time of initial authentication, the - expiration time, and the authorization data of the newly-issued - ticket will be copied from the TGT or renewable ticket. If the - transited field needs to be updated, but the transited type is not - supported, the KDC_ERR_TRTYPE_NOSUPP error is returned. - - If the request specifies an endtime, then the endtime of the new - ticket is set to the minimum of (a) that request, (b) the endtime - from the TGT, and (c) the starttime of the TGT plus the minimum of - the maximum life for the application server and the maximum life for - the local realm (the maximum life for the requesting principal was - already applied when the TGT was issued). If the new ticket is to be - a renewal, then the endtime above is replaced by the minimum of (a) - the value of the renew_till field of the ticket and (b) the starttime - for the new ticket plus the life (endtime-starttime) of the old - ticket. - - If the FORWARDED option has been requested, then the resulting ticket - will contain the addresses specified by the client. This option will - only be honored if the FORWARDABLE flag is set in the TGT. The PROXY - option is similar; the resulting ticket will contain the addresses - - - -Neuman, et al. Standards Track [Page 38] - -RFC 4120 Kerberos V5 July 2005 - - - specified by the client. It will be honored only if the PROXIABLE - flag in the TGT is set. The PROXY option will not be honored on - requests for additional TGTs. - - If the requested starttime is absent, indicates a time in the past, - or is within the window of acceptable clock skew for the KDC and the - POSTDATE option has not been specified, then the starttime of the - ticket is set to the authentication server's current time. If it - indicates a time in the future beyond the acceptable clock skew, but - the POSTDATED option has not been specified or the MAY-POSTDATE flag - is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is - returned. Otherwise, if the TGT has the MAY-POSTDATE flag set, then - the resulting ticket will be postdated, and the requested starttime - is checked against the policy of the local realm. If acceptable, the - ticket's starttime is set as requested, and the INVALID flag is set. - The postdated ticket MUST be validated before use by presenting it to - the KDC after the starttime has been reached. However, in no case - may the starttime, endtime, or renew-till time of a newly-issued - postdated ticket extend beyond the renew-till time of the TGT. - - If the ENC-TKT-IN-SKEY option has been specified and an additional - ticket has been included in the request, it indicates that the client - is using user-to-user authentication to prove its identity to a - server that does not have access to a persistent key. Section 3.7 - describes the effect of this option on the entire Kerberos protocol. - When generating the KRB_TGS_REP message, this option in the - KRB_TGS_REQ message tells the KDC to decrypt the additional ticket - using the key for the server to which the additional ticket was - issued and to verify that it is a TGT. If the name of the requested - server is missing from the request, the name of the client in the - additional ticket will be used. Otherwise, the name of the requested - server will be compared to the name of the client in the additional - ticket. If it is different, the request will be rejected. If the - request succeeds, the session key from the additional ticket will be - used to encrypt the new ticket that is issued instead of using the - key of the server for which the new ticket will be used. - - If (a) the name of the server in the ticket that is presented to the - KDC as part of the authentication header is not that of the TGS - itself, (b) the server is registered in the realm of the KDC, and (c) - the RENEW option is requested, then the KDC will verify that the - RENEWABLE flag is set in the ticket, that the INVALID flag is not set - in the ticket, and that the renew_till time is still in the future. - If the VALIDATE option is requested, the KDC will check that the - starttime has passed and that the INVALID flag is set. If the PROXY - option is requested, then the KDC will check that the PROXIABLE flag - - - - - -Neuman, et al. Standards Track [Page 39] - -RFC 4120 Kerberos V5 July 2005 - - - is set in the ticket. If the tests succeed and the ticket passes the - hotlist check described in the next section, the KDC will issue the - appropriate new ticket. - - The ciphertext part of the response in the KRB_TGS_REP message is - encrypted in the sub-session key from the Authenticator, if present, - or in the session key from the TGT. It is not encrypted using the - client's secret key. Furthermore, the client's key's expiration date - and the key version number fields are left out since these values are - stored along with the client's database record, and that record is - not needed to satisfy a request based on a TGT. - -3.3.3.1. Checking for Revoked Tickets - - Whenever a request is made to the ticket-granting server, the - presented ticket(s) is (are) checked against a hot-list of tickets - that have been canceled. This hot-list might be implemented by - storing a range of issue timestamps for 'suspect tickets'; if a - presented ticket had an authtime in that range, it would be rejected. - In this way, a stolen TGT or renewable ticket cannot be used to gain - additional tickets (renewals or otherwise) once the theft has been - reported to the KDC for the realm in which the server resides. Any - normal ticket obtained before it was reported stolen will still be - valid (because tickets require no interaction with the KDC), but only - until its normal expiration time. If TGTs have been issued for - cross-realm authentication, use of the cross-realm TGT will not be - affected unless the hot-list is propagated to the KDCs for the realms - for which such cross-realm tickets were issued. - -3.3.3.2. Encoding the Transited Field - - If the identity of the server in the TGT that is presented to the KDC - as part of the authentication header is that of the ticket-granting - service, but the TGT was issued from another realm, the KDC will look - up the inter-realm key shared with that realm and use that key to - decrypt the ticket. If the ticket is valid, then the KDC will honor - the request, subject to the constraints outlined above in the section - describing the AS exchange. The realm part of the client's identity - will be taken from the TGT. The name of the realm that issued the - TGT, if it is not the realm of the client principal, will be added to - the transited field of the ticket to be issued. This is accomplished - by reading the transited field from the TGT (which is treated as an - unordered set of realm names), adding the new realm to the set, and - then constructing and writing out its encoded (shorthand) form (this - may involve a rearrangement of the existing encoding). - - Note that the ticket-granting service does not add the name of its - own realm. Instead, its responsibility is to add the name of the - - - -Neuman, et al. Standards Track [Page 40] - -RFC 4120 Kerberos V5 July 2005 - - - previous realm. This prevents a malicious Kerberos server from - intentionally leaving out its own name (it could, however, omit other - realms' names). - - The names of neither the local realm nor the principal's realm are to - be included in the transited field. They appear elsewhere in the - ticket and both are known to have taken part in authenticating the - principal. Because the endpoints are not included, both local and - single-hop inter-realm authentication result in a transited field - that is empty. - - Because this field has the name of each transited realm added to it, - it might potentially be very long. To decrease the length of this - field, its contents are encoded. The initially supported encoding is - optimized for the normal case of inter-realm communication: a - hierarchical arrangement of realms using either domain or X.500 style - realm names. This encoding (called DOMAIN-X500-COMPRESS) is now - described. - - Realm names in the transited field are separated by a ",". The ",", - "\", trailing "."s, and leading spaces (" ") are special characters, - and if they are part of a realm name, they MUST be quoted in the - transited field by preceding them with a "\". - - A realm name ending with a "." is interpreted as being prepended to - the previous realm. For example, we can encode traversal of EDU, - MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: - - "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". - - Note that if either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were - endpoints, they would not be included in this field, and we would - have: - - "EDU,MIT.,WASHINGTON.EDU" - - A realm name beginning with a "/" is interpreted as being appended to - the previous realm. For the purpose of appending, the realm - preceding the first listed realm is considered the null realm (""). - If a realm name beginning with a "/" is to stand by itself, then it - SHOULD be preceded by a space (" "). For example, we can encode - traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: - - "/COM,/HP,/APOLLO, /COM/DEC". - - As in the example above, if /COM/HP/APOLLO and /COM/DEC were - endpoints, they would not be included in this field, and we would - have: - - - -Neuman, et al. Standards Track [Page 41] - -RFC 4120 Kerberos V5 July 2005 - - - "/COM,/HP" - - A null subfield preceding or following a "," indicates that all - realms between the previous realm and the next realm have been - traversed. For the purpose of interpreting null subfields, the - client's realm is considered to precede those in the transited field, - and the server's realm is considered to follow them. Thus, "," means - that all realms along the path between the client and the server have - been traversed. ",EDU, /COM," means that all realms from the - client's realm up to EDU (in a domain style hierarchy) have been - traversed, and that everything from /COM down to the server's realm - in an X.500 style has also been traversed. This could occur if the - EDU realm in one hierarchy shares an inter-realm key directly with - the /COM realm in another hierarchy. - -3.3.4. Receipt of KRB_TGS_REP Message - - When the KRB_TGS_REP is received by the client, it is processed in - the same manner as the KRB_AS_REP processing described above. The - primary difference is that the ciphertext part of the response must - be decrypted using the sub-session key from the Authenticator, if it - was specified in the request, or the session key from the TGT, rather - than the client's secret key. The server name returned in the reply - is the true principal name of the service. - -3.4. The KRB_SAFE Exchange - - The KRB_SAFE message MAY be used by clients requiring the ability to - detect modifications of messages they exchange. It achieves this by - including a keyed collision-proof checksum of the user data and some - control information. The checksum is keyed with an encryption key - (usually the last key negotiated via subkeys, or the session key if - no negotiation has occurred). - -3.4.1. Generation of a KRB_SAFE Message - - When an application wishes to send a KRB_SAFE message, it collects - its data and the appropriate control information and computes a - checksum over them. The checksum algorithm should be the keyed - checksum mandated to be implemented along with the crypto system used - for the sub-session or session key. The checksum is generated using - the sub-session key, if present, or the session key. Some - implementations use a different checksum algorithm for the KRB_SAFE - messages, but doing so in an interoperable manner is not always - possible. - - The control information for the KRB_SAFE message includes both a - timestamp and a sequence number. The designer of an application - - - -Neuman, et al. Standards Track [Page 42] - -RFC 4120 Kerberos V5 July 2005 - - - using the KRB_SAFE message MUST choose at least one of the two - mechanisms. This choice SHOULD be based on the needs of the - application protocol. - - Sequence numbers are useful when all messages sent will be received - by one's peer. Connection state is presently required to maintain - the session key, so maintaining the next sequence number should not - present an additional problem. - - If the application protocol is expected to tolerate lost messages - without their being resent, the use of the timestamp is the - appropriate replay detection mechanism. Using timestamps is also the - appropriate mechanism for multi-cast protocols in which all of one's - peers share a common sub-session key, but some messages will be sent - to a subset of one's peers. - - After computing the checksum, the client then transmits the - information and checksum to the recipient in the message format - specified in Section 5.6.1. - -3.4.2. Receipt of KRB_SAFE Message - - When an application receives a KRB_SAFE message, it verifies it as - follows. If any error occurs, an error code is reported for use by - the application. - - The message is first checked by verifying that the protocol version - and type fields match the current version and KRB_SAFE, respectively. - A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE - error. The application verifies that the checksum used is a - collision-proof keyed checksum that uses keys compatible with the - sub-session or session key as appropriate (or with the application - key derived from the session or sub-session keys). If it is not, a - KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address MUST - be included in the control information; the recipient verifies that - the operating system's report of the sender's address matches the - sender's address in the message, and (if a recipient address is - specified or the recipient requires an address) that one of the - recipient's addresses appears as the recipient's address in the - message. To work with network address translation, senders MAY use - the directional address type specified in Section 8.1 for the sender - address and not include recipient addresses. A failed match for - either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp - and usec and/or the sequence number fields are checked. If timestamp - and usec are expected and not present, or if they are present but not - current, the KRB_AP_ERR_SKEW error is generated. Timestamps are not - required to be strictly ordered; they are only required to be in the - skew window. If the server name, along with the client name, time, - - - -Neuman, et al. Standards Track [Page 43] - -RFC 4120 Kerberos V5 July 2005 - - - and microsecond fields from the Authenticator match any recently-seen - (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is - generated. If an incorrect sequence number is included, or if a - sequence number is expected but not present, the KRB_AP_ERR_BADORDER - error is generated. If neither a time-stamp and usec nor a sequence - number is present, a KRB_AP_ERR_MODIFIED error is generated. - Finally, the checksum is computed over the data and control - information, and if it doesn't match the received checksum, a - KRB_AP_ERR_MODIFIED error is generated. - - If all the checks succeed, the application is assured that the - message was generated by its peer and was not modified in transit. - - Implementations SHOULD accept any checksum algorithm they implement - that has both adequate security and keys compatible with the sub- - session or session key. Unkeyed or non-collision-proof checksums are - not suitable for this use. - -3.5. The KRB_PRIV Exchange - - The KRB_PRIV message MAY be used by clients requiring confidentiality - and the ability to detect modifications of exchanged messages. It - achieves this by encrypting the messages and adding control - information. - -3.5.1. Generation of a KRB_PRIV Message - - When an application wishes to send a KRB_PRIV message, it collects - its data and the appropriate control information (specified in - Section 5.7.1) and encrypts them under an encryption key (usually the - last key negotiated via subkeys, or the session key if no negotiation - has occurred). As part of the control information, the client MUST - choose to use either a timestamp or a sequence number (or both); see - the discussion in Section 3.4.1 for guidelines on which to use. - After the user data and control information are encrypted, the client - transmits the ciphertext and some 'envelope' information to the - recipient. - -3.5.2. Receipt of KRB_PRIV Message - - When an application receives a KRB_PRIV message, it verifies it as - follows. If any error occurs, an error code is reported for use by - the application. - - The message is first checked by verifying that the protocol version - and type fields match the current version and KRB_PRIV, respectively. - A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE - error. The application then decrypts the ciphertext and processes - - - -Neuman, et al. Standards Track [Page 44] - -RFC 4120 Kerberos V5 July 2005 - - - the resultant plaintext. If decryption shows that the data has been - modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. - - The sender's address MUST be included in the control information; the - recipient verifies that the operating system's report of the sender's - address matches the sender's address in the message. If a recipient - address is specified or the recipient requires an address, then one - of the recipient's addresses MUST also appear as the recipient's - address in the message. Where a sender's or receiver's address might - not otherwise match the address in a message because of network - address translation, an application MAY be written to use addresses - of the directional address type in place of the actual network - address. - - A failed match for either case generates a KRB_AP_ERR_BADADDR error. - To work with network address translation, implementations MAY use the - directional address type defined in Section 7.1 for the sender - address and include no recipient address. - - Next the timestamp and usec and/or the sequence number fields are - checked. If timestamp and usec are expected and not present, or if - they are present but not current, the KRB_AP_ERR_SKEW error is - generated. If the server name, along with the client name, time, and - microsecond fields from the Authenticator match any such recently- - seen tuples, the KRB_AP_ERR_REPEAT error is generated. If an - incorrect sequence number is included, or if a sequence number is - expected but not present, the KRB_AP_ERR_BADORDER error is generated. - If neither a time-stamp and usec nor a sequence number is present, a - KRB_AP_ERR_MODIFIED error is generated. - - If all the checks succeed, the application can assume the message was - generated by its peer and was securely transmitted (without intruders - seeing the unencrypted contents). - -3.6. The KRB_CRED Exchange - - The KRB_CRED message MAY be used by clients requiring the ability to - send Kerberos credentials from one host to another. It achieves this - by sending the tickets together with encrypted data containing the - session keys and other information associated with the tickets. - -3.6.1. Generation of a KRB_CRED Message - - When an application wishes to send a KRB_CRED message, it first - (using the KRB_TGS exchange) obtains credentials to be sent to the - remote host. It then constructs a KRB_CRED message using the ticket - or tickets so obtained, placing the session key needed to use each - - - - -Neuman, et al. Standards Track [Page 45] - -RFC 4120 Kerberos V5 July 2005 - - - ticket in the key field of the corresponding KrbCredInfo sequence of - the encrypted part of the KRB_CRED message. - - Other information associated with each ticket and obtained during the - KRB_TGS exchange is also placed in the corresponding KrbCredInfo - sequence in the encrypted part of the KRB_CRED message. The current - time and, if they are specifically required by the application, the - nonce, s-address, and r-address fields are placed in the encrypted - part of the KRB_CRED message, which is then encrypted under an - encryption key previously exchanged in the KRB_AP exchange (usually - the last key negotiated via subkeys, or the session key if no - negotiation has occurred). - - Implementation note: When constructing a KRB_CRED message for - inclusion in a GSSAPI initial context token, the MIT implementation - of Kerberos will not encrypt the KRB_CRED message if the session key - is a DES or triple DES key. For interoperability with MIT, the - Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI - token if it is using a DES session key. Starting at version 1.2.5, - MIT Kerberos can receive and decode either encrypted or unencrypted - KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation - of Kerberos can also accept either encrypted or unencrypted KRB_CRED - messages. Since the KRB_CRED message in a GSSAPI token is encrypted - in the authenticator, the MIT behavior does not present a security - problem, although it is a violation of the Kerberos specification. - -3.6.2. Receipt of KRB_CRED Message - - When an application receives a KRB_CRED message, it verifies it. If - any error occurs, an error code is reported for use by the - application. The message is verified by checking that the protocol - version and type fields match the current version and KRB_CRED, - respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or - KRB_AP_ERR_MSG_TYPE error. The application then decrypts the - ciphertext and processes the resultant plaintext. If decryption - shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY - error is generated. - - If present or required, the recipient MAY verify that the operating - system's report of the sender's address matches the sender's address - in the message, and that one of the recipient's addresses appears as - the recipient's address in the message. The address check does not - provide any added security, since the address, if present, has - already been checked in the KRB_AP_REQ message and there is not any - benefit to be gained by an attacker in reflecting a KRB_CRED message - back to its originator. Thus, the recipient MAY ignore the address - even if it is present in order to work better in Network Address - Translation (NAT) environments. A failed match for either case - - - -Neuman, et al. Standards Track [Page 46] - -RFC 4120 Kerberos V5 July 2005 - - - generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the - address check, as the KRB_CRED message cannot generally be reflected - back to the originator. The timestamp and usec fields (and the nonce - field, if required) are checked next. If the timestamp and usec are - not present, or if they are present but not current, the - KRB_AP_ERR_SKEW error is generated. - - If all the checks succeed, the application stores each of the new - tickets in its credentials cache together with the session key and - other information in the corresponding KrbCredInfo sequence from the - encrypted part of the KRB_CRED message. - -3.7. User-to-User Authentication Exchanges - - User-to-User authentication provides a method to perform - authentication when the verifier does not have a access to long-term - service key. This might be the case when running a server (for - example, a window server) as a user on a workstation. In such cases, - the server may have access to the TGT obtained when the user logged - in to the workstation, but because the server is running as an - unprivileged user, it might not have access to system keys. Similar - situations may arise when running peer-to-peer applications. - - Summary - - Message direction Message type Sections - 0. Message from application server Not specified - 1. Client to Kerberos KRB_TGS_REQ 3.3 & 5.4.1 - 2. Kerberos to client KRB_TGS_REP or 3.3 & 5.4.2 - KRB_ERROR 5.9.1 - 3. Client to application server KRB_AP_REQ 3.2 & 5.5.1 - - To address this problem, the Kerberos protocol allows the client to - request that the ticket issued by the KDC be encrypted using a - session key from a TGT issued to the party that will verify the - authentication. This TGT must be obtained from the verifier by means - of an exchange external to the Kerberos protocol, usually as part of - the application protocol. This message is shown in the summary above - as message 0. Note that because the TGT is encrypted in the KDC's - secret key, it cannot be used for authentication without possession - of the corresponding secret key. Furthermore, because the verifier - does not reveal the corresponding secret key, providing a copy of the - verifier's TGT does not allow impersonation of the verifier. - - Message 0 in the table above represents an application-specific - negotiation between the client and server, at the end of which both - have determined that they will use user-to-user authentication, and - the client has obtained the server's TGT. - - - -Neuman, et al. Standards Track [Page 47] - -RFC 4120 Kerberos V5 July 2005 - - - Next, the client includes the server's TGT as an additional ticket in - its KRB_TGS_REQ request to the KDC (message 1 in the table above) and - specifies the ENC-TKT-IN-SKEY option in its request. - - If validated according to the instructions in Section 3.3.3, the - application ticket returned to the client (message 2 in the table - above) will be encrypted using the session key from the additional - ticket and the client will note this when it uses or stores the - application ticket. - - When contacting the server using a ticket obtained for user-to-user - authentication (message 3 in the table above), the client MUST - specify the USE-SESSION-KEY flag in the ap-options field. This tells - the application server to use the session key associated with its TGT - to decrypt the server ticket provided in the application request. - -4. Encryption and Checksum Specifications - - The Kerberos protocols described in this document are designed to - encrypt messages of arbitrary sizes, using stream or block encryption - ciphers. Encryption is used to prove the identities of the network - entities participating in message exchanges. The Key Distribution - Center for each realm is trusted by all principals registered in that - realm to store a secret key in confidence. Proof of knowledge of - this secret key is used to verify the authenticity of a principal. - - The KDC uses the principal's secret key (in the AS exchange) or a - shared session key (in the TGS exchange) to encrypt responses to - ticket requests; the ability to obtain the secret key or session key - implies the knowledge of the appropriate keys and the identity of the - KDC. The ability of a principal to decrypt the KDC response and to - present a Ticket and a properly formed Authenticator (generated with - the session key from the KDC response) to a service verifies the - identity of the principal; likewise the ability of the service to - extract the session key from the Ticket and to prove its knowledge - thereof in a response verifies the identity of the service. - - [RFC3961] defines a framework for defining encryption and checksum - mechanisms for use with Kerberos. It also defines several such - mechanisms, and more may be added in future updates to that document. - - The string-to-key operation provided by [RFC3961] is used to produce - a long-term key for a principal (generally for a user). The default - salt string, if none is provided via pre-authentication data, is the - concatenation of the principal's realm and name components, in order, - with no separators. Unless it is indicated otherwise, the default - string-to-key opaque parameter set as defined in [RFC3961] is used. - - - - -Neuman, et al. Standards Track [Page 48] - -RFC 4120 Kerberos V5 July 2005 - - - Encrypted data, keys, and checksums are transmitted using the - EncryptedData, EncryptionKey, and Checksum data objects defined in - Section 5.2.9. The encryption, decryption, and checksum operations - described in this document use the corresponding encryption, - decryption, and get_mic operations described in [RFC3961], with - implicit "specific key" generation using the "key usage" values - specified in the description of each EncryptedData or Checksum object - to vary the key for each operation. Note that in some cases, the - value to be used is dependent on the method of choosing the key or - the context of the message. - - Key usages are unsigned 32-bit integers; zero is not permitted. The - key usage values for encrypting or checksumming Kerberos messages are - indicated in Section 5 along with the message definitions. The key - usage values 512-1023 are reserved for uses internal to a Kerberos - implementation. (For example, seeding a pseudo-random number - generator with a value produced by encrypting something with a - session key and a key usage value not used for any other purpose.) - Key usage values between 1024 and 2047 (inclusive) are reserved for - application use; applications SHOULD use even values for encryption - and odd values for checksums within this range. Key usage values are - also summarized in a table in Section 7.5.1. - - There might exist other documents that define protocols in terms of - the RFC 1510 encryption types or checksum types. These documents - would not know about key usages. In order that these specifications - continue to be meaningful until they are updated, if no key usage - values are specified, then key usages 1024 and 1025 must be used to - derive keys for encryption and checksums, respectively. (This does - not apply to protocols that do their own encryption independent of - this framework, by directly using the key resulting from the Kerberos - authentication exchange.) New protocols defined in terms of the - Kerberos encryption and checksum types SHOULD use their own key usage - values. - - Unless it is indicated otherwise, no cipher state chaining is done - from one encryption operation to another. - - Implementation note: Although it is not recommended, some application - protocols will continue to use the key data directly, even if only in - currently existing protocol specifications. An implementation - intended to support general Kerberos applications may therefore need - to make key data available, as well as the attributes and operations - described in [RFC3961]. One of the more common reasons for directly - performing encryption is direct control over negotiation and - selection of a "sufficiently strong" encryption algorithm (in the - context of a given application). Although Kerberos does not directly - provide a facility for negotiating encryption types between the - - - -Neuman, et al. Standards Track [Page 49] - -RFC 4120 Kerberos V5 July 2005 - - - application client and server, there are approaches for using - Kerberos to facilitate this negotiation. For example, a client may - request only "sufficiently strong" session key types from the KDC and - expect that any type returned by the KDC will be understood and - supported by the application server. - -5. Message Specifications - - The ASN.1 collected here should be identical to the contents of - Appendix A. In the case of a conflict, the contents of Appendix A - shall take precedence. - - The Kerberos protocol is defined here in terms of Abstract Syntax - Notation One (ASN.1) [X680], which provides a syntax for specifying - both the abstract layout of protocol messages as well as their - encodings. Implementors not utilizing an existing ASN.1 compiler or - support library are cautioned to understand the actual ASN.1 - specification thoroughly in order to ensure correct implementation - behavior. There is more complexity in the notation than is - immediately obvious, and some tutorials and guides to ASN.1 are - misleading or erroneous. - - Note that in several places, changes to abstract types from RFC 1510 - have been made. This is in part to address widespread assumptions - that various implementors have made, in some cases resulting in - unintentional violations of the ASN.1 standard. These are clearly - flagged where they occur. The differences between the abstract types - in RFC 1510 and abstract types in this document can cause - incompatible encodings to be emitted when certain encoding rules, - e.g., the Packed Encoding Rules (PER), are used. This theoretical - incompatibility should not be relevant for Kerberos, since Kerberos - explicitly specifies the use of the Distinguished Encoding Rules - (DER). It might be an issue for protocols seeking to use Kerberos - types with other encoding rules. (This practice is not recommended.) - With very few exceptions (most notably the usages of BIT STRING), the - encodings resulting from using the DER remain identical between the - types defined in RFC 1510 and the types defined in this document. - - The type definitions in this section assume an ASN.1 module - definition of the following form: - - - - - - - - - - - -Neuman, et al. Standards Track [Page 50] - -RFC 4120 Kerberos V5 July 2005 - - - KerberosV5Spec2 { - iso(1) identified-organization(3) dod(6) internet(1) - security(5) kerberosV5(2) modules(4) krb5spec2(2) - } DEFINITIONS EXPLICIT TAGS ::= BEGIN - - -- rest of definitions here - - END - - This specifies that the tagging context for the module will be - explicit and non-automatic. - - Note that in some other publications (such as [RFC1510] and - [RFC1964]), the "dod" portion of the object identifier is erroneously - specified as having the value "5". In the case of RFC 1964, use of - the "correct" OID value would result in a change in the wire - protocol; therefore, it remains unchanged for now. - - Note that elsewhere in this document, nomenclature for various - message types is inconsistent, but it largely follows C language - conventions, including use of underscore (_) characters and all-caps - spelling of names intended to be numeric constants. Also, in some - places, identifiers (especially those referring to constants) are - written in all-caps in order to distinguish them from surrounding - explanatory text. - - The ASN.1 notation does not permit underscores in identifiers, so in - actual ASN.1 definitions, underscores are replaced with hyphens (-). - Additionally, structure member names and defined values in ASN.1 MUST - begin with a lowercase letter, whereas type names MUST begin with an - uppercase letter. - -5.1. Specific Compatibility Notes on ASN.1 - - For compatibility purposes, implementors should heed the following - specific notes regarding the use of ASN.1 in Kerberos. These notes - do not describe deviations from standard usage of ASN.1. The purpose - of these notes is instead to describe some historical quirks and - non-compliance of various implementations, as well as historical - ambiguities, which, although they are valid ASN.1, can lead to - confusion during implementation. - -5.1.1. ASN.1 Distinguished Encoding Rules - - The encoding of Kerberos protocol messages shall obey the - Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. - Some implementations (believed primarily to be those derived from DCE - 1.1 and earlier) are known to use the more general Basic Encoding - - - -Neuman, et al. Standards Track [Page 51] - -RFC 4120 Kerberos V5 July 2005 - - - Rules (BER); in particular, these implementations send indefinite - encodings of lengths. Implementations MAY accept such encodings in - the interest of backward compatibility, though implementors are - warned that decoding fully-general BER is fraught with peril. - -5.1.2. Optional Integer Fields - - Some implementations do not internally distinguish between an omitted - optional integer value and a transmitted value of zero. The places - in the protocol where this is relevant include various microseconds - fields, nonces, and sequence numbers. Implementations SHOULD treat - omitted optional integer values as having been transmitted with a - value of zero, if the application is expecting this. - -5.1.3. Empty SEQUENCE OF Types - - There are places in the protocol where a message contains a SEQUENCE - OF type as an optional member. This can result in an encoding that - contains an empty SEQUENCE OF encoding. The Kerberos protocol does - not semantically distinguish between an absent optional SEQUENCE OF - type and a present optional but empty SEQUENCE OF type. - Implementations SHOULD NOT send empty SEQUENCE OF encodings that are - marked OPTIONAL, but SHOULD accept them as being equivalent to an - omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos - messages, instances of these problematic optional SEQUENCE OF types - are indicated with a comment. - -5.1.4. Unrecognized Tag Numbers - - Future revisions to this protocol may include new message types with - different APPLICATION class tag numbers. Such revisions should - protect older implementations by only sending the message types to - parties that are known to understand them; e.g., by means of a flag - bit set by the receiver in a preceding request. In the interest of - robust error handling, implementations SHOULD gracefully handle - receiving a message with an unrecognized tag anyway, and return an - error message, if appropriate. - - In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the - incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT - respond to messages received with an unknown tag over UDP transport - in order to avoid denial of service attacks. For non-KDC - applications, the Kerberos implementation typically indicates an - error to the application which takes appropriate steps based on the - application protocol. - - - - - - -Neuman, et al. Standards Track [Page 52] - -RFC 4120 Kerberos V5 July 2005 - - -5.1.5. Tag Numbers Greater Than 30 - - A naive implementation of a DER ASN.1 decoder may experience problems - with ASN.1 tag numbers greater than 30, due to such tag numbers being - encoded using more than one byte. Future revisions of this protocol - may utilize tag numbers greater than 30, and implementations SHOULD - be prepared to gracefully return an error, if appropriate, when they - do not recognize the tag. - -5.2. Basic Kerberos Types - - This section defines a number of basic types that are potentially - used in multiple Kerberos protocol messages. - -5.2.1. KerberosString - - The original specification of the Kerberos protocol in RFC 1510 uses - GeneralString in numerous places for human-readable string data. - Historical implementations of Kerberos cannot utilize the full power - of GeneralString. This ASN.1 type requires the use of designation - and invocation escape sequences as specified in ISO-2022/ECMA-35 - [ISO-2022/ECMA-35] to switch character sets, and the default - character set that is designated as G0 is the ISO-646/ECMA-6 - [ISO-646/ECMA-6] International Reference Version (IRV) (a.k.a. U.S. - ASCII), which mostly works. - - ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) - and two Control-function code elements (C0..C1). DER prohibits the - designation of character sets as any but the G0 and C0 sets. - Unfortunately, this seems to have the side effect of prohibiting the - use of ISO-8859 (ISO Latin) [ISO-8859] character sets or any other - character sets that utilize a 96-character set, as ISO-2022/ECMA-35 - prohibits designating them as the G0 code element. This side effect - is being investigated in the ASN.1 standards community. - - In practice, many implementations treat GeneralStrings as if they - were 8-bit strings of whichever character set the implementation - defaults to, without regard to correct usage of character-set - designation escape sequences. The default character set is often - determined by the current user's operating system-dependent locale. - At least one major implementation places unescaped UTF-8 encoded - Unicode characters in the GeneralString. This failure to adhere to - the GeneralString specifications results in interoperability issues - when conflicting character encodings are utilized by the Kerberos - clients, services, and KDC. - - - - - - -Neuman, et al. Standards Track [Page 53] - -RFC 4120 Kerberos V5 July 2005 - - - This unfortunate situation is the result of improper documentation of - the restrictions of the ASN.1 GeneralString type in prior Kerberos - specifications. - - The new (post-RFC 1510) type KerberosString, defined below, is a - GeneralString that is constrained to contain only characters in - IA5String. - - KerberosString ::= GeneralString (IA5String) - - In general, US-ASCII control characters should not be used in - KerberosString. Control characters SHOULD NOT be used in principal - names or realm names. - - For compatibility, implementations MAY choose to accept GeneralString - values that contain characters other than those permitted by - IA5String, but they should be aware that character set designation - codes will likely be absent, and that the encoding should probably be - treated as locale-specific in almost every way. Implementations MAY - also choose to emit GeneralString values that are beyond those - permitted by IA5String, but they should be aware that doing so is - extraordinarily risky from an interoperability perspective. - - Some existing implementations use GeneralString to encode unescaped - locale-specific characters. This is a violation of the ASN.1 - standard. Most of these implementations encode US-ASCII in the - left-hand half, so as long as the implementation transmits only - US-ASCII, the ASN.1 standard is not violated in this regard. As soon - as such an implementation encodes unescaped locale-specific - characters with the high bit set, it violates the ASN.1 standard. - - Other implementations have been known to use GeneralString to contain - a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 - is a different encoding, not a 94 or 96 character "G" set as defined - by ISO 2022. It is believed that these implementations do not even - use the ISO 2022 escape sequence to change the character encoding. - Even if implementations were to announce the encoding change by using - that escape sequence, the ASN.1 standard prohibits the use of any - escape sequences other than those used to designate/invoke "G" or "C" - sets allowed by GeneralString. - - Future revisions to this protocol will almost certainly allow for a - more interoperable representation of principal names, probably - including UTF8String. - - Note that applying a new constraint to a previously unconstrained - type constitutes creation of a new ASN.1 type. In this particular - case, the change does not result in a changed encoding under DER. - - - -Neuman, et al. Standards Track [Page 54] - -RFC 4120 Kerberos V5 July 2005 - - -5.2.2. Realm and PrincipalName - - Realm ::= KerberosString - - PrincipalName ::= SEQUENCE { - name-type [0] Int32, - name-string [1] SEQUENCE OF KerberosString - } - - Kerberos realm names are encoded as KerberosStrings. Realms shall - not contain a character with the code 0 (the US-ASCII NUL). Most - realms will usually consist of several components separated by - periods (.), in the style of Internet Domain Names, or separated by - slashes (/), in the style of X.500 names. Acceptable forms for realm - names are specified in Section 6.1. A PrincipalName is a typed - sequence of components consisting of the following subfields: - - name-type - This field specifies the type of name that follows. Pre-defined - values for this field are specified in Section 6.2. The name-type - SHOULD be treated as a hint. Ignoring the name type, no two names - can be the same (i.e., at least one of the components, or the - realm, must be different). - - name-string - This field encodes a sequence of components that form a name, each - component encoded as a KerberosString. Taken together, a - PrincipalName and a Realm form a principal identifier. Most - PrincipalNames will have only a few components (typically one or - two). - -5.2.3. KerberosTime - - KerberosTime ::= GeneralizedTime -- with no fractional seconds - - The timestamps used in Kerberos are encoded as GeneralizedTimes. A - KerberosTime value shall not include any fractional portions of the - seconds. As required by the DER, it further shall not include any - separators, and it shall specify the UTC time zone (Z). Example: The - only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 - November 1985 is 19851106210627Z. - -5.2.4. Constrained Integer Types - - Some integer members of types SHOULD be constrained to values - representable in 32 bits, for compatibility with reasonable - implementation limits. - - - - -Neuman, et al. Standards Track [Page 55] - -RFC 4120 Kerberos V5 July 2005 - - - Int32 ::= INTEGER (-2147483648..2147483647) - -- signed values representable in 32 bits - - UInt32 ::= INTEGER (0..4294967295) - -- unsigned 32 bit values - - Microseconds ::= INTEGER (0..999999) - -- microseconds - - Although this results in changes to the abstract types from the RFC - 1510 version, the encoding in DER should be unaltered. Historical - implementations were typically limited to 32-bit integer values - anyway, and assigned numbers SHOULD fall in the space of integer - values representable in 32 bits in order to promote interoperability - anyway. - - Several integer fields in messages are constrained to fixed values. - - pvno - also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always - the constant integer 5. There is no easy way to make this field - into a useful protocol version number, so its value is fixed. - - msg-type - this integer field is usually identical to the application tag - number of the containing message type. - -5.2.5. HostAddress and HostAddresses - - HostAddress ::= SEQUENCE { - addr-type [0] Int32, - address [1] OCTET STRING - } - - -- NOTE: HostAddresses is always used as an OPTIONAL field and - -- should not be empty. - HostAddresses -- NOTE: subtly different from rfc1510, - -- but has a value mapping and encodes the same - ::= SEQUENCE OF HostAddress - - The host address encodings consist of two fields: - - addr-type - This field specifies the type of address that follows. Pre- - defined values for this field are specified in Section 7.5.3. - - address - This field encodes a single address of type addr-type. - - - -Neuman, et al. Standards Track [Page 56] - -RFC 4120 Kerberos V5 July 2005 - - -5.2.6. AuthorizationData - - -- NOTE: AuthorizationData is always used as an OPTIONAL field and - -- should not be empty. - AuthorizationData ::= SEQUENCE OF SEQUENCE { - ad-type [0] Int32, - ad-data [1] OCTET STRING - } - - ad-data - This field contains authorization data to be interpreted according - to the value of the corresponding ad-type field. - - ad-type - This field specifies the format for the ad-data subfield. All - negative values are reserved for local use. Non-negative values - are reserved for registered use. - - Each sequence of type and data is referred to as an authorization - element. Elements MAY be application specific; however, there is a - common set of recursive elements that should be understood by all - implementations. These elements contain other elements embedded - within them, and the interpretation of the encapsulating element - determines which of the embedded elements must be interpreted, and - which may be ignored. - - These common authorization data elements are recursively defined, - meaning that the ad-data for these types will itself contain a - sequence of authorization data whose interpretation is affected by - the encapsulating element. Depending on the meaning of the - encapsulating element, the encapsulated elements may be ignored, - might be interpreted as issued directly by the KDC, or might be - stored in a separate plaintext part of the ticket. The types of the - encapsulating elements are specified as part of the Kerberos - specification because the behavior based on these values should be - understood across implementations, whereas other elements need only - be understood by the applications that they affect. - - Authorization data elements are considered critical if present in a - ticket or authenticator. If an unknown authorization data element - type is received by a server either in an AP-REQ or in a ticket - contained in an AP-REQ, then, unless it is encapsulated in a known - authorization data element amending the criticality of the elements - it contains, authentication MUST fail. Authorization data is - intended to restrict the use of a ticket. If the service cannot - determine whether the restriction applies to that service, then a - - - - - -Neuman, et al. Standards Track [Page 57] - -RFC 4120 Kerberos V5 July 2005 - - - security weakness may result if the ticket can be used for that - service. Authorization elements that are optional can be enclosed in - an AD-IF-RELEVANT element. - - In the definitions that follow, the value of the ad-type for the - element will be specified as the least significant part of the - subsection number, and the value of the ad-data will be as shown in - the ASN.1 structure that follows the subsection heading. - - Contents of ad-data ad-type - - DER encoding of AD-IF-RELEVANT 1 - - DER encoding of AD-KDCIssued 4 - - DER encoding of AD-AND-OR 5 - - DER encoding of AD-MANDATORY-FOR-KDC 8 - -5.2.6.1. IF-RELEVANT - - AD-IF-RELEVANT ::= AuthorizationData - - AD elements encapsulated within the if-relevant element are intended - for interpretation only by application servers that understand the - particular ad-type of the embedded element. Application servers that - do not understand the type of an element embedded within the - if-relevant element MAY ignore the uninterpretable element. This - element promotes interoperability across implementations that may - have local extensions for authorization. The ad-type for - AD-IF-RELEVANT is (1). - -5.2.6.2. KDCIssued - - AD-KDCIssued ::= SEQUENCE { - ad-checksum [0] Checksum, - i-realm [1] Realm OPTIONAL, - i-sname [2] PrincipalName OPTIONAL, - elements [3] AuthorizationData - } - - ad-checksum - A cryptographic checksum computed over the DER encoding of the - AuthorizationData in the "elements" field, keyed with the session - key. Its checksumtype is the mandatory checksum type for the - encryption type of the session key, and its key usage value is 19. - - - - - -Neuman, et al. Standards Track [Page 58] - -RFC 4120 Kerberos V5 July 2005 - - - i-realm, i-sname - The name of the issuing principal if different from that of the - KDC itself. This field would be used when the KDC can verify the - authenticity of elements signed by the issuing principal, and it - allows this KDC to notify the application server of the validity - of those elements. - - elements - A sequence of authorization data elements issued by the KDC. - - The KDC-issued ad-data field is intended to provide a means for - Kerberos principal credentials to embed within themselves privilege - attributes and other mechanisms for positive authorization, - amplifying the privileges of the principal beyond what can be done - using credentials without such an a-data element. - - The above means cannot be provided without this element because the - definition of the authorization-data field allows elements to be - added at will by the bearer of a TGT at the time when they request - service tickets, and elements may also be added to a delegated ticket - by inclusion in the authenticator. - - For KDC-issued elements, this is prevented because the elements are - signed by the KDC by including a checksum encrypted using the - server's key (the same key used to encrypt the ticket or a key - derived from that key). Elements encapsulated with in the KDC-issued - element MUST be ignored by the application server if this "signature" - is not present. Further, elements encapsulated within this element - from a TGT MAY be interpreted by the KDC, and used as a basis - according to policy for including new signed elements within - derivative tickets, but they will not be copied to a derivative - ticket directly. If they are copied directly to a derivative ticket - by a KDC that is not aware of this element, the signature will not be - correct for the application ticket elements, and the field will be - ignored by the application server. - - This element and the elements it encapsulates MAY safely be ignored - by applications, application servers, and KDCs that do not implement - this element. - - The ad-type for AD-KDC-ISSUED is (4). - -5.2.6.3. AND-OR - - AD-AND-OR ::= SEQUENCE { - condition-count [0] Int32, - elements [1] AuthorizationData - } - - - -Neuman, et al. Standards Track [Page 59] - -RFC 4120 Kerberos V5 July 2005 - - - When restrictive AD elements are encapsulated within the and-or - element, the and-or element is considered satisfied if and only if at - least the number of encapsulated elements specified in condition- - count are satisfied. Therefore, this element MAY be used to - implement an "or" operation by setting the condition-count field to - 1, and it MAY specify an "and" operation by setting the condition - count to the number of embedded elements. Application servers that - do not implement this element MUST reject tickets that contain - authorization data elements of this type. - - The ad-type for AD-AND-OR is (5). - -5.2.6.4. MANDATORY-FOR-KDC - - AD-MANDATORY-FOR-KDC ::= AuthorizationData - - AD elements encapsulated within the mandatory-for-kdc element are to - be interpreted by the KDC. KDCs that do not understand the type of - an element embedded within the mandatory-for-kdc element MUST reject - the request. - - The ad-type for AD-MANDATORY-FOR-KDC is (8). - -5.2.7. PA-DATA - - Historically, PA-DATA have been known as "pre-authentication data", - meaning that they were used to augment the initial authentication - with the KDC. Since that time, they have also been used as a typed - hole with which to extend protocol exchanges with the KDC. - - PA-DATA ::= SEQUENCE { - -- NOTE: first tag is [1], not [0] - padata-type [1] Int32, - padata-value [2] OCTET STRING -- might be encoded AP-REQ - } - - padata-type - Indicates the way that the padata-value element is to be - interpreted. Negative values of padata-type are reserved for - unregistered use; non-negative values are used for a registered - interpretation of the element type. - - padata-value - Usually contains the DER encoding of another type; the padata-type - field identifies which type is encoded here. - - - - - - -Neuman, et al. Standards Track [Page 60] - -RFC 4120 Kerberos V5 July 2005 - - - padata-type Name Contents of padata-value - - 1 pa-tgs-req DER encoding of AP-REQ - - 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP - - 3 pa-pw-salt salt (not ASN.1 encoded) - - 11 pa-etype-info DER encoding of ETYPE-INFO - - 19 pa-etype-info2 DER encoding of ETYPE-INFO2 - - This field MAY also contain information needed by certain - extensions to the Kerberos protocol. For example, it might be - used to verify the identity of a client initially before any - response is returned. - - The padata field can also contain information needed to help the - KDC or the client select the key needed for generating or - decrypting the response. This form of the padata is useful for - supporting the use of certain token cards with Kerberos. The - details of such extensions are specified in separate documents. - See [Pat92] for additional uses of this field. - -5.2.7.1. PA-TGS-REQ - - In the case of requests for additional tickets (KRB_TGS_REQ), - padata-value will contain an encoded AP-REQ. The checksum in the - authenticator (which MUST be collision-proof) is to be computed over - the KDC-REQ-BODY encoding. - -5.2.7.2. Encrypted Timestamp Pre-authentication - - There are pre-authentication types that may be used to pre- - authenticate a client by means of an encrypted timestamp. - - PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC - - PA-ENC-TS-ENC ::= SEQUENCE { - patimestamp [0] KerberosTime -- client's time --, - pausec [1] Microseconds OPTIONAL - } - - Patimestamp contains the client's time, and pausec contains the - microseconds, which MAY be omitted if a client will not generate more - than one request per second. The ciphertext (padata-value) consists - of the PA-ENC-TS-ENC encoding, encrypted using the client's secret - key and a key usage value of 1. - - - -Neuman, et al. Standards Track [Page 61] - -RFC 4120 Kerberos V5 July 2005 - - - This pre-authentication type was not present in RFC 1510, but many - implementations support it. - -5.2.7.3. PA-PW-SALT - - The padata-value for this pre-authentication type contains the salt - for the string-to-key to be used by the client to obtain the key for - decrypting the encrypted part of an AS-REP message. Unfortunately, - for historical reasons, the character set to be used is unspecified - and probably locale-specific. - - This pre-authentication type was not present in RFC 1510, but many - implementations support it. It is necessary in any case where the - salt for the string-to-key algorithm is not the default. - - In the trivial example, a zero-length salt string is very commonplace - for realms that have converted their principal databases from - Kerberos Version 4. - - A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message - that requests additional pre-authentication. Implementation note: - Some KDC implementations issue an erroneous PA-PW-SALT when issuing a - KRB-ERROR message that requests additional pre-authentication. - Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a - KRB-ERROR message that requests additional pre-authentication. As - noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the - client's AS-REQ includes at least one "newer" etype. - -5.2.7.4. PA-ETYPE-INFO - - The ETYPE-INFO pre-authentication type is sent by the KDC in a - KRB-ERROR indicating a requirement for additional pre-authentication. - It is usually used to notify a client of which key to use for the - encryption of an encrypted timestamp for the purposes of sending a - PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an - AS-REP to provide information to the client about which key salt to - use for the string-to-key to be used by the client to obtain the key - for decrypting the encrypted part the AS-REP. - - ETYPE-INFO-ENTRY ::= SEQUENCE { - etype [0] Int32, - salt [1] OCTET STRING OPTIONAL - } - - ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY - - The salt, like that of PA-PW-SALT, is also completely unspecified - with respect to character set and is probably locale-specific. - - - -Neuman, et al. Standards Track [Page 62] - -RFC 4120 Kerberos V5 July 2005 - - - If ETYPE-INFO is sent in an AS-REP, there shall be exactly one - ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in - the AS-REP. - - This pre-authentication type was not present in RFC 1510, but many - implementations that support encrypted timestamps for pre- - authentication need to support ETYPE-INFO as well. As noted in - Section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's - AS-REQ includes at least one "newer" etype. - -5.2.7.5. PA-ETYPE-INFO2 - - The ETYPE-INFO2 pre-authentication type is sent by the KDC in a - KRB-ERROR indicating a requirement for additional pre-authentication. - It is usually used to notify a client of which key to use for the - encryption of an encrypted timestamp for the purposes of sending a - PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an - AS-REP to provide information to the client about which key salt to - use for the string-to-key to be used by the client to obtain the key - for decrypting the encrypted part the AS-REP. - -ETYPE-INFO2-ENTRY ::= SEQUENCE { - etype [0] Int32, - salt [1] KerberosString OPTIONAL, - s2kparams [2] OCTET STRING OPTIONAL -} - -ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY - - The type of the salt is KerberosString, but existing installations - might have locale-specific characters stored in salt strings, and - implementors MAY choose to handle them. - - The interpretation of s2kparams is specified in the cryptosystem - description associated with the etype. Each cryptosystem has a - default interpretation of s2kparams that will hold if that element is - omitted from the encoding of ETYPE-INFO2-ENTRY. - - If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one - ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in - the AS-REP. - - The preferred ordering of the "hint" pre-authentication data that - affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO, - followed by PW-SALT. As noted in Section 3.1.3, a KDC MUST NOT send - ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one - "newer" etype. - - - - -Neuman, et al. Standards Track [Page 63] - -RFC 4120 Kerberos V5 July 2005 - - - The ETYPE-INFO2 pre-authentication type was not present in RFC 1510. - -5.2.8. KerberosFlags - - For several message types, a specific constrained bit string type, - KerberosFlags, is used. - - KerberosFlags ::= BIT STRING (SIZE (32..MAX)) - -- minimum number of bits shall be sent, - -- but no fewer than 32 - - Compatibility note: The following paragraphs describe a change from - the RFC 1510 description of bit strings that would result in - incompatility in the case of an implementation that strictly - conformed to ASN.1 DER and RFC 1510. - - ASN.1 bit strings have multiple uses. The simplest use of a bit - string is to contain a vector of bits, with no particular meaning - attached to individual bits. This vector of bits is not necessarily - a multiple of eight bits long. The use in Kerberos of a bit string - as a compact boolean vector wherein each element has a distinct - meaning poses some problems. The natural notation for a compact - boolean vector is the ASN.1 "NamedBit" notation, and the DER require - that encodings of a bit string using "NamedBit" notation exclude any - trailing zero bits. This truncation is easy to neglect, especially - given C language implementations that naturally choose to store - boolean vectors as 32-bit integers. - - For example, if the notation for KDCOptions were to include the - "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be - encoded had only the "forwardable" (bit number one) bit set, the DER - encoding MUST include only two bits: the first reserved bit - ("reserved", bit number zero, value zero) and the one-valued bit (bit - number one) for "forwardable". - - Most existing implementations of Kerberos unconditionally send 32 - bits on the wire when encoding bit strings used as boolean vectors. - This behavior violates the ASN.1 syntax used for flag values in RFC - 1510, but it occurs on such a widely installed base that the protocol - description is being modified to accommodate it. - - Consequently, this document removes the "NamedBit" notations for - individual bits, relegating them to comments. The size constraint on - the KerberosFlags type requires that at least 32 bits be encoded at - all times, though a lenient implementation MAY choose to accept fewer - than 32 bits and to treat the missing bits as set to zero. - - - - - -Neuman, et al. Standards Track [Page 64] - -RFC 4120 Kerberos V5 July 2005 - - - Currently, no uses of KerberosFlags specify more than 32 bits' worth - of flags, although future revisions of this document may do so. When - more than 32 bits are to be transmitted in a KerberosFlags value, - future revisions to this document will likely specify that the - smallest number of bits needed to encode the highest-numbered one- - valued bit should be sent. This is somewhat similar to the DER - encoding of a bit string that is declared with the "NamedBit" - notation. - -5.2.9. Cryptosystem-Related Types - - Many Kerberos protocol messages contain an EncryptedData as a - container for arbitrary encrypted data, which is often the encrypted - encoding of another data type. Fields within EncryptedData assist - the recipient in selecting a key with which to decrypt the enclosed - data. - - EncryptedData ::= SEQUENCE { - etype [0] Int32 -- EncryptionType --, - kvno [1] UInt32 OPTIONAL, - cipher [2] OCTET STRING -- ciphertext - } - - etype - This field identifies which encryption algorithm was used to - encipher the cipher. - - kvno - This field contains the version number of the key under which data - is encrypted. It is only present in messages encrypted under long - lasting keys, such as principals' secret keys. - - cipher - This field contains the enciphered text, encoded as an OCTET - STRING. (Note that the encryption mechanisms defined in [RFC3961] - MUST incorporate integrity protection as well, so no additional - checksum is required.) - - The EncryptionKey type is the means by which cryptographic keys used - for encryption are transferred. - - EncryptionKey ::= SEQUENCE { - keytype [0] Int32 -- actually encryption type --, - keyvalue [1] OCTET STRING - } - - - - - - -Neuman, et al. Standards Track [Page 65] - -RFC 4120 Kerberos V5 July 2005 - - - keytype - This field specifies the encryption type of the encryption key - that follows in the keyvalue field. Although its name is - "keytype", it actually specifies an encryption type. Previously, - multiple cryptosystems that performed encryption differently but - were capable of using keys with the same characteristics were - permitted to share an assigned number to designate the type of - key; this usage is now deprecated. - - keyvalue - This field contains the key itself, encoded as an octet string. - - Messages containing cleartext data to be authenticated will usually - do so by using a member of type Checksum. Most instances of Checksum - use a keyed hash, though exceptions will be noted. - - Checksum ::= SEQUENCE { - cksumtype [0] Int32, - checksum [1] OCTET STRING - } - - cksumtype - This field indicates the algorithm used to generate the - accompanying checksum. - - checksum - This field contains the checksum itself, encoded as an octet - string. - - See Section 4 for a brief description of the use of encryption and - checksums in Kerberos. - -5.3. Tickets - - This section describes the format and encryption parameters for - tickets and authenticators. When a ticket or authenticator is - included in a protocol message, it is treated as an opaque object. A - ticket is a record that helps a client authenticate to a service. A - Ticket contains the following information: - - Ticket ::= [APPLICATION 1] SEQUENCE { - tkt-vno [0] INTEGER (5), - realm [1] Realm, - sname [2] PrincipalName, - enc-part [3] EncryptedData -- EncTicketPart - } - - -- Encrypted part of ticket - - - -Neuman, et al. Standards Track [Page 66] - -RFC 4120 Kerberos V5 July 2005 - - - EncTicketPart ::= [APPLICATION 3] SEQUENCE { - flags [0] TicketFlags, - key [1] EncryptionKey, - crealm [2] Realm, - cname [3] PrincipalName, - transited [4] TransitedEncoding, - authtime [5] KerberosTime, - starttime [6] KerberosTime OPTIONAL, - endtime [7] KerberosTime, - renew-till [8] KerberosTime OPTIONAL, - caddr [9] HostAddresses OPTIONAL, - authorization-data [10] AuthorizationData OPTIONAL - } - - -- encoded Transited field - TransitedEncoding ::= SEQUENCE { - tr-type [0] Int32 -- must be registered --, - contents [1] OCTET STRING - } - - TicketFlags ::= KerberosFlags - -- reserved(0), - -- forwardable(1), - -- forwarded(2), - -- proxiable(3), - -- proxy(4), - -- may-postdate(5), - -- postdated(6), - -- invalid(7), - -- renewable(8), - -- initial(9), - -- pre-authent(10), - -- hw-authent(11), - -- the following are new since 1510 - -- transited-policy-checked(12), - -- ok-as-delegate(13) - - tkt-vno - This field specifies the version number for the ticket format. - This document describes version number 5. - - realm - This field specifies the realm that issued a ticket. It also - serves to identify the realm part of the server's principal - identifier. Since a Kerberos server can only issue tickets for - servers within its realm, the two will always be identical. - - - - - -Neuman, et al. Standards Track [Page 67] - -RFC 4120 Kerberos V5 July 2005 - - - sname - This field specifies all components of the name part of the - server's identity, including those parts that identify a specific - instance of a service. - - enc-part - This field holds the encrypted encoding of the EncTicketPart - sequence. It is encrypted in the key shared by Kerberos and the - end server (the server's secret key), using a key usage value of - 2. - - flags - This field indicates which of various options were used or - requested when the ticket was issued. The meanings of the flags - are as follows: - - Bit(s) Name Description - - 0 reserved Reserved for future expansion of this field. - - 1 forwardable The FORWARDABLE flag is normally only - interpreted by the TGS, and can be ignored - by end servers. When set, this flag tells - the ticket-granting server that it is OK to - issue a new TGT with a different network - address based on the presented ticket. - - 2 forwarded When set, this flag indicates that the - ticket has either been forwarded or was - issued based on authentication involving a - forwarded TGT. - - 3 proxiable The PROXIABLE flag is normally only - interpreted by the TGS, and can be ignored - by end servers. The PROXIABLE flag has an - interpretation identical to that of the - FORWARDABLE flag, except that the PROXIABLE - flag tells the ticket-granting server that - only non-TGTs may be issued with different - network addresses. - - 4 proxy When set, this flag indicates that a ticket - is a proxy. - - 5 may-postdate The MAY-POSTDATE flag is normally only - interpreted by the TGS, and can be ignored - by end servers. This flag tells the - - - - -Neuman, et al. Standards Track [Page 68] - -RFC 4120 Kerberos V5 July 2005 - - - ticket-granting server that a post-dated - ticket MAY be issued based on this TGT. - - 6 postdated This flag indicates that this ticket has - been postdated. The end-service can check - the authtime field to see when the original - authentication occurred. - - 7 invalid This flag indicates that a ticket is - invalid, and it must be validated by the KDC - before use. Application servers must reject - tickets which have this flag set. - - 8 renewable The RENEWABLE flag is normally only - interpreted by the TGS, and can usually be - ignored by end servers (some particularly - careful servers MAY disallow renewable - tickets). A renewable ticket can be used to - obtain a replacement ticket that expires at - a later date. - - 9 initial This flag indicates that this ticket was - issued using the AS protocol, and not issued - based on a TGT. - - 10 pre-authent This flag indicates that during initial - authentication, the client was authenticated - by the KDC before a ticket was issued. The - strength of the pre-authentication method is - not indicated, but is acceptable to the KDC. - - 11 hw-authent This flag indicates that the protocol - employed for initial authentication required - the use of hardware expected to be possessed - solely by the named client. The hardware - authentication method is selected by the KDC - and the strength of the method is not - indicated. - - 12 transited- This flag indicates that the KDC for - policy-checked the realm has checked the transited field - against a realm-defined policy for trusted - certifiers. If this flag is reset (0), then - the application server must check the - transited field itself, and if unable to do - so, it must reject the authentication. If - the flag is set (1), then the application - server MAY skip its own validation of the - - - -Neuman, et al. Standards Track [Page 69] - -RFC 4120 Kerberos V5 July 2005 - - - transited field, relying on the validation - performed by the KDC. At its option the - application server MAY still apply its own - validation based on a separate policy for - acceptance. - - This flag is new since RFC 1510. - - 13 ok-as-delegate This flag indicates that the server (not the - client) specified in the ticket has been - determined by policy of the realm to be a - suitable recipient of delegation. A client - can use the presence of this flag to help it - decide whether to delegate credentials - (either grant a proxy or a forwarded TGT) to - this server. The client is free to ignore - the value of this flag. When setting this - flag, an administrator should consider the - security and placement of the server on - which the service will run, as well as - whether the service requires the use of - delegated credentials. - - This flag is new since RFC 1510. - - 14-31 reserved Reserved for future use. - - key - This field exists in the ticket and the KDC response and is used - to pass the session key from Kerberos to the application server - and the client. - - crealm - This field contains the name of the realm in which the client is - registered and in which initial authentication took place. - - cname - This field contains the name part of the client's principal - identifier. - - transited - This field lists the names of the Kerberos realms that took part - in authenticating the user to whom this ticket was issued. It - does not specify the order in which the realms were transited. - See Section 3.3.3.2 for details on how this field encodes the - traversed realms. When the names of CAs are to be embedded in the - transited field (as specified for some extensions to the - - - - -Neuman, et al. Standards Track [Page 70] - -RFC 4120 Kerberos V5 July 2005 - - - protocol), the X.500 names of the CAs SHOULD be mapped into items - in the transited field using the mapping defined by RFC 2253. - - authtime - This field indicates the time of initial authentication for the - named principal. It is the time of issue for the original ticket - on which this ticket is based. It is included in the ticket to - provide additional information to the end service, and to provide - the necessary information for implementation of a "hot list" - service at the KDC. An end service that is particularly paranoid - could refuse to accept tickets for which the initial - authentication occurred "too far" in the past. This field is also - returned as part of the response from the KDC. When it is - returned as part of the response to initial authentication - (KRB_AS_REP), this is the current time on the Kerberos server. It - is NOT recommended that this time value be used to adjust the - workstation's clock, as the workstation cannot reliably determine - that such a KRB_AS_REP actually came from the proper KDC in a - timely manner. - - starttime - This field in the ticket specifies the time after which the ticket - is valid. Together with endtime, this field specifies the life of - the ticket. If the starttime field is absent from the ticket, - then the authtime field SHOULD be used in its place to determine - the life of the ticket. - - endtime - This field contains the time after which the ticket will not be - honored (its expiration time). Note that individual services MAY - place their own limits on the life of a ticket and MAY reject - tickets which have not yet expired. As such, this is really an - upper bound on the expiration time for the ticket. - - renew-till - This field is only present in tickets that have the RENEWABLE flag - set in the flags field. It indicates the maximum endtime that may - be included in a renewal. It can be thought of as the absolute - expiration time for the ticket, including all renewals. - - caddr - This field in a ticket contains zero (if omitted) or more (if - present) host addresses. These are the addresses from which the - ticket can be used. If there are no addresses, the ticket can be - used from any location. The decision by the KDC to issue or by - the end server to accept addressless tickets is a policy decision - and is left to the Kerberos and end-service administrators; they - MAY refuse to issue or accept such tickets. Because of the wide - - - -Neuman, et al. Standards Track [Page 71] - -RFC 4120 Kerberos V5 July 2005 - - - deployment of network address translation, it is recommended that - policy allow the issue and acceptance of such tickets. - - Network addresses are included in the ticket to make it harder for - an attacker to use stolen credentials. Because the session key is - not sent over the network in cleartext, credentials can't be - stolen simply by listening to the network; an attacker has to gain - access to the session key (perhaps through operating system - security breaches or a careless user's unattended session) to make - use of stolen tickets. - - Note that the network address from which a connection is received - cannot be reliably determined. Even if it could be, an attacker - who has compromised the client's workstation could use the - credentials from there. Including the network addresses only - makes it more difficult, not impossible, for an attacker to walk - off with stolen credentials and then to use them from a "safe" - location. - - authorization-data - The authorization-data field is used to pass authorization data - from the principal on whose behalf a ticket was issued to the - application service. If no authorization data is included, this - field will be left out. Experience has shown that the name of - this field is confusing, and that a better name would be - "restrictions". Unfortunately, it is not possible to change the - name at this time. - - This field contains restrictions on any authority obtained on the - basis of authentication using the ticket. It is possible for any - principal in possession of credentials to add entries to the - authorization data field since these entries further restrict what - can be done with the ticket. Such additions can be made by - specifying the additional entries when a new ticket is obtained - during the TGS exchange, or they MAY be added during chained - delegation using the authorization data field of the - authenticator. - - Because entries may be added to this field by the holder of - credentials, except when an entry is separately authenticated by - encapsulation in the KDC-issued element, it is not allowable for - the presence of an entry in the authorization data field of a - ticket to amplify the privileges one would obtain from using a - ticket. - - The data in this field may be specific to the end service; the - field will contain the names of service specific objects, and the - rights to those objects. The format for this field is described - - - -Neuman, et al. Standards Track [Page 72] - -RFC 4120 Kerberos V5 July 2005 - - - in Section 5.2.6. Although Kerberos is not concerned with the - format of the contents of the subfields, it does carry type - information (ad-type). - - By using the authorization_data field, a principal is able to - issue a proxy that is valid for a specific purpose. For example, - a client wishing to print a file can obtain a file server proxy to - be passed to the print server. By specifying the name of the file - in the authorization_data field, the file server knows that the - print server can only use the client's rights when accessing the - particular file to be printed. - - A separate service providing authorization or certifying group - membership may be built using the authorization-data field. In - this case, the entity granting authorization (not the authorized - entity) may obtain a ticket in its own name (e.g., the ticket is - issued in the name of a privilege server), and this entity adds - restrictions on its own authority and delegates the restricted - authority through a proxy to the client. The client would then - present this authorization credential to the application server - separately from the authentication exchange. Alternatively, such - authorization credentials MAY be embedded in the ticket - authenticating the authorized entity, when the authorization is - separately authenticated using the KDC-issued authorization data - element (see 5.2.6.2). - - Similarly, if one specifies the authorization-data field of a - proxy and leaves the host addresses blank, the resulting ticket - and session key can be treated as a capability. See [Neu93] for - some suggested uses of this field. - - The authorization-data field is optional and does not have to be - included in a ticket. - -5.4. Specifications for the AS and TGS Exchanges - - This section specifies the format of the messages used in the - exchange between the client and the Kerberos server. The format of - possible error messages appears in Section 5.9.1. - -5.4.1. KRB_KDC_REQ Definition - - The KRB_KDC_REQ message has no application tag number of its own. - Instead, it is incorporated into either KRB_AS_REQ or KRB_TGS_REQ, - each of which has an application tag, depending on whether the - request is for an initial ticket or an additional ticket. In either - case, the message is sent from the client to the KDC to request - credentials for a service. - - - -Neuman, et al. Standards Track [Page 73] - -RFC 4120 Kerberos V5 July 2005 - - - The message fields are as follows: - -AS-REQ ::= [APPLICATION 10] KDC-REQ - -TGS-REQ ::= [APPLICATION 12] KDC-REQ - -KDC-REQ ::= SEQUENCE { - -- NOTE: first tag is [1], not [0] - pvno [1] INTEGER (5) , - msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), - padata [3] SEQUENCE OF PA-DATA OPTIONAL - -- NOTE: not empty --, - req-body [4] KDC-REQ-BODY -} - -KDC-REQ-BODY ::= SEQUENCE { - kdc-options [0] KDCOptions, - cname [1] PrincipalName OPTIONAL - -- Used only in AS-REQ --, - realm [2] Realm - -- Server's realm - -- Also client's in AS-REQ --, - sname [3] PrincipalName OPTIONAL, - from [4] KerberosTime OPTIONAL, - till [5] KerberosTime, - rtime [6] KerberosTime OPTIONAL, - nonce [7] UInt32, - etype [8] SEQUENCE OF Int32 -- EncryptionType - -- in preference order --, - addresses [9] HostAddresses OPTIONAL, - enc-authorization-data [10] EncryptedData OPTIONAL - -- AuthorizationData --, - additional-tickets [11] SEQUENCE OF Ticket OPTIONAL - -- NOTE: not empty -} - -KDCOptions ::= KerberosFlags - -- reserved(0), - -- forwardable(1), - -- forwarded(2), - -- proxiable(3), - -- proxy(4), - -- allow-postdate(5), - -- postdated(6), - -- unused7(7), - -- renewable(8), - -- unused9(9), - -- unused10(10), - - - -Neuman, et al. Standards Track [Page 74] - -RFC 4120 Kerberos V5 July 2005 - - - -- opt-hardware-auth(11), - -- unused12(12), - -- unused13(13), --- 15 is reserved for canonicalize - -- unused15(15), --- 26 was unused in 1510 - -- disable-transited-check(26), --- - -- renewable-ok(27), - -- enc-tkt-in-skey(28), - -- renew(30), - -- validate(31) - - The fields in this message are as follows: - - pvno - This field is included in each message, and specifies the protocol - version number. This document specifies protocol version 5. - - msg-type - This field indicates the type of a protocol message. It will - almost always be the same as the application identifier associated - with a message. It is included to make the identifier more - readily accessible to the application. For the KDC-REQ message, - this type will be KRB_AS_REQ or KRB_TGS_REQ. - - padata - Contains pre-authentication data. Requests for additional tickets - (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. - - The padata (pre-authentication data) field contains a sequence of - authentication information that may be needed before credentials - can be issued or decrypted. - - req-body - This field is a placeholder delimiting the extent of the remaining - fields. If a checksum is to be calculated over the request, it is - calculated over an encoding of the KDC-REQ-BODY sequence which is - enclosed within the req-body field. - - kdc-options - This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to - the KDC and indicates the flags that the client wants set on the - tickets as well as other information that is to modify the - behavior of the KDC. Where appropriate, the name of an option may - be the same as the flag that is set by that option. Although in - most cases, the bit in the options field will be the same as that - in the flags field, this is not guaranteed, so it is not - - - -Neuman, et al. Standards Track [Page 75] - -RFC 4120 Kerberos V5 July 2005 - - - acceptable simply to copy the options field to the flags field. - There are various checks that must be made before an option is - honored anyway. - - The kdc_options field is a bit-field, where the selected options - are indicated by the bit being set (1), and the unselected options - and reserved fields being reset (0). The encoding of the bits is - specified in Section 5.2. The options are described in more - detail above in Section 2. The meanings of the options are as - follows: - - Bits Name Description - - 0 RESERVED Reserved for future expansion of - this field. - - 1 FORWARDABLE The FORWARDABLE option indicates - that the ticket to be issued is to - have its forwardable flag set. It - may only be set on the initial - request, or in a subsequent request - if the TGT on which it is based is - also forwardable. - - 2 FORWARDED The FORWARDED option is only - specified in a request to the - ticket-granting server and will only - be honored if the TGT in the request - has its FORWARDABLE bit set. This - option indicates that this is a - request for forwarding. The - address(es) of the host from which - the resulting ticket is to be valid - are included in the addresses field - of the request. - - 3 PROXIABLE The PROXIABLE option indicates that - the ticket to be issued is to have - its proxiable flag set. It may only - be set on the initial request, or a - subsequent request if the TGT on - which it is based is also proxiable. - - 4 PROXY The PROXY option indicates that this - is a request for a proxy. This - option will only be honored if the - TGT in the request has its PROXIABLE - bit set. The address(es) of the - - - -Neuman, et al. Standards Track [Page 76] - -RFC 4120 Kerberos V5 July 2005 - - - host from which the resulting ticket - is to be valid are included in the - addresses field of the request. - - 5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates - that the ticket to be issued is to - have its MAY-POSTDATE flag set. It - may only be set on the initial - request, or in a subsequent request - if the TGT on which it is based also - has its MAY-POSTDATE flag set. - - 6 POSTDATED The POSTDATED option indicates that - this is a request for a postdated - ticket. This option will only be - honored if the TGT on which it is - based has its MAY-POSTDATE flag set. - The resulting ticket will also have - its INVALID flag set, and that flag - may be reset by a subsequent request - to the KDC after the starttime in - the ticket has been reached. - - 7 RESERVED This option is presently unused. - - 8 RENEWABLE The RENEWABLE option indicates that - the ticket to be issued is to have - its RENEWABLE flag set. It may only - be set on the initial request, or - when the TGT on which the request is - based is also renewable. If this - option is requested, then the rtime - field in the request contains the - desired absolute expiration time for - the ticket. - - 9 RESERVED Reserved for PK-Cross. - - 10 RESERVED Reserved for future use. - - 11 RESERVED Reserved for opt-hardware-auth. - - 12-25 RESERVED Reserved for future use. - - 26 DISABLE-TRANSITED-CHECK By default the KDC will check the - transited field of a TGT against the - policy of the local realm before it - will issue derivative tickets based - - - -Neuman, et al. Standards Track [Page 77] - -RFC 4120 Kerberos V5 July 2005 - - - on the TGT. If this flag is set in - the request, checking of the - transited field is disabled. - Tickets issued without the - performance of this check will be - noted by the reset (0) value of the - TRANSITED-POLICY-CHECKED flag, - indicating to the application server - that the transited field must be - checked locally. KDCs are - encouraged but not required to honor - the DISABLE-TRANSITED-CHECK option. - - This flag is new since RFC 1510. - - 27 RENEWABLE-OK The RENEWABLE-OK option indicates - that a renewable ticket will be - acceptable if a ticket with the - requested life cannot otherwise be - provided, in which case a renewable - ticket may be issued with a renew- - till equal to the requested endtime. - The value of the renew-till field - may still be limited by local - limits, or limits selected by the - individual principal or server. - - 28 ENC-TKT-IN-SKEY This option is used only by the - ticket-granting service. The ENC- - TKT-IN-SKEY option indicates that - the ticket for the end server is to - be encrypted in the session key from - the additional TGT provided. - - 29 RESERVED Reserved for future use. - - 30 RENEW This option is used only by the - ticket-granting service. The RENEW - option indicates that the present - request is for a renewal. The - ticket provided is encrypted in the - secret key for the server on which - it is valid. This option will only - be honored if the ticket to be - renewed has its RENEWABLE flag set - and if the time in its renew-till - field has not passed. The ticket to - be renewed is passed in the padata - - - -Neuman, et al. Standards Track [Page 78] - -RFC 4120 Kerberos V5 July 2005 - - - field as part of the authentication - header. - - 31 VALIDATE This option is used only by the - ticket-granting service. The - VALIDATE option indicates that the - request is to validate a postdated - ticket. It will only be honored if - the ticket presented is postdated, - presently has its INVALID flag set, - and would otherwise be usable at - this time. A ticket cannot be - validated before its starttime. The - ticket presented for validation is - encrypted in the key of the server - for which it is valid and is passed - in the padata field as part of the - authentication header. - - cname and sname - These fields are the same as those described for the ticket in - section 5.3. The sname may only be absent when the ENC-TKT-IN- - SKEY option is specified. If the sname is absent, the name of the - server is taken from the name of the client in the ticket passed - as additional-tickets. - - enc-authorization-data - The enc-authorization-data, if present (and it can only be present - in the TGS_REQ form), is an encoding of the desired - authorization-data encrypted under the sub-session key if present - in the Authenticator, or alternatively from the session key in the - TGT (both the Authenticator and TGT come from the padata field in - the KRB_TGS_REQ). The key usage value used when encrypting is 5 - if a sub-session key is used, or 4 if the session key is used. - - realm - This field specifies the realm part of the server's principal - identifier. In the AS exchange, this is also the realm part of - the client's principal identifier. - - from - This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket - requests when the requested ticket is to be postdated. It - specifies the desired starttime for the requested ticket. If this - field is omitted, then the KDC SHOULD use the current time - instead. - - - - - -Neuman, et al. Standards Track [Page 79] - -RFC 4120 Kerberos V5 July 2005 - - - till - This field contains the expiration date requested by the client in - a ticket request. It is not optional, but if the requested - endtime is "19700101000000Z", the requested ticket is to have the - maximum endtime permitted according to KDC policy. Implementation - note: This special timestamp corresponds to a UNIX time_t value of - zero on most systems. - - rtime - This field is the requested renew-till time sent from a client to - the KDC in a ticket request. It is optional. - - nonce - This field is part of the KDC request and response. It is - intended to hold a random number generated by the client. If the - same number is included in the encrypted response from the KDC, it - provides evidence that the response is fresh and has not been - replayed by an attacker. Nonces MUST NEVER be reused. - - etype - This field specifies the desired encryption algorithm to be used - in the response. - - addresses - This field is included in the initial request for tickets, and it - is optionally included in requests for additional tickets from the - ticket-granting server. It specifies the addresses from which the - requested ticket is to be valid. Normally it includes the - addresses for the client's host. If a proxy is requested, this - field will contain other addresses. The contents of this field - are usually copied by the KDC into the caddr field of the - resulting ticket. - - additional-tickets - Additional tickets MAY be optionally included in a request to the - ticket-granting server. If the ENC-TKT-IN-SKEY option has been - specified, then the session key from the additional ticket will be - used in place of the server's key to encrypt the new ticket. When - the ENC-TKT-IN-SKEY option is used for user-to-user - authentication, this additional ticket MAY be a TGT issued by the - local realm or an inter-realm TGT issued for the current KDC's - realm by a remote KDC. If more than one option that requires - additional tickets has been specified, then the additional tickets - are used in the order specified by the ordering of the options - bits (see kdc-options, above). - - - - - - -Neuman, et al. Standards Track [Page 80] - -RFC 4120 Kerberos V5 July 2005 - - - The application tag number will be either ten (10) or twelve (12) - depending on whether the request is for an initial ticket (AS-REQ) or - for an additional ticket (TGS-REQ). - - The optional fields (addresses, authorization-data, and additional- - tickets) are only included if necessary to perform the operation - specified in the kdc-options field. - - Note that in KRB_TGS_REQ, the protocol version number appears twice - and two different message types appear: the KRB_TGS_REQ message - contains these fields as does the authentication header (KRB_AP_REQ) - that is passed in the padata field. - -5.4.2. KRB_KDC_REP Definition - - The KRB_KDC_REP message format is used for the reply from the KDC for - either an initial (AS) request or a subsequent (TGS) request. There - is no message type for KRB_KDC_REP. Instead, the type will be either - KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext - part of the reply depends on the message type. For KRB_AS_REP, the - ciphertext is encrypted in the client's secret key, and the client's - key version number is included in the key version number for the - encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the - sub-session key from the Authenticator; if it is absent, the - ciphertext is encrypted in the session key from the TGT used in the - request. In that case, no version number will be present in the - EncryptedData sequence. - - The KRB_KDC_REP message contains the following fields: - - AS-REP ::= [APPLICATION 11] KDC-REP - - TGS-REP ::= [APPLICATION 13] KDC-REP - - KDC-REP ::= SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), - padata [2] SEQUENCE OF PA-DATA OPTIONAL - -- NOTE: not empty --, - crealm [3] Realm, - cname [4] PrincipalName, - ticket [5] Ticket, - enc-part [6] EncryptedData - -- EncASRepPart or EncTGSRepPart, - -- as appropriate - } - - EncASRepPart ::= [APPLICATION 25] EncKDCRepPart - - - -Neuman, et al. Standards Track [Page 81] - -RFC 4120 Kerberos V5 July 2005 - - - EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart - - EncKDCRepPart ::= SEQUENCE { - key [0] EncryptionKey, - last-req [1] LastReq, - nonce [2] UInt32, - key-expiration [3] KerberosTime OPTIONAL, - flags [4] TicketFlags, - authtime [5] KerberosTime, - starttime [6] KerberosTime OPTIONAL, - endtime [7] KerberosTime, - renew-till [8] KerberosTime OPTIONAL, - srealm [9] Realm, - sname [10] PrincipalName, - caddr [11] HostAddresses OPTIONAL - } - - LastReq ::= SEQUENCE OF SEQUENCE { - lr-type [0] Int32, - lr-value [1] KerberosTime - } - - pvno and msg-type - These fields are described above in Section 5.4.1. msg-type is - either KRB_AS_REP or KRB_TGS_REP. - - padata - This field is described in detail in Section 5.4.1. One possible - use for it is to encode an alternate "salt" string to be used with - a string-to-key algorithm. This ability is useful for easing - transitions if a realm name needs to change (e.g., when a company - is acquired); in such a case all existing password-derived entries - in the KDC database would be flagged as needing a special salt - string until the next password change. - - crealm, cname, srealm, and sname - These fields are the same as those described for the ticket in - section 5.3. - - ticket - The newly-issued ticket, from Section 5.3. - - enc-part - This field is a place holder for the ciphertext and related - information that forms the encrypted part of a message. The - description of the encrypted part of the message follows each - appearance of this field. - - - - -Neuman, et al. Standards Track [Page 82] - -RFC 4120 Kerberos V5 July 2005 - - - The key usage value for encrypting this field is 3 in an AS-REP - message, using the client's long-term key or another key selected - via pre-authentication mechanisms. In a TGS-REP message, the key - usage value is 8 if the TGS session key is used, or 9 if a TGS - authenticator subkey is used. - - Compatibility note: Some implementations unconditionally send an - encrypted EncTGSRepPart (application tag number 26) in this field - regardless of whether the reply is a AS-REP or a TGS-REP. In the - interest of compatibility, implementors MAY relax the check on the - tag number of the decrypted ENC-PART. - - key - This field is the same as described for the ticket in Section 5.3. - - last-req - This field is returned by the KDC and specifies the time(s) of the - last request by a principal. Depending on what information is - available, this might be the last time that a request for a TGT - was made, or the last time that a request based on a TGT was - successful. It also might cover all servers for a realm, or just - the particular server. Some implementations MAY display this - information to the user to aid in discovering unauthorized use of - one's identity. It is similar in spirit to the last login time - displayed when logging in to timesharing systems. - - lr-type - This field indicates how the following lr-value field is to be - interpreted. Negative values indicate that the information - pertains only to the responding server. Non-negative values - pertain to all servers for the realm. - - If the lr-type field is zero (0), then no information is conveyed - by the lr-value subfield. If the absolute value of the lr-type - field is one (1), then the lr-value subfield is the time of last - initial request for a TGT. If it is two (2), then the lr-value - subfield is the time of last initial request. If it is three (3), - then the lr-value subfield is the time of issue for the newest TGT - used. If it is four (4), then the lr-value subfield is the time - of the last renewal. If it is five (5), then the lr-value - subfield is the time of last request (of any type). If it is (6), - then the lr-value subfield is the time when the password will - expire. If it is (7), then the lr-value subfield is the time when - the account will expire. - - - - - - - -Neuman, et al. Standards Track [Page 83] - -RFC 4120 Kerberos V5 July 2005 - - - lr-value - This field contains the time of the last request. The time MUST - be interpreted according to the contents of the accompanying lr- - type subfield. - - nonce - This field is described above in Section 5.4.1. - - key-expiration - The key-expiration field is part of the response from the KDC and - specifies the time that the client's secret key is due to expire. - The expiration might be the result of password aging or an account - expiration. If present, it SHOULD be set to the earlier of the - user's key expiration and account expiration. The use of this - field is deprecated, and the last-req field SHOULD be used to - convey this information instead. This field will usually be left - out of the TGS reply since the response to the TGS request is - encrypted in a session key and no client information has to be - retrieved from the KDC database. It is up to the application - client (usually the login program) to take appropriate action - (such as notifying the user) if the expiration time is imminent. - - flags, authtime, starttime, endtime, renew-till and caddr - These fields are duplicates of those found in the encrypted - portion of the attached ticket (see Section 5.3), provided so the - client MAY verify that they match the intended request and in - order to assist in proper ticket caching. If the message is of - type KRB_TGS_REP, the caddr field will only be filled in if the - request was for a proxy or forwarded ticket, or if the user is - substituting a subset of the addresses from the TGT. If the - client-requested addresses are not present or not used, then the - addresses contained in the ticket will be the same as those - included in the TGT. - -5.5. Client/Server (CS) Message Specifications - - This section specifies the format of the messages used for the - authentication of the client to the application server. - -5.5.1. KRB_AP_REQ Definition - - The KRB_AP_REQ message contains the Kerberos protocol version number, - the message type KRB_AP_REQ, an options field to indicate any options - in use, and the ticket and authenticator themselves. The KRB_AP_REQ - message is often referred to as the "authentication header". - - - - - - -Neuman, et al. Standards Track [Page 84] - -RFC 4120 Kerberos V5 July 2005 - - - AP-REQ ::= [APPLICATION 14] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (14), - ap-options [2] APOptions, - ticket [3] Ticket, - authenticator [4] EncryptedData -- Authenticator - } - - APOptions ::= KerberosFlags - -- reserved(0), - -- use-session-key(1), - -- mutual-required(2) - - pvno and msg-type - These fields are described above in Section 5.4.1. msg-type is - KRB_AP_REQ. - - ap-options - This field appears in the application request (KRB_AP_REQ) and - affects the way the request is processed. It is a bit-field, - where the selected options are indicated by the bit being set (1), - and the unselected options and reserved fields by being reset (0). - The encoding of the bits is specified in Section 5.2. The - meanings of the options are as follows: - - Bit(s) Name Description - - 0 reserved Reserved for future expansion of this field. - - 1 use-session-key The USE-SESSION-KEY option indicates that - the ticket the client is presenting to a - server is encrypted in the session key from - the server's TGT. When this option is not - specified, the ticket is encrypted in the - server's secret key. - - 2 mutual-required The MUTUAL-REQUIRED option tells the server - that the client requires mutual - authentication, and that it must respond - with a KRB_AP_REP message. - - 3-31 reserved Reserved for future use. - - ticket - This field is a ticket authenticating the client to the server. - - - - - - -Neuman, et al. Standards Track [Page 85] - -RFC 4120 Kerberos V5 July 2005 - - - authenticator - This contains the encrypted authenticator, which includes the - client's choice of a subkey. - - The encrypted authenticator is included in the AP-REQ; it certifies - to a server that the sender has recent knowledge of the encryption - key in the accompanying ticket, to help the server detect replays. - It also assists in the selection of a "true session key" to use with - the particular session. The DER encoding of the following is - encrypted in the ticket's session key, with a key usage value of 11 - in normal application exchanges, or 7 when used as the PA-TGS-REQ - PA-DATA field of a TGS-REQ exchange (see Section 5.4.1): - - -- Unencrypted authenticator - Authenticator ::= [APPLICATION 2] SEQUENCE { - authenticator-vno [0] INTEGER (5), - crealm [1] Realm, - cname [2] PrincipalName, - cksum [3] Checksum OPTIONAL, - cusec [4] Microseconds, - ctime [5] KerberosTime, - subkey [6] EncryptionKey OPTIONAL, - seq-number [7] UInt32 OPTIONAL, - authorization-data [8] AuthorizationData OPTIONAL - } - - authenticator-vno - This field specifies the version number for the format of the - authenticator. This document specifies version 5. - - crealm and cname - These fields are the same as those described for the ticket in - section 5.3. - - cksum - This field contains a checksum of the application data that - accompanies the KRB_AP_REQ, computed using a key usage value of 10 - in normal application exchanges, or 6 when used in the TGS-REQ - PA-TGS-REQ AP-DATA field. - - cusec - This field contains the microsecond part of the client's - timestamp. Its value (before encryption) ranges from 0 to 999999. - It often appears along with ctime. The two fields are used - together to specify a reasonably accurate timestamp. - - ctime - This field contains the current time on the client's host. - - - -Neuman, et al. Standards Track [Page 86] - -RFC 4120 Kerberos V5 July 2005 - - - subkey - This field contains the client's choice for an encryption key to - be used to protect this specific application session. Unless an - application specifies otherwise, if this field is left out, the - session key from the ticket will be used. - - seq-number - This optional field includes the initial sequence number to be - used by the KRB_PRIV or KRB_SAFE messages when sequence numbers - are used to detect replays. (It may also be used by application - specific messages.) When included in the authenticator, this - field specifies the initial sequence number for messages from the - client to the server. When included in the AP-REP message, the - initial sequence number is that for messages from the server to - the client. When used in KRB_PRIV or KRB_SAFE messages, it is - incremented by one after each message is sent. Sequence numbers - fall in the range 0 through 2^32 - 1 and wrap to zero following - the value 2^32 - 1. - - For sequence numbers to support the detection of replays - adequately, they SHOULD be non-repeating, even across connection - boundaries. The initial sequence number SHOULD be random and - uniformly distributed across the full space of possible sequence - numbers, so that it cannot be guessed by an attacker and so that - it and the successive sequence numbers do not repeat other - sequences. In the event that more than 2^32 messages are to be - generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying - SHOULD be performed before sequence numbers are reused with the - same encryption key. - - Implmentation note: Historically, some implementations transmit - signed twos-complement numbers for sequence numbers. In the - interests of compatibility, implementations MAY accept the - equivalent negative number where a positive number greater than - 2^31 - 1 is expected. - - Implementation note: As noted before, some implementations omit - the optional sequence number when its value would be zero. - Implementations MAY accept an omitted sequence number when - expecting a value of zero, and SHOULD NOT transmit an - Authenticator with a initial sequence number of zero. - - authorization-data - This field is the same as described for the ticket in Section 5.3. - It is optional and will only appear when additional restrictions - are to be placed on the use of a ticket, beyond those carried in - the ticket itself. - - - - -Neuman, et al. Standards Track [Page 87] - -RFC 4120 Kerberos V5 July 2005 - - -5.5.2. KRB_AP_REP Definition - - The KRB_AP_REP message contains the Kerberos protocol version number, - the message type, and an encrypted time-stamp. The message is sent - in response to an application request (KRB_AP_REQ) for which the - mutual authentication option has been selected in the ap-options - field. - - AP-REP ::= [APPLICATION 15] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (15), - enc-part [2] EncryptedData -- EncAPRepPart - } - - EncAPRepPart ::= [APPLICATION 27] SEQUENCE { - ctime [0] KerberosTime, - cusec [1] Microseconds, - subkey [2] EncryptionKey OPTIONAL, - seq-number [3] UInt32 OPTIONAL - } - - The encoded EncAPRepPart is encrypted in the shared session key of - the ticket. The optional subkey field can be used in an - application-arranged negotiation to choose a per association session - key. - - pvno and msg-type - These fields are described above in Section 5.4.1. msg-type is - KRB_AP_REP. - - enc-part - This field is described above in Section 5.4.2. It is computed - with a key usage value of 12. - - ctime - This field contains the current time on the client's host. - - cusec - This field contains the microsecond part of the client's - timestamp. - - subkey - This field contains an encryption key that is to be used to - protect this specific application session. See Section 3.2.6 for - specifics on how this field is used to negotiate a key. Unless an - application specifies otherwise, if this field is left out, the - sub-session key from the authenticator or if the latter is also - left out, the session key from the ticket will be used. - - - -Neuman, et al. Standards Track [Page 88] - -RFC 4120 Kerberos V5 July 2005 - - - seq-number - This field is described above in Section 5.3.2. - -5.5.3. Error Message Reply - - If an error occurs while processing the application request, the - KRB_ERROR message will be sent in response. See Section 5.9.1 for - the format of the error message. The cname and crealm fields MAY be - left out if the server cannot determine their appropriate values from - the corresponding KRB_AP_REQ message. If the authenticator was - decipherable, the ctime and cusec fields will contain the values from - it. - -5.6. KRB_SAFE Message Specification - - This section specifies the format of a message that can be used by - either side (client or server) of an application to send a tamper- - proof message to its peer. It presumes that a session key has - previously been exchanged (for example, by using the - KRB_AP_REQ/KRB_AP_REP messages). - -5.6.1. KRB_SAFE definition - - The KRB_SAFE message contains user data along with a collision-proof - checksum keyed with the last encryption key negotiated via subkeys, - or with the session key if no negotiation has occurred. The message - fields are as follows: - - KRB-SAFE ::= [APPLICATION 20] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (20), - safe-body [2] KRB-SAFE-BODY, - cksum [3] Checksum - } - - KRB-SAFE-BODY ::= SEQUENCE { - user-data [0] OCTET STRING, - timestamp [1] KerberosTime OPTIONAL, - usec [2] Microseconds OPTIONAL, - seq-number [3] UInt32 OPTIONAL, - s-address [4] HostAddress, - r-address [5] HostAddress OPTIONAL - } - - pvno and msg-type - These fields are described above in Section 5.4.1. msg-type is - KRB_SAFE. - - - - -Neuman, et al. Standards Track [Page 89] - -RFC 4120 Kerberos V5 July 2005 - - - safe-body - This field is a placeholder for the body of the KRB-SAFE message. - - cksum - This field contains the checksum of the application data, computed - with a key usage value of 15. - - The checksum is computed over the encoding of the KRB-SAFE - sequence. First, the cksum is set to a type zero, zero-length - value, and the checksum is computed over the encoding of the KRB- - SAFE sequence. Then the checksum is set to the result of that - computation. Finally, the KRB-SAFE sequence is encoded again. - This method, although different than the one specified in RFC - 1510, corresponds to existing practice. - - user-data - This field is part of the KRB_SAFE and KRB_PRIV messages, and - contains the application-specific data that is being passed from - the sender to the recipient. - - timestamp - This field is part of the KRB_SAFE and KRB_PRIV messages. Its - contents are the current time as known by the sender of the - message. By checking the timestamp, the recipient of the message - is able to make sure that it was recently generated, and is not a - replay. - - usec - This field is part of the KRB_SAFE and KRB_PRIV headers. It - contains the microsecond part of the timestamp. - - seq-number - This field is described above in Section 5.3.2. - - s-address - Sender's address. - - This field specifies the address in use by the sender of the - message. - - r-address - This field specifies the address in use by the recipient of the - message. It MAY be omitted for some uses (such as broadcast - protocols), but the recipient MAY arbitrarily reject such - messages. This field, along with s-address, can be used to help - detect messages that have been incorrectly or maliciously - delivered to the wrong recipient. - - - - -Neuman, et al. Standards Track [Page 90] - -RFC 4120 Kerberos V5 July 2005 - - -5.7. KRB_PRIV Message Specification - - This section specifies the format of a message that can be used by - either side (client or server) of an application to send a message to - its peer securely and privately. It presumes that a session key has - previously been exchanged (for example, by using the - KRB_AP_REQ/KRB_AP_REP messages). - -5.7.1. KRB_PRIV Definition - - The KRB_PRIV message contains user data encrypted in the Session Key. - The message fields are as follows: - - KRB-PRIV ::= [APPLICATION 21] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (21), - -- NOTE: there is no [2] tag - enc-part [3] EncryptedData -- EncKrbPrivPart - } - - EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { - user-data [0] OCTET STRING, - timestamp [1] KerberosTime OPTIONAL, - usec [2] Microseconds OPTIONAL, - seq-number [3] UInt32 OPTIONAL, - s-address [4] HostAddress -- sender's addr --, - r-address [5] HostAddress OPTIONAL -- recip's addr - } - - pvno and msg-type - These fields are described above in Section 5.4.1. msg-type is - KRB_PRIV. - - enc-part - This field holds an encoding of the EncKrbPrivPart sequence - encrypted under the session key, with a key usage value of 13. - This encrypted encoding is used for the enc-part field of the - KRB-PRIV message. - - user-data, timestamp, usec, s-address, and r-address - These fields are described above in Section 5.6.1. - - seq-number - This field is described above in Section 5.3.2. - - - - - - - -Neuman, et al. Standards Track [Page 91] - -RFC 4120 Kerberos V5 July 2005 - - -5.8. KRB_CRED Message Specification - - This section specifies the format of a message that can be used to - send Kerberos credentials from one principal to another. It is - presented here to encourage a common mechanism to be used by - applications when forwarding tickets or providing proxies to - subordinate servers. It presumes that a session key has already been - exchanged, perhaps by using the KRB_AP_REQ/KRB_AP_REP messages. - -5.8.1. KRB_CRED Definition - - The KRB_CRED message contains a sequence of tickets to be sent and - information needed to use the tickets, including the session key from - each. The information needed to use the tickets is encrypted under - an encryption key previously exchanged or transferred alongside the - KRB_CRED message. The message fields are as follows: - - KRB-CRED ::= [APPLICATION 22] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (22), - tickets [2] SEQUENCE OF Ticket, - enc-part [3] EncryptedData -- EncKrbCredPart - } - - EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { - ticket-info [0] SEQUENCE OF KrbCredInfo, - nonce [1] UInt32 OPTIONAL, - timestamp [2] KerberosTime OPTIONAL, - usec [3] Microseconds OPTIONAL, - s-address [4] HostAddress OPTIONAL, - r-address [5] HostAddress OPTIONAL - } - - KrbCredInfo ::= SEQUENCE { - key [0] EncryptionKey, - prealm [1] Realm OPTIONAL, - pname [2] PrincipalName OPTIONAL, - flags [3] TicketFlags OPTIONAL, - authtime [4] KerberosTime OPTIONAL, - starttime [5] KerberosTime OPTIONAL, - endtime [6] KerberosTime OPTIONAL, - renew-till [7] KerberosTime OPTIONAL, - srealm [8] Realm OPTIONAL, - sname [9] PrincipalName OPTIONAL, - caddr [10] HostAddresses OPTIONAL - } - - - - - -Neuman, et al. Standards Track [Page 92] - -RFC 4120 Kerberos V5 July 2005 - - - pvno and msg-type - These fields are described above in Section 5.4.1. msg-type is - KRB_CRED. - - tickets - These are the tickets obtained from the KDC specifically for use - by the intended recipient. Successive tickets are paired with the - corresponding KrbCredInfo sequence from the enc-part of the KRB- - CRED message. - - enc-part - This field holds an encoding of the EncKrbCredPart sequence - encrypted under the session key shared by the sender and the - intended recipient, with a key usage value of 14. This encrypted - encoding is used for the enc-part field of the KRB-CRED message. - - Implementation note: Implementations of certain applications, most - notably certain implementations of the Kerberos GSS-API mechanism, - do not separately encrypt the contents of the EncKrbCredPart of - the KRB-CRED message when sending it. In the case of those GSS- - API mechanisms, this is not a security vulnerability, as the - entire KRB-CRED message is itself embedded in an encrypted - message. - - nonce - If practical, an application MAY require the inclusion of a nonce - generated by the recipient of the message. If the same value is - included as the nonce in the message, it provides evidence that - the message is fresh and has not been replayed by an attacker. A - nonce MUST NEVER be reused. - - timestamp and usec - These fields specify the time that the KRB-CRED message was - generated. The time is used to provide assurance that the message - is fresh. - - s-address and r-address - These fields are described above in Section 5.6.1. They are used - optionally to provide additional assurance of the integrity of the - KRB-CRED message. - - key - This field exists in the corresponding ticket passed by the KRB- - CRED message and is used to pass the session key from the sender - to the intended recipient. The field's encoding is described in - Section 5.2.9. - - - - - -Neuman, et al. Standards Track [Page 93] - -RFC 4120 Kerberos V5 July 2005 - - - The following fields are optional. If present, they can be - associated with the credentials in the remote ticket file. If left - out, then it is assumed that the recipient of the credentials already - knows their values. - - prealm and pname - The name and realm of the delegated principal identity. - - flags, authtime, starttime, endtime, renew-till, srealm, sname, - and caddr - These fields contain the values of the corresponding fields from - the ticket found in the ticket field. Descriptions of the fields - are identical to the descriptions in the KDC-REP message. - -5.9. Error Message Specification - - This section specifies the format for the KRB_ERROR message. The - fields included in the message are intended to return as much - information as possible about an error. It is not expected that all - the information required by the fields will be available for all - types of errors. If the appropriate information is not available - when the message is composed, the corresponding field will be left - out of the message. - - Note that because the KRB_ERROR message is not integrity protected, - it is quite possible for an intruder to synthesize or modify it. In - particular, this means that the client SHOULD NOT use any fields in - this message for security-critical purposes, such as setting a system - clock or generating a fresh authenticator. The message can be - useful, however, for advising a user on the reason for some failure. - -5.9.1. KRB_ERROR Definition - - The KRB_ERROR message consists of the following fields: - - KRB-ERROR ::= [APPLICATION 30] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (30), - ctime [2] KerberosTime OPTIONAL, - cusec [3] Microseconds OPTIONAL, - stime [4] KerberosTime, - susec [5] Microseconds, - error-code [6] Int32, - crealm [7] Realm OPTIONAL, - cname [8] PrincipalName OPTIONAL, - realm [9] Realm -- service realm --, - sname [10] PrincipalName -- service name --, - e-text [11] KerberosString OPTIONAL, - - - -Neuman, et al. Standards Track [Page 94] - -RFC 4120 Kerberos V5 July 2005 - - - e-data [12] OCTET STRING OPTIONAL - } - - pvno and msg-type - These fields are described above in Section 5.4.1. msg-type is - KRB_ERROR. - - ctime and cusec - These fields are described above in Section 5.5.2. If the values - for these fields are known to the entity generating the error (as - they would be if the KRB-ERROR is generated in reply to, e.g., a - failed authentication service request), they should be populated - in the KRB-ERROR. If the values are not available, these fields - can be omitted. - - stime - This field contains the current time on the server. It is of type - KerberosTime. - - susec - This field contains the microsecond part of the server's - timestamp. Its value ranges from 0 to 999999. It appears along - with stime. The two fields are used in conjunction to specify a - reasonably accurate timestamp. - - error-code - This field contains the error code returned by Kerberos or the - server when a request fails. To interpret the value of this field - see the list of error codes in Section 7.5.9. Implementations are - encouraged to provide for national language support in the display - of error messages. - - crealm, and cname - These fields are described above in Section 5.3. When the entity - generating the error knows these values, they should be populated - in the KRB-ERROR. If the values are not known, the crealm and - cname fields SHOULD be omitted. - - realm and sname - These fields are described above in Section 5.3. - - e-text - This field contains additional text to help explain the error code - associated with the failed request (for example, it might include - a principal name which was unknown). - - - - - - -Neuman, et al. Standards Track [Page 95] - -RFC 4120 Kerberos V5 July 2005 - - - e-data - This field contains additional data about the error for use by the - application to help it recover from or handle the error. If the - errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will - contain an encoding of a sequence of padata fields, each - corresponding to an acceptable pre-authentication method and - optionally containing data for the method: - - METHOD-DATA ::= SEQUENCE OF PA-DATA - - For error codes defined in this document other than - KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field - are implementation-defined. Similarly, for future error codes, the - format and contents of the e-data field are implementation-defined - unless specified otherwise. Whether defined by the implementation or - in a future document, the e-data field MAY take the form of TYPED- - DATA: - - TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { - data-type [0] Int32, - data-value [1] OCTET STRING OPTIONAL - } - -5.10. Application Tag Numbers - - The following table lists the application class tag numbers used by - various data types defined in this section. - - Tag Number(s) Type Name Comments - - 0 unused - - 1 Ticket PDU - - 2 Authenticator non-PDU - - 3 EncTicketPart non-PDU - - 4-9 unused - - 10 AS-REQ PDU - - 11 AS-REP PDU - - 12 TGS-REQ PDU - - 13 TGS-REP PDU - - - - -Neuman, et al. Standards Track [Page 96] - -RFC 4120 Kerberos V5 July 2005 - - - 14 AP-REQ PDU - - 15 AP-REP PDU - - 16 RESERVED16 TGT-REQ (for user-to-user) - - 17 RESERVED17 TGT-REP (for user-to-user) - - 18-19 unused - - 20 KRB-SAFE PDU - - 21 KRB-PRIV PDU - - 22 KRB-CRED PDU - - 23-24 unused - - 25 EncASRepPart non-PDU - - 26 EncTGSRepPart non-PDU - - 27 EncApRepPart non-PDU - - 28 EncKrbPrivPart non-PDU - - 29 EncKrbCredPart non-PDU - - 30 KRB-ERROR PDU - - The ASN.1 types marked above as "PDU" (Protocol Data Unit) are the - only ASN.1 types intended as top-level types of the Kerberos - protocol, and are the only types that may be used as elements in - another protocol that makes use of Kerberos. - -6. Naming Constraints - -6.1. Realm Names - - Although realm names are encoded as GeneralStrings and technically a - realm can select any name it chooses, interoperability across realm - boundaries requires agreement on how realm names are to be assigned, - and what information they imply. - - To enforce these conventions, each realm MUST conform to the - conventions itself, and it MUST require that any realms with which - inter-realm keys are shared also conform to the conventions and - require the same from its neighbors. - - - -Neuman, et al. Standards Track [Page 97] - -RFC 4120 Kerberos V5 July 2005 - - - Kerberos realm names are case sensitive. Realm names that differ - only in the case of the characters are not equivalent. There are - presently three styles of realm names: domain, X500, and other. - Examples of each style follow: - - domain: ATHENA.MIT.EDU - X500: C=US/O=OSF - other: NAMETYPE:rest/of.name=without-restrictions - - Domain style realm names MUST look like domain names: they consist of - components separated by periods (.) and they contain neither colons - (:) nor slashes (/). Though domain names themselves are case - insensitive, in order for realms to match, the case must match as - well. When establishing a new realm name based on an internet domain - name it is recommended by convention that the characters be converted - to uppercase. - - X.500 names contain an equals sign (=) and cannot contain a colon (:) - before the equals sign. The realm names for X.500 names will be - string representations of the names with components separated by - slashes. Leading and trailing slashes will not be included. Note - that the slash separator is consistent with Kerberos implementations - based on RFC 1510, but it is different from the separator recommended - in RFC 2253. - - Names that fall into the other category MUST begin with a prefix that - contains no equals sign (=) or period (.), and the prefix MUST be - followed by a colon (:) and the rest of the name. All prefixes - expect those beginning with used. Presently none are assigned. - - The reserved category includes strings that do not fall into the - first three categories. All names in this category are reserved. It - is unlikely that names will be assigned to this category unless there - is a very strong argument for not using the 'other' category. - - These rules guarantee that there will be no conflicts between the - various name styles. The following additional constraints apply to - the assignment of realm names in the domain and X.500 categories: - either the name of a realm for the domain or X.500 formats must be - used by the organization owning (to whom it was assigned) an Internet - domain name or X.500 name, or, in the case that no such names are - registered, authority to use a realm name MAY be derived from the - authority of the parent realm. For example, if there is no domain - name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can - authorize the creation of a realm with that name. - - This is acceptable because the organization to which the parent is - assigned is presumably the organization authorized to assign names to - - - -Neuman, et al. Standards Track [Page 98] - -RFC 4120 Kerberos V5 July 2005 - - - its children in the X.500 and domain name systems as well. If the - parent assigns a realm name without also registering it in the domain - name or X.500 hierarchy, it is the parent's responsibility to make - sure that in the future there will not exist a name identical to the - realm name of the child unless it is assigned to the same entity as - the realm name. - -6.2. Principal Names - - As was the case for realm names, conventions are needed to ensure - that all agree on what information is implied by a principal name. - The name-type field that is part of the principal name indicates the - kind of information implied by the name. The name-type SHOULD be - treated only as a hint to interpreting the meaning of a name. It is - not significant when checking for equivalence. Principal names that - differ only in the name-type identify the same principal. The name - type does not partition the name space. Ignoring the name type, no - two names can be the same (i.e., at least one of the components, or - the realm, MUST be different). The following name types are defined: - - Name Type Value Meaning - - NT-UNKNOWN 0 Name type not known - NT-PRINCIPAL 1 Just the name of the principal as in DCE, - or for users - NT-SRV-INST 2 Service and other unique instance (krbtgt) - NT-SRV-HST 3 Service with host name as instance - (telnet, rcommands) - NT-SRV-XHST 4 Service with host as remaining components - NT-UID 5 Unique ID - NT-X500-PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] - NT-SMTP-NAME 7 Name in form of SMTP email name - (e.g., user@example.com) - NT-ENTERPRISE 10 Enterprise name - may be mapped to principal - name - - When a name implies no information other than its uniqueness at a - particular time, the name type PRINCIPAL SHOULD be used. The - principal name type SHOULD be used for users, and it might also be - used for a unique server. If the name is a unique machine-generated - ID that is guaranteed never to be reassigned, then the name type of - UID SHOULD be used. (Note that it is generally a bad idea to - reassign names of any type since stale entries might remain in access - control lists.) - - If the first component of a name identifies a service and the - remaining components identify an instance of the service in a - server-specified manner, then the name type of SRV-INST SHOULD be - - - -Neuman, et al. Standards Track [Page 99] - -RFC 4120 Kerberos V5 July 2005 - - - used. An example of this name type is the Kerberos ticket-granting - service whose name has a first component of krbtgt and a second - component identifying the realm for which the ticket is valid. - - If the first component of a name identifies a service and there is a - single component following the service name identifying the instance - as the host on which the server is running, then the name type - SRV-HST SHOULD be used. This type is typically used for Internet - services such as telnet and the Berkeley R commands. If the separate - components of the host name appear as successive components following - the name of the service, then the name type SRV-XHST SHOULD be used. - This type might be used to identify servers on hosts with X.500 - names, where the slash (/) might otherwise be ambiguous. - - A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an - X.509 certificate is translated into a Kerberos name. The encoding - of the X.509 name as a Kerberos principal shall conform to the - encoding rules specified in RFC 2253. - - A name type of SMTP allows a name to be of a form that resembles an - SMTP email name. This name, including an "@" and a domain name, is - used as the one component of the principal name. - - A name type of UNKNOWN SHOULD be used when the form of the name is - not known. When comparing names, a name of type UNKNOWN will match - principals authenticated with names of any type. A principal - authenticated with a name of type UNKNOWN, however, will only match - other names of type UNKNOWN. - - Names of any type with an initial component of 'krbtgt' are reserved - for the Kerberos ticket-granting service. See Section 7.3 for the - form of such names. - -6.2.1. Name of Server Principals - - The principal identifier for a server on a host will generally be - composed of two parts: (1) the realm of the KDC with which the server - is registered, and (2) a two-component name of type NT-SRV-HST, if - the host name is an Internet domain name, or a multi-component name - of type NT-SRV-XHST, if the name of the host is of a form (such as - X.500) that allows slash (/) separators. The first component of the - two- or multi-component name will identify the service, and the - latter components will identify the host. Where the name of the host - is not case sensitive (for example, with Internet domain names) the - name of the host MUST be lowercase. If specified by the application - protocol for services such as telnet and the Berkeley R commands that - run with system privileges, the first component MAY be the string - 'host' instead of a service-specific identifier. - - - -Neuman, et al. Standards Track [Page 100] - -RFC 4120 Kerberos V5 July 2005 - - -7. Constants and Other Defined Values - -7.1. Host Address Types - - All negative values for the host address type are reserved for local - use. All non-negative values are reserved for officially assigned - type fields and interpretations. - - Internet (IPv4) Addresses - - Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded - in MSB order (most significant byte first). The IPv4 loopback - address SHOULD NOT appear in a Kerberos PDU. The type of IPv4 - addresses is two (2). - - Internet (IPv6) Addresses - - IPv6 addresses [RFC3513] are 128-bit (16-octet) quantities, - encoded in MSB order (most significant byte first). The type of - IPv6 addresses is twenty-four (24). The following addresses MUST - NOT appear in any Kerberos PDU: - - * the Unspecified Address - * the Loopback Address - * Link-Local addresses - - This restriction applies to the inclusion in the address fields of - Kerberos PDUs, but not to the address fields of packets that might - carry such PDUs. The restriction is necessary because the use of - an address with non-global scope could allow the acceptance of a - message sent from a node that may have the same address, but which - is not the host intended by the entity that added the restriction. - If the link-local address type needs to be used for communication, - then the address restriction in tickets must not be used (i.e., - addressless tickets must be used). - - IPv4-mapped IPv6 addresses MUST be represented as addresses of - type 2. - - DECnet Phase IV Addresses - - DECnet Phase IV addresses are 16-bit addresses, encoded in LSB - order. The type of DECnet Phase IV addresses is twelve (12). - - - - - - - - -Neuman, et al. Standards Track [Page 101] - -RFC 4120 Kerberos V5 July 2005 - - - Netbios Addresses - - Netbios addresses are 16-octet addresses typically composed of 1 - to 15 alphanumeric characters and padded with the US-ASCII SPC - character (code 32). The 16th octet MUST be the US-ASCII NUL - character (code 0). The type of Netbios addresses is twenty (20). - - Directional Addresses - - Including the sender address in KRB_SAFE and KRB_PRIV messages is - undesirable in many environments because the addresses may be - changed in transport by network address translators. However, if - these addresses are removed, the messages may be subject to a - reflection attack in which a message is reflected back to its - originator. The directional address type provides a way to avoid - transport addresses and reflection attacks. Directional addresses - are encoded as four-byte unsigned integers in network byte order. - If the message is originated by the party sending the original - KRB_AP_REQ message, then an address of 0 SHOULD be used. If the - message is originated by the party to whom that KRB_AP_REQ was - sent, then the address 1 SHOULD be used. Applications involving - multiple parties can specify the use of other addresses. - - Directional addresses MUST only be used for the sender address - field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used - as a ticket address or in a KRB_AP_REQ message. This address type - SHOULD only be used in situations where the sending party knows - that the receiving party supports the address type. This - generally means that directional addresses may only be used when - the application protocol requires their support. Directional - addresses are type (3). - -7.2. KDC Messaging: IP Transports - - Kerberos defines two IP transport mechanisms for communication - between clients and servers: UDP/IP and TCP/IP. - -7.2.1. UDP/IP transport - - Kerberos servers (KDCs) supporting IP transports MUST accept UDP - requests and SHOULD listen for them on port 88 (decimal) unless - specifically configured to listen on an alternative UDP port. - Alternate ports MAY be used when running multiple KDCs for multiple - realms on the same host. - - - - - - - -Neuman, et al. Standards Track [Page 102] - -RFC 4120 Kerberos V5 July 2005 - - - Kerberos clients supporting IP transports SHOULD support the sending - of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to - identify the IP address and port to which they will send their - request. - - When contacting a KDC for a KRB_KDC_REQ request using UDP/IP - transport, the client shall send a UDP datagram containing only an - encoding of the request to the KDC. The KDC will respond with a - reply datagram containing only an encoding of the reply message - (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the - sender's IP address. The response to a request made through UDP/IP - transport MUST also use UDP/IP transport. If the response cannot be - handled using UDP (for example, because it is too large), the KDC - MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the - request using the TCP transport. - -7.2.2. TCP/IP Transport - - Kerberos servers (KDCs) supporting IP transports MUST accept TCP - requests and SHOULD listen for them on port 88 (decimal) unless - specifically configured to listen on an alternate TCP port. - Alternate ports MAY be used when running multiple KDCs for multiple - realms on the same host. - - Clients MUST support the sending of TCP requests, but MAY choose to - try a request initially using the UDP transport. Clients SHOULD use - KDC discovery [7.2.3] to identify the IP address and port to which - they will send their request. - - Implementation note: Some extensions to the Kerberos protocol will - not succeed if any client or KDC not supporting the TCP transport is - involved. Implementations of RFC 1510 were not required to support - TCP/IP transports. - - When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, - the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to - the client on the same TCP stream that was established for the - request. The KDC MAY close the TCP stream after sending a response, - but MAY leave the stream open for a reasonable period of time if it - expects a follow-up. Care must be taken in managing TCP/IP - connections on the KDC to prevent denial of service attacks based on - the number of open TCP/IP connections. - - The client MUST be prepared to have the stream closed by the KDC at - any time after the receipt of a response. A stream closure SHOULD - NOT be treated as a fatal error. Instead, if multiple exchanges are - required (e.g., certain forms of pre-authentication), the client may - need to establish a new connection when it is ready to send - - - -Neuman, et al. Standards Track [Page 103] - -RFC 4120 Kerberos V5 July 2005 - - - subsequent messages. A client MAY close the stream after receiving a - response, and SHOULD close the stream if it does not expect to send - follow-up messages. - - A client MAY send multiple requests before receiving responses, - though it must be prepared to handle the connection being closed - after the first response. - - Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) - sent over the TCP stream is preceded by the length of the request as - 4 octets in network byte order. The high bit of the length is - reserved for future expansion and MUST currently be set to zero. If - a KDC that does not understand how to interpret a set high bit of the - length encoding receives a request with the high order bit of the - length set, it MUST return a KRB-ERROR message with the error - KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream. - - If multiple requests are sent over a single TCP connection and the - KDC sends multiple responses, the KDC is not required to send the - responses in the order of the corresponding requests. This may - permit some implementations to send each response as soon as it is - ready, even if earlier requests are still being processed (for - example, waiting for a response from an external device or database). - -7.2.3. KDC Discovery on IP Networks - - Kerberos client implementations MUST provide a means for the client - to determine the location of the Kerberos Key Distribution Centers - (KDCs). Traditionally, Kerberos implementations have stored such - configuration information in a file on each client machine. - Experience has shown that this method of storing configuration - information presents problems with out-of-date information and - scaling, especially when using cross-realm authentication. This - section describes a method for using the Domain Name System [RFC1035] - for storing KDC location information. - -7.2.3.1. DNS vs. Kerberos: Case Sensitivity of Realm Names - - In Kerberos, realm names are case sensitive. Although it is strongly - encouraged that all realm names be all uppercase, this recommendation - has not been adopted by all sites. Some sites use all lowercase - names and other use mixed case. DNS, on the other hand, is case - insensitive for queries. Because the realm names "MYREALM", - "myrealm", and "MyRealm" are all different, but resolve the same in - the domain name system, it is necessary that only one of the possible - combinations of upper- and lowercase characters be used in realm - names. - - - - -Neuman, et al. Standards Track [Page 104] - -RFC 4120 Kerberos V5 July 2005 - - -7.2.3.2. Specifying KDC Location Information with DNS SRV records - - KDC location information is to be stored using the DNS SRV RR - [RFC2782]. The format of this RR is as follows: - - _Service._Proto.Realm TTL Class SRV Priority Weight Port Target - - The Service name for Kerberos is always "kerberos". - - The Proto can be either "udp" or "tcp". If these SRV records are to - be used, both "udp" and "tcp" records MUST be specified for all KDC - deployments. - - The Realm is the Kerberos realm that this record corresponds to. The - realm MUST be a domain-style realm name. - - TTL, Class, SRV, Priority, Weight, and Target have the standard - meaning as defined in RFC 2782. - - As per RFC 2782, the Port number used for "_udp" and "_tcp" SRV - records SHOULD be the value assigned to "kerberos" by the Internet - Assigned Number Authority: 88 (decimal), unless the KDC is configured - to listen on an alternate TCP port. - - Implementation note: Many existing client implementations do not - support KDC Discovery and are configured to send requests to the IANA - assigned port (88 decimal), so it is strongly recommended that KDCs - be configured to listen on that port. - -7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks - - These are DNS records for a Kerberos realm EXAMPLE.COM. It has two - Kerberos servers, kdc1.example.com and kdc2.example.com. Queries - should be directed to kdc1.example.com first as per the specified - priority. Weights are not used in these sample records. - - _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. - _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. - _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. - _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. - -7.3. Name of the TGS - - The principal identifier of the ticket-granting service shall be - composed of three parts: the realm of the KDC issuing the TGS ticket, - and a two-part name of type NT-SRV-INST, with the first part "krbtgt" - and the second part the name of the realm that will accept the TGT. - For example, a TGT issued by the ATHENA.MIT.EDU realm to be used to - - - -Neuman, et al. Standards Track [Page 105] - -RFC 4120 Kerberos V5 July 2005 - - - get tickets from the ATHENA.MIT.EDU KDC has a principal identifier of - "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A TGT - issued by the ATHENA.MIT.EDU realm to be used to get tickets from the - MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), - ("krbtgt", "MIT.EDU") (name). - -7.4. OID Arc for KerberosV5 - - This OID MAY be used to identify Kerberos protocol messages - encapsulated in other protocols. It also designates the OID arc for - KerberosV5-related OIDs assigned by future IETF action. - Implementation note: RFC 1510 had an incorrect value (5) for "dod" in - its OID. - - id-krb5 OBJECT IDENTIFIER ::= { - iso(1) identified-organization(3) dod(6) internet(1) - security(5) kerberosV5(2) - } - - Assignment of OIDs beneath the id-krb5 arc must be obtained by - contacting the registrar for the id-krb5 arc, or its designee. At - the time of the issuance of this RFC, such registrations can be - obtained by contacting krb5-oid-registrar@mit.edu. - -7.5. Protocol Constants and Associated Values - - The following tables list constants used in the protocol and define - their meanings. In the "specification" section, ranges are specified - that limit the values of constants for which values are defined here. - This allows implementations to make assumptions about the maximum - values that will be received for these constants. Implementations - receiving values outside the range specified in the "specification" - section MAY reject the request, but they MUST recover cleanly. - -7.5.1. Key Usage Numbers - - The encryption and checksum specifications in [RFC3961] require as - input a "key usage number", to alter the encryption key used in any - specific message in order to make certain types of cryptographic - attack more difficult. These are the key usage values assigned in - this document: - - 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with - the client key (Section 5.2.7.2) - - - - - - - -Neuman, et al. Standards Track [Page 106] - -RFC 4120 Kerberos V5 July 2005 - - - 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session - key or application session key), encrypted with the - service key (Section 5.3) - 3. AS-REP encrypted part (includes TGS session key or - application session key), encrypted with the client key - (Section 5.4.2) - 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with - the TGS session key (Section 5.4.1) - 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with - the TGS authenticator subkey (Section 5.4.1) - 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, - keyed with the TGS session key (Section 5.5.1) - 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes - TGS authenticator subkey), encrypted with the TGS session - key (Section 5.5.1) - 8. TGS-REP encrypted part (includes application session - key), encrypted with the TGS session key (Section 5.4.2) - 9. TGS-REP encrypted part (includes application session - key), encrypted with the TGS authenticator subkey - (Section 5.4.2) - 10. AP-REQ Authenticator cksum, keyed with the application - session key (Section 5.5.1) - 11. AP-REQ Authenticator (includes application authenticator - subkey), encrypted with the application session key - (Section 5.5.1) - 12. AP-REP encrypted part (includes application session - subkey), encrypted with the application session key - (Section 5.5.2) - 13. KRB-PRIV encrypted part, encrypted with a key chosen by - the application (Section 5.7.1) - 14. KRB-CRED encrypted part, encrypted with a key chosen by - the application (Section 5.8.1) - 15. KRB-SAFE cksum, keyed with a key chosen by the - application (Section 5.6.1) - 16-18. Reserved for future use in Kerberos and related - protocols. - 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) - 20-21. Reserved for future use in Kerberos and related - protocols. - 22-25. Reserved for use in the Kerberos Version 5 GSS-API - mechanisms [RFC4121]. - 26-511. Reserved for future use in Kerberos and related - protocols. - 512-1023. Reserved for uses internal to a Kerberos implementation. - 1024. Encryption for application use in protocols that do not - specify key usage values - - - - - -Neuman, et al. Standards Track [Page 107] - -RFC 4120 Kerberos V5 July 2005 - - - 1025. Checksums for application use in protocols that do not - specify key usage values - 1026-2047. Reserved for application use. - -7.5.2. PreAuthentication Data Types - - Padata and Data Type Padata-type Comment - Value - - PA-TGS-REQ 1 - PA-ENC-TIMESTAMP 2 - PA-PW-SALT 3 - [reserved] 4 - PA-ENC-UNIX-TIME 5 (deprecated) - PA-SANDIA-SECUREID 6 - PA-SESAME 7 - PA-OSF-DCE 8 - PA-CYBERSAFE-SECUREID 9 - PA-AFS3-SALT 10 - PA-ETYPE-INFO 11 - PA-SAM-CHALLENGE 12 (sam/otp) - PA-SAM-RESPONSE 13 (sam/otp) - PA-PK-AS-REQ_OLD 14 (pkinit) - PA-PK-AS-REP_OLD 15 (pkinit) - PA-PK-AS-REQ 16 (pkinit) - PA-PK-AS-REP 17 (pkinit) - PA-ETYPE-INFO2 19 (replaces pa-etype-info) - PA-USE-SPECIFIED-KVNO 20 - PA-SAM-REDIRECT 21 (sam/otp) - PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) - TD-PADATA 22 (embeds padata) - PA-SAM-ETYPE-INFO 23 (sam/otp) - PA-ALT-PRINC 24 (crawdad@fnal.gov) - PA-SAM-CHALLENGE2 30 (kenh@pobox.com) - PA-SAM-RESPONSE2 31 (kenh@pobox.com) - PA-EXTRA-TGT 41 Reserved extra TGT - TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS - TD-KRB-PRINCIPAL 102 PrincipalName - TD-KRB-REALM 103 Realm - TD-TRUSTED-CERTIFIERS 104 from PKINIT - TD-CERTIFICATE-INDEX 105 from PKINIT - TD-APP-DEFINED-ERROR 106 application specific - TD-REQ-NONCE 107 INTEGER - TD-REQ-SEQ 108 INTEGER - PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) - - - - - - -Neuman, et al. Standards Track [Page 108] - -RFC 4120 Kerberos V5 July 2005 - - -7.5.3. Address Types - - Address Type Value - - IPv4 2 - Directional 3 - ChaosNet 5 - XNS 6 - ISO 7 - DECNET Phase IV 12 - AppleTalk DDP 16 - NetBios 20 - IPv6 24 - -7.5.4. Authorization Data Types - - Authorization Data Type Ad-type Value - - AD-IF-RELEVANT 1 - AD-INTENDED-FOR-SERVER 2 - AD-INTENDED-FOR-APPLICATION-CLASS 3 - AD-KDC-ISSUED 4 - AD-AND-OR 5 - AD-MANDATORY-TICKET-EXTENSIONS 6 - AD-IN-TICKET-EXTENSIONS 7 - AD-MANDATORY-FOR-KDC 8 - Reserved values 9-63 - OSF-DCE 64 - SESAME 65 - AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) - AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) - AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com) - -7.5.5. Transited Encoding Types - - Transited Encoding Type Tr-type Value - - DOMAIN-X500-COMPRESS 1 - Reserved values All others - -7.5.6. Protocol Version Number - - Label Value Meaning or MIT Code - - pvno 5 Current Kerberos protocol version number - - - - - - -Neuman, et al. Standards Track [Page 109] - -RFC 4120 Kerberos V5 July 2005 - - -7.5.7. Kerberos Message Types - - Message Type Value Meaning - - KRB_AS_REQ 10 Request for initial authentication - KRB_AS_REP 11 Response to KRB_AS_REQ request - KRB_TGS_REQ 12 Request for authentication based on TGT - KRB_TGS_REP 13 Response to KRB_TGS_REQ request - KRB_AP_REQ 14 Application request to server - KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL - KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request - KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply - KRB_SAFE 20 Safe (checksummed) application message - KRB_PRIV 21 Private (encrypted) application message - KRB_CRED 22 Private (encrypted) message to forward - credentials - KRB_ERROR 30 Error response - -7.5.8. Name Types - - Name Type Value Meaning - - KRB_NT_UNKNOWN 0 Name type not known - KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, - or for users - KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) - KRB_NT_SRV_HST 3 Service with host name as instance - (telnet, rcommands) - KRB_NT_SRV_XHST 4 Service with host as remaining components - KRB_NT_UID 5 Unique ID - KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] - KRB_NT_SMTP_NAME 7 Name in form of SMTP email name - (e.g., user@example.com) - KRB_NT_ENTERPRISE 10 Enterprise name; may be mapped to - principal name - -7.5.9. Error Codes - - Error Code Value Meaning - - KDC_ERR_NONE 0 No error - KDC_ERR_NAME_EXP 1 Client's entry in database - has expired - KDC_ERR_SERVICE_EXP 2 Server's entry in database - has expired - KDC_ERR_BAD_PVNO 3 Requested protocol version - number not supported - - - - -Neuman, et al. Standards Track [Page 110] - -RFC 4120 Kerberos V5 July 2005 - - - KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in - old master key - KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in - old master key - KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in - Kerberos database - KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in - Kerberos database - KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries - in database - KDC_ERR_NULL_KEY 9 The client or server has a - null key - KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for - postdating - KDC_ERR_NEVER_VALID 11 Requested starttime is - later than end time - KDC_ERR_POLICY 12 KDC policy rejects request - KDC_ERR_BADOPTION 13 KDC cannot accommodate - requested option - KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for - encryption type - KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for - checksum type - KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for - padata type - KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for - transited type - KDC_ERR_CLIENT_REVOKED 18 Clients credentials have - been revoked - KDC_ERR_SERVICE_REVOKED 19 Credentials for server have - been revoked - KDC_ERR_TGT_REVOKED 20 TGT has been revoked - KDC_ERR_CLIENT_NOTYET 21 Client not yet valid; try - again later - KDC_ERR_SERVICE_NOTYET 22 Server not yet valid; try - again later - KDC_ERR_KEY_EXPIRED 23 Password has expired; - change password to reset - KDC_ERR_PREAUTH_FAILED 24 Pre-authentication - information was invalid - KDC_ERR_PREAUTH_REQUIRED 25 Additional pre- - authentication required - KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket - don't match - KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for - user2user only - KDC_ERR_PATH_NOT_ACCEPTED 28 KDC Policy rejects - transited path - - - -Neuman, et al. Standards Track [Page 111] - -RFC 4120 Kerberos V5 July 2005 - - - KDC_ERR_SVC_UNAVAILABLE 29 A service is not available - KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on - decrypted field failed - KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired - KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid - KRB_AP_ERR_REPEAT 34 Request is a replay - KRB_AP_ERR_NOT_US 35 The ticket isn't for us - KRB_AP_ERR_BADMATCH 36 Ticket and authenticator - don't match - KRB_AP_ERR_SKEW 37 Clock skew too great - KRB_AP_ERR_BADADDR 38 Incorrect net address - KRB_AP_ERR_BADVERSION 39 Protocol version mismatch - KRB_AP_ERR_MSG_TYPE 40 Invalid msg type - KRB_AP_ERR_MODIFIED 41 Message stream modified - KRB_AP_ERR_BADORDER 42 Message out of order - KRB_AP_ERR_BADKEYVER 44 Specified version of key is - not available - KRB_AP_ERR_NOKEY 45 Service key not available - KRB_AP_ERR_MUT_FAIL 46 Mutual authentication - failed - KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction - KRB_AP_ERR_METHOD 48 Alternative authentication - method required - KRB_AP_ERR_BADSEQ 49 Incorrect sequence number - in message - KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of - checksum in message - KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited - path - KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP; - retry with TCP - KRB_ERR_GENERIC 60 Generic error (description - in e-text) - KRB_ERR_FIELD_TOOLONG 61 Field is too long for this - implementation - KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT - KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT - KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT - KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT - KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT - KRB_AP_ERR_NO_TGT 67 No TGT available to - validate USER-TO-USER - KDC_ERR_WRONG_REALM 68 Reserved for future use - KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for - USER-TO-USER - KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT - KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT - KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT - - - -Neuman, et al. Standards Track [Page 112] - -RFC 4120 Kerberos V5 July 2005 - - - KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT - KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT - KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT - KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT - -8. Interoperability Requirements - - Version 5 of the Kerberos protocol supports a myriad of options. - Among these are multiple encryption and checksum types; alternative - encoding schemes for the transited field; optional mechanisms for - pre-authentication; the handling of tickets with no addresses; - options for mutual authentication; user-to-user authentication; - support for proxies; the format of realm names; the handling of - authorization data; and forwarding, postdating, and renewing tickets. - - In order to ensure the interoperability of realms, it is necessary to - define a minimal configuration that must be supported by all - implementations. This minimal configuration is subject to change as - technology does. For example, if at some later date it is discovered - that one of the required encryption or checksum algorithms is not - secure, it will be replaced. - -8.1. Specification 2 - - This section defines the second specification of these options. - Implementations which are configured in this way can be said to - support Kerberos Version 5 Specification 2 (5.2). Specification 1 - (deprecated) may be found in RFC 1510. - - Transport - - TCP/IP and UDP/IP transport MUST be supported by clients and KDCs - claiming conformance to specification 2. - - Encryption and Checksum Methods - - The following encryption and checksum mechanisms MUST be - supported: - - Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962] - Checksums: HMAC-SHA1-96-AES256 [RFC3962] - - Implementations SHOULD support other mechanisms as well, but the - additional mechanisms may only be used when communicating with - principals known to also support them. The following mechanisms - from [RFC3961] and [RFC3962] SHOULD be supported: - - - - - -Neuman, et al. Standards Track [Page 113] - -RFC 4120 Kerberos V5 July 2005 - - - Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD - Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128 - - Implementations MAY support other mechanisms as well, but the - additional mechanisms may only be used when communicating with - principals known to support them also. - - Implementation note: Earlier implementations of Kerberos generate - messages using the CRC-32 and RSA-MD5 checksum methods. For - interoperability with these earlier releases, implementors MAY - consider supporting these checksum methods but should carefully - analyze the security implications to limit the situations within - which these methods are accepted. - - Realm Names - - All implementations MUST understand hierarchical realms in both - the Internet Domain and the X.500 style. When a TGT for an - unknown realm is requested, the KDC MUST be able to determine the - names of the intermediate realms between the KDCs realm and the - requested realm. - - Transited Field Encoding - - DOMAIN-X500-COMPRESS (described in Section 3.3.3.2) MUST be - supported. Alternative encodings MAY be supported, but they may - only be used when that encoding is supported by ALL intermediate - realms. - - Pre-authentication Methods - - The TGS-REQ method MUST be supported. It is not used on the - initial request. The PA-ENC-TIMESTAMP method MUST be supported by - clients, but whether it is enabled by default MAY be determined on - a realm-by-realm basis. If the method is not used in the initial - request and the error KDC_ERR_PREAUTH_REQUIRED is returned - specifying PA-ENC-TIMESTAMP as an acceptable method, the client - SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- - authentication method. Servers need not support the PA-ENC- - TIMESTAMP method, but if it is not supported the server SHOULD - ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a - request. - - The ETYPE-INFO2 method MUST be supported; this method is used to - communicate the set of supported encryption types, and - corresponding salt and string to key parameters. The ETYPE-INFO - method SHOULD be supported for interoperability with older - implementation. - - - -Neuman, et al. Standards Track [Page 114] - -RFC 4120 Kerberos V5 July 2005 - - - Mutual Authentication - - Mutual authentication (via the KRB_AP_REP message) MUST be - supported. - - Ticket Addresses and Flags - - All KDCs MUST pass through tickets that carry no addresses (i.e., - if a TGT contains no addresses, the KDC will return derivative - tickets). Implementations SHOULD default to requesting - addressless tickets, as this significantly increases - interoperability with network address translation. In some cases, - realms or application servers MAY require that tickets have an - address. - - Implementations SHOULD accept directional address type for the - KRB_SAFE and KRB_PRIV message and SHOULD include directional - addresses in these messages when other address types are not - available. - - Proxies and forwarded tickets MUST be supported. Individual - realms and application servers can set their own policy on when - such tickets will be accepted. - - All implementations MUST recognize renewable and postdated - tickets, but they need not actually implement them. If these - options are not supported, the starttime and endtime in the ticket - SHALL specify a ticket's entire useful life. When a postdated - ticket is decoded by a server, all implementations SHALL make the - presence of the postdated flag visible to the calling server. - - User-to-User Authentication - - Support for user-to-user authentication (via the ENC-TKT-IN-SKEY - KDC option) MUST be provided by implementations, but individual - realms MAY decide as a matter of policy to reject such requests on - a per-principal or realm-wide basis. - - Authorization Data - - Implementations MUST pass all authorization data subfields from - TGTs to any derivative tickets unless they are directed to - suppress a subfield as part of the definition of that registered - subfield type. (It is never incorrect to pass on a subfield, and - no registered subfield types presently specify suppression at the - KDC.) - - - - - -Neuman, et al. Standards Track [Page 115] - -RFC 4120 Kerberos V5 July 2005 - - - Implementations MUST make the contents of any authorization data - subfields available to the server when a ticket is used. - Implementations are not required to allow clients to specify the - contents of the authorization data fields. - - Constant Ranges - - All protocol constants are constrained to 32-bit (signed) values - unless further constrained by the protocol definition. This limit - is provided to allow implementations to make assumptions about the - maximum values that will be received for these constants. - Implementations receiving values outside this range MAY reject the - request, but they MUST recover cleanly. - -8.2. Recommended KDC Values - - Following is a list of recommended values for a KDC configuration. - - Minimum lifetime 5 minutes - Maximum renewable lifetime 1 week - Maximum ticket lifetime 1 day - Acceptable clock skew 5 minutes - Empty addresses Allowed - Proxiable, etc. Allowed - -9. IANA Considerations - - Section 7 of this document specifies protocol constants and other - defined values required for the interoperability of multiple - implementations. Until a subsequent RFC specifies otherwise, or the - Kerberos working group is shut down, allocations of additional - protocol constants and other defined values required for extensions - to the Kerberos protocol will be administered by the Kerberos working - group. Following the recommendations outlined in [RFC2434], guidance - is provided to the IANA as follows: - - "reserved" realm name types in Section 6.1 and "other" realm types - except those beginning with "X-" or "x-" will not be registered - without IETF standards action, at which point guidelines for further - assignment will be specified. Realm name types beginning with "X-" - or "x-" are for private use. - - For host address types described in Section 7.1, negative values are - for private use. Assignment of additional positive numbers is - subject to review by the Kerberos working group or other expert - review. - - - - - -Neuman, et al. Standards Track [Page 116] - -RFC 4120 Kerberos V5 July 2005 - - - Additional key usage numbers, as defined in Section 7.5.1, will be - assigned subject to review by the Kerberos working group or other - expert review. - - Additional preauthentication data type values, as defined in section - 7.5.2, will be assigned subject to review by the Kerberos working - group or other expert review. - - Additional authorization data types as defined in Section 7.5.4, will - be assigned subject to review by the Kerberos working group or other - expert review. Although it is anticipated that there may be - significant demand for private use types, provision is intentionally - not made for a private use portion of the namespace because conflicts - between privately assigned values could have detrimental security - implications. - - Additional transited encoding types, as defined in Section 7.5.5, - present special concerns for interoperability with existing - implementations. As such, such assignments will only be made by - standards action, except that the Kerberos working group or another - other working group with competent jurisdiction may make preliminary - assignments for documents that are moving through the standards - process. - - Additional Kerberos message types, as described in Section 7.5.7, - will be assigned subject to review by the Kerberos working group or - other expert review. - - Additional name types, as described in Section 7.5.8, will be - assigned subject to review by the Kerberos working group or other - expert review. - - Additional error codes described in Section 7.5.9 will be assigned - subject to review by the Kerberos working group or other expert - review. - -10. Security Considerations - - As an authentication service, Kerberos provides a means of verifying - the identity of principals on a network. By itself, Kerberos does - not provide authorization. Applications should not accept the - issuance of a service ticket by the Kerberos server as granting - authority to use the service, since such applications may become - vulnerable to the bypass of this authorization check in an - environment where they inter-operate with other KDCs or where other - options for application authentication are provided. - - - - - -Neuman, et al. Standards Track [Page 117] - -RFC 4120 Kerberos V5 July 2005 - - - Denial of service attacks are not solved with Kerberos. There are - places in the protocols where an intruder can prevent an application - from participating in the proper authentication steps. Because - authentication is a required step for the use of many services, - successful denial of service attacks on a Kerberos server might - result in the denial of other network services that rely on Kerberos - for authentication. Kerberos is vulnerable to many kinds of denial - of service attacks: those on the network, which would prevent clients - from contacting the KDC; those on the domain name system, which could - prevent a client from finding the IP address of the Kerberos server; - and those by overloading the Kerberos KDC itself with repeated - requests. - - Interoperability conflicts caused by incompatible character-set usage - (see 5.2.1) can result in denial of service for clients that utilize - character-sets in Kerberos strings other than those stored in the KDC - database. - - Authentication servers maintain a database of principals (i.e., users - and servers) and their secret keys. The security of the - authentication server machines is critical. The breach of security - of an authentication server will compromise the security of all - servers that rely upon the compromised KDC, and will compromise the - authentication of any principals registered in the realm of the - compromised KDC. - - Principals must keep their secret keys secret. If an intruder - somehow steals a principal's key, it will be able to masquerade as - that principal or impersonate any server to the legitimate principal. - - Password-guessing attacks are not solved by Kerberos. If a user - chooses a poor password, it is possible for an attacker to - successfully mount an off-line dictionary attack by repeatedly - attempting to decrypt, with successive entries from a dictionary, - messages obtained that are encrypted under a key derived from the - user's password. - - Unless pre-authentication options are required by the policy of a - realm, the KDC will not know whether a request for authentication - succeeds. An attacker can request a reply with credentials for any - principal. These credentials will likely not be of much use to the - attacker unless it knows the client's secret key, but the - availability of the response encrypted in the client's secret key - provides the attacker with ciphertext that may be used to mount brute - force or dictionary attacks to decrypt the credentials, by guessing - the user's password. For this reason it is strongly encouraged that - Kerberos realms require the use of pre-authentication. Even with - - - - -Neuman, et al. Standards Track [Page 118] - -RFC 4120 Kerberos V5 July 2005 - - - pre-authentication, attackers may try brute force or dictionary - attacks against credentials that are observed by eavesdropping on the - network. - - Because a client can request a ticket for any server principal and - can attempt a brute force or dictionary attack against the server - principal's key using that ticket, it is strongly encouraged that - keys be randomly generated (rather than generated from passwords) for - any principals that are usable as the target principal for a - KRB_TGS_REQ or KRB_AS_REQ messages. [RFC4086] - - Although the DES-CBC-MD5 encryption method and DES-MD5 checksum - methods are listed as SHOULD be implemented for backward - compatibility, the single DES encryption algorithm on which these are - based is weak, and stronger algorithms should be used whenever - possible. - - Each host on the network must have a clock that is loosely - synchronized to the time of the other hosts; this synchronization is - used to reduce the bookkeeping needs of application servers when they - do replay detection. The degree of "looseness" can be configured on - a per-server basis, but it is typically on the order of 5 minutes. - If the clocks are synchronized over the network, the clock - synchronization protocol MUST itself be secured from network - attackers. - - Principal identifiers must not recycled on a short-term basis. A - typical mode of access control will use access control lists (ACLs) - to grant permissions to particular principals. If a stale ACL entry - remains for a deleted principal and the principal identifier is - reused, the new principal will inherit rights specified in the stale - ACL entry. By not reusing principal identifiers, the danger of - inadvertent access is removed. - - Proper decryption of an KRB_AS_REP message from the KDC is not - sufficient for the host to verify the identity of the user; the user - and an attacker could cooperate to generate a KRB_AS_REP format - message that decrypts properly but is not from the proper KDC. To - authenticate a user logging on to a local system, the credentials - obtained in the AS exchange may first be used in a TGS exchange to - obtain credentials for a local server. Those credentials must then - be verified by a local server through successful completion of the - Client/Server exchange. - - Many RFC 1510-compliant implementations ignore unknown authorization - data elements. Depending on these implementations to honor - authorization data restrictions may create a security weakness. - - - - -Neuman, et al. Standards Track [Page 119] - -RFC 4120 Kerberos V5 July 2005 - - - Kerberos credentials contain clear-text information identifying the - principals to which they apply. If privacy of this information is - needed, this exchange should itself be encapsulated in a protocol - providing for confidentiality on the exchange of these credentials. - - Applications must take care to protect communications subsequent to - authentication, either by using the KRB_PRIV or KRB_SAFE messages as - appropriate, or by applying their own confidentiality or integrity - mechanisms on such communications. Completion of the KRB_AP_REQ and - KRB_AP_REP exchange without subsequent use of confidentiality and - integrity mechanisms provides only for authentication of the parties - to the communication and not confidentiality and integrity of the - subsequent communication. Applications applying confidentiality and - integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must - make sure that the authentication step is appropriately linked with - the protected communication channel that is established by the - application. - - Unless the application server provides its own suitable means to - protect against replay (for example, a challenge-response sequence - initiated by the server after authentication, or use of a server- - generated encryption subkey), the server must utilize a replay cache - to remember any authenticator presented within the allowable clock - skew. All services sharing a key need to use the same replay cache. - If separate replay caches are used, then an authenticator used with - one such service could later be replayed to a different service with - the same service principal. - - If a server loses track of authenticators presented within the - allowable clock skew, it must reject all requests until the clock - skew interval has passed, providing assurance that any lost or - replayed authenticators will fall outside the allowable clock skew - and can no longer be successfully replayed. - - Implementations of Kerberos should not use untrusted directory - servers to determine the realm of a host. To allow this would allow - the compromise of the directory server to enable an attacker to - direct the client to accept authentication with the wrong principal - (i.e., one with a similar name, but in a realm with which the - legitimate host was not registered). - - Implementations of Kerberos must not use DNS to map one name to - another (canonicalize) in order to determine the host part of the - principal name with which one is to communicate. To allow this - canonicalization would allow a compromise of the DNS to result in a - client obtaining credentials and correctly authenticating to the - - - - - -Neuman, et al. Standards Track [Page 120] - -RFC 4120 Kerberos V5 July 2005 - - - wrong principal. Though the client will know who it is communicating - with, it will not be the principal with which it intended to - communicate. - - If the Kerberos server returns a TGT for a realm 'closer' than the - desired realm, the client may use local policy configuration to - verify that the authentication path used is an acceptable one. - Alternatively, a client may choose its own authentication path rather - than rely on the Kerberos server to select one. In either case, any - policy or configuration information used to choose or validate - authentication paths, whether by the Kerberos server or client, must - be obtained from a trusted source. - - The Kerberos protocol in its basic form does not provide perfect - forward secrecy for communications. If traffic has been recorded by - an eavesdropper, then messages encrypted using the KRB_PRIV message, - or messages encrypted using application-specific encryption under - keys exchanged using Kerberos can be decrypted if the user's, - application server's, or KDC's key is subsequently discovered. This - is because the session key used to encrypt such messages, when - transmitted over the network, is encrypted in the key of the - application server. It is also encrypted under the session key from - the user's TGT when it is returned to the user in the KRB_TGS_REP - message. The session key from the TGT is sent to the user in the - KRB_AS_REP message encrypted in the user's secret key and embedded in - the TGT, which was encrypted in the key of the KDC. Applications - requiring perfect forward secrecy must exchange keys through - mechanisms that provide such assurance, but may use Kerberos for - authentication of the encrypted channel established through such - other means. - -11. Acknowledgements - - This document is a revision to RFC 1510 which was co-authored with - John Kohl. The specification of the Kerberos protocol described in - this document is the result of many years of effort. Over this - period, many individuals have contributed to the definition of the - protocol and to the writing of the specification. Unfortunately, it - is not possible to list all contributors as authors of this document, - though there are many not listed who are authors in spirit, including - those who contributed text for parts of some sections, who - contributed to the design of parts of the protocol, and who - contributed significantly to the discussion of the protocol in the - IETF common authentication technology (CAT) and Kerberos working - groups. - - - - - - -Neuman, et al. Standards Track [Page 121] - -RFC 4120 Kerberos V5 July 2005 - - - Among those contributing to the development and specification of - Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan - Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, - Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, - Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome - Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, - Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar - Westerlund, and Nicolas Williams. Many other members of MIT Project - Athena, the MIT networking group, and the Kerberos and CAT working - groups of the IETF contributed but are not listed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Neuman, et al. Standards Track [Page 122] - -RFC 4120 Kerberos V5 July 2005 - - -A. ASN.1 module - -KerberosV5Spec2 { - iso(1) identified-organization(3) dod(6) internet(1) - security(5) kerberosV5(2) modules(4) krb5spec2(2) -} DEFINITIONS EXPLICIT TAGS ::= BEGIN - --- OID arc for KerberosV5 --- --- This OID may be used to identify Kerberos protocol messages --- encapsulated in other protocols. --- --- This OID also designates the OID arc for KerberosV5-related OIDs. --- --- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. -id-krb5 OBJECT IDENTIFIER ::= { - iso(1) identified-organization(3) dod(6) internet(1) - security(5) kerberosV5(2) -} - -Int32 ::= INTEGER (-2147483648..2147483647) - -- signed values representable in 32 bits - -UInt32 ::= INTEGER (0..4294967295) - -- unsigned 32 bit values - -Microseconds ::= INTEGER (0..999999) - -- microseconds - -KerberosString ::= GeneralString (IA5String) - -Realm ::= KerberosString - -PrincipalName ::= SEQUENCE { - name-type [0] Int32, - name-string [1] SEQUENCE OF KerberosString -} - -KerberosTime ::= GeneralizedTime -- with no fractional seconds - -HostAddress ::= SEQUENCE { - addr-type [0] Int32, - address [1] OCTET STRING -} - --- NOTE: HostAddresses is always used as an OPTIONAL field and --- should not be empty. -HostAddresses -- NOTE: subtly different from rfc1510, - - - -Neuman, et al. Standards Track [Page 123] - -RFC 4120 Kerberos V5 July 2005 - - - -- but has a value mapping and encodes the same - ::= SEQUENCE OF HostAddress - --- NOTE: AuthorizationData is always used as an OPTIONAL field and --- should not be empty. -AuthorizationData ::= SEQUENCE OF SEQUENCE { - ad-type [0] Int32, - ad-data [1] OCTET STRING -} - -PA-DATA ::= SEQUENCE { - -- NOTE: first tag is [1], not [0] - padata-type [1] Int32, - padata-value [2] OCTET STRING -- might be encoded AP-REQ -} - -KerberosFlags ::= BIT STRING (SIZE (32..MAX)) - -- minimum number of bits shall be sent, - -- but no fewer than 32 - -EncryptedData ::= SEQUENCE { - etype [0] Int32 -- EncryptionType --, - kvno [1] UInt32 OPTIONAL, - cipher [2] OCTET STRING -- ciphertext -} - -EncryptionKey ::= SEQUENCE { - keytype [0] Int32 -- actually encryption type --, - keyvalue [1] OCTET STRING -} - -Checksum ::= SEQUENCE { - cksumtype [0] Int32, - checksum [1] OCTET STRING -} - -Ticket ::= [APPLICATION 1] SEQUENCE { - tkt-vno [0] INTEGER (5), - realm [1] Realm, - sname [2] PrincipalName, - enc-part [3] EncryptedData -- EncTicketPart -} - --- Encrypted part of ticket -EncTicketPart ::= [APPLICATION 3] SEQUENCE { - flags [0] TicketFlags, - key [1] EncryptionKey, - crealm [2] Realm, - - - -Neuman, et al. Standards Track [Page 124] - -RFC 4120 Kerberos V5 July 2005 - - - cname [3] PrincipalName, - transited [4] TransitedEncoding, - authtime [5] KerberosTime, - starttime [6] KerberosTime OPTIONAL, - endtime [7] KerberosTime, - renew-till [8] KerberosTime OPTIONAL, - caddr [9] HostAddresses OPTIONAL, - authorization-data [10] AuthorizationData OPTIONAL -} - --- encoded Transited field -TransitedEncoding ::= SEQUENCE { - tr-type [0] Int32 -- must be registered --, - contents [1] OCTET STRING -} - -TicketFlags ::= KerberosFlags - -- reserved(0), - -- forwardable(1), - -- forwarded(2), - -- proxiable(3), - -- proxy(4), - -- may-postdate(5), - -- postdated(6), - -- invalid(7), - -- renewable(8), - -- initial(9), - -- pre-authent(10), - -- hw-authent(11), --- the following are new since 1510 - -- transited-policy-checked(12), - -- ok-as-delegate(13) - -AS-REQ ::= [APPLICATION 10] KDC-REQ - -TGS-REQ ::= [APPLICATION 12] KDC-REQ - -KDC-REQ ::= SEQUENCE { - -- NOTE: first tag is [1], not [0] - pvno [1] INTEGER (5) , - msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), - padata [3] SEQUENCE OF PA-DATA OPTIONAL - -- NOTE: not empty --, - req-body [4] KDC-REQ-BODY -} - -KDC-REQ-BODY ::= SEQUENCE { - kdc-options [0] KDCOptions, - - - -Neuman, et al. Standards Track [Page 125] - -RFC 4120 Kerberos V5 July 2005 - - - cname [1] PrincipalName OPTIONAL - -- Used only in AS-REQ --, - realm [2] Realm - -- Server's realm - -- Also client's in AS-REQ --, - sname [3] PrincipalName OPTIONAL, - from [4] KerberosTime OPTIONAL, - till [5] KerberosTime, - rtime [6] KerberosTime OPTIONAL, - nonce [7] UInt32, - etype [8] SEQUENCE OF Int32 -- EncryptionType - -- in preference order --, - addresses [9] HostAddresses OPTIONAL, - enc-authorization-data [10] EncryptedData OPTIONAL - -- AuthorizationData --, - additional-tickets [11] SEQUENCE OF Ticket OPTIONAL - -- NOTE: not empty -} - -KDCOptions ::= KerberosFlags - -- reserved(0), - -- forwardable(1), - -- forwarded(2), - -- proxiable(3), - -- proxy(4), - -- allow-postdate(5), - -- postdated(6), - -- unused7(7), - -- renewable(8), - -- unused9(9), - -- unused10(10), - -- opt-hardware-auth(11), - -- unused12(12), - -- unused13(13), --- 15 is reserved for canonicalize - -- unused15(15), --- 26 was unused in 1510 - -- disable-transited-check(26), --- - -- renewable-ok(27), - -- enc-tkt-in-skey(28), - -- renew(30), - -- validate(31) - -AS-REP ::= [APPLICATION 11] KDC-REP - -TGS-REP ::= [APPLICATION 13] KDC-REP - - - - -Neuman, et al. Standards Track [Page 126] - -RFC 4120 Kerberos V5 July 2005 - - -KDC-REP ::= SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), - padata [2] SEQUENCE OF PA-DATA OPTIONAL - -- NOTE: not empty --, - crealm [3] Realm, - cname [4] PrincipalName, - ticket [5] Ticket, - enc-part [6] EncryptedData - -- EncASRepPart or EncTGSRepPart, - -- as appropriate -} - -EncASRepPart ::= [APPLICATION 25] EncKDCRepPart - -EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart - -EncKDCRepPart ::= SEQUENCE { - key [0] EncryptionKey, - last-req [1] LastReq, - nonce [2] UInt32, - key-expiration [3] KerberosTime OPTIONAL, - flags [4] TicketFlags, - authtime [5] KerberosTime, - starttime [6] KerberosTime OPTIONAL, - endtime [7] KerberosTime, - renew-till [8] KerberosTime OPTIONAL, - srealm [9] Realm, - sname [10] PrincipalName, - caddr [11] HostAddresses OPTIONAL -} - -LastReq ::= SEQUENCE OF SEQUENCE { - lr-type [0] Int32, - lr-value [1] KerberosTime -} - -AP-REQ ::= [APPLICATION 14] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (14), - ap-options [2] APOptions, - ticket [3] Ticket, - authenticator [4] EncryptedData -- Authenticator -} - -APOptions ::= KerberosFlags - -- reserved(0), - -- use-session-key(1), - - - -Neuman, et al. Standards Track [Page 127] - -RFC 4120 Kerberos V5 July 2005 - - - -- mutual-required(2) - --- Unencrypted authenticator -Authenticator ::= [APPLICATION 2] SEQUENCE { - authenticator-vno [0] INTEGER (5), - crealm [1] Realm, - cname [2] PrincipalName, - cksum [3] Checksum OPTIONAL, - cusec [4] Microseconds, - ctime [5] KerberosTime, - subkey [6] EncryptionKey OPTIONAL, - seq-number [7] UInt32 OPTIONAL, - authorization-data [8] AuthorizationData OPTIONAL -} - -AP-REP ::= [APPLICATION 15] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (15), - enc-part [2] EncryptedData -- EncAPRepPart -} - -EncAPRepPart ::= [APPLICATION 27] SEQUENCE { - ctime [0] KerberosTime, - cusec [1] Microseconds, - subkey [2] EncryptionKey OPTIONAL, - seq-number [3] UInt32 OPTIONAL -} - -KRB-SAFE ::= [APPLICATION 20] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (20), - safe-body [2] KRB-SAFE-BODY, - cksum [3] Checksum -} - -KRB-SAFE-BODY ::= SEQUENCE { - user-data [0] OCTET STRING, - timestamp [1] KerberosTime OPTIONAL, - usec [2] Microseconds OPTIONAL, - seq-number [3] UInt32 OPTIONAL, - s-address [4] HostAddress, - r-address [5] HostAddress OPTIONAL -} - -KRB-PRIV ::= [APPLICATION 21] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (21), - -- NOTE: there is no [2] tag - - - -Neuman, et al. Standards Track [Page 128] - -RFC 4120 Kerberos V5 July 2005 - - - enc-part [3] EncryptedData -- EncKrbPrivPart -} - -EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { - user-data [0] OCTET STRING, - timestamp [1] KerberosTime OPTIONAL, - usec [2] Microseconds OPTIONAL, - seq-number [3] UInt32 OPTIONAL, - s-address [4] HostAddress -- sender's addr --, - r-address [5] HostAddress OPTIONAL -- recip's addr -} - -KRB-CRED ::= [APPLICATION 22] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (22), - tickets [2] SEQUENCE OF Ticket, - enc-part [3] EncryptedData -- EncKrbCredPart -} - -EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { - ticket-info [0] SEQUENCE OF KrbCredInfo, - nonce [1] UInt32 OPTIONAL, - timestamp [2] KerberosTime OPTIONAL, - usec [3] Microseconds OPTIONAL, - s-address [4] HostAddress OPTIONAL, - r-address [5] HostAddress OPTIONAL -} - -KrbCredInfo ::= SEQUENCE { - key [0] EncryptionKey, - prealm [1] Realm OPTIONAL, - pname [2] PrincipalName OPTIONAL, - flags [3] TicketFlags OPTIONAL, - authtime [4] KerberosTime OPTIONAL, - starttime [5] KerberosTime OPTIONAL, - endtime [6] KerberosTime OPTIONAL, - renew-till [7] KerberosTime OPTIONAL, - srealm [8] Realm OPTIONAL, - sname [9] PrincipalName OPTIONAL, - caddr [10] HostAddresses OPTIONAL -} - -KRB-ERROR ::= [APPLICATION 30] SEQUENCE { - pvno [0] INTEGER (5), - msg-type [1] INTEGER (30), - ctime [2] KerberosTime OPTIONAL, - cusec [3] Microseconds OPTIONAL, - stime [4] KerberosTime, - - - -Neuman, et al. Standards Track [Page 129] - -RFC 4120 Kerberos V5 July 2005 - - - susec [5] Microseconds, - error-code [6] Int32, - crealm [7] Realm OPTIONAL, - cname [8] PrincipalName OPTIONAL, - realm [9] Realm -- service realm --, - sname [10] PrincipalName -- service name --, - e-text [11] KerberosString OPTIONAL, - e-data [12] OCTET STRING OPTIONAL -} - -METHOD-DATA ::= SEQUENCE OF PA-DATA - -TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { - data-type [0] Int32, - data-value [1] OCTET STRING OPTIONAL -} - --- preauth stuff follows - -PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC - -PA-ENC-TS-ENC ::= SEQUENCE { - patimestamp [0] KerberosTime -- client's time --, - pausec [1] Microseconds OPTIONAL -} - -ETYPE-INFO-ENTRY ::= SEQUENCE { - etype [0] Int32, - salt [1] OCTET STRING OPTIONAL -} - -ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY - -ETYPE-INFO2-ENTRY ::= SEQUENCE { - etype [0] Int32, - salt [1] KerberosString OPTIONAL, - s2kparams [2] OCTET STRING OPTIONAL -} - -ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY - -AD-IF-RELEVANT ::= AuthorizationData - -AD-KDCIssued ::= SEQUENCE { - ad-checksum [0] Checksum, - i-realm [1] Realm OPTIONAL, - i-sname [2] PrincipalName OPTIONAL, - elements [3] AuthorizationData - - - -Neuman, et al. Standards Track [Page 130] - -RFC 4120 Kerberos V5 July 2005 - - -} - -AD-AND-OR ::= SEQUENCE { - condition-count [0] Int32, - elements [1] AuthorizationData -} - -AD-MANDATORY-FOR-KDC ::= AuthorizationData - -END - -B. Changes since RFC 1510 - - This document replaces RFC 1510 and clarifies specification of items - that were not completely specified. Where changes to recommended - implementation choices were made, or where new options were added, - those changes are described within the document and listed in this - section. More significantly, "Specification 2" in Section 8 changes - the required encryption and checksum methods to bring them in line - with the best current practices and to deprecate methods that are no - longer considered sufficiently strong. - - Discussion was added to Section 1 regarding the ability to rely on - the KDC to check the transited field, and on the inclusion of a flag - in a ticket indicating that this check has occurred. This is a new - capability not present in RFC 1510. Pre-existing implementations may - ignore or not set this flag without negative security implications. - - The definition of the secret key says that in the case of a user the - key may be derived from a password. In RFC 1510, it said that the - key was derived from the password. This change was made to - accommodate situations where the user key might be stored on a - smart-card, or otherwise obtained independently of a password. - - The introduction mentions the use of public key cryptography for - initial authentication in Kerberos by reference. RFC 1510 did not - include such a reference. - - Section 1.3 was added to explain that while Kerberos provides - authentication of a named principal, it is still the responsibility - of the application to ensure that the authenticated name is the - entity with which the application wishes to communicate. - - Discussion of extensibility has been added to the introduction. - - Discussion of how extensibility affects ticket flags and KDC options - was added to the introduction of Section 2. No changes were made to - existing options and flags specified in RFC 1510, though some of the - - - -Neuman, et al. Standards Track [Page 131] - -RFC 4120 Kerberos V5 July 2005 - - - sections in the specification were renumbered, and text was revised - to make the description and intent of existing options clearer, - especially with respect to the ENC-TKT-IN-SKEY option (now section - 2.9.2) which is used for user-to-user authentication. The new option - and ticket flag transited policy checking (Section 2.7) was added. - - A warning regarding generation of session keys for application use - was added to Section 3, urging the inclusion of key entropy from the - KDC generated session key in the ticket. An example regarding use of - the sub-session key was added to Section 3.2.6. Descriptions of the - pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data - items were added. The recommendation for use of pre-authentication - was changed from "MAY" to "SHOULD" and a note was added regarding - known plaintext attacks. - - In RFC 1510, Section 4 described the database in the KDC. This - discussion was not necessary for interoperability and unnecessarily - constrained implementation. The old Section 4 was removed. - - The current Section 4 was formerly Section 6 on encryption and - checksum specifications. The major part of this section was brought - up to date to support new encryption methods, and moved to a separate - document. Those few remaining aspects of the encryption and checksum - specification specific to Kerberos are now specified in Section 4. - - Significant changes were made to the layout of Section 5 to clarify - the correct behavior for optional fields. Many of these changes were - made necessary because of improper ASN.1 description in the original - Kerberos specification which left the correct behavior - underspecified. Additionally, the wording in this section was - tightened wherever possible to ensure that implementations conforming - to this specification will be extensible with the addition of new - fields in future specifications. - - Text was added describing time_t=0 issues in the ASN.1. Text was - also added, clarifying issues with implementations treating omitted - optional integers as zero. Text was added clarifying behavior for - optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was - added regarding sequence numbers and behavior of some - implementations, including "zero" behavior and negative numbers. A - compatibility note was added regarding the unconditional sending of - EncTGSRepPart regardless of the enclosing reply type. Minor changes - were made to the description of the HostAddresses type. Integer - types were constrained. KerberosString was defined as a - (significantly) constrained GeneralString. KerberosFlags was defined - to reflect existing implementation behavior that departs from the - - - - - -Neuman, et al. Standards Track [Page 132] - -RFC 4120 Kerberos V5 July 2005 - - - definition in RFC 1510. The transited-policy-checked(12) and the - ok-as-delegate(13) ticket flags were added. The disable-transited- - check(26) KDC option was added. - - Descriptions of commonly implemented PA-DATA were added to Section 5. - The description of KRB-SAFE has been updated to note the existing - implementation behavior of double-encoding. - - There were two definitions of METHOD-DATA in RFC 1510. The second - one, intended for use with KRB_AP_ERR_METHOD was removed leaving the - SEQUENCE OF PA-DATA definition. - - Section 7, naming constraints, from RFC 1510 was moved to Section 6. - - Words were added describing the convention that domain-based realm - names for newly-created realms should be specified as uppercase. - This recommendation does not make lowercase realm names illegal. - Words were added highlighting that the slash-separated components in - the X.500 style of realm names is consistent with existing RFC 1510 - based implementations, but that it conflicts with the general - recommendation of X.500 name representation specified in RFC 2253. - - Section 8, network transport, constants and defined values, from RFC - 1510 was moved to Section 7. Since RFC 1510, the definition of the - TCP transport for Kerberos messages was added, and the encryption and - checksum number assignments have been moved into a separate document. - - "Specification 2" in Section 8 of the current document changes the - required encryption and checksum methods to bring them in line with - the best current practices and to deprecate methods that are no - longer considered sufficiently strong. - - Two new sections, on IANA considerations and security considerations - were added. - - The pseudo-code has been removed from the appendix. The pseudo-code - was sometimes misinterpreted to limit implementation choices and in - RFC 1510, it was not always consistent with the words in the - specification. Effort was made to clear up any ambiguities in the - specification, rather than to rely on the pseudo-code. - - An appendix was added containing the complete ASN.1 module drawn from - the discussion in Section 5 of the current document. - -END NOTES - - (*TM) Project Athena, Athena, and Kerberos are trademarks of the - Massachusetts Institute of Technology (MIT). - - - -Neuman, et al. Standards Track [Page 133] - -RFC 4120 Kerberos V5 July 2005 - - -Normative References - - [RFC3961] Raeburn, K., "Encryption and Checksum - Specifications for Kerberos 5", RFC 3961, February - 2005. - - [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) - Encryption for Kerberos 5", RFC 3962, February - 2005. - - [ISO-646/ECMA-6] International Organization for Standardization, - "7-bit Coded Character Set for Information - Interchange", ISO/IEC 646:1991. - - [ISO-2022/ECMA-35] International Organization for Standardization, - "Character code structure and extension - techniques", ISO/IEC 2022:1994. - - [RFC1035] Mockapetris, P., "Domain names - implementation - and specification", STD 13, RFC 1035, November - 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to - Indicate Requirement Levels", BCP 14, RFC 2119, - March 1997. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for - Writing an IANA Considerations Section in RFCs", - BCP 26, RFC 2434, October 1998. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS - RR for specifying the location of services (DNS - SRV)", RFC 2782, February 2000. - - [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight - Directory Access Protocol (v3): UTF-8 String - Representation of Distinguished Names", RFC 2253, - December 1997. - - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol - Version 6 (IPv6) Addressing Architecture", RFC - 3513, April 2003. - - [X680] Abstract Syntax Notation One (ASN.1): - Specification of Basic Notation, ITU-T - Recommendation X.680 (1997) | ISO/IEC - International Standard 8824-1:1998. - - - - -Neuman, et al. Standards Track [Page 134] - -RFC 4120 Kerberos V5 July 2005 - - - [X690] ASN.1 encoding rules: Specification of Basic - Encoding Rules (BER), Canonical Encoding Rules - (CER) and Distinguished Encoding Rules (DER), - ITU-T Recommendation X.690 (1997)| ISO/IEC - International Standard 8825-1:1998. - -Informative References - - [ISO-8859] International Organization for Standardization, - "8-bit Single-byte Coded Graphic Character Sets -- - Latin Alphabet", ISO/IEC 8859. - - [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API - Mechanism", RFC 1964, June 1996. - - [DGT96] Don Davis, Daniel Geer, and Theodore Ts'o, - "Kerberos With Clocks Adrift: History, Protocols, - and Implementation", USENIX Computing Systems 9:1, - January 1996. - - [DS81] Dorothy E. Denning and Giovanni Maria Sacco, - "Time-stamps in Key Distribution Protocols," - Communications of the ACM, Vol. 24 (8), p. 533- - 536, August 1981. - - [KNT94] John T. Kohl, B. Clifford Neuman, and Theodore Y. - Ts'o, "The Evolution of the Kerberos - Authentication System". In Distributed Open - Systems, pages 78-94. IEEE Computer Society Press, - 1994. - - [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. - H. Saltzer, Section E.2.1: Kerberos Authentication - and Authorization System, M.I.T. Project Athena, - Cambridge, Massachusetts, December 21, 1987. - - [NS78] Roger M. Needham and Michael D. Schroeder, "Using - Encryption for Authentication in Large Networks of - Computers," Communications of the ACM, Vol. 21 - (12), pp. 993-999, December 1978. - - [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and - Accounting for Distributed Systems," in - Proceedings of the 13th International Conference - on Distributed Computing Systems, Pittsburgh, PA, - May 1993. - - - - - -Neuman, et al. Standards Track [Page 135] - -RFC 4120 Kerberos V5 July 2005 - - - [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An - Authentication Service for Computer Networks," - IEEE Communications Magazine, Vol. 32 (9), p. 33- - 38, September 1994. - - [Pat92] J. Pato, Using Pre-Authentication to Avoid - Password Guessing Attacks, Open Software - Foundation DCE Request for Comments 26 (December - 1992. - - [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network - Authentication Service (V5)", RFC 1510, September - 1993. - - [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, - RFC 4086, June 2005. - - [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, - "Kerberos: An Authentication Service for Open - Network Systems," p. 191-202, Usenix Conference - Proceedings, Dallas, Texas, February 1988. - - [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The - Kerberos Version 5 Generic Security Service - Application Program Interface (GSS-API) Mechanism: - Version 2", RFC 4121, July 2005. - - - - - - - - - - - - - - - - - - - - - - - - -Neuman, et al. Standards Track [Page 136] - -RFC 4120 Kerberos V5 July 2005 - - -Authors' Addresses - - Clifford Neuman - Information Sciences Institute - University of Southern California - 4676 Admiralty Way - Marina del Rey, CA 90292, USA - - EMail: bcn@isi.edu - - - Tom Yu - Massachusetts Institute of Technology - 77 Massachusetts Avenue - Cambridge, MA 02139, USA - - EMail: tlyu@mit.edu - - - Sam Hartman - Massachusetts Institute of Technology - 77 Massachusetts Avenue - Cambridge, MA 02139, USA - - EMail: hartmans-ietf@mit.edu - - - Kenneth Raeburn - Massachusetts Institute of Technology - 77 Massachusetts Avenue - Cambridge, MA 02139, USA - - EMail: raeburn@mit.edu - - - - - - - - - - - - - - - - - - -Neuman, et al. Standards Track [Page 137] - -RFC 4120 Kerberos V5 July 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Neuman, et al. Standards Track [Page 138] - diff --git a/doc/krb5-protocol/rfc4121.txt b/doc/krb5-protocol/rfc4121.txt deleted file mode 100644 index b4115143f5..0000000000 --- a/doc/krb5-protocol/rfc4121.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Network Working Group L. Zhu -Request for Comments: 4121 K. Jaganathan -Updates: 1964 Microsoft -Category: Standards Track S. Hartman - MIT - July 2005 - - - The Kerberos Version 5 - Generic Security Service Application Program Interface (GSS-API) - Mechanism: Version 2 - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document defines protocols, procedures, and conventions to be - employed by peers implementing the Generic Security Service - Application Program Interface (GSS-API) when using the Kerberos - Version 5 mechanism. - - RFC 1964 is updated and incremental changes are proposed in response - to recent developments such as the introduction of Kerberos - cryptosystem framework. These changes support the inclusion of new - cryptosystems, by defining new per-message tokens along with their - encryption and checksum algorithms based on the cryptosystem - profiles. - - - - - - - - - - - - - - -Zhu, et al. Standards Track [Page 1] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -Table of Contents - - 1. Introduction ....................................................2 - 2. Key Derivation for Per-Message Tokens ...........................4 - 3. Quality of Protection ...........................................4 - 4. Definitions and Token Formats ...................................5 - 4.1. Context Establishment Tokens ...............................5 - 4.1.1. Authenticator Checksum ..............................6 - 4.2. Per-Message Tokens .........................................9 - 4.2.1. Sequence Number .....................................9 - 4.2.2. Flags Field .........................................9 - 4.2.3. EC Field ...........................................10 - 4.2.4. Encryption and Checksum Operations .................10 - 4.2.5. RRC Field ..........................................11 - 4.2.6. Message Layouts ....................................12 - 4.3. Context Deletion Tokens ...................................13 - 4.4. Token Identifier Assignment Considerations ................13 - 5. Parameter Definitions ..........................................14 - 5.1. Minor Status Codes ........................................14 - 5.1.1. Non-Kerberos-specific Codes ........................14 - 5.1.2. Kerberos-specific Codes ............................15 - 5.2. Buffer Sizes ..............................................15 - 6. Backwards Compatibility Considerations .........................15 - 7. Security Considerations ........................................16 - 8. Acknowledgements................................................17 - 9. References .....................................................18 - 9.1. Normative References ......................................18 - 9.2. Informative References ....................................18 - -1. Introduction - - [RFC3961] defines a generic framework for describing encryption and - checksum types to be used with the Kerberos protocol and associated - protocols. - - [RFC1964] describes the GSS-API mechanism for Kerberos Version 5. It - defines the format of context establishment, per-message and context - deletion tokens, and uses algorithm identifiers for each cryptosystem - in per-message and context deletion tokens. - - The approach taken in this document obviates the need for algorithm - identifiers. This is accomplished by using the same encryption - algorithm, specified by the crypto profile [RFC3961] for the session - key or subkey that is created during context negotiation, and its - required checksum algorithm. Message layouts of the per-message - tokens are therefore revised to remove algorithm indicators and to - add extra information to support the generic crypto framework - [RFC3961]. - - - -Zhu, et al. Standards Track [Page 2] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - Tokens transferred between GSS-API peers for security context - establishment are also described in this document. The data elements - exchanged between a GSS-API endpoint implementation and the Kerberos - Key Distribution Center (KDC) [RFC4120] are not specific to GSS-API - usage and are therefore defined within [RFC4120] rather than this - specification. - - The new token formats specified in this document MUST be used with - all "newer" encryption types [RFC4120] and MAY be used with - encryption types that are not "newer", provided that the initiator - and acceptor know from the context establishment that they can both - process these new token formats. - - "Newer" encryption types are those which have been specified along - with or since the new Kerberos cryptosystem specification [RFC3961], - as defined in section 3.1.3 of [RFC4120]. The list of not-newer - encryption types is as follows [RFC3961]: - - Encryption Type Assigned Number - ---------------------------------------------- - des-cbc-crc 1 - des-cbc-md4 2 - des-cbc-md5 3 - des3-cbc-md5 5 - des3-cbc-sha1 7 - dsaWithSHA1-CmsOID 9 - md5WithRSAEncryption-CmsOID 10 - sha1WithRSAEncryption-CmsOID 11 - rc2CBC-EnvOID 12 - rsaEncryption-EnvOID 13 - rsaES-OAEP-ENV-OID 14 - des-ede3-cbc-Env-OID 15 - des3-cbc-sha1-kd 16 - rc4-hmac 23 - - Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - The term "little-endian order" is used for brevity to refer to the - least-significant-octet-first encoding, while the term "big-endian - order" is for the most-significant-octet-first encoding. - - - - - - - -Zhu, et al. Standards Track [Page 3] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -2. Key Derivation for Per-Message Tokens - - To limit the exposure of a given key, [RFC3961] adopted "one-way" - "entropy-preserving" derived keys, from a base key or protocol key, - for different purposes or key usages. - - This document defines four key usage values below that are used to - derive a specific key for signing and sealing messages from the - session key or subkey [RFC4120] created during the context - establishment. - - Name Value - ------------------------------------- - KG-USAGE-ACCEPTOR-SEAL 22 - KG-USAGE-ACCEPTOR-SIGN 23 - KG-USAGE-INITIATOR-SEAL 24 - KG-USAGE-INITIATOR-SIGN 25 - - When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is - used as the usage number in the key derivation function for deriving - keys to be used in MIC tokens (as defined in section 4.2.6.1). - KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens (as defined in section - 4.2.6.2). Similarly, when the sender is the context initiator, - KG-USAGE-INITIATOR-SIGN is used as the usage number in the key - derivation function for MIC tokens, while KG-USAGE-INITIATOR-SEAL is - used for Wrap tokens. Even if the Wrap token does not provide for - confidentiality, the same usage values specified above are used. - - During the context initiation and acceptance sequence, the acceptor - MAY assert a subkey in the AP-REP message. If the acceptor asserts a - subkey, the base key is the acceptor-asserted subkey and subsequent - per-message tokens MUST be flagged with "AcceptorSubkey", as - described in section 4.2.2. Otherwise, if the initiator asserts a - subkey in the AP-REQ message, the base key is this subkey; if the - initiator does not assert a subkey, the base key is the session key - in the service ticket. - -3. Quality of Protection - - The GSS-API specification [RFC2743] provides Quality of Protection - (QOP) values that can be used by applications to request a certain - type of encryption or signing. A zero QOP value is used to indicate - the "default" protection; applications that do not use the default - QOP are not guaranteed to be portable across implementations, or even - to inter-operate with different deployment configurations of the same - implementation. Using a different algorithm than the one for which - the key is defined may not be appropriate. Therefore, when the new - method in this document is used, the QOP value is ignored. - - - -Zhu, et al. Standards Track [Page 4] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - The encryption and checksum algorithms in per-message tokens are now - implicitly defined by the algorithms associated with the session key - or subkey. Therefore, algorithm identifiers as described in - [RFC1964] are no longer needed and are removed from the new token - headers. - -4. Definitions and Token Formats - - This section provides terms and definitions, as well as descriptions - for tokens specific to the Kerberos Version 5 GSS-API mechanism. - -4.1. Context Establishment Tokens - - All context establishment tokens emitted by the Kerberos Version 5 - GSS-API mechanism SHALL have the framing described in section 3.1 of - [RFC2743], as illustrated by the following pseudo-ASN.1 structures: - - GSS-API DEFINITIONS ::= - - BEGIN - - MechType ::= OBJECT IDENTIFIER - -- representing Kerberos V5 mechanism - - GSSAPI-Token ::= - -- option indication (delegation, etc.) indicated within - -- mechanism-specific token - [APPLICATION 0] IMPLICIT SEQUENCE { - thisMech MechType, - innerToken ANY DEFINED BY thisMech - -- contents mechanism-specific - -- ASN.1 structure not required - } - - END - - The innerToken field starts with a two-octet token-identifier - (TOK_ID) expressed in big-endian order, followed by a Kerberos - message. - - Following are the TOK_ID values used in the context establishment - tokens: - - Token TOK_ID Value in Hex - ----------------------------------------- - KRB_AP_REQ 01 00 - KRB_AP_REP 02 00 - KRB_ERROR 03 00 - - - -Zhu, et al. Standards Track [Page 5] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR - are defined in [RFC4120]. - - If an unknown token identifier (TOK_ID) is received in the initial - context establishment token, the receiver MUST return - GSS_S_CONTINUE_NEEDED major status, and the returned output token - MUST contain a KRB_ERROR message with the error code - KRB_AP_ERR_MSG_TYPE [RFC4120]. - -4.1.1. Authenticator Checksum - - The authenticator in the KRB_AP_REQ message MUST include the optional - sequence number and the checksum field. The checksum field is used - to convey service flags, channel bindings, and optional delegation - information. - - The checksum type MUST be 0x8003. When delegation is used, a - ticket-granting ticket will be transferred in a KRB_CRED message. - This ticket SHOULD have its forwardable flag set. The EncryptedData - field of the KRB_CRED message [RFC4120] MUST be encrypted in the - session key of the ticket used to authenticate the context. - - The authenticator checksum field SHALL have the following format: - - Octet Name Description - ----------------------------------------------------------------- - 0..3 Lgth Number of octets in Bnd field; Represented - in little-endian order; Currently contains - hex value 10 00 00 00 (16). - 4..19 Bnd Channel binding information, as described in - section 4.1.1.2. - 20..23 Flags Four-octet context-establishment flags in - little-endian order as described in section - 4.1.1.1. - 24..25 DlgOpt The delegation option identifier (=1) in - little-endian order [optional]. This field - and the next two fields are present if and - only if GSS_C_DELEG_FLAG is set as described - in section 4.1.1.1. - 26..27 Dlgth The length of the Deleg field in - little-endian order [optional]. - 28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28) - [optional]. - n..last Exts Extensions [optional]. - - The length of the checksum field MUST be at least 24 octets when - GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at - least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set. When - - - -Zhu, et al. Standards Track [Page 6] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth, and Deleg fields of the - checksum data MUST immediately follow the Flags field. The optional - trailing octets (namely the "Exts" field) facilitate future - extensions to this mechanism. When delegation is not used, but the - Exts field is present, the Exts field starts at octet 24 (DlgOpt, - Dlgth and Deleg are absent). - - Initiators that do not support the extensions MUST NOT include more - than 24 octets in the checksum field (when GSS_C_DELEG_FLAG is not - set) or more than 28 octets plus the KRB_CRED in the Deleg field - (when GSS_C_DELEG_FLAG is set). Acceptors that do not understand the - - Extensions MUST ignore any octets past the Deleg field of the - checksum data (when GSS_C_DELEG_FLAG is set) or past the Flags field - of the checksum data (when GSS_C_DELEG_FLAG is not set). - -4.1.1.1. Checksum Flags Field - - The checksum "Flags" field is used to convey service options or - extension negotiation information. - - The following context establishment flags are defined in [RFC2744]. - - Flag Name Value - --------------------------------- - GSS_C_DELEG_FLAG 1 - GSS_C_MUTUAL_FLAG 2 - GSS_C_REPLAY_FLAG 4 - GSS_C_SEQUENCE_FLAG 8 - GSS_C_CONF_FLAG 16 - GSS_C_INTEG_FLAG 32 - - Context establishment flags are exposed to the calling application. - If the calling application desires a particular service option, then - it requests that option via GSS_Init_sec_context() [RFC2743]. If the - corresponding return state values [RFC2743] indicate that any of the - above optional context level services will be active on the context, - the corresponding flag values in the table above MUST be set in the - checksum Flags field. - - Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use - with legacy vendor-specific extensions to this mechanism. - - - - - - - - - -Zhu, et al. Standards Track [Page 7] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - All other flag values not specified herein are reserved for future - use. Future revisions of this mechanism may use these reserved flags - and may rely on implementations of this version to not use such flags - in order to properly negotiate mechanism versions. Undefined flag - values MUST be cleared by the sender, and unknown flags MUST be - ignored by the receiver. - -4.1.1.2. Channel Binding Information - - These tags are intended to be used to identify the particular - communications channel for which the GSS-API security context - establishment tokens are intended, thus limiting the scope within - which an intercepted context establishment token can be reused by an - attacker (see [RFC2743], section 1.1.6). - - When using C language bindings, channel bindings are communicated to - the GSS-API using the following structure [RFC2744]: - - typedef struct gss_channel_bindings_struct { - OM_uint32 initiator_addrtype; - gss_buffer_desc initiator_address; - OM_uint32 acceptor_addrtype; - gss_buffer_desc acceptor_address; - gss_buffer_desc application_data; - } *gss_channel_bindings_t; - - The member fields and constants used for different address types are - defined in [RFC2744]. - - The "Bnd" field contains the MD5 hash of channel bindings, taken over - all non-null components of bindings, in order of declaration. - Integer fields within channel bindings are represented in little- - endian order for the purposes of the MD5 calculation. - - In computing the contents of the Bnd field, the following detailed - points apply: - - (1) For purposes of MD5 hash computation, each integer field and - input length field SHALL be formatted into four octets, using - little-endian octet ordering. - - (2) All input length fields within gss_buffer_desc elements of a - gss_channel_bindings_struct even those which are zero-valued, - SHALL be included in the hash calculation. The value elements of - gss_buffer_desc elements SHALL be dereferenced, and the resulting - data SHALL be included within the hash computation, only for the - case of gss_buffer_desc elements having non-zero length - specifiers. - - - -Zhu, et al. Standards Track [Page 8] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a - valid channel binding structure, the Bnd field SHALL be set to 16 - zero-valued octets. - - If the caller to GSS_Accept_sec_context [RFC2743] passes in - GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the - acceptor MAY ignore any channel bindings supplied by the initiator, - returning success even if the initiator did pass in channel bindings. - - If the application supplies, in the channel bindings, a buffer with a - length field larger than 4294967295 (2^32 - 1), the implementation of - this mechanism MAY choose to reject the channel bindings altogether, - using major status GSS_S_BAD_BINDINGS [RFC2743]. In any case, the - size of channel-binding data buffers that can be used (interoperable, - without extensions) with this specification is limited to 4294967295 - octets. - -4.2. Per-Message Tokens - - Two classes of tokens are defined in this section: (1) "MIC" tokens, - emitted by calls to GSS_GetMIC() and consumed by calls to - GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to - GSS_Wrap() and consumed by calls to GSS_Unwrap(). - - These new per-message tokens do not include the generic GSS-API token - framing used by the context establishment tokens. These new tokens - are designed to be used with newer crypto systems that can have - variable-size checksums. - -4.2.1. Sequence Number - - To distinguish intentionally-repeated messages from maliciously- - replayed ones, per-message tokens contain a sequence number field, - which is a 64 bit integer expressed in big-endian order. After - sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence - numbers SHALL be incremented by one. - -4.2.2. Flags Field - - The "Flags" field is a one-octet integer used to indicate a set of - attributes for the protected message. For example, one flag is - allocated as the direction-indicator, thus preventing the acceptance - of the same message sent back in the reverse direction by an - adversary. - - - - - - - -Zhu, et al. Standards Track [Page 9] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - The meanings of bits in this field (the least significant bit is bit - 0) are as follows: - - Bit Name Description - -------------------------------------------------------------- - 0 SentByAcceptor When set, this flag indicates the sender - is the context acceptor. When not set, - it indicates the sender is the context - initiator. - 1 Sealed When set in Wrap tokens, this flag - indicates confidentiality is provided - for. It SHALL NOT be set in MIC tokens. - 2 AcceptorSubkey A subkey asserted by the context acceptor - is used to protect the message. - - The rest of available bits are reserved for future use and MUST be - cleared. The receiver MUST ignore unknown flags. - -4.2.3. EC Field - - The "EC" (Extra Count) field is a two-octet integer field expressed - in big-endian order. - - In Wrap tokens with confidentiality, the EC field SHALL be used to - encode the number of octets in the filler, as described in section - 4.2.4. - - In Wrap tokens without confidentiality, the EC field SHALL be used to - encode the number of octets in the trailing checksum, as described in - section 4.2.4. - -4.2.4. Encryption and Checksum Operations - - The encryption algorithms defined by the crypto profiles provide for - integrity protection [RFC3961]. Therefore, no separate checksum is - needed. - - The result of decryption can be longer than the original plaintext - [RFC3961] and the extra trailing octets are called "crypto-system - residue" in this document. However, given the size of any plaintext - data, one can always find a (possibly larger) size, such that when - padding the to-be-encrypted text to that size, there will be no - crypto-system residue added [RFC3961]. - - In Wrap tokens that provide for confidentiality, the first 16 octets - of the Wrap token (the "header", as defined in section 4.2.6), SHALL - be appended to the plaintext data before encryption. Filler octets - MAY be inserted between the plaintext data and the "header." The - - - -Zhu, et al. Standards Track [Page 10] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - values and size of the filler octets are chosen by implementations, - such that there SHALL be no crypto-system residue present after the - decryption. The resulting Wrap token is {"header" | - encrypt(plaintext-data | filler | "header")}, where encrypt() is the - encryption operation (which provides for integrity protection) - defined in the crypto profile [RFC3961], and the RRC field (as - defined in section 4.2.5) in the to-be-encrypted header contains the - hex value 00 00. - - In Wrap tokens that do not provide for confidentiality, the checksum - SHALL be calculated first over the to-be-signed plaintext data, and - then over the first 16 octets of the Wrap token (the "header", as - defined in section 4.2.6). Both the EC field and the RRC field in - the token header SHALL be filled with zeroes for the purpose of - calculating the checksum. The resulting Wrap token is {"header" | - plaintext-data | get_mic(plaintext-data | "header")}, where get_mic() - is the checksum operation for the required checksum mechanism of the - chosen encryption mechanism defined in the crypto profile [RFC3961]. - - The parameters for the key and the cipher-state in the encrypt() and - get_mic() operations have been omitted for brevity. - - For MIC tokens, the checksum SHALL be calculated as follows: the - checksum operation is calculated first over the to-be-signed - plaintext data, and then over the first 16 octets of the MIC token, - where the checksum mechanism is the required checksum mechanism of - the chosen encryption mechanism defined in the crypto profile - [RFC3961]. - - The resulting Wrap and MIC tokens bind the data to the token header, - including the sequence number and the direction indicator. - -4.2.5. RRC Field - - The "RRC" (Right Rotation Count) field in Wrap tokens is added to - allow the data to be encrypted in-place by existing SSPI (Security - Service Provider Interface) [SSPI] applications that do not provide - an additional buffer for the trailer (the cipher text after the in- - place-encrypted data) in addition to the buffer for the header (the - cipher text before the in-place-encrypted data). Excluding the first - 16 octets of the token header, the resulting Wrap token in the - previous section is rotated to the right by "RRC" octets. The net - result is that "RRC" octets of trailing octets are moved toward the - header. - - Consider the following as an example of this rotation operation: - Assume that the RRC value is 3 and the token before the rotation is - {"header" | aa | bb | cc | dd | ee | ff | gg | hh}. The token after - - - -Zhu, et al. Standards Track [Page 11] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee - }, where {aa | bb | cc |...| hh} would be used to indicate the octet - sequence. - - The RRC field is expressed as a two-octet integer in big-endian - order. - - The rotation count value is chosen by the sender based on - implementation details. The receiver MUST be able to interpret all - possible rotation count values, including rotation counts greater - than the length of the token. - -4.2.6. Message Layouts - - Per-message tokens start with a two-octet token identifier (TOK_ID) - field, expressed in big-endian order. These tokens are defined - separately in the following sub-sections. - -4.2.6.1. MIC Tokens - - Use of the GSS_GetMIC() call yields a token (referred as the MIC - token in this document), separate from the user data being protected, - which can be used to verify the integrity of that data as received. - The token has the following format: - - Octet no Name Description - -------------------------------------------------------------- - 0..1 TOK_ID Identification field. Tokens emitted by - GSS_GetMIC() contain the hex value 04 04 - expressed in big-endian order in this - field. - 2 Flags Attributes field, as described in section - 4.2.2. - 3..7 Filler Contains five octets of hex value FF. - 8..15 SND_SEQ Sequence number field in clear text, - expressed in big-endian order. - 16..last SGN_CKSUM Checksum of the "to-be-signed" data and - octet 0..15, as described in section 4.2.4. - - The Filler field is included in the checksum calculation for - simplicity. - - - - - - - - - - -Zhu, et al. Standards Track [Page 12] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -4.2.6.2. Wrap Tokens - - Use of the GSS_Wrap() call yields a token (referred as the Wrap token - in this document), which consists of a descriptive header, followed - by a body portion that contains either the input user data in - plaintext concatenated with the checksum, or the input user data - encrypted. The GSS_Wrap() token SHALL have the following format: - - Octet no Name Description - -------------------------------------------------------------- - 0..1 TOK_ID Identification field. Tokens emitted by - GSS_Wrap() contain the hex value 05 04 - expressed in big-endian order in this - field. - 2 Flags Attributes field, as described in section - 4.2.2. - 3 Filler Contains the hex value FF. - 4..5 EC Contains the "extra count" field, in big- - endian order as described in section 4.2.3. - 6..7 RRC Contains the "right rotation count" in big- - endian order, as described in section - 4.2.5. - 8..15 SND_SEQ Sequence number field in clear text, - expressed in big-endian order. - 16..last Data Encrypted data for Wrap tokens with - confidentiality, or plaintext data followed - by the checksum for Wrap tokens without - confidentiality, as described in section - 4.2.4. - -4.3. Context Deletion Tokens - - Context deletion tokens are empty in this mechanism. Both peers to a - security context invoke GSS_Delete_sec_context() [RFC2743] - independently, passing a null output_context_token buffer to indicate - that no context_token is required. Implementations of - GSS_Delete_sec_context() should delete relevant locally-stored - context information. - -4.4. Token Identifier Assignment Considerations - - Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF inclusive - are reserved and SHALL NOT be assigned. Thus, by examining the first - two octets of a token, one can tell unambiguously if it is wrapped - with the generic GSS-API token framing. - - - - - - -Zhu, et al. Standards Track [Page 13] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -5. Parameter Definitions - - This section defines parameter values used by the Kerberos V5 GSS-API - mechanism. It defines interface elements that support portability, - and assumes use of C language bindings per [RFC2744]. - -5.1. Minor Status Codes - - This section recommends common symbolic names for minor_status values - to be returned by the Kerberos V5 GSS-API mechanism. Use of these - definitions will enable independent implementers to enhance - application portability across different implementations of the - mechanism defined in this specification. (In all cases, - implementations of GSS_Display_status() will enable callers to - convert minor_status indicators to text representations.) Each - implementation should make available, through include files or other - means, a facility to translate these symbolic names into the concrete - values that a particular GSS-API implementation uses to represent the - minor_status values specified in this section. - - This list may grow over time and the need for additional minor_status - codes, specific to particular implementations, may arise. However, - it is recommended that implementations should return a minor_status - value as defined on a mechanism-wide basis within this section when - that code accurately represents reportable status rather than using a - separate, implementation-defined code. - -5.1.1. Non-Kerberos-specific Codes - - GSS_KRB5_S_G_BAD_SERVICE_NAME - /* "No @ in SERVICE-NAME name string" */ - GSS_KRB5_S_G_BAD_STRING_UID - /* "STRING-UID-NAME contains nondigits" */ - GSS_KRB5_S_G_NOUSER - /* "UID does not resolve to username" */ - GSS_KRB5_S_G_VALIDATE_FAILED - /* "Validation error" */ - GSS_KRB5_S_G_BUFFER_ALLOC - /* "Couldn't allocate gss_buffer_t data" */ - GSS_KRB5_S_G_BAD_MSG_CTX - /* "Message context invalid" */ - GSS_KRB5_S_G_WRONG_SIZE - /* "Buffer is the wrong size" */ - GSS_KRB5_S_G_BAD_USAGE - /* "Credential usage type is unknown" */ - GSS_KRB5_S_G_UNKNOWN_QOP - /* "Unknown quality of protection specified" */ - - - - -Zhu, et al. Standards Track [Page 14] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -5.1.2. Kerberos-specific Codes - - GSS_KRB5_S_KG_CCACHE_NOMATCH - /* "Client principal in credentials does not match - specified name" */ - GSS_KRB5_S_KG_KEYTAB_NOMATCH - /* "No key available for specified service - principal" */ - GSS_KRB5_S_KG_TGT_MISSING - /* "No Kerberos ticket-granting ticket available" */ - GSS_KRB5_S_KG_NO_SUBKEY - /* "Authenticator has no subkey" */ - GSS_KRB5_S_KG_CONTEXT_ESTABLISHED - /* "Context is already fully established" */ - GSS_KRB5_S_KG_BAD_SIGN_TYPE - /* "Unknown signature type in token" */ - GSS_KRB5_S_KG_BAD_LENGTH - /* "Invalid field length in token" */ - GSS_KRB5_S_KG_CTX_INCOMPLETE - /* "Attempt to use incomplete security context" */ - -5.2. Buffer Sizes - - All implementations of this specification MUST be capable of - accepting buffers of at least 16K octets as input to GSS_GetMIC(), - GSS_VerifyMIC(), and GSS_Wrap(). They MUST also be capable of - accepting the output_token generated by GSS_Wrap() for a 16K octet - input buffer as input to GSS_Unwrap(). Implementations SHOULD - support 64K octet input buffers, and MAY support even larger input - buffer sizes. - -6. Backwards Compatibility Considerations - - The new token formats defined in this document will only be - recognized by new implementations. To address this, implementations - can always use the explicit sign or seal algorithm in [RFC1964] when - the key type corresponds to not "newer" enctypes. As an alternative, - one might retry sending the message with the sign or seal algorithm - explicitly defined as in [RFC1964]. However, this would require - either the use of a mechanism such as [RFC2478] to securely negotiate - the method, or the use of an out-of-band mechanism to choose the - appropriate mechanism. For this reason, it is RECOMMENDED that the - new token formats defined in this document SHOULD be used only if - both peers are known to support the new mechanism during context - negotiation because of, for example, the use of "new" enctypes. - - - - - - -Zhu, et al. Standards Track [Page 15] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - - GSS_Unwrap() or GSS_VerifyMIC() can process a message token as - follows: it can look at the first octet of the token header, and if - it is 0x60, then the token must carry the generic GSS-API pseudo - ASN.1 framing. Otherwise, the first two octets of the token contain - the TOK_ID that uniquely identify the token message format. - -7. Security Considerations - - Channel bindings are validated by the acceptor. The acceptor can - ignore the channel bindings restriction supplied by the initiator and - carried in the authenticator checksum, if (1) channel bindings are - not used by GSS_Accept_sec_context [RFC2743], and (2) the acceptor - does not prove to the initiator that it has the same channel bindings - as the initiator (even if the client requested mutual - authentication). This limitation should be considered by designers - of applications that would use channel bindings, whether to limit the - use of GSS-API contexts to nodes with specific network addresses, to - authenticate other established, secure channels using Kerberos - Version 5, or for any other purpose. - - Session key types are selected by the KDC. Under the current - mechanism, no negotiation of algorithm types occurs, so server-side - (acceptor) implementations cannot request that clients not use - algorithm types not understood by the server. However, - administrators can control what enctypes can be used for session keys - for this mechanism by controlling the set of the ticket session key - enctypes which the KDC is willing to use in tickets for a given - acceptor principal. Therefore, the KDC could be given the task of - limiting session keys for a given service to types actually supported - by the Kerberos and GSSAPI software on the server. This has a - drawback for cases in which a service principal name is used for both - GSSAPI-based and non-GSSAPI-based communication (most notably the - "host" service key), if the GSSAPI implementation does not understand - (for example) AES [RFC3962], but the Kerberos implementation does. - This means that AES session keys cannot be issued for that service - principal, which keeps the protection of non-GSSAPI services weaker - than necessary. KDC administrators desiring to limit the session key - types to support interoperability with such GSSAPI implementations - should carefully weigh the reduction in protection offered by such - mechanisms against the benefits of interoperability. - - - - - - - - - - - -Zhu, et al. Standards Track [Page 16] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -8. Acknowledgements - - Ken Raeburn and Nicolas Williams corrected many of our errors in the - use of generic profiles and were instrumental in the creation of this - document. - - The text for security considerations was contributed by Nicolas - Williams and Ken Raeburn. - - Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, - namely the encoding of the RRC field. - - Sam Hartman and Nicolas Williams recommended the replacing our - earlier key derivation function for directional keys with different - key usage numbers for each direction as well as retaining the - directional bit for maximum compatibility. - - Paul Leach provided numerous suggestions and comments. - - Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon - Josefsson also provided valuable inputs on this document. - - Jeffrey Hutzelman provided comments and clarifications for the text - related to the channel bindings. - - Jeffrey Hutzelman and Russ Housley suggested many editorial changes. - - Luke Howard provided implementations of this document for the Heimdal - code base, and helped inter-operability testing with the Microsoft - code base, together with Love Hornquist Astrand. These experiments - formed the basis of this document. - - Martin Rex provided suggestions of TOK_ID assignment recommendations, - thus the token tagging in this document is unambiguous if the token - is wrapped with the pseudo ASN.1 header. - - John Linn wrote the original Kerberos Version 5 mechanism - specification [RFC1964], of which some text has been retained. - - - - - - - - - - - - - -Zhu, et al. Standards Track [Page 17] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -9. References - -9.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2743] Linn, J., "Generic Security Service Application Program - Interface Version 2, Update 1", RFC 2743, January 2000. - - [RFC2744] Wray, J., "Generic Security Service API Version 2: - C-bindings", RFC 2744, January 2000. - - [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC - 1964, June 1996. - - [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for - Kerberos 5", RFC 3961, February 2005. - - [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", RFC 4120, - July 2005. - -9.2. Informative References - - [SSPI] Leach, P., "Security Service Provider Interface", - Microsoft Developer Network (MSDN), April 2003. - - [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) - Encryption for Kerberos 5", RFC 3962, February 2005. - - [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API - Negotiation Mechanism", RFC 2478, December 1998. - - - - - - - - - - - - - - - - - - -Zhu, et al. Standards Track [Page 18] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -Authors' Addresses - - Larry Zhu - One Microsoft Way - Redmond, WA 98052 - USA - - EMail: LZhu@microsoft.com - - - Karthik Jaganathan - One Microsoft Way - Redmond, WA 98052 - USA - - EMail: karthikj@microsoft.com - - - Sam Hartman - Massachusetts Institute of Technology - 77 Massachusetts Avenue - Cambridge, MA 02139 - USA - - EMail: hartmans-ietf@mit.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zhu, et al. Standards Track [Page 19] - -RFC 4121 Kerberos Version 5 GSS-API July 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Zhu, et al. Standards Track [Page 20] - diff --git a/doc/krb5-protocol/rfc4557.txt b/doc/krb5-protocol/rfc4557.txt deleted file mode 100644 index fe9a8810df..0000000000 --- a/doc/krb5-protocol/rfc4557.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group L. Zhu -Request for Comments: 4557 K. Jaganathan -Category: Standards Track Microsoft Corporation - N. Williams - Sun Microsystems - June 2006 - - - Online Certificate Status Protocol (OCSP) Support for - Public Key Cryptography for - Initial Authentication in Kerberos (PKINIT) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document defines a mechanism to enable in-band transmission of - Online Certificate Status Protocol (OCSP) responses in the Kerberos - network authentication protocol. These responses are used to verify - the validity of the certificates used in Public Key Cryptography for - Initial Authentication in Kerberos (PKINIT), which is the Kerberos - Version 5 extension that provides for the use of public key - cryptography. - -Table of Contents - - 1. Introduction ....................................................2 - 2. Conventions Used in This Document ...............................2 - 3. Message Definition ..............................................2 - 4. Security Considerations .........................................3 - 5. Acknowledgements ................................................4 - 6. References ......................................................4 - 6.1. Normative References .......................................4 - 6.2. Informative References .....................................4 - - - - - - - -Zhu, et al. Standards Track [Page 1] - -RFC 4557 OCSP Support for PKINIT June 2006 - - -1. Introduction - - Online Certificate Status Protocol (OCSP) [RFC2560] enables - applications to obtain timely information regarding the revocation - status of a certificate. Because OCSP responses are well bounded and - small in size, constrained clients may wish to use OCSP to check the - validity of the certificates for Kerberos Key Distribution Center - (KDC) in order to avoid transmission of large Certificate Revocation - Lists (CRLs) and therefore save bandwidth on constrained networks - [OCSP-PROFILE]. - - This document defines a pre-authentication type [RFC4120], where the - client and the KDC MAY piggyback OCSP responses for certificates used - in authentication exchanges, as defined in [RFC4556]. - - By using this OPTIONAL extension, PKINIT clients and the KDC can - maximize the reuse of cached OCSP responses. - -2. Conventions Used in This Document - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in [RFC2119]. - -3. Message Definition - - A pre-authentication type identifier is defined for this mechanism: - - PA-PK-OCSP-RESPONSE 18 - - The corresponding padata-value field [RFC4120] contains the DER [X60] - encoding of the following ASN.1 type: - - PKOcspData ::= SEQUENCE OF OcspResponse - -- If more than one OcspResponse is - -- included, the first OcspResponse - -- MUST contain the OCSP response - -- for the signer's certificate. - -- The signer refers to the client for - -- AS-REQ, and the KDC for the AS-REP, - -- respectively. - - OcspResponse ::= OCTET STRING - -- Contains a complete OCSP response, - -- as defined in [RFC2560]. - - The client MAY send OCSP responses for certificates used in PA-PK- - AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE. - - - -Zhu, et al. Standards Track [Page 2] - -RFC 4557 OCSP Support for PKINIT June 2006 - - - The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK- - OCSP-RESPONSE containing OCSP responses for certificates used in the - KDC's PA-PK-AS-REP. The client can request a PA-PK-OCSP-RESPONSE by - using a PKOcspData containing an empty sequence. - - The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a - PA-PK-OCSP-RESPONSE from the client. - - The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for - certificates used in PA-PK-AS-REP [RFC4556]. - - Note the lack of integrity protection for the empty or missing OCSP - response; lack of an expected OCSP response from the KDC for the - KDC's certificates SHOULD be treated as an error by the client, - unless it is configured otherwise. - - When using OCSP, the response is signed by the OCSP server, which is - trusted by the receiver. Depending on local policy, further - verification of the validity of the OCSP servers may be needed - - The client and the KDC SHOULD ignore invalid OCSP responses received - via this mechanism, and they MAY implement CRL processing logic as a - fall-back position, if the OCSP responses received via this mechanism - alone are not sufficient for the verification of certificate - validity. The client and/or the KDC MAY ignore a valid OCSP response - and perform its own revocation status verification independently. - -4. Security Considerations - - The pre-authentication data in this document do not actually - authenticate any principals, but are designed to be used in - conjunction with PKINIT. - - There is no binding between PA-PK-OCSP-RESPONSE pre-authentication - data and PKINIT pre-authentication data other than a given OCSP - response corresponding to a certificate used in a PKINIT pre- - authentication data element. Attacks involving removal or - replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements - are, at worst, downgrade attacks, where a PKINIT client or KDC would - proceed without use of CRLs or OCSP for certificate validation, or - denial-of-service attacks, where a PKINIT client or KDC that cannot - validate the other's certificate without an accompanying OCSP - response might reject the AS exchange or might have to download very - large CRLs in order to continue. Kerberos V does not protect against - denial-of-service attacks; therefore, the denial-of-service aspect of - these attacks is acceptable. - - - - - -Zhu, et al. Standards Track [Page 3] - -RFC 4557 OCSP Support for PKINIT June 2006 - - - If a PKINIT client or KDC cannot validate certificates without the - aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS - exchange, possibly according to local configuration. - -5. Acknowledgements - - This document was based on conversations among the authors, Jeffrey - Altman, Sam Hartman, Martin Rex, and other members of the Kerberos - working group. - -6. References - -6.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and - C. Adams, "X.509 Internet Public Key Infrastructure - Online Certificate Status Protocol - OCSP", RFC 2560, - June 1999. - - [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", RFC - 4120, July 2005. - - [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for - Initial Authentication in Kerberos (PKINIT)", RFC - 4556, June 2006. - - [X690] ASN.1 encoding rules: Specification of Basic Encoding - Rules (BER), Canonical Encoding Rules (CER) and - Distinguished Encoding Rules (DER), ITU-T - Recommendation X.690 (1997) | ISO/IEC International - Standard 8825-1:1998. - -6.2. Informative References - - [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for - High Volume Environments", Work in Progress, May 2006. - - - - - - - - - - - -Zhu, et al. Standards Track [Page 4] - -RFC 4557 OCSP Support for PKINIT June 2006 - - -Authors' Addresses - - Larry Zhu - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - EMail: lzhu@microsoft.com - - - Karthik Jaganathan - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - EMail: karthikj@microsoft.com - - - Nicolas Williams - Sun Microsystems - 5300 Riata Trace Ct - Austin, TX 78727 - US - - EMail: Nicolas.Williams@sun.com - - - - - - - - - - - - - - - - - - - - - - - - -Zhu, et al. Standards Track [Page 5] - -RFC 4557 OCSP Support for PKINIT June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zhu, et al. Standards Track [Page 6] - -- 2.47.2