diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt similarity index 74% rename from doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt rename to doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt index a1327fc5b..9b0e76ada 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt @@ -1,12 +1,12 @@ INTERNET-DRAFT Brian Tung -draft-ietf-cat-kerberos-pk-init-10.txt Clifford Neuman -Updates: RFC 1510 ISI -expires April 30, 2000 Matthew Hur +draft-ietf-cat-kerberos-pk-init-11.txt Clifford Neuman +Updates: RFC 1510 USC/ISI +expires September 15, 2000 Matthew Hur CyberSafe Corporation Ari Medvinsky - Excite + Keen.com, Inc. Sasha Medvinsky - General Instrument + Motorola John Wray Iris Associates, Inc. Jonathan Trostle @@ -41,7 +41,7 @@ expires April 30, 2000 Matthew Hur munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as - draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, + draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15, 2000. Please send comments to the authors. 1. Abstract @@ -181,7 +181,7 @@ expires April 30, 2000 Matthew Hur In many cases, PKINIT requires the encoding of the X.500 name of a certificate authority as a Realm. When such a name appears as - a ream it will be represented using the "other" form of the realm + a realm it will be represented using the "other" form of the realm name as specified in the naming constraints section of RFC1510. For a realm derived from an X.500 name, NAMETYPE will have the value X500-RFC2253. The full realm name will appear as follows: @@ -235,12 +235,62 @@ expires April 30, 2000 Matthew Hur 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. + For the purposes of encoding an X.500 name as a Kerberos name for + use in Kerberos structures, the name-string shall be encoded as a + single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL, + as noted above. All Kerberos names must conform to validity + requirements as given in RFC 1510. Note that name mapping may be + required or optional, based on policy. - Note that name mapping may be required or optional based on - policy. All names must conform to validity requirements as given - in RFC 1510. + We also define the following similar ASN.1 structure: + + CertPrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF UTF8String + } + + When a Kerberos PrincipalName is to be placed within an X.509 data + structure, the CertPrincipalName structure is to be used, with the + name-string encoded as a single UTF8String. The name-type should be + as identified in the original PrincipalName structure. The mapping + between the GeneralString and UTF8String formats can be found in + [19]. + + The following rules relate to the the matching of PrincipalNames (or + corresponding CertPrincipalNames) with regard to the PKI name + constraints for CAs as laid out in RFC 2459 [15]. In order to be + regarded as a match (for permitted and excluded name trees), the + following must be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a user plus instance plus realm name (as specified in + RFC 1510), the realm name must be valid (see 2.a-d below) + and the match must be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and must match exactly, byte for byte. + + b. Otherwise, if the realm contains an equal sign, it + is treated as an X.500 name. In order to match, every + component in the constraint MUST be in the principal + name, and have the same value. For example, 'C=US' + matches 'C=US/O=ISI' but not 'C=UK'. + + c. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + d. Otherwise, the realm name is invalid and does not match + under any conditions. 3.1.1. Encryption and Key Formats @@ -330,16 +380,18 @@ expires April 30, 2000 Matthew Hur PA-PK-AS-REQ ::= SEQUENCE { -- PA TYPE 14 signedAuthPack [0] SignedData - -- defined in CMS [11] - -- AuthPack (below) defines the data - -- that is signed + -- Defined in CMS [11]; + -- AuthPack (below) defines the + -- data that is signed. trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, - -- CAs that the client trusts + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. kdcCert [2] IssuerAndSerialNumber OPTIONAL - -- as defined in CMS [11] + -- As defined in CMS [11]; -- specifies a particular KDC -- certificate if the client - -- already has it; + -- already has it. encryptionCert [3] IssuerAndSerialNumber OPTIONAL -- For example, this may be the -- client's Diffie-Hellman @@ -361,29 +413,38 @@ expires April 30, 2000 Matthew Hur } 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 to - enable static-ephemeral Diffie-Hellman mode for the reply; in this - case, the client does NOT place its public value in the AuthPack - (defined below). As another example, the client may place an RSA - encryption certificate in this field. However, there must always - be (at least) a signature certificate. + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field shall contain the OID value for + pkdata: iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) pkdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. 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 certificate + chains 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 to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there must always be (at least) a signature certificate. AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, @@ -503,7 +564,13 @@ expires April 30, 2000 Matthew Hur 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. + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). If a trust relationship exists, the KDC then verifies the client's signature on AuthPack. If that fails, the KDC returns an error @@ -554,7 +621,7 @@ expires April 30, 2000 Matthew Hur 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 + is presented with an 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 @@ -604,34 +671,47 @@ expires April 30, 2000 Matthew Hur } 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. + + When 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: + + 1. 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. + + 2. 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. + + 3. If the reply key is DES, N=64 bits, where some of the bits + are replaced with parity bits, according to FIPS PUB 74. + + 4. 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. + + 5. The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field shall contain the OID value for + pkdata: iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) pkdata (1) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 6. 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). + + 7. 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 @@ -644,42 +724,60 @@ expires April 30, 2000 Matthew Hur } 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. + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which must contain exactly + one member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. 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) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field must contains the + ReplyKeyPack. + + * The eContentType field shall contain the OID value + for pkdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdata (1) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. 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). + + iii. The signerInfos field is a SET that must contain at + least one member, since it contains the actual + signature. ReplyKeyPack ::= SEQUENCE { -- not used for Diffie-Hellman @@ -715,26 +813,27 @@ expires April 30, 2000 Matthew Hur GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName GeneralName ::= CHOICE { - otherName [0] INSTANCE OF OTHER-NAME, + otherName [0] OtherName, ... } - OTHER-NAME ::= TYPE-IDENTIFIER + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } - 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: + For the purpose of specifying a Kerberos principal name, the value + in OtherName shall be a KerberosName as defined in RFC 1510, but with + the PrincipalName replaced by CertPrincipalName as mentioned in + Section 3.1: KerberosName ::= SEQUENCE { - realm [0] Realm, - -- as defined in RFC 1510 - principalName [1] PrincipalName, - -- as defined in RFC 1510 + realm [0] Realm, + principalName [1] CertPrincipalName -- defined above } This specific syntax is identified within subjectAltName by setting - the OID id-ce-subjectAltName to krb5PrincipalName, where (from the + the type-id in OtherName to krb5PrincipalName, where (from the Kerberos specification) we have krb5 OBJECT IDENTIFIER ::= { iso (1) @@ -765,11 +864,11 @@ expires April 30, 2000 Matthew Hur 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 + * 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 @@ -793,11 +892,12 @@ expires April 30, 2000 Matthew Hur 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. + tickets. PKINIT does allow KDCs to act as their own CAs, in the + limited capacity of self-signing their certificates, 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 @@ -837,16 +937,14 @@ expires April 30, 2000 Matthew Hur [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 + 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 + 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 + [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman. + Public Key Utilizing Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-02.txt [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using Public Key Cryptography. Symposium On Network and Distributed @@ -898,6 +996,10 @@ expires April 30, 2000 Matthew Hur [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access Protocol (v3), December 1997. Request for Comments 2251. + [19] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + 8. Acknowledgements Some of the ideas on which this proposal is based arose during @@ -912,7 +1014,7 @@ expires April 30, 2000 Matthew Hur 9. Expiration Date - This draft expires April 30, 2000. + This draft expires September 15, 2000. 10. Authors @@ -932,14 +1034,14 @@ expires April 30, 2000 Matthew Hur 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 + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com Sasha Medvinsky - General Instrument + Motorola 6450 Sequence Drive San Diego, CA 92121 Phone +1 619 404 2825 @@ -955,4 +1057,3 @@ expires April 30, 2000 Matthew Hur 170 W. Tasman Dr. San Jose, CA 95134 E-mail: jtrostle@cisco.com - diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt similarity index 53% rename from doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt rename to doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt index 16af15dbc..15921248c 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-04.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt @@ -1,35 +1,38 @@ -INTERNET-DRAFT Clifford Neuman - John Kohl - Theodore Ts'o - June 25, 1999 - Expires December 25, 1999 -draft-ietf-cat-kerberos-revisions-04.txt +INTERNET-DRAFT Clifford Neuman + John Kohl + Theodore Ts'o + March 10, 2000 + Expires September 10, 2000 The Kerberos Network Authentication Service (V5) +draft-ietf-cat-kerberos-revisions-05.txt STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. Internet-Drafts are working documents +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 +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. +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-revisions-04.txt, and expires December 25th, 1999. +draft-ietf-cat-kerberos-revisions-05.txt, and expires September 10, 2000. Please send comments to: krb-protocol@MIT.EDU ABSTRACT @@ -53,14 +56,16 @@ This INTERNET-DRAFT describes the concepts and model upon which the Kerberos network authentication system is based. It also specifies Version 5 of the Kerberos protocol. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - The motivations, goals, assumptions, and rationale behind most design decisions are treated cursorily; they are more fully described in a paper + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + available in IEEE communications [NT94] and earlier in the Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols have been a proposed standard and are being considered for advancement for draft standard through @@ -115,18 +120,19 @@ third-party authentication service by using conventional (shared secret key [2] cryptography. Kerberos extensions have been proposed and implemented that provide for the use of public key cryptography during certain phases of the authentication protocol. These extensions provide for authentication of - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - users registered with public key certification authorities, and allow the system to provide certain benefits of public key cryptography in situations where they are needed. The basic Kerberos authentication process proceeds as follows: A client + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + sends a request to the authentication server (AS) requesting 'credentials' for a given server. The AS responds with these credentials, encrypted in the client's key. The credentials consist of 1) a 'ticket' for the server and 2) @@ -181,17 +187,19 @@ 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. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - The integrity of the messages exchanged between principals can also be guaranteed 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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 using the session key contained in the @@ -244,13 +252,6 @@ 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 - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 @@ -258,6 +259,14 @@ the client. The application server is ultimately responsible for accepting or rejecting authentication and should check the transited field. The application server + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + may choose to rely on the 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 KDC's for intermediate @@ -282,10 +291,13 @@ by an application as authorizing the use of that service. Such separate authorization methods may be implemented as application specific access control functions and may be based on files such as the application server, or on separately issued authorization credentials such -as those based on proxies [Neu93] , or on other authorization services. +as those based on proxies [Neu93], or on other authorization services. +Separately authenticated authorization credentials may be embedded in a +tickets authorization data when encapsulated by the kdc-issued authorization +data element. -Applications should not be modified to accept the issuance of a service -ticket by the Kerberos server (even by an modified Kerberos server) as +Applications should not be modified to 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 if they interoperate with other KDCs or where other options for application @@ -310,17 +322,18 @@ properly function: 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. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - * 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + per-server basis, but 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. @@ -375,18 +388,19 @@ KDC the Authentication Server (or service). The ticket-granting ticket portion is sometimes referred to as the ticket-granting server (or service). - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - Kerberos Aside from the 3-headed dog guarding Hades, the name given to Project Athena's authentication service, the protocol used by that service, or the code used to implement the authentication service. Plaintext + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + The input to an encryption function or the output of a decryption function. Decryption transforms ciphertext into plaintext. Principal @@ -439,13 +453,6 @@ password-changing program) can insist that this flag be set in any tickets they accept, and thus be assured that the client's key was recently presented to the application client. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - The PRE-AUTHENT and HW-AUTHENT flags provide addition 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 @@ -453,6 +460,14 @@ a ticket-granting ticket (in which case the INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward from the ticket-granting ticket). + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 2.2. Invalid tickets The INVALID flag indicates that a ticket is invalid. Application servers @@ -496,13 +511,6 @@ 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. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 2.4. Postdated tickets Applications may occasionally need to obtain tickets for use much later, @@ -519,6 +527,14 @@ 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 ticket-granting ticket in order to issue a postdated ticket based on the presented ticket. It is reset by default; it may be requested + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. This flag does not allow a client to obtain a postdated ticket-granting ticket; postdated ticket-granting tickets can only by obtained by requesting @@ -559,13 +575,6 @@ authentication. By default, the client will request that it be set when requesting a ticket granting ticket, and reset when requesting any other ticket. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 @@ -585,6 +594,14 @@ provide an audit trail. 2.6. Forwardable tickets Authentication forwarding is an instance of a proxy where the service is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + granted complete use of the client's identity. An example where it might be used is when a user logs in to a remote system and wants authentication to work from that system as if the login were local. @@ -626,13 +643,6 @@ It indicates that the ticket to be issued for the end server is to be encrypted in the session key from the a additional second ticket-granting ticket provided with the request. See section 3.3.3 for specific details. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 3. Message Exchanges The following sections describe the interactions between network clients and @@ -651,6 +661,14 @@ 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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) without requiring further use of the client's secret key. This @@ -688,13 +706,6 @@ can be used to pass additional information that might be needed for the initial exchange. This field may be used for preauthentication as described in section [hl<>]. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 3.1.1. Generation of KRB_AS_REQ message The client may specify a number of options in the initial request. Among @@ -717,6 +728,14 @@ determined as follows. 3.1.3. Generation of KRB_AS_REP message + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + The authentication server looks up the client and server principals named in the KRB_AS_REQ in its database, extracting their respective keys. If required, the server pre-authenticates the request, and if the @@ -753,13 +772,6 @@ been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start time is checked against the policy of the local realm (the administrator might decide to prohibit certain types or ranges of postdated tickets), and if acceptable, the ticket's start time is set as - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 start time has been reached. @@ -783,6 +795,14 @@ 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' flag is set in the new ticket, and the renew-till value is set as if the 'RENEWABLE' option were requested + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + (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 @@ -815,13 +835,6 @@ 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. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 3.1.5. Receipt of KRB_AS_REP message If the reply message type is KRB_AS_REP, then the client verifies that the @@ -849,6 +862,14 @@ verified, then the identity of the user can be assured. 3.1.6. Receipt of KRB_ERROR message + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + If the reply message type is KRB_ERROR, then the client interprets it as an error and performs whatever application-specific tasks are necessary to recover. @@ -878,13 +899,6 @@ 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.' - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 3.2.2. Generation of a KRB_AP_REQ message When a client wishes to initiate authentication to a server, it obtains @@ -915,6 +929,14 @@ 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + application protocol if its 'raw' form is not acceptable to the protocol. The format of error messages is described in section 5.9.1. @@ -943,13 +965,6 @@ decrypted ticket. If decryption shows it to have 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 (they might - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - not match, for example, if the wrong session key was used to encrypt the authenticator). The addresses in the ticket (if any) are then searched for an address matching the operating-system reported address of the client. If @@ -982,6 +997,14 @@ 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. +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 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, the client has been authenticated to the server. See section A.10 for @@ -1008,13 +1031,6 @@ 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)[12]. If a sequence number is to be included, it should be randomly chosen as described above for the authenticator. A subkey may be - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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. See section A.11 for pseudocode. @@ -1047,6 +1063,14 @@ subequent 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 proposed key from the client as input, returning the new subkey in the subkey field of the application reply. This key could then be + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + used for subsequent communication. To make this example more concrete, if the encryption method in use required a 56 bit key, and for whatever reason, one of the parties was prevented from using a key with more than 40 unknown @@ -1067,13 +1091,6 @@ 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 assure integrity. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 3.3. The Ticket-Granting Service (TGS) Exchange Summary @@ -1113,6 +1130,14 @@ TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the session key from the ticket-granting ticket 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + text explaining what went wrong. The KRB_ERROR message is not encrypted. The KRB_TGS_REP message contains information which can be used to detect replays, and to associate it with the message to which it replies. The @@ -1132,13 +1157,6 @@ which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ message recursively). The 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 which is 'closer' to the desired realm (further - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - along the standard hierarchical path), in which case this step must be repeated with a Kerberos server in the realm specified in the returned TGT. If neither are returned, then the request must be retried with a Kerberos @@ -1179,6 +1197,14 @@ 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + appropriate inter-realm key must be used. If the accompanying ticket is not a ticket granting ticket for the current realm, but is for an application server in the current realm, the RENEW, VALIDATE, or PROXY options are @@ -1200,12 +1226,6 @@ the sub-session key from the Authenticator. If any of the decryptions indicate failed integrity checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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), @@ -1244,6 +1264,14 @@ honored if the FORWARDABLE flag is set in the TGT. The PROXY option is similar; the resulting ticket will contain the addresses 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 ticket-granting + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + tickets. If the requested start time is absent, indicates a time in the past, or is @@ -1262,13 +1290,6 @@ 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 ticket-granting ticket. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - If the ENC-TKT-IN-SKEY option has been specified and an additional ticket has been included in the request, the KDC will decrypt the additional ticket using the key for the server to which the additional ticket was issued and @@ -1310,6 +1331,14 @@ 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 the session key key from the ticket-granting ticket. It is not encrypted using the client's secret key. Furthermore, the client's key's expiration date and the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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 ticket-granting ticket. See section A.6 for pseudocode. @@ -1327,13 +1356,6 @@ ticket-granting ticket. The name of the realm that issued the ticket-granting ticket will be added to the transited field of the ticket to be issued. This is accomplished by reading the transited field from the ticket-granting ticket (which is treated as an unordered set of realm - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - names), adding the new realm to the set, then constructing and writing out its encoded (shorthand) form (this may involve a rearrangement of the existing encoding). @@ -1377,6 +1399,14 @@ previous realm[18]. If it 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: +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + "/COM,/HP,/APOLLO, /COM/DEC". Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they @@ -1393,13 +1423,6 @@ 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. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 @@ -1442,6 +1465,14 @@ If the application protocol is expected to tolerate lost messages without them being resent, the use of the timestamp is the appropriate replay detection mechanism. Using timestamps is also the appropriate mechanism for multi-cast protocols where all of one's peers share a common sub-session + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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 @@ -1458,13 +1489,6 @@ 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, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If the sender's address was included in the control information, the recipient - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 @@ -1508,6 +1532,14 @@ information to the recipient. 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. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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 @@ -1523,13 +1555,6 @@ 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 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 - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - microsecond fields from the Authenticator match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is included, or a sequence number is expected but not present, the @@ -1574,6 +1599,14 @@ 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + generated. If present or required, the recipient verifies that the operating system's @@ -1589,17 +1622,10 @@ its ticket cache together with the session key and other information in the corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED message. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 4. The Kerberos Database -The Kerberos server must have access to a database contain- ing the -principal identifiers and secret keys of principals to be authenticated[21]. +The Kerberos server must have access to a database containing the principal +identifiers and secret keys of principals to be authenticated[21]. 4.1. Database contents @@ -1640,18 +1666,19 @@ recipient find the proper key for decryption. When more than one key is active for a particular principal, the principal will have more than one record in the Kerberos database. The keys and key version numbers will differ between the records (the rest of the fields may + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + or may not be the same). Whenever Kerberos issues a ticket, or responds to a request for initial authentication, the most recent key (known by the Kerberos server) will be used for encryption. This is the key with the highest key version number. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 4.2. Additional fields Project Athena's KDC implementation uses additional fields in its database: @@ -1706,16 +1733,17 @@ the last-req field (see section 5.2). Other frequently changing information that can be maintained is the latest expiration time for any tickets that have been issued using each key. This + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + field would be used to indicate how long old keys must remain valid to allow the continued use of outstanding tickets. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 4.4. Site Constants The KDC implementation should have the following configurable constants or @@ -1772,17 +1800,19 @@ Note that since the underscore character (_) is not permitted in ASN.1 names, the hyphen (-) is used in its place for the purposes of ASN.1 names. Realm ::= GeneralString + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + PrincipalName ::= SEQUENCE { name-type[0] INTEGER, name-string[1] SEQUENCE OF GeneralString } -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - Kerberos realms are encoded as GeneralStrings. Realms shall not contain a character with the code 0 (the ASCII NUL). Most realms will usually consist of several components separated by periods (.), in the style of Internet @@ -1837,18 +1867,19 @@ AuthorizationData ::= SEQUENCE OF SEQUENCE { ad-data This field contains authorization data to be interpreted according to the value of the corresponding ad-type field. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - Each sequence of type and data is refered 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 @@ -1862,6 +1893,8 @@ TicketExtensions ::= SEQUENCE OF SEQUENCE { te-data[1] OCTET STRING } + + te-data This field contains opaque data that must be caried with the ticket to support extensions to the Kerberos protocol including but not limited @@ -1901,17 +1934,18 @@ KDCOptions ::= BIT STRING -- proxy(4), -- allow-postdate(5), -- postdated(6), + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + -- unused7(7), -- renewable(8), -- unused9(9), -- unused10(10), - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -- unused11(11), -- unused12(12), -- unused13(13), @@ -1968,11 +2002,12 @@ authenticators. When a ticket or authenticator is included in a protocol message it is treated as an opaque object. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 5.3.1. Tickets @@ -2003,8 +2038,7 @@ EncTicketPart ::= [APPLICATION 3] SEQUENCE { } -- encoded Transited field TransitedEncoding ::= SEQUENCE { - tr-type[0] INTEGER, -- must be -registered + tr-type[0] INTEGER, -- must be registered contents[1] OCTET STRING } @@ -2027,23 +2061,21 @@ sname enc-part This field holds the encrypted encoding of the EncTicketPart sequence. extensions - [*** This change is still subject to discussion. Several alternatives - for this - including none at all - will be distributed to the cat and - krb-protocol mailing lists before the Oslo IETF, and an alternative - will be selected and the spec modified by 7/14/99 ***] This optional - field contains a sequence of extentions that may be used to carry - information that must be carried with the ticket to support several + This optional field contains a sequence of extentions that may be used + to carry information that must be carried with the ticket to support + several extensions, including but not limited to plaintext + authorization data, tokens for exchanging inter-realm keys, and other + information that must be associated with a ticket for use by the + application server. See Appendix C for definitions of some common + extensions. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 - extensions, including but not limited to plaintext authorization data, - tokens for exchanging inter-realm keys, and other information that must - be associated with a ticket for use by the application server. See - Appendix C for definitions of some common extensions. Note that some older versions of Kerberos did not support this field. Because this is an optional field it will not break older clients, but @@ -2098,18 +2130,19 @@ flags ticket-granting tickets may be issued with different network addresses. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 4 PROXY When set, this flag indicates that a ticket is a proxy. 5 MAY-POSTDATE + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + The MAY-POSTDATE flag is normally only interpreted by the TGS, and can be ignored by end servers. This flag tells @@ -2163,19 +2196,20 @@ INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, selected by the KDC and the strength of the method is not indicated. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 12 TRANSITED This flag indicates that the KDC for the POLICY-CHECKED 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, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + and if unable to do so it must reject the authentication. If the flag is set (1) then the application server may skip @@ -2228,13 +2262,6 @@ key crealm This field contains the name of the realm in which the client is registered and in which initial authentication took place. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - cname This field contains the name part of the client's principal identifier. transited @@ -2242,6 +2269,14 @@ transited 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. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + When the names of CA's are to be embedded inthe transited field (as specified for some extentions to the protocol), the X.500 names of the CA's should be mapped into items in the transited field using the @@ -2256,7 +2291,7 @@ authtime 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 returned as part of the response to initial authentication - (KRB_AS_REP), this is the current time on the Ker- beros server[24]. + (KRB_AS_REP), this is the current time on the Kerberos server[24]. 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 @@ -2293,13 +2328,6 @@ caddr key (perhaps through operating system security breaches or a careless user's unattended session) to make use of stolen tickets. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - It is important to 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 @@ -2308,6 +2336,14 @@ INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, stolen credentials and then use them from a "safe" location. authorization-data The authorization-data field is used to pass authorization data from + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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 @@ -2324,9 +2360,10 @@ authorization-data authenticator. Because entries may be added to this field by the holder of - credentials, it is not allowable for the presence of an entry in the - authorization data field of a ticket to amplify the priveleges one - would obtain from using a ticket. + credentials, except when an entry is separately authenticated by + encapulation 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 priveleges 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 @@ -2345,11 +2382,15 @@ authorization-data 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), - obtains a ticket in its own name (e.g. the ticket is issued in the name - of a privelege 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. + may obtain a ticket in its own name (e.g. the ticket is issued in the + name of a privelege 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 B.4). Similarly, if one specifies the authorization-data field of a proxy and leaves the host addresses blank, the resulting ticket and session key @@ -2359,16 +2400,17 @@ authorization-data The authorization-data field is optional and does not have to be included in a ticket. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 5.3.2. Authenticators An authenticator is a record sent with a ticket to a server to certify the + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + client's knowledge of the encryption key in the ticket, to help the server detect replays, and to help choose a "true session key" to use with the particular session. The encoding is encrypted in the ticket's session key @@ -2387,6 +2429,7 @@ Authenticator ::= [APPLICATION 2] SEQUENCE { authorization-data[8] AuthorizationData OPTIONAL } + authenticator-vno This field specifies the version number for the format of the authenticator. This document specifies version 5. @@ -2423,17 +2466,18 @@ seq-number For sequence numbers to adequately support the detection of replays they should be non-repeating, even across connection boundaries. The initial sequence number should be random and uniformly distributed - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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. authorization-data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + This field is the same as described for the ticket in section 5.3.1. 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 @@ -2491,15 +2535,16 @@ KDC-REQ-BODY ::= SEQUENCE { additional-tickets[11] SEQUENCE OF Ticket OPTIONAL } - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - The fields in this message are: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + pvno This field is included in each message, and specifies the protocol version number. This document specifies protocol version 5. @@ -2558,14 +2603,15 @@ padata certain token cards with Kerberos. The details of such extensions are specified in separate documents. See [Pat92] for additional uses of this field. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - padata-type + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + The padata-type element of the padata field 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 @@ -2594,180 +2640,117 @@ kdc-options Bit(s) Name Description 0 RESERVED - Reserved for future expansion of -this + 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 -sub- - sequent request if the -ticket-granting - ticket on which it is based is also -for- + 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 sub- + sequent request if the ticket-granting + ticket on which it is based is also for- wardable. 2 FORWARDED - The FORWARDED option is only -specified - in a request to the -ticket-granting - server and will only be honored if -the - ticket-granting ticket 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 + The FORWARDED option is only specified + in a request to the ticket-granting + server and will only be honored if the + ticket-granting ticket 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. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 3 PROXIABLE - The PROXIABLE option indicates that -the - ticket to be issued is to have its -prox- - iable flag set. It may only be set -on - the initial request, or in a -subsequent - request if the ticket-granting ticket -on + The PROXIABLE option indicates that the + ticket to be issued is to have its prox- + iable flag set. It may only be set on + the initial request, or in a subsequent + request if the ticket-granting ticket on which it is based is also proxiable. +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 4 PROXY - The PROXY option indicates that this -is - a request for a proxy. This option -will - only be honored if the -ticket-granting - ticket in the request has its -PROXIABLE - bit set. The address(es) of the -host - from which the resulting ticket is to -be - valid are included in the -addresses + The PROXY option indicates that this is + a request for a proxy. This option will + only be honored if the ticket-granting + ticket in the request has its PROXIABLE + bit set. The address(es) of the 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 -sub- - sequent request if the -ticket-granting - ticket on which it is based also has -its + 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 sub- + sequent request if the ticket-granting + ticket 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 - ticket-granting ticket 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 + The POSTDATED option indicates that this + is a request for a postdated ticket. + This option will only be honored if the + ticket-granting ticket 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 UNUSED 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 - ticket-granting ticket 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 + 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 + ticket-granting ticket 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-13 UNUSED These options are presently unused. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 14 REQUEST-ANONYMOUS - The REQUEST-ANONYMOUS option -indicates - that the ticket to be issued is not -to - identify the user to which it -was - issued. Instead, the principal -identif- - ier is to be generic, as specified -by - the policy of the realm (e.g. -usually - anonymous@realm). The purpose of -the - ticket is only to securely distribute -a - session key, and not to identify -the - user. The ANONYMOUS flag on the -ticket - to be returned should be set. If -the - local realms policy does not -permit - anonymous credentials, the request is -to + The REQUEST-ANONYMOUS option indicates + that the ticket to be issued is not to + identify the user to which it was + issued. Instead, the principal identif- + ier is to be generic, as specified by + the policy of the realm (e.g. usually + anonymous@realm). The purpose of the + ticket is only to securely distribute a + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + session key, and not to identify the + user. The ANONYMOUS flag on the ticket + to be returned should be set. If the + local realms policy does not permit + anonymous credentials, the request is to be rejected. 15-25 RESERVED @@ -2780,119 +2763,77 @@ to realm before it will issue derivative tickets based on the ticket granting ticket. 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 + 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 tranisted field must be -checked + that the tranisted field must be checked locally. KDC's are encouraged but not required to honor the DISABLE-TRANSITED-CHECK option. 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. If a ticket -with - the requested life cannot be -provided, - then a renewable ticket may be -issued - with a renew-till equal to the -the - requested endtime. The value of -the - renew-till field may still be limited -by - local limits, or limits selected by -the + The RENEWABLE-OK option indicates that a + renewable ticket will be acceptable if a + ticket with the requested life cannot + otherwise be provided. If a ticket with + the requested life cannot be provided, + then a renewable ticket may be issued + with a renew-till equal to the 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 -ticket- + 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 ticket- granting ticket provided. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 - field as part of the -authentication + 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 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 + 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 -vali- - date a postdated ticket. It will -only - be honored if the ticket presented -is - postdated, presently has its -INVALID - flag set, and would be otherwise -usable - at this time. A ticket cannot be -vali- - dated 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 + This option is used only by the ticket- + granting service. The VALIDATE option + indicates that the request is to vali- + date a postdated ticket. It will only + be honored if the ticket presented is + postdated, presently has its INVALID + flag set, and would be otherwise usable + at this time. A ticket cannot be vali- + dated 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 @@ -2921,13 +2862,6 @@ till to have the maximum endtime permitted according to KDC policy for the parties to the authentication exchange as limited by expiration date of the ticket granting ticket or other preauthentication credentials. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - rtime This field is the requested renew-till time sent from a client to the KDC in a ticket request. It is optional. @@ -2938,6 +2872,14 @@ nonce that the response is fresh and has not been replayed by an attacker. Nonces must never be re-used. Ideally, it should be generated randomly, but if the correct time is known, it may suffice[25]. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + etype This field specifies the desired encryption algorithm to be used in the response. @@ -2985,13 +2927,6 @@ absent, the session key from the ticket-granting ticket used in the request. In that case, no version number will be present in the EncryptedData sequence. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - The KRB_KDC_REP message contains the following fields: AS-REP ::= [APPLICATION 11] KDC-REP @@ -3004,6 +2939,14 @@ KDC-REP ::= SEQUENCE { crealm[3] Realm, cname[4] PrincipalName, ticket[5] Ticket, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + enc-part[6] EncryptedData } @@ -3048,13 +2991,6 @@ enc-part The encrypted part is encoded as described in section 6.1. key This field is the same as described for the ticket in section 5.3.1. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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, @@ -3070,6 +3006,14 @@ nonce 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + expiration might be the result of password aging or an account expiration. 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 @@ -3114,11 +3058,6 @@ APOptions ::= BIT STRING { } -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 pvno and msg-type These fields are described above in section 5.4.1. msg-type is @@ -3130,35 +3069,43 @@ ap-options options and reserved fields being reset (0). The encoding of the bits is specified in section 5.2. The meanings of the options are: - Bit(s) Name Description + Bit(s) Name Description - 0 RESERVED - Reserved for future expansion of this - field. + 0 RESERVED + Reserved for future expansion of this - 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 ticket-granting - ticket. When this option is not speci- - fied, the ticket is encrypted in the - server's secret key. +Neuman, Ts'o, Kohl Expires: 10 September, 2000 - 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. + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 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 ticket-granting + ticket. When this option is not speci- + fied, 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. + This field is a ticket authenticating the client to the server. authenticator - This contains the authenticator, which includes the client's choice of - a subkey. Its encoding is described in section 5.3.2. + This contains the authenticator, which includes the client's choice of + a subkey. Its encoding is described in section 5.3.2. 5.5.2. KRB_AP_REP definition @@ -3180,12 +3127,6 @@ EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { seq-number[3] INTEGER OPTIONAL } -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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. @@ -3199,6 +3140,14 @@ ctime This field contains the current time on the client's host. cusec This field contains the microsecond part of the client's timestamp. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + subkey This field contains an encryption key which is to be used to protect this specific application session. See section 3.2.6 for specifics on @@ -3245,13 +3194,6 @@ KRB-SAFE-BODY ::= SEQUENCE { r-address[5] HostAddress OPTIONAL } - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - pvno and msg-type These fields are described above in section 5.4.1. msg-type is KRB_SAFE. @@ -3265,6 +3207,14 @@ cksum the checksum is set to the result of that computation, and finally the KRB-SAFE sequence is encoded again. user-data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + This field is part of the KRB_SAFE and KRB_PRIV messages and contain the application specific data that is being passed from the sender to the recipient. @@ -3312,27 +3262,26 @@ KRB-PRIV ::= [APPLICATION 21] SEQUENCE { enc-part[3] EncryptedData } - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { user-data[0] OCTET STRING, timestamp[1] KerberosTime OPTIONAL, usec[2] INTEGER OPTIONAL, seq-number[3] INTEGER OPTIONAL, - s-address[4] HostAddress OPTIONAL, -- sender's -addr - r-address[5] HostAddress OPTIONAL -- recip's -addr + s-address[4] HostAddress OPTIONAL, -- 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. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + enc-part This field holds an encoding of the EncKrbPrivPart sequence encrypted under the session key[32]. This encrypted encoding is used for the @@ -3379,13 +3328,6 @@ EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { KrbCredInfo ::= SEQUENCE { key[0] EncryptionKey, prealm[1] Realm OPTIONAL, - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - pname[2] PrincipalName OPTIONAL, flags[3] TicketFlags OPTIONAL, authtime[4] KerberosTime OPTIONAL, @@ -3399,6 +3341,14 @@ INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, pvno and msg-type These fields are described above in section 5.4.1. msg-type is + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + KRB_CRED. tickets These are the tickets obtained from the KDC specifically for use by the @@ -3441,13 +3391,6 @@ flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr ticket found in the ticket field. Descriptions of the fields are identical to the descriptions in the KDC-REP message. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 5.9. Error message specification This section specifies the format for the KRB_ERROR message. The fields @@ -3466,6 +3409,14 @@ 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. +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 5.9.1. KRB_ERROR definition The KRB_ERROR message consists of the following fields: @@ -3485,10 +3436,10 @@ KRB-ERROR ::= [APPLICATION 30] SEQUENCE { e-text[11] GeneralString OPTIONAL, e-data[12] OCTET STRING OPTIONAL, e-cksum[13] Checksum OPTIONAL, -(*REMOVE7/14*) e-typed-data[14] SEQUENCE of ETypedData -OPTIONAL } + + pvno and msg-type These fields are described above in section 5.4.1. msg-type is KRB_ERROR. @@ -3504,13 +3455,6 @@ susec value ranges from 0 to 999999. It appears along with stime. The two fields are used in conjunction to specify a reasonably accurate timestamp. - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 @@ -3532,6 +3476,14 @@ e-data pre-authentication method and optionally containing data for the method: +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + TYPED-DATA ::= SEQUENCE of TypeData METHOD-DATA ::= SEQUENCE of PA-DATA @@ -3563,1148 +3515,1247 @@ e-cksum knowledge of the secret key by the client[33]. If a checksum can not be computed because the key to be used is not available, no checksum will be included. -e-typed-data - [***Will be deleted 7/14***] This field contains optional data that may - be used to help the client recover from the indicated error. [This - could contain the METHOD-DATA specified since I don't think anyone - actually uses it yet. It could also contain the PA-DATA sequence for - the preauth required error if we had a clear way to transition to the -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 + 6. Encryption and Checksum Specifications - use of this field from the use of the untyped e-data field.] For - example, this field may specify the key version of the key used to - verify preauthentication: + The Kerberos protocols described in this document are designed to use + stream encryption ciphers, which can be simulated using commonly + available block encryption ciphers, such as the Data Encryption + Standard [DES77], and triple DES variants, in conjunction with block + chaining and checksum methods [DESM80]. 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. - e-data-type := 20 -- Key version number - e-data-value := Integer -- Key version number used to - verify preauthentication + 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 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 prove its knowledge thereof in a response + verifies the identity of the service. -6. Encryption and Checksum Specifications + The Kerberos protocols generally assume that the encryption used is + secure from cryptanalysis; however, in some cases, the order of fields -The Kerberos protocols described in this document are designed to use stream -encryption ciphers, which can be simulated using commonly available block -encryption ciphers, such as the Data Encryption Standard, [DES77] in -conjunction with block chaining and checksum methods [DESM80]. 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. [*** Discussion above will change to use 3DES as example -7/14/99 ***] - -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 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 prove its knowledge -thereof in a response verifies the identity of the service. - -The Kerberos protocols generally assume that the encryption used is secure -from cryptanalysis; however, in some cases, the order of fields in the -encrypted portions of messages are arranged to minimize the effects of -poorly chosen keys. It is still important to choose good keys. If keys are -derived from user-typed passwords, those passwords need to be well chosen to -make brute force attacks more difficult. Poorly chosen keys still make easy -targets for intruders. - -The following sections specify the encryption and checksum mechanisms -currently defined for Kerberos. The encodings, chaining, and padding -requirements for each are described. For encryption methods, it is often -desirable to place random information (often referred to as a confounder) at -the start of the message. The requirements for a confounder are specified -with each encryption mechanism. - -Some encryption systems use a block-chaining method to improve the the -security characteristics of the ciphertext. However, these chaining methods -often don't provide an integrity check upon decryption. Such systems (such -as DES in CBC mode) must be augmented with a checksum of the plain-text -which can be verified at decryption and used to detect any tampering or -damage. Such checksums should be good at detecting burst errors in the -input. If any damage is detected, the decryption routine is expected to -return an error indicating the failure of an integrity check. Each -encryption type is expected to provide and verify an appropriate checksum. -The specification of each encryption method sets out its checksum -requirements. +Neuman, Ts'o, Kohl Expires: 10 September, 2000 -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -Finally, where a key is to be derived from a user's password, an algorithm -for converting the password to a key of the appropriate type is included. It -is desirable for the string to key function to be one-way, and for the -mapping to be different in different realms. This is important because users -who are registered in more than one realm will often use the same password -in each, and it is desirable that an attacker compromising the Kerberos -server in one realm not obtain or derive the user's key in another. - -For an discussion of the integrity characteristics of the candidate -encryption and checksum methods considered for Kerberos, the reader is -referred to [SG92]. - -6.1. Encryption Specifications - -The following ASN.1 definition describes all encrypted messages. The -enc-part field which appears in the unencrypted part of messages in section -5 is a sequence consisting of an encryption type, an optional key version -number, and the ciphertext. - -EncryptedData ::= SEQUENCE { - etype[0] INTEGER, -- EncryptionType - kvno[1] INTEGER OPTIONAL, - cipher[2] OCTET STRING -- ciphertext -} - -etype - This field identifies which encryption algorithm was used to encipher - the cipher. Detailed specifications for selected encryption types - appear later in this section. -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. - -The cipher field is generated by applying the specified encryption algorithm -to data composed of the message and algorithm-specific inputs. Encryption -mechanisms defined for use with Kerberos must take sufficient measures to -guarantee the integrity of the plaintext, and we recommend they also take -measures to protect against precomputed dictionary attacks. If the -encryption algorithm is not itself capable of doing so, the protections can -often be enhanced by adding a checksum and a confounder. - -The suggested format for the data to be encrypted includes a confounder, a -checksum, the encoded plaintext, and any necessary padding. The msg-seq -field contains the part of the protocol message described in section 5 which -is to be encrypted. The confounder, checksum, and padding are all untagged -and untyped, and their length is exactly sufficient to hold the appropriate -item. The type and length is implicit and specified by the particular -encryption type being used (etype). The format for the data to be encrypted -is described in the following diagram: -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 - +-----------+----------+-------------+-----+ - |confounder | check | msg-seq | pad | - +-----------+----------+-------------+-----+ + in the encrypted portions of messages are arranged to minimize the + effects of poorly chosen keys. It is still important to choose good + keys. If keys are derived from user-typed passwords, those passwords + need to be well chosen to make brute force attacks more difficult. + Poorly chosen keys still make easy targets for intruders. -The format cannot be described in ASN.1, but for those who prefer an -ASN.1-like notation: + The following sections specify the encryption and checksum mechanisms + currently defined for Kerberos. The encodings, chaining, and padding + requirements for each are described. For encryption methods, it is + often desirable to place random information (often referred to as a + confounder) at the start of the message. The requirements for a + confounder are specified with each encryption mechanism. -CipherText ::= ENCRYPTED SEQUENCE { - confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, - check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, - msg-seq[2] MsgSequence, - pad UNTAGGED OCTET STRING(pad_length) OPTIONAL -} + Some encryption systems use a block-chaining method to improve the the + security characteristics of the ciphertext. However, these chaining + methods often don't provide an integrity check upon decryption. Such + systems (such as DES in CBC mode) must be augmented with a checksum of + the plain-text which can be verified at decryption and used to detect + any tampering or damage. Such checksums should be good at detecting + burst errors in the input. If any damage is detected, the decryption + routine is expected to return an error indicating the failure of an + integrity check. Each encryption type is expected to provide and verify + an appropriate checksum. The specification of each encryption method + sets out its checksum requirements. -One generates a random confounder of the appropriate length, placing it in -confounder; zeroes out check; calculates the appropriate checksum over -confounder, check, and msg-seq, placing the result in check; adds the -necessary padding; then encrypts using the specified encryption type and the -appropriate key. + Finally, where a key is to be derived from a user's password, an + algorithm for converting the password to a key of the appropriate type + is included. It is desirable for the string to key function to be + one-way, and for the mapping to be different in different realms. This + is important because users who are registered in more than one realm + will often use the same password in each, and it is desirable that an + attacker compromising the Kerberos server in one realm not obtain or + derive the user's key in another. -Unless otherwise specified, a definition of an encryption algorithm that -specifies a checksum, a length for the confounder field, or an octet -boundary for padding uses this ciphertext format[36]. Those fields which are -not specified will be omitted. + For an discussion of the integrity characteristics of the candidate + encryption and checksum methods considered for Kerberos, the reader is + referred to [SG92]. -In the interest of allowing all implementations using a particular -encryption type to communicate with all others using that type, the -specification of an encryption type defines any checksum that is needed as -part of the encryption process. If an alternative checksum is to be used, a -new encryption type must be defined. + 6.1. Encryption Specifications -Some cryptosystems require additional information beyond the key and the -data to be encrypted. For example, DES, when used in cipher-block-chaining -mode, requires an initialization vector. If required, the description for -each encryption type must specify the source of such additional information. -6.2. Encryption Keys + The following ASN.1 definition describes all encrypted messages. The + enc-part field which appears in the unencrypted part of messages in + section 5 is a sequence consisting of an encryption type, an optional + key version number, and the ciphertext. -The sequence below shows the encoding of an encryption key: - - EncryptionKey ::= SEQUENCE { - keytype[0] INTEGER, - keyvalue[1] OCTET STRING - } - -keytype - This field specifies the type of encryption that is to be performed - using the key that follows in the keyvalue field. It will always - correspond to the etype to be used to generate or decode the - EncryptedData. In cases when multiple algorithms use a common kind of - key (e.g., if the encryption algorithm uses an alternate checksum - algorithm for an integrity check, or a different chaining mechanism), - the keytype provides information needed to determine which algorithm is - to be used. -keyvalue - This field contains the key itself, encoded as an octet string. - -All negative values for the encryption key type are reserved for local use. -All non-negative values are reserved for officially assigned type fields and -interpreta- tions. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -6.3. Encryption Systems - -6.3.1. The NULL Encryption System (null) - -If no encryption is in use, the encryption system is said to be the NULL -encryption system. In the NULL encryption system there is no checksum, -confounder or padding. The ciphertext is simply the plaintext. The NULL Key -is used by the null encryption system and is zero octets in length, with -keytype zero (0). - -6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) - -The des-cbc-crc encryption mode encrypts information under the Data -Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A -CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the -confounder and message sequence (msg-seq) and placed in the cksum field. DES -blocks are 8 bytes. As a result, the data to be encrypted (the concatenation -of confounder, checksum, and message) must be padded to an 8 byte boundary -before encryption. The details of the encryption of this data are identical -to those for the des-cbc-md5 encryption mode. - -Note that, since the 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 recommended for environments where such attacks represent a -significant threat. The use of the CRC-32 as the checksum for ticket or -authenticator is no longer mandated as an interoperability requirement for -Kerberos Version 5 Specification 1 (See section 9.1 for specific details). - -6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) - -The des-cbc-md4 encryption mode encrypts information under the Data -Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. -An MD4 checksum (described in [MD492]) is applied to the confounder and -message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 -bytes. As a result, the data to be encrypted (the concatenation of -confounder, checksum, and message) must be padded to an 8 byte boundary -before encryption. The details of the encryption of this data are identical -to those for the des-cbc-md5 encryption mode. - -6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) - -The des-cbc-md5 encryption mode encrypts information under the Data -Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. -An MD5 checksum (described in [MD5-92].) is applied to the confounder and -message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 -bytes. As a result, the data to be encrypted (the concatenation of -confounder, checksum, and message) must be padded to an 8 byte boundary -before encryption. - -Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are -concatenated to make the 64-bit inputs for the DES algorithms. The first -octet supplies the 8 most significant bits (with the octet's MSbit used as -the DES input block's MSbit, etc.), the second octet the next 8 bits, ..., -and the eighth octet supplies the 8 least significant bits. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -Encryption under DES using cipher block chaining requires an additional -input in the form of an initialization vector. Unless otherwise specified, -zero should be used as the initialization vector. Kerberos' use of DES -requires an 8 octet confounder. - -The DES specifications identify some 'weak' and 'semi-weak' keys; those keys -shall not be used for encrypting messages for use in Kerberos. Additionally, -because of the way that keys are derived for the encryption of checksums, -keys shall not be used that yield 'weak' or 'semi-weak' keys when -eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0. - -A DES key is 8 octets of data, with keytype one (1). This consists of 56 -bits of key, and 8 parity bits (one per octet). The key is encoded as a -series of 8 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 -MSbit). [See the FIPS 81 introduction for reference.] - -String to key transformation - -To generate a DES key from a text string (password), a "salt" is -concatenated to the text string, and then padded with ASCII nulls to an 8 -byte boundary. This "salt" is normally the realm and each component of the -principal's name appended. However, sometimes different salts are used --- -for example, when a realm is renamed, or if a user changes her username, or -for compatibility with Kerberos V4 (whose string-to-key algorithm uses a -null string for the salt). This string is then fan-folded and eXclusive-ORed -with itself to form an 8 byte DES key. Before eXclusive-ORing a block, every -byte is shifted one bit to the left to leave the lowest bit zero. The key is -the "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 00000000000000F0. 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 the "corrected" as described above to form -the result which is return as the key. Pseudocode follows: - - name_to_default_salt(realm, name) { - s = realm - for(each component in name) { - s = s + component; - } - return s; + EncryptedData ::= SEQUENCE { + etype[0] INTEGER, -- EncryptionType + kvno[1] INTEGER OPTIONAL, + cipher[2] OCTET STRING -- ciphertext } - key_correction(key) { - fixparity(key); - if (is_weak_key_key(key)) - key = key XOR 0xF0; - return(key); + + + etype + This field identifies which encryption algorithm was used to + encipher the cipher. Detailed specifications for selected + encryption types appear later in this section. + kvno + This field contains the version number of the key under which data + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 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. + The cipher field is generated by applying the specified encryption + algorithm to data composed of the message and algorithm-specific + inputs. Encryption mechanisms defined for use with Kerberos must take + sufficient measures to guarantee the integrity of the plaintext, and we + recommend they also take measures to protect against precomputed + dictionary attacks. If the encryption algorithm is not itself capable + of doing so, the protections can often be enhanced by adding a checksum + and a confounder. + + The suggested format for the data to be encrypted includes a + confounder, a checksum, the encoded plaintext, and any necessary + padding. The msg-seq field contains the part of the protocol message + described in section 5 which is to be encrypted. The confounder, + checksum, and padding are all untagged and untyped, and their length is + exactly sufficient to hold the appropriate item. The type and length is + implicit and specified by the particular encryption type being used + (etype). The format for the data to be encrypted for some methods is + described in the following diagram, but other methods may deviate from + this layour - so long as the definition of the method defines the + layout actually in use. + + +-----------+----------+-------------+-----+ + |confounder | check | msg-seq | pad | + +-----------+----------+-------------+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + CipherText ::= ENCRYPTED SEQUENCE { + confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, + check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, + msg-seq[2] MsgSequence, + pad UNTAGGED OCTET STRING(pad_length) OPTIONAL } - string_to_key(string,salt) { + One generates a random confounder of the appropriate length, placing it + in confounder; zeroes out check; calculates the appropriate checksum + over confounder, check, and msg-seq, placing the result in check; adds + the necessary padding; then encrypts using the specified encryption + type and the appropriate key. - odd = 1; - s = string + salt; - tempkey = NULL; + Unless otherwise specified, a definition of an encryption algorithm + that specifies a checksum, a length for the confounder field, or an + octet boundary for padding uses this ciphertext format[36]. Those + fields which are not specified will be omitted. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 + In the interest of allowing all implementations using a particular + encryption type to communicate with all others using that type, the + specification of an encryption type defines any checksum that is needed + as part of the encryption process. If an alternative checksum is to be + used, a new encryption type must be defined. - pad(s); /* with nulls to 8 byte boundary */ - for(8byteblock in s) { - if(odd == 0) { - odd = 1; - reverse(8byteblock) + Some cryptosystems require additional information beyond the key and + the data to be encrypted. For example, DES, when used in + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + cipher-block-chaining mode, requires an initialization vector. If + required, the description for each encryption type must specify the + source of such additional information. 6.2. Encryption Keys + + The sequence below shows the encoding of an encryption key: + + EncryptionKey ::= SEQUENCE { + keytype[0] INTEGER, + keyvalue[1] OCTET STRING + } + + keytype + This field specifies the type of encryption that is to be + performed using the key that follows in the keyvalue field. It + will always correspond to the etype to be used to generate or + decode the EncryptedData. In cases when multiple algorithms use a + common kind of key (e.g., if the encryption algorithm uses an + alternate checksum algorithm for an integrity check, or a + different chaining mechanism), the keytype provides information + needed to determine which algorithm is to be used. + keyvalue + This field contains the key itself, encoded as an octet string. + All negative values for the encryption key type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpreta- tions. + + 6.3. Encryption Systems + + 6.3.1. The NULL Encryption System (null) + + If no encryption is in use, the encryption system is said to be the + NULL encryption system. In the NULL encryption system there is no + checksum, confounder or padding. The ciphertext is simply the + plaintext. The NULL Key is used by the null encryption system and is + zero octets in length, with keytype zero (0). + + 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) + + The des-cbc-crc encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is + applied to the confounder and message sequence (msg-seq) and placed in + the cksum field. DES blocks are 8 bytes. As a result, the data to be + encrypted (the concatenation of confounder, checksum, and message) must + be padded to an 8 byte boundary before encryption. The details of the + encryption of this data are identical to those for the des-cbc-md5 + encryption mode. + + Note that, since the 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 recommended for environments where such + attacks represent a significant threat. The use of the CRC-32 as the + checksum for ticket or authenticator is no longer mandated as an + interoperability requirement for Kerberos Version 5 Specification 1 + (See section 9.1 for specific details). + + 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The des-cbc-md4 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD4 checksum (described in [MD492]) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be padded + to an 8 byte boundary before encryption. The details of the encryption + of this data are identical to those for the des-cbc-md5 encryption + mode. + + 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) + + The des-cbc-md5 encryption mode encrypts information under the Data + Encryption Standard [DES77] using the cipher block chaining mode + [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the + confounder and message sequence (msg-seq) and placed in the cksum + field. DES blocks are 8 bytes. As a result, the data to be encrypted + (the concatenation of confounder, checksum, and message) must be padded + to an 8 byte boundary before encryption. + + Plaintext and DES ciphtertext are encoded as blocks of 8 octets which + are concatenated to make the 64-bit inputs for the DES algorithms. The + first octet supplies the 8 most significant bits (with the octet's + MSbit used as the DES input block's MSbit, etc.), the second octet the + next 8 bits, ..., and 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. Unless otherwise + specified, zero should be used as the initialization vector. Kerberos' + use of DES requires an 8 octet confounder. + + The DES specifications identify some 'weak' and 'semi-weak' keys; those + keys shall not be used for encrypting messages for use in Kerberos. + Additionally, because of the way that keys are derived for the + encryption of checksums, keys shall not be used that yield 'weak' or + 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant + F0F0F0F0F0F0F0F0. + + A DES key is 8 octets of data, with keytype one (1). This consists of + 56 bits of key, and 8 parity bits (one per octet). The key is encoded + as a series of 8 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 MSbit). [See the FIPS 81 introduction for reference.] + + String to key transformation + + To generate a DES key from a text string (password), a "salt" is + concatenated to the text string, and then padded with ASCII nulls to an + 8 byte boundary. This "salt" is normally the realm and each component + of the principal's name appended. However, sometimes different salts + are used --- for example, when a realm is renamed, or if a user changes + her username, or for compatibility with Kerberos V4 (whose + string-to-key algorithm uses a null string for the salt). This string + is then fan-folded and eXclusive-ORed with itself to form an 8 byte DES + key. Before eXclusive-ORing a block, every byte is shifted one bit to + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the left to leave the lowest bit zero. The key is the "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 00000000000000F0. 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 the "corrected" as + described above to form the result which is return as the key. + Pseudocode follows: + + name_to_default_salt(realm, name) { + s = realm + for(each component in name) { + s = s + component; } - else odd = 0; - left shift every byte in 8byteblock one bit; - tempkey = tempkey XOR 8byteblock; + return s; } - tempkey = key_correction(tempkey); - key = key_correction(DES-CBC-check(s,tempkey)); - return(key); + + key_correction(key) { + fixparity(key); + if (is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + + string_to_key(string,salt) { + + odd = 1; + s = string + salt; + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + left shift every byte in 8byteblock one bit; + tempkey = tempkey XOR 8byteblock; + } + tempkey = key_correction(tempkey); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + + 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and + without Key Derivation [Original draft by Marc Horowitz, revisions by + David Miller] + + This encryption type is based on the Triple DES cryptosystem, the + HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key + derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may not + be used in conjunction with the use of Triple DES keys. + + Algorithm Identifiers + + The des3-cbc-hmac-sha1 encryption type has been assigned the value 7. + The des3-cbc-hmac-sha1-kd encryption type, specifying the key + derivation variant of the encryption type, has been assigned the value + 16. The hmac-sha1-des3 checksum type has been assigned the value 13. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + The hmac-sha1-des3-kd checksum type, specifying the key derivation + variant of the checksum, has been assigned the value 12. + + Triple DES Key Production + + The EncryptionKey value is 24 octets long. The 7 most significant bits + of each octet contain key bits, and the least significant bit is the + inverse of the xor of the key bits. + + For the purposes of key derivation, the block size is 64 bits, and the + key size is 168 bits. The 168 bits output by key derivation are + converted to an EncryptionKey value as follows. First, the 168 bits are + divided into three groups of 56 bits, which are expanded individually + into 64 bits as follows: + + 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 are concatenated to form the EncryptionKey value. + + When the HMAC-SHA1 of a string is computed, the key is used in the + EncryptedKey form. + + The string-to-key function is used to tranform UNICODE passwords into + DES3 keys. The DES3 string-to-key function relies on the "N-fold" + algorithm, which is detailed in [9]. The description of the N-fold + algorithm in that document is as follows: + o 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, addition with end-around carry) + to yield an n-bit result" + o The n-fold algorithm, as with DES string-to-key, is applied to the + password string concatenated with a salt value. The salt value is + derived in the same was as for the DES string-to-key algorithm. + For 3-key triple DES then, the operation will involve a 168-fold + of the input password string. The remainder of the string-to-key + function for DES3 is shown here in pseudocode: + + DES3string-to-key(passwordString, key) + + salt = name_to_default_salt(realm, name) + s = passwordString + salt + tmpKey1 = 168-fold(s) + parityFix(tmpKey1); + if not weakKey(tmpKey1) + /* + * Encrypt temp key in itself with a + * zero initialization vector + * + * Function signature is DES3encrypt(plain, key, iv) + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + * with cipher as the return value + */ + tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec) + /* + * Encrypt resultant temp key in itself with third component + * of first temp key as initialization vector + */ + key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2]) + parityFix(key) + if not weakKey(key) + return SUCCESS + else + return FAILURE + else + return FAILURE + + The weakKey function above is the same weakKey function used with DES + keys, but applied to each of the three single DES keys that comprise + the triple DES key. + + The lengths of UNICODE encoded character strings include the trailing + terminator character (0). + + Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd + + EncryptedData using this type must be generated as described in + [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. + The checksum algorithm is HMAC-SHA1. If the key derivation variant of + the encryption type is used, encryption key values are modified + according to the method under the Key Derivation section below. + + Unless otherwise specified, a zero IV must be used. + + If the length of the input data is not a multiple of the block size, + zero octets must be used to pad the plaintext to the next eight-octet + boundary. The counfounder must be eight random octets (one block). + + Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd + + Checksums using this type must be generated as described in + [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key + derivation variant of the checksum type is used, checksum key values + are modified according to the method under the Key Derivation section + below. + + Key Derivation + + In the Kerberos protocol, cryptographic keys are used in a number of + places. In order to minimize the effect of compromising a key, it is + desirable to use a different key for each of these places. Key + derivation [Horowitz96] can be used to construct different keys for + each operation from the keys transported on the network. For this to be + possible, a small change to the specification is necessary. + + This section specifies a profile for the use of key derivation + [Horowitz96] with Kerberos. For each place where a key is used, a ``key + usage'' must is specified for that purpose. The key, key usage, and + encryption/checksum type together describe the transformation from + plaintext to ciphertext, or plaintext to checksum. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + Key Usage Values + + This is a complete list of places keys are used in the kerberos + protocol, with key usage values and RFC 1510 section numbers: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the + client key (section 5.4.1) + 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or + application session key), encrypted with the service key + (section 5.4.2) + 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 (sections 5.3.2, 5.4.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs + authenticator subkey), encrypted with the tgs session key + (section 5.3.2) + 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.3.2) + 11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (section + 5.3.2) + 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.6.1) + 15. KRB-SAVE cksum, keyed with a key chosen by the application + (section 5.8.1) + 18. KRB-ERROR checksum (e-cksum in section 5.9.1) + 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) + 20. Checksum for Mandatory Ticket Extensions (appendix B.6) + 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) + + 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. + + A few of these key usages need a little clarification. A service which + receives an AP-REQ has no way to know if the enclosed Ticket was part + of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for + generating a Ticket, whether it is in response to an AS- REQ or + TGS-REQ. + + There might exist other documents which define protocols in terms of + the RFC1510 encryption types or checksum types. Such documents would + not know about key usages. In order that these documents continue to be + meaningful until they are updated, key usages 1024 and 1025 must be + used to derive keys for encryption and checksums, respectively. New + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + protocols defined in terms of the Kerberos encryption and checksum + types should use their own key usages. Key usages may be registered + with IANA to avoid conflicts. Key usages must be unsigned 32 bit + integers. Zero is not permitted. + + Defining Cryptosystems Using Key Derivation + + Kerberos requires that the ciphertext component of EncryptedData be + tamper-resistant as well as confidential. This implies encryption and + integrity functions, which must each use their own separate keys. So, + for each key usage, two keys must be generated, one for encryption + (Ke), and one for integrity (Ki): + + Ke = DK(protocol key, key usage | 0xAA) + Ki = DK(protocol key, key usage | 0x55) + + where the protocol key is from the EncryptionKey from the wire + protocol, and the key usage is represented as a 32 bit integer in + network byte order. The ciphertest must be generated from the plaintext + as follows: + + ciphertext = E(Ke, confounder | plaintext | padding) | + H(Ki, confounder | plaintext | padding) + + The confounder and padding are specific to the encryption algorithm E. + + When generating a checksum only, there is no need for a confounder or + padding. Again, a new key (Kc) must be used. Checksums must be + generated from the plaintext as follows: + + Kc = DK(protocol key, key usage | 0x99) + MAC = H(Kc, plaintext) + + Note that each enctype is described by an encryption algorithm E and a + keyed hash algorithm H, and each checksum type is described by a keyed + hash algorithm H. HMAC, with an appropriate hash, is required for use + as H. + + Key Derivation from Passwords + + The well-known constant for password key derivation must be the byte + string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values + correspond to the ASCII encoding for the string "kerberos". + + 6.4. Checksums + + The following is the ASN.1 definition used for a checksum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + 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. + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + Detailed specification of selected checksum types appear later in this + section. Negative values for the checksum type are reserved for local + use. All non-negative values are reserved for officially assigned type + fields and interpretations. + + Checksums used by Kerberos can be classified by two properties: whether + they are collision-proof, and whether they are keyed. It is infeasible + to find two plaintexts which generate the same checksum value for a + collision-proof checksum. A key is required to perturb or initialize + the algorithm in a keyed checksum. To prevent message-stream + modification by an active attacker, unkeyed checksums should only be + used when the checksum and message will be subsequently encrypted (e.g. + the checksums defined as part of the encryption algorithms covered + earlier in this section). + + Collision-proof checksums can be made tamper-proof if the checksum + value is encrypted before inclusion in a message. In such cases, the + composition of the checksum and the encryption algorithm must be + considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using + DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed + checksums, as well as for the encrypted forms of unkeyed + collision-proof checksums, Kerberos prepends a confounder before the + checksum is calculated. + + 6.4.1. The CRC-32 Checksum (crc32) + + The CRC-32 checksum calculates a checksum based on a cyclic redundancy + check as described in ISO 3309 [ISO3309]. The resulting checksum is + four (4) octets in length. The CRC-32 is neither keyed nor + collision-proof. 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 use of collision-proof checksums is recommended for + environments where such attacks represent a significant threat. + + 6.4.2. The RSA MD4 Checksum (rsa-md4) + + 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 (16 octet) checksum. RSA-MD4 is + believed to be collision-proof. + + 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) + + The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by + prepending an 8 octet confounder before the text, applying the RSA MD4 + checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be + zero. The resulting checksum is 24 octets long (8 octets of which are + redundant). This checksum is tamper-proof and believed to be + collision-proof. + + The DES specifications identify some weak keys' and 'semi-weak keys'; + those keys shall not be used for generating RSA-MD4 checksums for use + in Kerberos. + + The format for the checksum is described in the follow- ing diagram: + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) } -6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with Key -Derivation [Horowitz] - -[*** Note that there are several 3DES varients in use in different Kerberos -implemenations, updates to this section will be sent to the cat list and -krb-protocol list prior to the Oslo IETF, including the key derivation and -non-key derivation varients ***] NOTE: This description currently refers to -documents, the contents of which might be bettered included by value in this -spec. The description below was provided by Marc Horowitz, and the form in -which it will finally appear is yet to be determined. This description is -included in this version of the draft because it does describe the -implemenation ready for use with the MIT implementation. Note also that the -encryption identifier has been left unspecified here because the value from -Marc Horowitz's spec conflicted with some other impmenentations implemented -based on perevious versions of the specification. - -This encryption type is based on the Triple DES cryptosystem, the HMAC-SHA1 -[Krawczyk96] message authentication algorithm, and key derivation for -Kerberos V5 [HorowitzB96]. - -The des3-cbc-hmac-sha1 encryption type has been assigned the value ??. The -hmac-sha1-des3 checksum type has been assigned the value 12. - -Encryption Type des3-cbc-hmac-sha1 - -EncryptedData using this type must be generated as described in -[Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. The -keyed hash algorithm is HMAC-SHA1. Unless otherwise specified, a zero IV -must be used. If the length of the input data is not a multiple of the block -size, zero octets must be used to pad the plaintext to the next eight-octet -boundary. The counfounder must be eight random octets (one block). - -Checksum Type hmac-sha1-des3 - -Checksums using this type must be generated as described in [Horowitz96]. -The keyed hash algorithm is HMAC-SHA1. - -Common Requirements - -The EncryptionKey value is 24 octets long. The 7 most significant bits of -each octet contain key bits, and the least significant bit is the inverse of -the xor of the key bits. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -For the purposes of key derivation, the block size is 64 bits, and the key -size is 168 bits. The 168 bits output by key derivation are converted to an -EncryptionKey value as follows. First, the 168 bits are divided into three -groups of 56 bits, which are expanded individually into 64 bits as follows: - - 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 are concatenated to form the EncryptionKey value. - -When the HMAC-SHA1 of a string is computed, the key is used in the -EncryptedKey form. - -Key Derivation - -In the Kerberos protocol, cryptographic keys are used in a number of places. -In order to minimize the effect of compromising a key, it is desirable to -use a different key for each of these places. Key derivation [Horowitz96] -can be used to construct different keys for each operation from the keys -transported on the network. For this to be possible, a small change to the -specification is necessary. - -This section specifies a profile for the use of key derivation [Horowitz96] -with Kerberos. For each place where a key is used, a ``key usage'' must is -specified for that purpose. The key, key usage, and encryption/checksum type -together describe the transformation from plaintext to ciphertext, or -plaintext to checksum. - -Key Usage Values - -This is a complete list of places keys are used in the kerberos protocol, -with key usage values and RFC 1510 section numbers: - - 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the - client key (section 5.4.1) - 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or - application session key), encrypted with the service key - (section 5.4.2) - 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 (sections 5.3.2, 5.4.1) - 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs - authenticator subkey), encrypted with the tgs session key - (section 5.3.2) - 8. TGS-REP encrypted part (includes application session key), - encrypted with the tgs session key (section 5.4.2) - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - 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.3.2) -11. AP-REQ Authenticator (includes application authenticator - subkey), encrypted with the application session key (section - 5.3.2) -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.6.1) -15. KRB-SAVE cksum, keyed with a key chosen by the application - (section 5.8.1) -18. KRB-ERROR checksum (e-cksum in section 5.9.1) -19. AD-KDCIssued checksum (ad-checksum in appendix B.1) -20. Checksum for Mandatory Ticket Extensions (appendix B.6) -21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) - -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. - -A few of these key usages need a little clarification. A service which -receives an AP-REQ has no way to know if the enclosed Ticket was part of an -AS-REP or TGS-REP. Therefore, key usage 2 must always be used for generating -a Ticket, whether it is in response to an AS- REQ or TGS-REQ. - -There might exist other documents which define protocols in terms of the -RFC1510 encryption types or checksum types. Such documents would not know -about key usages. In order that these documents continue to be meaningful -until they are updated, key usages 1024 and 1025 must be used to derive keys -for encryption and checksums, respectively. New protocols defined in terms -of the Kerberos encryption and checksum types should use their own key -usages. Key usages may be registered with IANA to avoid conflicts. Key -usages must be unsigned 32 bit integers. Zero is not permitted. - -Defining Cryptosystems Using Key Derivation - -Kerberos requires that the ciphertext component of EncryptedData be -tamper-resistant as well as confidential. This implies encryption and -integrity functions, which must each use their own separate keys. So, for -each key usage, two keys must be generated, one for encryption (Ke), and one -for integrity (Ki): - - Ke = DK(protocol key, key usage | 0xAA) - Ki = DK(protocol key, key usage | 0x55) - -where the protocol key is from the EncryptionKey from the wire protocol, and -the key usage is represented as a 32 bit integer in network byte order. The -ciphertest must be generated from the plaintext as follows: - - ciphertext = E(Ke, confounder | plaintext | padding) | - H(Ki, confounder | plaintext | padding) - -The confounder and padding are specific to the encryption algorithm E. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -When generating a checksum only, there is no need for a confounder or -padding. Again, a new key (Kc) must be used. Checksums must be generated -from the plaintext as follows: - - Kc = DK(protocol key, key usage | 0x99) - - MAC = H(Kc, plaintext) - -Note that each enctype is described by an encryption algorithm E and a keyed -hash algorithm H, and each checksum type is described by a keyed hash -algorithm H. HMAC, with an appropriate hash, is recommended for use as H. - -Key Derivation from Passwords - -The well-known constant for password key derivation must be the byte string -{0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the -ASCII encoding for the string "kerberos". - -6.4. Checksums - -The following is the ASN.1 definition used for a checksum: - - Checksum ::= SEQUENCE { - cksumtype[0] INTEGER, - 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. - -Detailed specification of selected checksum types appear later in this -section. Negative values for the checksum type are reserved for local use. -All non-negative values are reserved for officially assigned type fields and -interpretations. - -Checksums used by Kerberos can be classified by two properties: whether they -are collision-proof, and whether they are keyed. It is infeasible to find -two plaintexts which generate the same checksum value for a collision-proof -checksum. A key is required to perturb or initialize the algorithm in a -keyed checksum. To prevent message-stream modification by an active -attacker, unkeyed checksums should only be used when the checksum and -message will be subsequently encrypted (e.g. the checksums defined as part -of the encryption algorithms covered earlier in this section). - -Collision-proof checksums can be made tamper-proof if the checksum value is -encrypted before inclusion in a message. In such cases, the composition of -the checksum and the encryption algorithm must be considered a separate -checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum -algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the -encrypted forms of unkeyed collision-proof checksums, Kerberos prepends a -confounder before the checksum is calculated. + 6.4.4. The RSA MD5 Checksum (rsa-md5) + The RSA-MD5 checksum calculates a checksum 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 (16 octet) checksum. RSA-MD5 is + believed to be collision-proof. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -6.4.1. The CRC-32 Checksum (crc32) - -The CRC-32 checksum calculates a checksum based on a cyclic redundancy check -as described in ISO 3309 [ISO3309]. The resulting checksum is four (4) -octets in length. The CRC-32 is neither keyed nor collision-proof. 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 use of collision-proof -checksums is recommended for environments where such attacks represent a -significant threat. + 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) -6.4.2. The RSA MD4 Checksum (rsa-md4) + The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by + prepending an 8 octet confounder before the text, applying the RSA MD5 + checksum algorithm, and encrypting the confounder and the checksum + using DES in cipher-block-chaining (CBC) mode using a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should + be zero. The resulting checksum is 24 octets long (8 octets of which + are redundant). This checksum is tamper-proof and believed to be + collision-proof. -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 (16 octet) checksum. RSA-MD4 is believed to -be collision-proof. + The DES specifications identify some 'weak keys' and 'semi-weak keys'; + those keys shall not be used for encrypting RSA-MD5 checksums for use + in Kerberos. -6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) + The format for the checksum is described in the following diagram: -The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by -prepending an 8 octet confounder before the text, applying the RSA MD4 -checksum algorithm, and encrypting the confounder and the checksum using DES -in cipher-block-chaining (CBC) mode using a variant of the key, where the -variant is computed by eXclusive-ORing the key with the constant -F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The -resulting checksum is 24 octets long (8 octets of which are redundant). This -checksum is tamper-proof and believed to be collision-proof. + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -The DES specifications identify some weak keys' and 'semi-weak keys'; those -keys shall not be used for generating RSA-MD4 checksums for use in Kerberos. - -The format for the checksum is described in the follow- ing diagram: - -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: -The format cannot be described in ASN.1, but for those who prefer an -ASN.1-like notation: - -rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { - confounder[0] UNTAGGED OCTET STRING(8), - check[1] UNTAGGED OCTET STRING(16) -} - -6.4.4. The RSA MD5 Checksum (rsa-md5) - -The RSA-MD5 checksum calculates a checksum 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 (16 octet) checksum. RSA-MD5 is believed to -be collision-proof. - -6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) - -The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by -prepending an 8 octet confounder before the text, applying the RSA MD5 -checksum algorithm, and encrypting the confounder and the checksum using DES - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -in cipher-block-chaining (CBC) mode using a variant of the key, where the -variant is computed by eXclusive-ORing the key with the hexadecimal constant -F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting -checksum is 24 octets long (8 octets of which are redundant). This checksum -is tamper-proof and believed to be collision-proof. - -The DES specifications identify some 'weak keys' and 'semi-weak keys'; those -keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos. - -The format for the checksum is described in the following diagram: - -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -The format cannot be described in ASN.1, but for those who prefer an -ASN.1-like notation: - -rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { - confounder[0] UNTAGGED OCTET STRING(8), - check[1] UNTAGGED OCTET STRING(16) -} - -6.4.6. DES cipher-block chained checksum (des-mac) - -The DES-MAC checksum is computed by prepending an 8 octet confounder to the -plaintext, performing a DES CBC-mode encryption on the result using the key -and an initialization vector of zero, taking the last block of the -ciphertext, prepending the same confounder and encrypting the pair using DES -in cipher-block-chaining (CBC) mode using a a variant of the key, where the -variant is computed by eXclusive-ORing the key with the hexadecimal constant -F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting -checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This -checksum is tamper-proof and collision-proof. - -The format for the checksum is described in the following diagram: - -+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ -| des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | -+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ - -The format cannot be described in ASN.1, but for those who prefer an -ASN.1-like notation: - -des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { - confounder[0] UNTAGGED OCTET STRING(8), - check[1] UNTAGGED OCTET STRING(8) -} - -The DES specifications identify some 'weak' and 'semi-weak' keys; those keys -shall not be used for generating DES-MAC checksums for use in Kerberos, nor -shall a key be used whose variant is 'weak' or 'semi-weak'. - -6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k) - -The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by -applying the RSA MD4 checksum algorithm and encrypting the results using DES -in cipher-block-chaining (CBC) mode using a DES key as both key and - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -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 and it -is no longer recommended. - -6.4.8. DES cipher-block chained checksum alternative (des-mac-k) - -The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption -of the plaintext, and using the last block of the ciphertext as the checksum -value. It is keyed with an encryption key and an initialization vector; any -uses which do not specify an additional initialization vector will use the -key as both key and initialization vector. The resulting checksum is 64 bits -(8 octets) long. This checksum is tamper-proof and collision-proof. Note -that this checksum type is the old method for encoding the DES-MAC checksum -and it is no longer recommended. The DES specifications identify some 'weak -keys' and 'semi-weak keys'; those keys shall not be used for generating -DES-MAC checksums for use in Kerberos. - -7. Naming Constraints - -7.1. Realm Names - -Although realm names are encoded as GeneralStrings and although a realm can -technically 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. - -Kerberos realm names are case sensitive. Realm names that differ only in the -case of the characters are not equivalent. There are presently four styles -of realm names: domain, X500, other, and reserved. Examples of each style -follow: - - domain: ATHENA.MIT.EDU (example) - X500: C=US/O=OSF (example) - other: NAMETYPE:rest/of.name=without-restrictions (example) - reserved: reserved, but will not conflict with above - -Domain names must look like domain names: they consist of components -separated by periods (.) and they contain neither colons (:) nor slashes -(/). Domain names must be converted to upper case when used as realm names. - -X.500 names contain an equal (=) and cannot contain a colon (:) before the -equal. 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. - -Names that fall into the other category must begin with a prefix that -contains no equal (=) or period (.) and the prefix must be followed by a -colon (:) and the rest of the name. All prefixes must be assigned before -they may be used. Presently none are assigned. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -The reserved category includes strings which 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: the name of a realm for the -domain or X.500 formats must either 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 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 there will not in the -future exists a name identical to the realm name of the child unless it is -assigned to the same entity as the realm name. - -7.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 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). The following name types are -defined: - - name-type value meaning - - NT-UNKNOWN 0 Name type not known - NT-PRINCIPAL 1 General principal name (e.g. username, or DCE -principal) - 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 slash-separated host name components - NT-UID 5 Unique ID - NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] - -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 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. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -If instance is a single component following the service name and the -instance identifies 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 -certificiate 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 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 8.2.3 for the form of such -names. - -7.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 lower case. If specified by the -application protocol for services such as telnet and the Berkeley R commands -which run with system privileges, the first component may be the string -'host' instead of a service specific identifier. When a host has an official -name and one or more aliases, the official name of the host must be used -when constructing the name of the server principal. - -8. Constants and other defined values - -8.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. - -The values of the types for the following addresses are chosen to match the -defined address family constants in the Berkeley Standard Distributions of -Unix. They can be found in with symbolic names AF_xxx (where xxx is an -abbreviation of the address family name). - -Internet (IPv4) Addresses - -Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB -order. The type of IPv4 addresses is two (2). - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -Internet (IPv6) Addresses [Westerlund] - -IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The -type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The -following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: - - * the Unspecified Address - * the Loopback Address - * Link-Local addresses - -IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. - -CHAOSnet addresses - -CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order. -The type of CHAOSnet addresses is five (5). - -ISO addresses - -ISO addresses are variable-length. The type of ISO addresses is seven (7). - -Xerox Network Services (XNS) addresses - -XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The -type of XNS addresses is six (6). - -AppleTalk Datagram Delivery Protocol (DDP) addresses - -AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network -number. The first octet of the address is the node number; the remaining two -octets encode the network number in MSB order. The type of AppleTalk DDP -addresses is sixteen (16). - -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). - -Netbios addresses - -Netbios addresses are 16-octet addresses typically composed of 1 to 15 -characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0. -The type of Netbios addresses is 20 (0x14). - -8.2. KDC messages - -8.2.1. UDP/IP transport - -When contacting a Kerberos server (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 port 88 (decimal) at the KDC's IP address; 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. Kerberos servers supporting IP transport must -accept UDP requests on port 88 (decimal). The response to a request made -through UDP/IP transport must also use UDP/IP transport. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -8.2.2. TCP/IP transport [Westerlund,Danielsson] - -Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) and -clients should support the sending of TCP requests on port 88 (decimal). -When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new -connection will be established for each authentication exchange (request and -response). The KRB_KDC_REP or KRB_ERROR message will be returned to the -client on the same TCP stream that was established for the request. The -response to a request made through TCP/IP transport must also use TCP/IP -transport. Implementors should note that some extentions to the Kerberos -protocol will not work if any implementation not supporting the TCP -transport is involved (client or KDC). Implementors are strongly urged to -support the TCP transport on both the client and server and are advised that -the current notation of "should" support will likely change in the future to -must support. The KDC may close the TCP stream after sending a response, but -may leave the stream open if it expects a followup - in which case it may -close the stream at any time if resource constratints or other factors make -it desirable to do so. Care must be taken in managing TCP/IP connections -with the KDC to prevent denial of service attacks based on the number of -TCP/IP connections with the KDC that remain open. If multiple exchanges with -the KDC are needed for certain forms of preauthentication, multiple TCP -connections may be required. A client may close the stream after receiving -response, and should close the stream if it does not expect to send followup -messages. The client must be prepared to have the stream closed by the KDC -at anytime, in which case it must simply connect again when it is ready to -send subsequent messages. - -The first four octets of the TCP stream used to transmit the request request -will encode in network byte order the length of the request (KRB_KDC_REQ), -and the length will be followed by the request itself. The response will -similarly be preceeded by a 4 octet encoding in network byte order of the -length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by -the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is set on the -integer represented by the first 4 octets, then the next 4 octets will be -read, extending the length of the field by another 4 octets (less the sign -bit which is reserved for future expansion). - -8.2.3. OSI transport - -During authentication of an OSI client to an OSI server, the mutual -authentication of an OSI server to an OSI client, the transfer of -credentials from an OSI client to an OSI server, or during exchange of -private or integrity checked messages, Kerberos protocol messages may be -treated as opaque objects and the type of the authentication mechanism will -be: - -OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), - security(5),kerberosv5(2)} - -Depending on the situation, the opaque object will be an authentication -header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message -(KRB_SAFE), a private message (KRB_PRIV), or a credentials message -(KRB_CRED). The opaque data contains an application code as specified in the -ASN.1 description for each message. The application code may be used by -Kerberos to determine the message type. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -8.2.3. Name of the TGS - -The principal identifier of the ticket-granting service shall be composed of -three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part -name of type NT-SRV-INST, with the first part "krbtgt" and the second part -the name of the realm which will accept the ticket-granting ticket. For -example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be -used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier -of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A -ticket-granting ticket 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). - -8.3. Protocol constants and associated values - -The following tables list constants used in the protocol and defines their -meanings. Ranges are specified in the "specification" section 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. Implementation receiving values outside the -range specified in the "specification" section may reject the request, but -they must recover cleanly. - -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 -sign-dsa-generate 8 -(old-pkinit-will-remove) -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) -des3kd-cbc-sha1 ?? 8 0 8 -ENCTYPE_PK_CROSS 48 (reserved for pkcross) - 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 -rsa-md5-des3 9 24 -hmac-sha1-des3 12 20 (I had this as 10, is it -12) - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -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 -SAM-CHALLENGE 12 (sam/otp) -SAM-RESPONSE 13 (sam/otp) -PA-PK-AS-REQ 14 (pkinit) -PA-PK-AS-REP 15 (pkinit) -PA-PK-AS-SIGN 16 (***remove on 7/14***) -PA-PK-KEY-REQ 17 (***remove on 7/14***) -PA-PK-KEY-REP 18 (***remove on 7/14***) -PA-USE-SPECIFIED-KVNO 20 -SAM-REDIRECT 21 (sam/otp) -PA-GET-FROM-TYPED-DATA 22 + rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + + 6.4.6. DES cipher-block chained checksum (des-mac) + + The DES-MAC checksum is computed by prepending an 8 octet confounder to + the plaintext, performing a DES CBC-mode encryption on the result using + the key and an initialization vector of zero, taking the last block of + the ciphertext, prepending the same confounder and encrypting the pair + using DES in cipher-block-chaining (CBC) mode using a a variant of the + key, where the variant is computed by eXclusive-ORing the key with the + hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + be zero. The resulting checksum is 128 bits (16 octets) long, 64 bits + of which are redundant. This checksum is tamper-proof and + collision-proof. + + The format for the checksum is described in the following diagram: + + +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(8) + } + + The DES specifications identify some 'weak' and 'semi-weak' keys; those + keys shall not be used for generating DES-MAC checksums for use in + Kerberos, nor shall a key be used whose variant is 'weak' or + 'semi-weak'. + + 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative + (rsa-md4-des-k) + + The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum + by applying the RSA MD4 checksum algorithm and encrypting the results + using DES in cipher-block-chaining (CBC) mode using 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 and it is no longer recommended. + + 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, and using the last block of the ciphertext + as the checksum value. It is keyed with an encryption key and an + initialization vector; any uses which do not specify an additional + initialization vector will use the key as both key and initialization + vector. The resulting checksum is 64 bits (8 octets) long. This + checksum is tamper-proof and collision-proof. Note that this checksum + type is the old method for encoding the DES-MAC checksum and it is no + longer recommended. The DES specifications identify some 'weak keys' + and 'semi-weak keys'; those keys shall not be used for generating + DES-MAC checksums for use in Kerberos. + + 7. Naming Constraints + + 7.1. Realm Names + + Although realm names are encoded as GeneralStrings and although a realm + can technically 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + inter-realm keys are shared also conform to the conventions and require + the same from its neighbors. + + Kerberos realm names are case sensitive. Realm names that differ only + in the case of the characters are not equivalent. There are presently + four styles of realm names: domain, X500, other, and reserved. Examples + of each style follow: + + domain: ATHENA.MIT.EDU (example) + X500: C=US/O=OSF (example) + other: NAMETYPE:rest/of.name=without-restrictions (example) + reserved: reserved, but will not conflict with above + + Domain names must look like domain names: they consist of components + separated by periods (.) and they contain neither colons (:) nor + slashes (/). Domain names must be converted to upper case when used as + realm names. + + X.500 names contain an equal (=) and cannot contain a colon (:) before + the equal. 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. + + Names that fall into the other category must begin with a prefix that + contains no equal (=) or period (.) and the prefix must be followed by + a colon (:) and the rest of the name. All prefixes must be assigned + before they may be used. Presently none are assigned. + + The reserved category includes strings which 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: the name + of a realm for the domain or X.500 formats must either 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 + 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 there will not in the future exists a name identical to the realm + name of the child unless it is assigned to the same entity as the realm + name. + + 7.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 as + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 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). The + following name types are defined: + + name-type value meaning + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) + 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 slash-separated host name components + NT-UID 5 Unique ID + NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] + + 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 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 instance is a single component following the service name and the + instance identifies 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 certificiate 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 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 8.2.3 for the + form of such names. + + 7.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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 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 lower case. If specified by the application protocol + for services such as telnet and the Berkeley R commands which run with + system privileges, the first component may be the string 'host' instead + of a service specific identifier. When a host has an official name and + one or more aliases, the official name of the host must be used when + constructing the name of the server principal. + + 8. Constants and other defined values + + 8.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. + + The values of the types for the following addresses are chosen to match + the defined address family constants in the Berkeley Standard + Distributions of Unix. They can be found in with symbolic names AF_xxx + (where xxx is an abbreviation of the address family name). + + Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in + MSB order. The type of IPv4 addresses is two (2). + + Internet (IPv6) Addresses [Westerlund] + + IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. + The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. + The following addresses (see [RFC1884]) MUST not appear in any Kerberos + packet: + o the Unspecified Address + o the Loopback Address + o Link-Local addresses + IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. + + CHAOSnet addresses + + CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB + order. The type of CHAOSnet addresses is five (5). + + ISO addresses + + ISO addresses are variable-length. The type of ISO addresses is seven + (7). + + Xerox Network Services (XNS) addresses + + XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. + The type of XNS addresses is six (6). + + AppleTalk Datagram Delivery Protocol (DDP) addresses + + AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + network number. The first octet of the address is the node number; the + remaining two octets encode the network number in MSB order. The type + of AppleTalk DDP addresses is sixteen (16). + + 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). + + Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 to 15 + characters, trailing blank (ascii char 20) filled, with a 16th octet of + 0x0. The type of Netbios addresses is 20 (0x14). + + 8.2. KDC messages + + 8.2.1. UDP/IP transport + + When contacting a Kerberos server (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 port 88 (decimal) at the KDC's IP + address; 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. Kerberos servers + supporting IP transport must accept UDP requests on port 88 (decimal). + The response to a request made through UDP/IP transport must also use + UDP/IP transport. + + 8.2.2. TCP/IP transport [Westerlund,Danielsson] + + Kerberos servers (KDC's) should accept TCP requests on port 88 + (decimal) and clients should support the sending of TCP requests on + port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC over + a TCP stream, a new connection will be established for each + authentication exchange (request and response). The KRB_KDC_REP or + KRB_ERROR message will be returned to the client on the same TCP stream + that was established for the request. The response to a request made + through TCP/IP transport must also use TCP/IP transport. Implementors + should note that some extentions to the Kerberos protocol will not work + if any implementation not supporting the TCP transport is involved + (client or KDC). Implementors are strongly urged to support the TCP + transport on both the client and server and are advised that the + current notation of "should" support will likely change in the future + to must support. The KDC may close the TCP stream after sending a + response, but may leave the stream open if it expects a followup - in + which case it may close the stream at any time if resource constratints + or other factors make it desirable to do so. Care must be taken in + managing TCP/IP connections with the KDC to prevent denial of service + attacks based on the number of TCP/IP connections with the KDC that + remain open. If multiple exchanges with the KDC are needed for certain + forms of preauthentication, multiple TCP connections may be required. A + client may close the stream after receiving response, and should close + the stream if it does not expect to send followup messages. The client + must be prepared to have the stream closed by the KDC at anytime, in + which case it must simply connect again when it is ready to send + subsequent messages. + + The first four octets of the TCP stream used to transmit the request + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + request will encode in network byte order the length of the request + (KRB_KDC_REQ), and the length will be followed by the request itself. + The response will similarly be preceeded by a 4 octet encoding in + network byte order of the length of the KRB_KDC_REP or the KRB_ERROR + message and will be followed by the KRB_KDC_REP or the KRB_ERROR + response. If the sign bit is set on the integer represented by the + first 4 octets, then the next 4 octets will be read, extending the + length of the field by another 4 octets (less the sign bit which is + reserved for future expansion). + + 8.2.3. OSI transport + + During authentication of an OSI client to an OSI server, the mutual + authentication of an OSI server to an OSI client, the transfer of + credentials from an OSI client to an OSI server, or during exchange of + private or integrity checked messages, Kerberos protocol messages may + be treated as opaque objects and the type of the authentication + mechanism will be: + + OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} + + Depending on the situation, the opaque object will be an authentication + header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe + message (KRB_SAFE), a private message (KRB_PRIV), or a credentials + message (KRB_CRED). The opaque data contains an application code as + specified in the ASN.1 description for each message. The application + code may be used by Kerberos to determine the message type. + + 8.2.3. Name of the TGS + + The principal identifier of the ticket-granting service shall be + composed of three parts: (1) the realm of the KDC issuing the TGS + ticket (2) a two-part name of type NT-SRV-INST, with the first part + "krbtgt" and the second part the name of the realm which will accept + the ticket-granting ticket. For example, a ticket-granting ticket + issued by the ATHENA.MIT.EDU realm to be used to get tickets from the + ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" + (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket + 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). + + 8.3. Protocol constants and associated values + + The following tables list constants used in the protocol and defines + their meanings. Ranges are specified in the "specification" section + 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. Implementation + receiving values outside the range specified in the "specification" + section may reject the request, but they must recover cleanly. + + 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 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 6 + des3-cbc-sha1 7 8 0 8 + 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 (Tom Yu) + rc4-hmac 23 (swift) + rc4-hmac-exp 24 (swift) + + ENCTYPE_PK_CROSS 48 (reserved for pkcross) + 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 (drop rsa ?) + rsa-md5 7 16 (drop rsa ?) + rsa-md5-des 8 24 (drop rsa ?) + rsa-md5-des3 9 24 (drop rsa ?) + hmac-sha1-des3-kd 12 20 + hmac-sha1-des3 13 20 + + padata type padata-type value + + PA-TGS-REQ 1 + PA-ENC-TIMESTAMP 2 + PA-PW-SALT 3 + 4 + PA-ENC-UNIX-TIME 5 (depricated) + 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 14 (pkinit) + PA-PK-AS-REP 15 (pkinit) + PA-USE-SPECIFIED-KVNO 20 + PA-SAM-REDIRECT 21 (sam/otp) + PA-GET-FROM-TYPED-DATA 22 + PA-SAM-ETYPE-INFO 23 (sam/otp) data-type value form of typed-data - 1-21 + 1-21 TD-PADATA 22 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS TD-KRB-PRINCIPAL 102 TD-KRB-REALM 103 TD-TRUSTED-CERTIFIERS 104 + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + TD-CERTIFICATE-INDEX 105 authorization data type ad-type value @@ -4718,22 +4769,16 @@ AD-IN-TICKET-EXTENSIONS 7 reserved values 8-63 OSF-DCE 64 SESAME 65 +AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) Ticket Extension Types TE-TYPE-NULL 0 Null ticket extension TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data - 2 TE-TYPE-PKCROSS-KDC (I have reservations) + 2 TE-TYPE-PKCROSS-KDC (I have reservations) TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp - 5 TE-TYPE-DEST-HOST (I have reservations) - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 + 5 TE-TYPE-DEST-HOST (I have reservations) alternate authentication type method-type value reserved values 0-63 @@ -4757,29 +4802,33 @@ 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_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_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_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 Distingished name [RFC 2253] + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + 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_BAD_PVNO 3 Requested prot vers number 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 @@ -4787,8 +4836,7 @@ 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_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 @@ -4798,27 +4846,16 @@ 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 - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - 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 -KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was -invalid -KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired -[40] +KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid +KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 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_MUST_USE_USER2USER 27 Server principal valid for user2user only KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 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_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 @@ -4830,25 +4867,29 @@ 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_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_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_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 +KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) KDC_ERROR_INVALID_SIG 64 (pkinit) KDC_ERR_KEY_TOO_WEAK 65 (pkinit) + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) KRB_AP_ERR_NO_TGT 67 (user-to-user) KDC_ERR_WRONG_REALM 68 (user-to-user) @@ -4861,1920 +4902,1965 @@ KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) -9. Interoperability requirements + 9. 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, forwarding, postdating, -and renewing tickets, the format of realm names, and the handling of -authorization data. + 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, forwarding, postdating, and renewing tickets, the format of + realm names, and the handling of authorization data. + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration which 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. -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 + 9.1. Specification 2 -In order to ensure the interoperability of realms, it is necessary to define -a minimal configuration which 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. + 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.1). Specification 1 (depricated) + may be found in RFC1510. -9.1. Specification 2 + Transport -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.1). Specification 1 (depricated) may -be found in RFC1510. + TCP/IP and UDP/IP transport must be supported by KDCs claiming + conformance to specification 2. Kerberos clients claiming conformance + to specification 2 must support UDP/IP transport for messages with the + KDC and should support TCP/IP transport. -Transport + Encryption and checksum methods -TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance -to specification 2. Kerberos clients claiming conformance to specification 2 -must support UDP/IP transport for messages with the KDC and should support -TCP/IP transport. + The following encryption and checksum mechanisms must be supported. + Implementations may support other mechanisms as well, but the + additional mechanisms may only be used when communicating with + principals known to also support them: This list is to be determined. -Encryption and checksum methods + Encryption: DES-CBC-MD5, one triple des variant (tbd) + Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd) -The following encryption and checksum mechanisms must be supported. -Implementations may support other mechanisms as well, but the additional -mechanisms may only be used when communicating with principals known to also -support them: This list is to be determined. [***This section will change, -and alternatives will be sent to the cat and krb-protocol list prior to the -Oslo IETF - change will be made 7/14/99 ***] + Realm Names -Encryption: DES-CBC-MD5 -Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 + All implementations must understand hierarchical realms in both the + Internet Domain and the X.500 style. When a ticket granting ticket 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 -Realm Names +Neuman, Ts'o, Kohl Expires: 10 September, 2000 -All implementations must understand hierarchical realms in both the Internet -Domain and the X.500 style. When a ticket granting ticket 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 be used only when that -encoding is supported by ALL intermediate realms. -Pre-authentication methods +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 -The TGS-REQ method must be supported. The TGS-REQ method 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 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 preauthentication method. Servers need not support the -PA-ENC-TIMESTAMP method, but if not supported the server should ignore the -presence of PA-ENC-TIMESTAMP pre-authentication in a request. + requested realm. + Transited field encoding -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 + DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. + Alternative encodings may be supported, but they may be used only when + that encoding is supported by ALL intermediate realms. -Mutual authentication + Pre-authentication methods -Mutual authentication (via the KRB_AP_REP message) must be supported. + The TGS-REQ method must be supported. The TGS-REQ method 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 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 preauthentication method. Servers need not support + the PA-ENC-TIMESTAMP method, but if not supported the server should + ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a + request. -Ticket addresses and flags + Mutual authentication -All KDC's must pass on tickets that carry no addresses (i.e. if a TGT -contains no addresses, the KDC will return derivative tickets), but each -realm may set its own policy for issuing such tickets, and each application -server will set its own policy with respect to accepting them. - -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 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. + Mutual authentication (via the KRB_AP_REP message) must be supported. -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. + Ticket addresses and flags -Authorization data + All KDC's must pass on tickets that carry no addresses (i.e. if a TGT + contains no addresses, the KDC will return derivative tickets), but + each realm may set its own policy for issuing such tickets, and each + application server will set its own policy with respect to accepting + them. -Implementations must pass all authorization data subfields from -ticket-granting tickets to any derivative tickets unless 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). + Proxies and forwarded tickets must be supported. Individual realms and + application servers can set their own policy on when such tickets will + be accepted. -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. + All implementations must recognize renewable and postdated tickets, but + 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. -Constant ranges + User-to-user authentication -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. Implementation receiving values outside -this range may reject the request, but they must recover cleanly. + 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. -9.2. Recommended KDC values + Authorization data -Following is a list of recommended values for a KDC implementation, based on -the list of suggested configuration constants (see section 4.4). - -minimum lifetime 5 minutes -maximum renewable lifetime 1 week -maximum ticket lifetime 1 day -empty addresses only when suitable restrictions appear - in authorization data -proxiable, etc. Allowed. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 + Implementations must pass all authorization data subfields from + ticket-granting tickets to any derivative tickets unless 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). -10. REFERENCES -[NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- - cation Service for Computer Networks," IEEE Communica- - tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). +Neuman, Ts'o, Kohl Expires: 10 September, 2000 -[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). -[SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- - beros: An Authentication Service for Open Network Sys- - tems," pp. 191-202 in Usenix Conference Proceedings, - Dallas, Texas (February, 1988). -[NS78] Roger M. Needham and Michael D. Schroeder, "Using - Encryption for Authentication in Large Networks of Com- - puters," Communications of the ACM, Vol. 21(12), - pp. 993-999 (December, 1978). -[DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- - stamps in Key Distribution Protocols," Communications - of the ACM, Vol. 24(8), pp. 533-536 (August 1981). +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 -[KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, - "The Evolution of the Kerberos Authentication Service," - in an IEEE Computer Society Text soon to be published - (June 1992). + 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. -[Neu93] B. Clifford Neuman, "Proxy-Based Authorization and - Accounting for Distributed Systems," in Proceedings of - the 13th International Conference on Distributed Com- - puting Systems, Pittsburgh, PA (May, 1993). - -[DS90] Don Davis and Ralph Swick, "Workstation Services and - Kerberos Authentication at Project Athena," Technical - Memorandum TM-424, MIT Laboratory for Computer Science - (February 1990). - -[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- - merfeld, and K. Raeburn, Section E.1: Service Manage- - ment System, M.I.T. Project Athena, Cambridge, Mas- - sachusetts (1987). - -[X509-88] CCITT, Recommendation X.509: The Directory Authentica- - tion Framework, December 1988. - -[Pat92]. J. Pato, Using Pre-Authentication to Avoid Password - Guessing Attacks, Open Software Foundation DCE Request - for Comments 26 (December 1992). - -[DES77] National Bureau of Standards, U.S. Department of Com- - merce, "Data Encryption Standard," Federal Information - Processing Standards Publication 46, Washington, DC - (1977). - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -[DESM80] National Bureau of Standards, U.S. Department of Com- - merce, "DES Modes of Operation," Federal Information - Processing Standards Publication 81, Springfield, VA - (December 1980). - -[SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message - Integrity in Cryptographic Protocols," in Proceedings - of the IEEE Symposium on Research in Security and - Privacy, Oakland, California (May 1992). - -[IS3309] International Organization for Standardization, "ISO - Information Processing Systems - Data Communication - - High-Level Data Link Control Procedure - Frame Struc- - ture," IS 3309 (October 1984). 3rd Edition. - -[MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC - 1320, MIT Laboratory for Computer Science (April - 1992). - -[MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC - 1321, MIT Laboratory for Computer Science (April - 1992). - -[KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication," Working Draft - draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). - -[Horowitz96] Horowitz, M., "Key Derivation for Authentication, - Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, - August 1998. - -[HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- - horowitz-kerb-key-derivation-01.txt, September 1998. - -[Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: - Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac- - md5-01.txt, August, 1996. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -A. Pseudo-code for protocol processing - -This appendix provides pseudo-code describing how the messages are to be -constructed and interpreted by clients and servers. - -A.1. KRB_AS_REQ generation - - request.pvno := protocol version; /* pvno = 5 */ - request.msg-type := message type; /* type = KRB_AS_REQ */ - - if(pa_enc_timestamp_required) then - request.padata.padata-type = PA-ENC-TIMESTAMP; - get system_time; - padata-body.patimestamp,pausec = system_time; - encrypt padata-body into request.padata.padata-value - using client.key; /* derived from password */ - endif - - body.kdc-options := users's preferences; - body.cname := user's name; - body.realm := user's realm; - body.sname := service's name; /* usually "krbtgt", "localrealm" */ - if (body.kdc-options.POSTDATED is set) then - body.from := requested starting time; - else - omit body.from; - endif - body.till := requested end time; - if (body.kdc-options.RENEWABLE is set) then - body.rtime := requested final renewal time; - endif - body.nonce := random_nonce(); - body.etype := requested etypes; - if (user supplied addresses) then - body.addresses := user's addresses; - else - omit body.addresses; - endif - omit body.enc-authorization-data; - request.req-body := body; - - kerberos := lookup(name of local kerberos server (or servers)); - send(packet,kerberos); - - wait(for response); - if (timed_out) then - retry or use alternate server; - endif - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -A.2. KRB_AS_REQ verification and KRB_AS_REP generation - - decode message into req; - - client := lookup(req.cname,req.realm); - server := lookup(req.sname,req.realm); - - get system_time; - kdc_time := system_time.seconds; - - if (!client) then - /* no client in Database */ - error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); - endif - if (!server) then - /* no server in Database */ - error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); - endif - - if(client.pa_enc_timestamp_required and - pa_enc_timestamp not present) then - error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); - endif - - if(pa_enc_timestamp present) then - decrypt req.padata-value into decrypted_enc_timestamp - using client.key; - using auth_hdr.authenticator.subkey; - if (decrypt_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - if(decrypted_enc_timestamp is not within allowable skew) -then - error_out(KDC_ERR_PREAUTH_FAILED); - endif - if(decrypted_enc_timestamp and usec is replay) - error_out(KDC_ERR_PREAUTH_FAILED); - endif - add decrypted_enc_timestamp and usec to replay cache; - endif - - use_etype := first supported etype in req.etypes; - - if (no support for req.etypes) then - error_out(KDC_ERR_ETYPE_NOSUPP); - endif - - new_tkt.vno := ticket version; /* = 5 */ - new_tkt.sname := req.sname; - new_tkt.srealm := req.srealm; - reset all flags in new_tkt.flags; - - /* It should be noted that local policy may affect the */ - /* processing of any of these flags. For example, some */ - /* realms may refuse to issue renewable tickets */ - - if (req.kdc-options.FORWARDABLE is set) then - set new_tkt.flags.FORWARDABLE; - endif - if (req.kdc-options.PROXIABLE is set) then - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - set new_tkt.flags.PROXIABLE; - endif - - if (req.kdc-options.ALLOW-POSTDATE is set) then - set new_tkt.flags.MAY-POSTDATE; - endif - if ((req.kdc-options.RENEW is set) or - (req.kdc-options.VALIDATE is set) or - (req.kdc-options.PROXY is set) or - (req.kdc-options.FORWARDED is set) or - (req.kdc-options.ENC-TKT-IN-SKEY is set)) then - error_out(KDC_ERR_BADOPTION); - endif - - new_tkt.session := random_session_key(); - new_tkt.cname := req.cname; - new_tkt.crealm := req.crealm; - new_tkt.transited := empty_transited_field(); - - new_tkt.authtime := kdc_time; - - if (req.kdc-options.POSTDATED is set) then - if (against_postdate_policy(req.from)) then - error_out(KDC_ERR_POLICY); - endif - set new_tkt.flags.POSTDATED; - set new_tkt.flags.INVALID; - new_tkt.starttime := req.from; - else - omit new_tkt.starttime; /* treated as authtime when omitted */ - endif - if (req.till = 0) then - till := infinity; - else - till := req.till; - endif - - new_tkt.endtime := min(till, - new_tkt.starttime+client.max_life, - new_tkt.starttime+server.max_life, - new_tkt.starttime+max_life_for_realm); - - if ((req.kdc-options.RENEWABLE-OK is set) and - (new_tkt.endtime < req.till)) then - /* we set the RENEWABLE option for later processing */ - set req.kdc-options.RENEWABLE; - req.rtime := req.till; - endif - - if (req.rtime = 0) then - rtime := infinity; - else - rtime := req.rtime; - endif - - if (req.kdc-options.RENEWABLE is set) then - set new_tkt.flags.RENEWABLE; - new_tkt.renew-till := min(rtime, - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - new_tkt.starttime+client.max_rlife, - new_tkt.starttime+server.max_rlife, - new_tkt.starttime+max_rlife_for_realm); - else - omit new_tkt.renew-till; /* only present if RENEWABLE */ - endif - - if (req.addresses) then - new_tkt.caddr := req.addresses; - else - omit new_tkt.caddr; - endif - - new_tkt.authorization_data := empty_authorization_data(); - - encode to-be-encrypted part of ticket into OCTET STRING; - new_tkt.enc-part := encrypt OCTET STRING - using etype_for_key(server.key), server.key, server.p_kvno; - - /* Start processing the response */ - - resp.pvno := 5; - resp.msg-type := KRB_AS_REP; - resp.cname := req.cname; - resp.crealm := req.realm; - resp.ticket := new_tkt; - - resp.key := new_tkt.session; - resp.last-req := fetch_last_request_info(client); - resp.nonce := req.nonce; - resp.key-expiration := client.expiration; - resp.flags := new_tkt.flags; - - resp.authtime := new_tkt.authtime; - resp.starttime := new_tkt.starttime; - resp.endtime := new_tkt.endtime; - - if (new_tkt.flags.RENEWABLE) then - resp.renew-till := new_tkt.renew-till; - endif - - resp.realm := new_tkt.realm; - resp.sname := new_tkt.sname; - - resp.caddr := new_tkt.caddr; - - encode body of reply into OCTET STRING; - - resp.enc-part := encrypt OCTET STRING - using use_etype, client.key, client.p_kvno; - send(resp); - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -A.3. KRB_AS_REP verification - - decode response into resp; - - if (resp.msg-type = KRB_ERROR) then - if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then - set pa_enc_timestamp_required; - goto KRB_AS_REQ; - endif - process_error(resp); - return; - endif - - /* On error, discard the response, and zero the session key */ - /* from the response immediately */ - - key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, - resp.padata); - unencrypted part of resp := decode of decrypt of resp.enc-part - using resp.enc-part.etype and key; - zero(key); - - if (common_as_rep_tgs_rep_checks fail) then - destroy resp.key; - return error; - endif - - if near(resp.princ_exp) then - print(warning message); - endif - save_for_later(ticket,session,client,server,times,flags); - -A.4. KRB_AS_REP and KRB_TGS_REP common checks - - if (decryption_error() or - (req.cname != resp.cname) or - (req.realm != resp.crealm) or - (req.sname != resp.sname) or - (req.realm != resp.realm) or - (req.nonce != resp.nonce) or - (req.addresses != resp.caddr)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - - /* make sure no flags are set that shouldn't be, and that all that -*/ - /* should be are set -*/ - if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - - if ((req.from = 0) and - (resp.starttime is not within allowable skew)) then - destroy resp.key; - return KRB_AP_ERR_SKEW; - endif - if ((req.from != 0) and (req.from != resp.starttime)) then - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - if ((req.till != 0) and (resp.endtime > req.till)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - - if ((req.kdc-options.RENEWABLE is set) and - (req.rtime != 0) and (resp.renew-till > req.rtime)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - if ((req.kdc-options.RENEWABLE-OK is set) and - (resp.flags.RENEWABLE) and - (req.till != 0) and - (resp.renew-till > req.till)) then - destroy resp.key; - return KRB_AP_ERR_MODIFIED; - endif - -A.5. KRB_TGS_REQ generation - - /* Note that make_application_request might have to recursivly -*/ - /* call this routine to get the appropriate ticket-granting ticket -*/ - - request.pvno := protocol version; /* pvno = 5 */ - request.msg-type := message type; /* type = KRB_TGS_REQ */ - - body.kdc-options := users's preferences; - /* If the TGT is not for the realm of the end-server */ - /* then the sname will be for a TGT for the end-realm */ - /* and the realm of the requested ticket (body.realm) */ - /* will be that of the TGS to which the TGT we are */ - /* sending applies */ - body.sname := service's name; - body.realm := service's realm; - - if (body.kdc-options.POSTDATED is set) then - body.from := requested starting time; - else - omit body.from; - endif - body.till := requested end time; - if (body.kdc-options.RENEWABLE is set) then - body.rtime := requested final renewal time; - endif - body.nonce := random_nonce(); - body.etype := requested etypes; - if (user supplied addresses) then - body.addresses := user's addresses; - else - omit body.addresses; - endif - - body.enc-authorization-data := user-supplied data; - if (body.kdc-options.ENC-TKT-IN-SKEY) then - body.additional-tickets_ticket := second TGT; - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - endif - - request.req-body := body; - check := generate_checksum (req.body,checksumtype); - - request.padata[0].padata-type := PA-TGS-REQ; - request.padata[0].padata-value := create a KRB_AP_REQ using - the TGT and checksum - - /* add in any other padata as required/supplied */ - - kerberos := lookup(name of local kerberose server (or servers)); - send(packet,kerberos); - - wait(for response); - if (timed_out) then - retry or use alternate server; - endif - -A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation - - /* note that reading the application request requires first - determining the server for which a ticket was issued, and choosing -the - correct key for decryption. The name of the server appears in the - plaintext part of the ticket. */ - - if (no KRB_AP_REQ in req.padata) then - error_out(KDC_ERR_PADATA_TYPE_NOSUPP); - endif - verify KRB_AP_REQ in req.padata; - - /* Note that the realm in which the Kerberos server is operating is - determined by the instance from the ticket-granting ticket. The -realm - in the ticket-granting ticket is the realm under which the ticket - granting ticket was issued. It is possible for a single Kerberos - server to support more than one realm. */ - - auth_hdr := KRB_AP_REQ; - tgt := auth_hdr.ticket; - - if (tgt.sname is not a TGT for local realm and is not req.sname) -then - error_out(KRB_AP_ERR_NOT_US); - - realm := realm_tgt_is_for(tgt); - - decode remainder of request; - - if (auth_hdr.authenticator.cksum is missing) then - error_out(KRB_AP_ERR_INAPP_CKSUM); - endif - - if (auth_hdr.authenticator.cksum type is not supported) then - error_out(KDC_ERR_SUMTYPE_NOSUPP); - endif - if (auth_hdr.authenticator.cksum is not both collision-proof and - keyed) then - error_out(KRB_AP_ERR_INAPP_CKSUM); - endif - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - set computed_checksum := checksum(req); - if (computed_checksum != auth_hdr.authenticatory.cksum) then - error_out(KRB_AP_ERR_MODIFIED); - endif - - server := lookup(req.sname,realm); - - if (!server) then - if (is_foreign_tgt_name(req.sname)) then - server := best_intermediate_tgs(req.sname); - else - /* no server in Database */ - error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); - endif - endif - - session := generate_random_session_key(); - - use_etype := first supported etype in req.etypes; - - if (no support for req.etypes) then - error_out(KDC_ERR_ETYPE_NOSUPP); - endif - - new_tkt.vno := ticket version; /* = 5 */ - new_tkt.sname := req.sname; - new_tkt.srealm := realm; - reset all flags in new_tkt.flags; - - /* It should be noted that local policy may affect the */ - /* processing of any of these flags. For example, some */ - /* realms may refuse to issue renewable tickets */ - - new_tkt.caddr := tgt.caddr; - resp.caddr := NULL; /* We only include this if they change */ - if (req.kdc-options.FORWARDABLE is set) then - if (tgt.flags.FORWARDABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.FORWARDABLE; - endif - if (req.kdc-options.FORWARDED is set) then - if (tgt.flags.FORWARDABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.FORWARDED; - new_tkt.caddr := req.addresses; - resp.caddr := req.addresses; - endif - if (tgt.flags.FORWARDED is set) then - set new_tkt.flags.FORWARDED; - endif - - if (req.kdc-options.PROXIABLE is set) then - if (tgt.flags.PROXIABLE is reset) - error_out(KDC_ERR_BADOPTION); - endif - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - set new_tkt.flags.PROXIABLE; - endif - if (req.kdc-options.PROXY is set) then - if (tgt.flags.PROXIABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.PROXY; - new_tkt.caddr := req.addresses; - resp.caddr := req.addresses; - endif - - if (req.kdc-options.ALLOW-POSTDATE is set) then - if (tgt.flags.MAY-POSTDATE is reset) - error_out(KDC_ERR_BADOPTION); - endif - set new_tkt.flags.MAY-POSTDATE; - endif - if (req.kdc-options.POSTDATED is set) then - if (tgt.flags.MAY-POSTDATE is reset) then - error_out(KDC_ERR_BADOPTION); + 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. Implementation receiving + values outside this range may reject the request, but they must recover + cleanly. + + 9.2. Recommended KDC values + + Following is a list of recommended values for a KDC implementation, + based on the list of suggested configuration constants (see section + 4.4). + + minimum lifetime 5 minutes + maximum renewable lifetime 1 week + maximum ticket lifetime 1 day + empty addresses only when suitable restrictions appear + in authorization data + proxiable, etc. Allowed. + + 10. REFERENCES + + [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- + cation Service for Computer Networks," IEEE Communica- + tions Magazine, Vol. 32(9), pp. 33-38 (September 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). + + [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- + beros: An Authentication Service for Open Network Sys- + tems," pp. 191-202 in Usenix Conference Proceedings, + Dallas, Texas (February, 1988). + + [NS78] Roger M. Needham and Michael D. Schroeder, "Using + Encryption for Authentication in Large Networks of Com- + puters," Communications of the ACM, Vol. 21(12), + pp. 993-999 (December, 1978). + + [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- + stamps in Key Distribution Protocols," Communications + of the ACM, Vol. 24(8), pp. 533-536 (August 1981). + + [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, + "The Evolution of the Kerberos Authentication Service," + in an IEEE Computer Society Text soon to be published + (June 1992). + + [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in Proceedings of + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + the 13th International Conference on Distributed Com- + puting Systems, Pittsburgh, PA (May, 1993). + + [DS90] Don Davis and Ralph Swick, "Workstation Services and + Kerberos Authentication at Project Athena," Technical + Memorandum TM-424, MIT Laboratory for Computer Science + (February 1990). + + [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- + merfeld, and K. Raeburn, Section E.1: Service Manage- + ment System, M.I.T. Project Athena, Cambridge, Mas- + sachusetts (1987). + + [X509-88] CCITT, Recommendation X.509: The Directory Authentica- + tion Framework, December 1988. + + [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password + Guessing Attacks, Open Software Foundation DCE Request + for Comments 26 (December 1992). + + [DES77] National Bureau of Standards, U.S. Department of Com- + merce, "Data Encryption Standard," Federal Information + Processing Standards Publication 46, Washington, DC + (1977). + + [DESM80] National Bureau of Standards, U.S. Department of Com- + merce, "DES Modes of Operation," Federal Information + Processing Standards Publication 81, Springfield, VA + (December 1980). + + [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message + Integrity in Cryptographic Protocols," in Proceedings + of the IEEE Symposium on Research in Security and + Privacy, Oakland, California (May 1992). + + [IS3309] International Organization for Standardization, "ISO + Information Processing Systems - Data Communication - + High-Level Data Link Control Procedure - Frame Struc- + ture," IS 3309 (October 1984). 3rd Edition. + + [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC + 1320, MIT Laboratory for Computer Science (April + 1992). + + [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC + 1321, MIT Laboratory for Computer Science (April + 1992). + + [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication," Working Draft + draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). + + [Horowitz96] Horowitz, M., "Key Derivation for Authentication, + Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, + August 1998. + + [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- + horowitz-kerb-key-derivation-01.txt, September 1998. + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac- + md5-01.txt, August, 1996. + + A. Pseudo-code for protocol processing + + This appendix provides pseudo-code describing how the messages are to + be constructed and interpreted by clients and servers. + + A.1. KRB_AS_REQ generation + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_AS_REQ */ + + if(pa_enc_timestamp_required) then + request.padata.padata-type = PA-ENC-TIMESTAMP; + get system_time; + padata-body.patimestamp,pausec = system_time; + encrypt padata-body into request.padata.padata-value + using client.key; /* derived from password */ + endif + + body.kdc-options := users's preferences; + body.cname := user's name; + body.realm := user's realm; + body.sname := service's name; /* usually "krbtgt", + "localrealm" */ + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + omit body.enc-authorization-data; + request.req-body := body; + + kerberos := lookup(name of local kerberos server (or servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.2. KRB_AS_REQ verification and KRB_AS_REP generation + + decode message into req; + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + client := lookup(req.cname,req.realm); + server := lookup(req.sname,req.realm); + + get system_time; + kdc_time := system_time.seconds; + + if (!client) then + /* no client in Database */ + error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); + endif + if (!server) then + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + + if(client.pa_enc_timestamp_required and + pa_enc_timestamp not present) then + error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); + endif + + if(pa_enc_timestamp present) then + decrypt req.padata-value into decrypted_enc_timestamp + using client.key; + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + if(decrypted_enc_timestamp is not within allowable skew) + then + error_out(KDC_ERR_PREAUTH_FAILED); + endif + if(decrypted_enc_timestamp and usec is replay) + error_out(KDC_ERR_PREAUTH_FAILED); + endif + add decrypted_enc_timestamp and usec to replay cache; + endif + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := req.srealm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + if (req.kdc-options.FORWARDABLE is set) then + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.PROXIABLE is set) then + set new_tkt.flags.PROXIABLE; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + set new_tkt.flags.MAY-POSTDATE; + endif + if ((req.kdc-options.RENEW is set) or + (req.kdc-options.VALIDATE is set) or + (req.kdc-options.PROXY is set) or + (req.kdc-options.FORWARDED is set) or + (req.kdc-options.ENC-TKT-IN-SKEY is set)) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.session := random_session_key(); + new_tkt.cname := req.cname; + new_tkt.crealm := req.crealm; + new_tkt.transited := empty_transited_field(); + + new_tkt.authtime := kdc_time; + + if (req.kdc-options.POSTDATED is set) then + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); endif set new_tkt.flags.POSTDATED; set new_tkt.flags.INVALID; - if (against_postdate_policy(req.from)) then - error_out(KDC_ERR_POLICY); - endif new_tkt.starttime := req.from; - endif + else + omit new_tkt.starttime; /* treated as authtime when omitted */ + endif + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif - if (req.kdc-options.VALIDATE is set) then - if (tgt.flags.INVALID is reset) then - error_out(KDC_ERR_POLICY); - endif - if (tgt.starttime > kdc_time) then - error_out(KRB_AP_ERR_NYV); - endif - if (check_hot_list(tgt)) then - error_out(KRB_AP_ERR_REPEAT); - endif - tkt := tgt; - reset new_tkt.flags.INVALID; - endif + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm); - if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, - and those already processed) is set) then - error_out(KDC_ERR_BADOPTION); - endif + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till)) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := req.till; + endif - new_tkt.authtime := tgt.authtime; + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif - if (req.kdc-options.RENEW is set) then - /* Note that if the endtime has already passed, the ticket would -*/ - /* have been rejected in the initial authentication stage, so -*/ - /* there is no need to check again here -*/ - if (tgt.flags.RENEWABLE is reset) then - error_out(KDC_ERR_BADOPTION); - endif - if (tgt.renew-till < kdc_time) then + if (req.kdc-options.RENEWABLE is set) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm); + else + omit new_tkt.renew-till; /* only present if RENEWABLE */ -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - error_out(KRB_AP_ERR_TKT_EXPIRED); - endif - tkt := tgt; - new_tkt.starttime := kdc_time; - old_life := tgt.endttime - tgt.starttime; - new_tkt.endtime := min(tgt.renew-till, - new_tkt.starttime + old_life); - else - new_tkt.starttime := kdc_time; - if (req.till = 0) then - till := infinity; - else - till := req.till; - endif - new_tkt.endtime := min(till, - new_tkt.starttime+client.max_life, - new_tkt.starttime+server.max_life, - new_tkt.starttime+max_life_for_realm, - tgt.endtime); - - if ((req.kdc-options.RENEWABLE-OK is set) and - (new_tkt.endtime < req.till) and - (tgt.flags.RENEWABLE is set) then - /* we set the RENEWABLE option for later processing -*/ - set req.kdc-options.RENEWABLE; - req.rtime := min(req.till, tgt.renew-till); - endif - endif - - if (req.rtime = 0) then - rtime := infinity; - else - rtime := req.rtime; - endif - - if ((req.kdc-options.RENEWABLE is set) and - (tgt.flags.RENEWABLE is set)) then - set new_tkt.flags.RENEWABLE; - new_tkt.renew-till := min(rtime, - new_tkt.starttime+client.max_rlife, - new_tkt.starttime+server.max_rlife, - new_tkt.starttime+max_rlife_for_realm, - tgt.renew-till); - else - new_tkt.renew-till := OMIT; /* leave the renew-till field out -*/ - endif - if (req.enc-authorization-data is present) then - decrypt req.enc-authorization-data into -decrypted_authorization_data - using auth_hdr.authenticator.subkey; - if (decrypt_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - endif - new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data -+ - decrypted_authorization_data; - - new_tkt.key := session; - new_tkt.crealm := tgt.crealm; - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - new_tkt.cname := req.auth_hdr.ticket.cname; - - if (realm_tgt_is_for(tgt) := tgt.realm) then - /* tgt issued by local realm */ - new_tkt.transited := tgt.transited; - else - /* was issued for this realm by some other realm */ - if (tgt.transited.tr-type not supported) then - error_out(KDC_ERR_TRTYPE_NOSUPP); - endif - new_tkt.transited := compress_transited(tgt.transited + -tgt.realm) - /* Don't check tranited field if TGT for foreign realm, - * or requested not to check */ - if (is_not_foreign_tgt_name(new_tkt.server) - && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then - /* Check it, so end-server does not have to - * but don't fail, end-server may still accept it */ - if (check_transited_field(new_tkt.transited) == OK) - set new_tkt.flags.TRANSITED-POLICY-CHECKED; - endif - endif - endif - - encode encrypted part of new_tkt into OCTET STRING; - if (req.kdc-options.ENC-TKT-IN-SKEY is set) then - if (server not specified) then - server = req.second_ticket.client; - endif - if ((req.second_ticket is not a TGT) or - (req.second_ticket.client != server)) then - error_out(KDC_ERR_POLICY); - endif - - new_tkt.enc-part := encrypt OCTET STRING using - using etype_for_key(second-ticket.key), second-ticket.key; - else - new_tkt.enc-part := encrypt OCTET STRING - using etype_for_key(server.key), server.key, server.p_kvno; - endif - - resp.pvno := 5; - resp.msg-type := KRB_TGS_REP; - resp.crealm := tgt.crealm; - resp.cname := tgt.cname; - resp.ticket := new_tkt; - - resp.key := session; - resp.nonce := req.nonce; - resp.last-req := fetch_last_request_info(client); - resp.flags := new_tkt.flags; - - resp.authtime := new_tkt.authtime; - resp.starttime := new_tkt.starttime; - resp.endtime := new_tkt.endtime; - - omit resp.key-expiration; - - resp.sname := new_tkt.sname; - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - resp.realm := new_tkt.realm; - - if (new_tkt.flags.RENEWABLE) then - resp.renew-till := new_tkt.renew-till; - endif - - encode body of reply into OCTET STRING; - - if (req.padata.authenticator.subkey) - resp.enc-part := encrypt OCTET STRING using use_etype, - req.padata.authenticator.subkey; - else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; - - send(resp); - -A.7. KRB_TGS_REP verification - - decode response into resp; - - if (resp.msg-type = KRB_ERROR) then - process_error(resp); - return; - endif - - /* On error, discard the response, and zero the session key from - the response immediately */ - - if (req.padata.authenticator.subkey) - unencrypted part of resp := decode of decrypt of -resp.enc-part - using resp.enc-part.etype and subkey; - else unencrypted part of resp := decode of decrypt of resp.enc-part - using resp.enc-part.etype and tgt's session key; - if (common_as_rep_tgs_rep_checks fail) then - destroy resp.key; - return error; - endif - - check authorization_data as necessary; - save_for_later(ticket,session,client,server,times,flags); - -A.8. Authenticator generation - - body.authenticator-vno := authenticator vno; /* = 5 */ - body.cname, body.crealm := client name; - if (supplying checksum) then - body.cksum := checksum; - endif - get system_time; - body.ctime, body.cusec := system_time; - if (selecting sub-session key) then - select sub-session key; - body.subkey := sub-session key; - endif - if (using sequence numbers) then - select initial sequence number; - body.seq-number := initial sequence; - endif +Neuman, Ts'o, Kohl Expires: 10 September, 2000 -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 -A.9. KRB_AP_REQ generation - obtain ticket and session_key from cache; +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_AP_REQ */ + endif - if (desired(MUTUAL_AUTHENTICATION)) then - set packet.ap-options.MUTUAL-REQUIRED; - else - reset packet.ap-options.MUTUAL-REQUIRED; - endif - if (using session key for ticket) then - set packet.ap-options.USE-SESSION-KEY; - else - reset packet.ap-options.USE-SESSION-KEY; - endif - packet.ticket := ticket; /* ticket */ - generate authenticator; - encode authenticator into OCTET STRING; - encrypt OCTET STRING into packet.authenticator using session_key; + if (req.addresses) then + new_tkt.caddr := req.addresses; + else + omit new_tkt.caddr; + endif -A.10. KRB_AP_REQ verification + new_tkt.authorization_data := empty_authorization_data(); - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_AP_REQ) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - if (packet.ticket.tkt_vno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.ap_options.USE-SESSION-KEY is set) then - retrieve session key from ticket-granting ticket for - packet.ticket.{sname,srealm,enc-part.etype}; - else - retrieve service key for - packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; - endif - if (no_key_available) then - if (cannot_find_specified_skvno) then - error_out(KRB_AP_ERR_BADKEYVER); - else - error_out(KRB_AP_ERR_NOKEY); - endif - endif - decrypt packet.ticket.enc-part into decr_ticket using retrieved key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - decrypt packet.authenticator into decr_authenticator - using decr_ticket.key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); + encode to-be-encrypted part of ticket into OCTET STRING; + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, server.p_kvno; -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 + /* Start processing the response */ - endif - if (decr_authenticator.{cname,crealm} != - decr_ticket.{cname,crealm}) then - error_out(KRB_AP_ERR_BADMATCH); - endif - if (decr_ticket.caddr is present) then - if (sender_address(packet) is not in decr_ticket.caddr) then - error_out(KRB_AP_ERR_BADADDR); - endif - elseif (application requires addresses) then - error_out(KRB_AP_ERR_BADADDR); - endif - if (not in_clock_skew(decr_authenticator.ctime, - decr_authenticator.cusec)) then - error_out(KRB_AP_ERR_SKEW); - endif - if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then - error_out(KRB_AP_ERR_REPEAT); - endif - save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); - get system_time; - if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or - (decr_ticket.flags.INVALID is set)) then - /* it hasn't yet become valid */ - error_out(KRB_AP_ERR_TKT_NYV); - endif - if (system_time-decr_ticket.endtime > CLOCK_SKEW) then - error_out(KRB_AP_ERR_TKT_EXPIRED); - endif - if (decr_ticket.transited) then - /* caller may ignore the TRANSITED-POLICY-CHECKED and do - * check anyway */ - if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then - if (check_transited_field(decr_ticket.transited) then - error_out(KDC_AP_PATH_NOT_ACCPETED); + resp.pvno := 5; + resp.msg-type := KRB_AS_REP; + resp.cname := req.cname; + resp.crealm := req.realm; + resp.ticket := new_tkt; + + resp.key := new_tkt.session; + resp.last-req := fetch_last_request_info(client); + resp.nonce := req.nonce; + resp.key-expiration := client.expiration; + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + resp.realm := new_tkt.realm; + resp.sname := new_tkt.sname; + + resp.caddr := new_tkt.caddr; + + encode body of reply into OCTET STRING; + + resp.enc-part := encrypt OCTET STRING + using use_etype, client.key, client.p_kvno; + send(resp); + + A.3. KRB_AS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then + set pa_enc_timestamp_required; + goto KRB_AS_REQ; + endif + process_error(resp); + return; + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + + /* On error, discard the response, and zero the session key */ + /* from the response immediately */ + + key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, + resp.padata); + unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and key; + zero(key); + + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + if near(resp.princ_exp) then + print(warning message); + endif + save_for_later(ticket,session,client,server,times,flags); + + A.4. KRB_AS_REP and KRB_TGS_REP common checks + + if (decryption_error() or + (req.cname != resp.cname) or + (req.realm != resp.crealm) or + (req.sname != resp.sname) or + (req.realm != resp.realm) or + (req.nonce != resp.nonce) or + (req.addresses != resp.caddr)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + /* make sure no flags are set that shouldn't be, and that all that */ + /* should be are set */ + if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.from = 0) and + (resp.starttime is not within allowable skew)) then + destroy resp.key; + return KRB_AP_ERR_SKEW; + endif + if ((req.from != 0) and (req.from != resp.starttime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.till != 0) and (resp.endtime > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (req.rtime != 0) and (resp.renew-till > req.rtime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if ((req.kdc-options.RENEWABLE-OK is set) and + (resp.flags.RENEWABLE) and + (req.till != 0) and + (resp.renew-till > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + A.5. KRB_TGS_REQ generation + + /* Note that make_application_request might have to recursivly */ + /* call this routine to get the appropriate ticket-granting ticket */ + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_TGS_REQ */ + + body.kdc-options := users's preferences; + /* If the TGT is not for the realm of the end-server */ + /* then the sname will be for a TGT for the end-realm */ + /* and the realm of the requested ticket (body.realm) */ + /* will be that of the TGS to which the TGT we are */ + /* sending applies */ + body.sname := service's name; + body.realm := service's realm; + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + + body.enc-authorization-data := user-supplied data; + if (body.kdc-options.ENC-TKT-IN-SKEY) then + body.additional-tickets_ticket := second TGT; + endif + + request.req-body := body; + check := generate_checksum (req.body,checksumtype); + + request.padata[0].padata-type := PA-TGS-REQ; + request.padata[0].padata-value := create a KRB_AP_REQ using + the TGT and checksum + + /* add in any other padata as required/supplied */ + + kerberos := lookup(name of local kerberose server (or servers)); + send(packet,kerberos); + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + + A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation + + /* note that reading the application request requires first + determining the server for which a ticket was issued, and + choosing the correct key for decryption. The name of the + server appears in the plaintext part of the ticket. */ + + if (no KRB_AP_REQ in req.padata) then + error_out(KDC_ERR_PADATA_TYPE_NOSUPP); + endif + verify KRB_AP_REQ in req.padata; + + /* Note that the realm in which the Kerberos server is + operating is determined by the instance from the + ticket-granting ticket. The realm in the ticket-granting + ticket is the realm under which the ticket granting + ticket was issued. It is possible for a single Kerberos + server to support more than one realm. */ + + auth_hdr := KRB_AP_REQ; + tgt := auth_hdr.ticket; + + if (tgt.sname is not a TGT for local realm and is not req.sname) + then + error_out(KRB_AP_ERR_NOT_US); + + realm := realm_tgt_is_for(tgt); + + decode remainder of request; + + if (auth_hdr.authenticator.cksum is missing) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + if (auth_hdr.authenticator.cksum type is not supported) then + error_out(KDC_ERR_SUMTYPE_NOSUPP); + endif + if (auth_hdr.authenticator.cksum is not both collision-proof + and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + set computed_checksum := checksum(req); + if (computed_checksum != auth_hdr.authenticatory.cksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + server := lookup(req.sname,realm); + + if (!server) then + if (is_foreign_tgt_name(req.sname)) then + server := best_intermediate_tgs(req.sname); + else + /* no server in Database */ + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + endif + + session := generate_random_session_key(); + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := realm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + new_tkt.caddr := tgt.caddr; + resp.caddr := NULL; /* We only include this if they change */ + if (req.kdc-options.FORWARDABLE is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.FORWARDED is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDED; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + if (tgt.flags.FORWARDED is set) then + set new_tkt.flags.FORWARDED; + endif + + if (req.kdc-options.PROXIABLE is set) then + if (tgt.flags.PROXIABLE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXIABLE; + endif + if (req.kdc-options.PROXY is set) then + if (tgt.flags.PROXIABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXY; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + if (tgt.flags.MAY-POSTDATE is reset) + error_out(KDC_ERR_BADOPTION); + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + endif + set new_tkt.flags.MAY-POSTDATE; + endif + if (req.kdc-options.POSTDATED is set) then + if (tgt.flags.MAY-POSTDATE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + new_tkt.starttime := req.from; + endif + + if (req.kdc-options.VALIDATE is set) then + if (tgt.flags.INVALID is reset) then + error_out(KDC_ERR_POLICY); + endif + if (tgt.starttime > kdc_time) then + error_out(KRB_AP_ERR_NYV); + endif + if (check_hot_list(tgt)) then + error_out(KRB_AP_ERR_REPEAT); + endif + tkt := tgt; + reset new_tkt.flags.INVALID; + endif + + if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, + and those already processed) is set) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.authtime := tgt.authtime; + + if (req.kdc-options.RENEW is set) then + /* Note that if the endtime has already passed, the ticket would */ + /* have been rejected in the initial authentication stage, so */ + /* there is no need to check again here */ + if (tgt.flags.RENEWABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + if (tgt.renew-till < kdc_time) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + tkt := tgt; + new_tkt.starttime := kdc_time; + old_life := tgt.endttime - tgt.starttime; + new_tkt.endtime := min(tgt.renew-till, + new_tkt.starttime + old_life); + else + new_tkt.starttime := kdc_time; + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + new_tkt.endtime := min(till, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm, + tgt.endtime); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till) and + (tgt.flags.RENEWABLE is set) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := min(req.till, tgt.renew-till); + endif + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (tgt.flags.RENEWABLE is set)) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm, + tgt.renew-till); + else + new_tkt.renew-till := OMIT; /* leave the + renew-till field out */ + endif + if (req.enc-authorization-data is present) then + decrypt req.enc-authorization-data into + decrypted_authorization_data + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + endif + new_tkt.authorization_data := + req.auth_hdr.ticket.authorization_data + + decrypted_authorization_data; + + new_tkt.key := session; + new_tkt.crealm := tgt.crealm; + new_tkt.cname := req.auth_hdr.ticket.cname; + + if (realm_tgt_is_for(tgt) := tgt.realm) then + /* tgt issued by local realm */ + new_tkt.transited := tgt.transited; + else + /* was issued for this realm by some other realm */ + if (tgt.transited.tr-type not supported) then + error_out(KDC_ERR_TRTYPE_NOSUPP); + endif + new_tkt.transited := + compress_transited(tgt.transited + tgt.realm) + /* Don't check tranited field if TGT for foreign realm, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + * or requested not to check */ + if (is_not_foreign_tgt_name(new_tkt.server) + && req.kdc-options.DISABLE-TRANSITED-CHECK not + set) then + /* Check it, so end-server does not have to + * but don't fail, end-server may still accept it */ + if (check_transited_field(new_tkt.transited) == OK) + set new_tkt.flags.TRANSITED-POLICY-CHECKED; + endif + endif + endif + + encode encrypted part of new_tkt into OCTET STRING; + if (req.kdc-options.ENC-TKT-IN-SKEY is set) then + if (server not specified) then + server = req.second_ticket.client; + endif + if ((req.second_ticket is not a TGT) or + (req.second_ticket.client != server)) then + error_out(KDC_ERR_POLICY); + endif + + new_tkt.enc-part := encrypt OCTET STRING using + using etype_for_key(second-ticket.key), + second-ticket.key; + else + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), + server.key, server.p_kvno; + endif + + resp.pvno := 5; + resp.msg-type := KRB_TGS_REP; + resp.crealm := tgt.crealm; + resp.cname := tgt.cname; + resp.ticket := new_tkt; + + resp.key := session; + resp.nonce := req.nonce; + resp.last-req := fetch_last_request_info(client); + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + omit resp.key-expiration; + + resp.sname := new_tkt.sname; + resp.realm := new_tkt.realm; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + encode body of reply into OCTET STRING; + + if (req.padata.authenticator.subkey) + resp.enc-part := encrypt OCTET STRING using use_etype, + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + req.padata.authenticator.subkey; + else resp.enc-part := encrypt OCTET STRING using + use_etype, tgt.key; + + send(resp); + + A.7. KRB_TGS_REP verification + + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key from + the response immediately */ + + if (req.padata.authenticator.subkey) + unencrypted part of resp := decode of decrypt of + resp.enc-part + using resp.enc-part.etype and subkey; + else unencrypted part of resp := decode of decrypt of + resp.enc-part + using resp.enc-part.etype and + tgt's session key; + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + check authorization_data as necessary; + save_for_later(ticket,session,client,server,times,flags); + + A.8. Authenticator generation + + body.authenticator-vno := authenticator vno; /* = 5 */ + body.cname, body.crealm := client name; + if (supplying checksum) then + body.cksum := checksum; + endif + get system_time; + body.ctime, body.cusec := system_time; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + A.9. KRB_AP_REQ generation + + obtain ticket and session_key from cache; + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REQ */ + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (desired(MUTUAL_AUTHENTICATION)) then + set packet.ap-options.MUTUAL-REQUIRED; + else + reset packet.ap-options.MUTUAL-REQUIRED; + endif + if (using session key for ticket) then + set packet.ap-options.USE-SESSION-KEY; + else + reset packet.ap-options.USE-SESSION-KEY; + endif + packet.ticket := ticket; /* ticket */ + generate authenticator; + encode authenticator into OCTET STRING; + encrypt OCTET STRING into packet.authenticator using session_key; + + A.10. KRB_AP_REQ verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REQ) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.ticket.tkt_vno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.ap_options.USE-SESSION-KEY is set) then + retrieve session key from ticket-granting ticket for + packet.ticket.{sname,srealm,enc-part.etype}; + else + retrieve service key for + packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; + endif + if (no_key_available) then + if (cannot_find_specified_skvno) then + error_out(KRB_AP_ERR_BADKEYVER); + else + error_out(KRB_AP_ERR_NOKEY); + endif + endif + decrypt packet.ticket.enc-part into decr_ticket using + retrieved key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + decrypt packet.authenticator into decr_authenticator + using decr_ticket.key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (decr_authenticator.{cname,crealm} != + decr_ticket.{cname,crealm}) then + error_out(KRB_AP_ERR_BADMATCH); + endif + if (decr_ticket.caddr is present) then + if (sender_address(packet) is not in + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + decr_ticket.caddr) then + error_out(KRB_AP_ERR_BADADDR); + endif + elseif (application requires addresses) then + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(decr_authenticator.ctime, + decr_authenticator.cusec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then + error_out(KRB_AP_ERR_REPEAT); + endif + save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); + get system_time; + if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or + (decr_ticket.flags.INVALID is set)) then + /* it hasn't yet become valid */ + error_out(KRB_AP_ERR_TKT_NYV); + endif + if (system_time-decr_ticket.endtime > CLOCK_SKEW) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + if (decr_ticket.transited) then + /* caller may ignore the TRANSITED-POLICY-CHECKED and do + * check anyway */ + if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then + if (check_transited_field(decr_ticket.transited) then + error_out(KDC_AP_PATH_NOT_ACCPETED); + endif endif - endif - endif - /* caller must check decr_ticket.flags for any pertinent details */ - return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -A.11. KRB_AP_REP generation - - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_AP_REP */ - - body.ctime := packet.ctime; - body.cusec := packet.cusec; - if (selecting sub-session key) then - select sub-session key; - body.subkey := sub-session key; - endif - if (using sequence numbers) then - select initial sequence number; - body.seq-number := initial sequence; - endif - - encode body into OCTET STRING; - - select encryption type; - encrypt OCTET STRING into packet.enc-part; - -A.12. KRB_AP_REP verification - - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_AP_REP) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - cleartext := decrypt(packet.enc-part) using ticket's session key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - if (cleartext.ctime != authenticator.ctime) then - error_out(KRB_AP_ERR_MUT_FAIL); - endif - if (cleartext.cusec != authenticator.cusec) then - error_out(KRB_AP_ERR_MUT_FAIL); - endif - if (cleartext.subkey is present) then - save cleartext.subkey for future use; - endif - if (cleartext.seq-number is present) then - save cleartext.seq-number for future verifications; - endif - return(AUTHENTICATION_SUCCEEDED); - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -A.13. KRB_SAFE generation - - collect user data in buffer; - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_SAFE */ - - body.user-data := buffer; /* DATA */ - if (using timestamp) then - get system_time; - body.timestamp, body.usec := system_time; - endif - if (using sequence numbers) then - body.seq-number := sequence number; - endif - body.s-address := sender host addresses; - if (only one recipient) then - body.r-address := recipient host address; - endif - checksum.cksumtype := checksum type; - compute checksum over body; - checksum.checksum := checksum value; /* checksum.checksum */ - packet.cksum := checksum; - packet.safe-body := body; - -A.14. KRB_SAFE verification - - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_SAFE) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - if (packet.checksum.cksumtype is not both collision-proof - and keyed) then - error_out(KRB_AP_ERR_INAPP_CKSUM); - endif - if (safe_priv_common_checks_ok(packet)) then - set computed_checksum := checksum(packet.body); - if (computed_checksum != packet.checksum) then - error_out(KRB_AP_ERR_MODIFIED); - endif - return (packet, PACKET_IS_GENUINE); - else - return common_checks_error; - endif - -A.15. KRB_SAFE and KRB_PRIV common checks - - if (packet.s-address != O/S_sender(packet)) then - /* O/S report of sender not who claims to have sent it */ - error_out(KRB_AP_ERR_BADADDR); - endif - if ((packet.r-address is present) and - (packet.r-address != local_host_address)) then - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - /* was not sent to proper place */ - error_out(KRB_AP_ERR_BADADDR); - endif - if (((packet.timestamp is present) and - (not in_clock_skew(packet.timestamp,packet.usec))) or - (packet.timestamp is not present and timestamp expected)) then - error_out(KRB_AP_ERR_SKEW); - endif - if (repeated(packet.timestamp,packet.usec,packet.s-address)) then - error_out(KRB_AP_ERR_REPEAT); - endif - - if (((packet.seq-number is present) and - ((not in_sequence(packet.seq-number)))) or - (packet.seq-number is not present and sequence expected)) then - error_out(KRB_AP_ERR_BADORDER); - endif - if (packet.timestamp not present and packet.seq-number - not present) then - error_out(KRB_AP_ERR_MODIFIED); - endif - - save_identifier(packet.{timestamp,usec,s-address}, - sender_principal(packet)); - - return PACKET_IS_OK; - -A.16. KRB_PRIV generation - - collect user data in buffer; - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_PRIV */ - - packet.enc-part.etype := encryption type; - - body.user-data := buffer; - if (using timestamp) then - get system_time; - body.timestamp, body.usec := system_time; - endif - if (using sequence numbers) then - body.seq-number := sequence number; - endif - body.s-address := sender host addresses; - if (only one recipient) then - body.r-address := recipient host address; - endif - - encode body into OCTET STRING; - - select encryption type; - encrypt OCTET STRING into packet.enc-part.cipher; - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -A.17. KRB_PRIV verification - - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_PRIV) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - - cleartext := decrypt(packet.enc-part) using negotiated key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - - if (safe_priv_common_checks_ok(cleartext)) then - return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); - else - return common_checks_error; - endif - -A.18. KRB_CRED generation - - invoke KRB_TGS; /* obtain tickets to be provided to peer */ - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_CRED */ - - for (tickets[n] in tickets to be forwarded) do - packet.tickets[n] = tickets[n].ticket; - done - - packet.enc-part.etype := encryption type; - - for (ticket[n] in tickets to be forwarded) do - body.ticket-info[n].key = tickets[n].session; - body.ticket-info[n].prealm = tickets[n].crealm; - body.ticket-info[n].pname = tickets[n].cname; - body.ticket-info[n].flags = tickets[n].flags; - body.ticket-info[n].authtime = tickets[n].authtime; - body.ticket-info[n].starttime = tickets[n].starttime; - body.ticket-info[n].endtime = tickets[n].endtime; - body.ticket-info[n].renew-till = tickets[n].renew-till; - body.ticket-info[n].srealm = tickets[n].srealm; - body.ticket-info[n].sname = tickets[n].sname; - body.ticket-info[n].caddr = tickets[n].caddr; - done - - get system_time; - body.timestamp, body.usec := system_time; - - if (using nonce) then - body.nonce := nonce; - endif - - if (using s-address) then - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - - body.s-address := sender host addresses; - endif - if (limited recipients) then - body.r-address := recipient host address; - endif - - encode body into OCTET STRING; - - select encryption type; - encrypt OCTET STRING into packet.enc-part.cipher - using negotiated encryption key; - -A.19. KRB_CRED verification - - receive packet; - if (packet.pvno != 5) then - either process using other protocol spec - or error_out(KRB_AP_ERR_BADVERSION); - endif - if (packet.msg-type != KRB_CRED) then - error_out(KRB_AP_ERR_MSG_TYPE); - endif - - cleartext := decrypt(packet.enc-part) using negotiated key; - if (decryption_error()) then - error_out(KRB_AP_ERR_BAD_INTEGRITY); - endif - if ((packet.r-address is present or required) and - (packet.s-address != O/S_sender(packet)) then - /* O/S report of sender not who claims to have sent it */ - error_out(KRB_AP_ERR_BADADDR); - endif - if ((packet.r-address is present) and - (packet.r-address != local_host_address)) then - /* was not sent to proper place */ - error_out(KRB_AP_ERR_BADADDR); - endif - if (not in_clock_skew(packet.timestamp,packet.usec)) then - error_out(KRB_AP_ERR_SKEW); - endif - if (repeated(packet.timestamp,packet.usec,packet.s-address)) then - error_out(KRB_AP_ERR_REPEAT); - endif - if (packet.nonce is required or present) and - (packet.nonce != expected-nonce) then - error_out(KRB_AP_ERR_MODIFIED); - endif - - for (ticket[n] in tickets that were forwarded) do - save_for_later(ticket[n],key[n],principal[n], - server[n],times[n],flags[n]); - return - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -A.20. KRB_ERROR generation - - /* assemble packet: */ - packet.pvno := protocol version; /* 5 */ - packet.msg-type := message type; /* KRB_ERROR */ - - get system_time; - packet.stime, packet.susec := system_time; - packet.realm, packet.sname := server name; - - if (client time available) then - packet.ctime, packet.cusec := client_time; - endif - packet.error-code := error code; - if (client name available) then - packet.cname, packet.crealm := client name; - endif - if (error text available) then - packet.e-text := error text; - endif - if (error data available) then - packet.e-data := error data; - endif - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -B. Definition of common authorization data elements - -This appendix contains the definitions of common authorization data -elements. These common authorization data elements are recursivly defined, -meaning 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 they 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 which they affect. - -In the definitions that follow, the value of the ad-type for the element -will be specified in the subsection number, and the value of the ad-data -will be as shown in the ASN.1 structure that follows the subsection heading. - -B.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 which may have local extensions for authorization. - -B.2. Intended for server - -AD-INTENDED-FOR-SERVER SEQUENCE { - intended-server[0] SEQUENCE OF PrincipalName - elements[1] AuthorizationData -} - -AD elements encapsulated within the intended-for-server element may be -ignored if the application server is not in the list of principal names of -intended servers. Further, a KDC issuing a ticket for an application server -can remove this element if the application server is not in the list of -intended servers. - -Application servers should check for their principal name in the -intended-server field of this element. If their principal name is not found, -this element should be ignored. If found, then the encapsulated elements -should be evaluated in the same manner as if they were present in the top -level authorization data field. Applications and application servers that do -not implement this element should reject tickets that contain authorization -data elements of this type. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -B.3. Intended for application class - -AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0] -SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements -encapsulated within the intended-for-application-class element may be -ignored if the application server is not in one of the named classes of -application servers. Examples of application server classes include -"FILESYSTEM", and other kinds of servers. - -This element and the elements it encapulates may be safely ignored by -applications, application servers, and KDCs that do not implement this -element. - -B.4. KDC Issued - -AD-KDCIssued SEQUENCE { - ad-checksum[0] Checksum, - i-realm[1] Realm OPTIONAL, - i-sname[2] PrincipalName OPTIONAL, - elements[3] AuthorizationData. -} - -ad-checksum - A checksum over the elements field using a cryptographic checksum - method that is identical to the checksum used to protect the ticket - itself (i.e. using the same hash function and the same encryption - algorithm used to encrypt the ticket) and using a key derived from the - same key used to protect the ticket. -i-realm, i-sname - The name of the issuing principal if different from 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 priveleges of -the principal beyond what can be done using a credentials without such an -a-data element. - -This can not 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 that 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 will be ignored by the -application server if this "signature" is not present. Further, elements -encapsulated within this element from a ticket granting ticket 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 encapulates may be safely ignored by -applications, application servers, and KDCs that do not implement this -element. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -B.5. And-Or - -AD-AND-OR SEQUENCE { - condition-count[0] INTEGER, - elements[1] AuthorizationData -} - -When restrictive AD elements encapsulated within the and-or element are -encountered, only the number specified in condition-count of the -encapsulated conditions must be met in order to satisfy this element. 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. - -B.6. Mandatory ticket extensions - -AD-Mandatory-Ticket-Extensions Checksum - -An authorization data element of type mandatory-ticket-extensions specifies -a collision-proof checksum using the same hash algorithm used to protect the -integrity of the ticket itself. This checksum will be calculated over an -individual extension field. If there are more than one extension, multiple -Mandatory-Ticket-Extensions authorization data elements may be present, each -with a checksum for a different extension field. This restriction indicates -that the ticket should not be accepted if a ticket extension is not present -in the ticket for which the checksum does not match that checksum specified -in the authorization data element. Application servers that do not implement -this element must reject tickets that contain authorization data elements of -this type. - -B.7. Authorization Data in ticket extensions - -AD-IN-Ticket-Extensions Checksum - -An authorization data element of type in-ticket-extensions specifies a -collision-proof checksum using the same hash algorithm used to protect the -integrity of the ticket itself. This checksum is calculated over a separate -external AuthorizationData field carried in the ticket extensions. -Application servers that do not implement this element must reject tickets -that contain authorization data elements of this type. Application servers -that do implement this element will search the ticket extensions for -authorization data fields, calculate the specified checksum over each -authorization data field and look for one matching the checksum in this -in-ticket-extensions element. If not found, then the ticket must be -rejected. If found, the corresponding authorization data elements will be -interpreted in the same manner as if they were contained in the top level -authorization data field. - -Note that if multiple external authorization data fields are present in a -ticket, each will have a corresponding element of type in-ticket-extensions -in the top level authorization data field, and the external entries will be -linked to the corresponding element by their checksums. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -C. Definition of common ticket extensions - -This appendix contains the definitions of common ticket extensions. Support -for these extensions is optional. However, certain extensions have -associated authorization data elements that may require rejection of a -ticket containing an extension by application servers that do not implement -the particular extension. Other extensions have been defined beyond those -described in this specification. Such extensions are described elswhere and -for some of those extensions the reserved number may be found in the list of -constants. - -It is known that older versions of Kerberos did not support this field, and -that some clients will strip this field from a ticket when they parse and -then reassemble a ticket as it is passed to the application servers. The -presence of the extension will not break such clients, but any functionaly -dependent on the extensions will not work when such tickets are handled by -old clients. In such situations, some implementation may use alternate -methods to transmit the information in the extensions field. - -C.1. Null ticket extension - -TE-NullExtension OctetString -- The empty Octet String - -The te-data field in the null ticket extension is an octet string of lenght -zero. This extension may be included in a ticket granting ticket so that the -KDC can determine on presentation of the ticket granting ticket whether the -client software will strip the extensions field. - -C.2. External Authorization Data - -TE-ExternalAuthorizationData AuthorizationData - -The te-data field in the external authorization data ticket extension is -field of type AuthorizationData containing one or more authorization data -elements. If present, a corresponding authorization data element will be -present in the primary authorization data for the ticket and that element -will contain a checksum of the external authorization data ticket extension. - ------------------------------------------------------------------------ -[TM] Project Athena, Athena, and Kerberos are trademarks of the -Massachusetts Institute of Technology (MIT). No commercial use of these -trademarks may be made without prior written permission of MIT. - -[1] Note, however, that many applications use Kerberos' functions only upon -the initiation of a stream-based network connection. Unless an application -subsequently provides integrity protection for the data stream, the identity -verification applies only to the initiation of the connection, and does not -guarantee that subsequent messages on the connection originate from the same -principal. - -[2] Secret and private are often used interchangeably in the literature. In -our usage, it takes two (or more) to share a secret, thus a shared DES key -is a secret key. Something is only private when no one but its owner knows -it. Thus, in public key cryptosystems, one has a public and a private key. - -[3] Of course, with appropriate permission the client could arrange -registration of a separately-named prin- cipal 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. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -[4] Though it is permissible to request or issue tick- ets with no network -addresses specified. - -[5] The password-changing request must not be honored unless the requester -can provide the old password (the user's current secret key). Otherwise, it -would be possible for someone to walk up to an unattended ses- sion and -change another user's password. - -[6] 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. - -[7] "Random" means that, among other things, it should be impossible to -guess the next session key based on knowledge of past session keys. This can -only 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. - -[8] 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. - -[9] 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. - -[10] This is used for user-to-user authentication as described in [8]. - -[11] 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 be have their authenticators -rejected if the time and microsecond fields happen to match some other -client's authenticator. - -[12] 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. - -[13] Note that for encrypting the KRB_AP_REP message, the sub-session key is -not used, even if present in the Authenticator. - -[14] Implementations of the protocol may wish to provide routines to choose -subkeys based on session keys and random numbers and to generate a -negotiated key to be returned in the KRB_AP_REP message. - -[15]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 configura- tion 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 authenti- cated. -This might result in the use of a realm which has been compromised, and -would result in an attacker's ability to compromise the authentication of -the application server to the client. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -[16] If the client selects a sub-session key, care must be taken to ensure -the randomness of the selected sub- session key. One approach would be to -generate a random number and XOR it with the session key from the -ticket-granting ticket. - -[17] This allows easy implementation of user-to-user authentication [8], -which uses ticket-granting ticket session keys in lieu of secret server keys -in situa- tions where such secret keys could be easily comprom- ised. - -[18] For the purpose of appending, the realm preceding the first listed -realm is considered to be the null realm (""). - -[19] 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. - -[20] This means that a client and server running on the same host and -communicating with one another using the KRB_SAFE messages should not share -a common replay cache to detect KRB_SAFE replays. - -[21] The implementation of the Kerberos server need not combine the database -and the server on the same machine; it is feasible to store the principal -database in, say, a network name service, as long as the entries stored -therein are protected from disclosure to and modification by unauthorized -parties. However, we recommend against such strategies, as they can make -system management and threat analysis quite complex. - -[22] See the discussion of the padata field in section 5.4.2 for details on -why this can be useful. - -[23] Warning for implementations that unpack and repack data structures -during the generation and verification of embedded checksums: Because any -checksums applied to data structures must be checked against the original -data the length of bit strings must be preserved within a data structure -between the time that a checksum is generated through transmission to the -time that the checksum is verified. - -[24] It is NOT recommended that this time value be used to adjust the -workstation's clock since the workstation cannot reliably determine that -such a KRB_AS_REP actually came from the proper KDC in a timely manner. - -[25] Note, however, that if the time is used as the nonce, one must make -sure that the workstation time is monotonically increasing. If the time is -ever reset backwards, there is a small, but finite, probability that a nonce -will be reused. - -[27] An application code in the encrypted part of a message provides an -additional check that the message was decrypted properly. - -[29] An application code in the encrypted part of a message provides an -additional check that the message was decrypted properly. - -[31] An application code in the encrypted part of a message provides an -additional check that the message was decrypted properly. - - -Neuman, Ts'o, Kohl Expires: 25 December, -1999 - -INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, -1999 - -[32] If supported by the encryption method in use, an initialization vector -may be passed to the encryption procedure, in order to achieve proper cipher -chaining. The initialization vector might come from the last block of the -ciphertext from the previous KRB_PRIV message, but it is the application's -choice whether or not to use such an initialization vector. If left out, the -default initialization vector for the encryption algorithm will be used. - -[33] This prevents an attacker who generates an incorrect AS request from -obtaining verifiable plaintext for use in an off-line password guessing -attack. - -[35] In the above specification, UNTAGGED OCTET STRING(length) is the -notation for an octet string with its tag and length removed. It is not a -valid ASN.1 type. The tag bits and length must be removed from the -confounder since the purpose of the confounder is so that the message starts -with random data, but the tag and its length are fixed. For other fields, -the length and tag would be redundant if they were included because they are -specified by the encryption type. [36] The ordering of the fields in the -CipherText is important. Additionally, messages encoded in this format must -include a length as part of the msg-seq field. This allows the recipient to -verify that the message has not been truncated. Without a length, an -attacker could use a chosen plaintext attack to generate a message which -could be truncated, while leaving the checksum intact. Note that if the -msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length -is part of that encoding. - -[37] In some cases, it may be necessary to use a different "mix-in" string -for compatibility reasons; see the discussion of padata in section 5.4.2. - -[38] In some cases, it may be necessary to use a different "mix-in" string -for compatibility reasons; see the discussion of padata in section 5.4.2. - -[39] A variant of the key is used to limit the use of a key to a particular -function, separating the functions of generating a checksum from other -encryption performed using the session key. The constant F0F0F0F0F0F0F0F0 -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. - -[40] 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. + endif + /* caller must check decr_ticket.flags for any pertinent details */ + return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); + + A.11. KRB_AP_REP generation + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REP */ + + body.ctime := packet.ctime; + body.cusec := packet.cusec; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part; + + A.12. KRB_AP_REP verification + + receive packet; + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REP) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + cleartext := decrypt(packet.enc-part) using ticket's session key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (cleartext.ctime != authenticator.ctime) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.cusec != authenticator.cusec) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.subkey is present) then + save cleartext.subkey for future use; + endif + if (cleartext.seq-number is present) then + save cleartext.seq-number for future verifications; + endif + return(AUTHENTICATION_SUCCEEDED); + + A.13. KRB_SAFE generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_SAFE */ + + body.user-data := buffer; /* DATA */ + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + checksum.cksumtype := checksum type; + compute checksum over body; + checksum.checksum := checksum value; /* checksum.checksum */ + packet.cksum := checksum; + packet.safe-body := body; + + A.14. KRB_SAFE verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_SAFE) then + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.checksum.cksumtype is not both collision-proof + and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + if (safe_priv_common_checks_ok(packet)) then + set computed_checksum := checksum(packet.body); + if (computed_checksum != packet.checksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + return (packet, PACKET_IS_GENUINE); + else + return common_checks_error; + endif + + A.15. KRB_SAFE and KRB_PRIV common checks + + if (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (((packet.timestamp is present) and + (not in_clock_skew(packet.timestamp,packet.usec))) or + (packet.timestamp is not present and timestamp expected)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + + if (((packet.seq-number is present) and + ((not in_sequence(packet.seq-number)))) or + (packet.seq-number is not present and sequence expected)) then + error_out(KRB_AP_ERR_BADORDER); + endif + if (packet.timestamp not present and packet.seq-number + not present) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + save_identifier(packet.{timestamp,usec,s-address}, + sender_principal(packet)); + + return PACKET_IS_OK; + + A.16. KRB_PRIV generation + + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_PRIV */ + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + packet.enc-part.etype := encryption type; + + body.user-data := buffer; + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher; + + A.17. KRB_PRIV verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_PRIV) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + + if (safe_priv_common_checks_ok(cleartext)) then + return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); + else + return common_checks_error; + endif + + A.18. KRB_CRED generation + + invoke KRB_TGS; /* obtain tickets to be provided to peer */ + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_CRED */ + + for (tickets[n] in tickets to be forwarded) do + packet.tickets[n] = tickets[n].ticket; + done + + packet.enc-part.etype := encryption type; + + for (ticket[n] in tickets to be forwarded) do + body.ticket-info[n].key = tickets[n].session; + body.ticket-info[n].prealm = tickets[n].crealm; + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + body.ticket-info[n].pname = tickets[n].cname; + body.ticket-info[n].flags = tickets[n].flags; + body.ticket-info[n].authtime = tickets[n].authtime; + body.ticket-info[n].starttime = tickets[n].starttime; + body.ticket-info[n].endtime = tickets[n].endtime; + body.ticket-info[n].renew-till = tickets[n].renew-till; + body.ticket-info[n].srealm = tickets[n].srealm; + body.ticket-info[n].sname = tickets[n].sname; + body.ticket-info[n].caddr = tickets[n].caddr; + done + + get system_time; + body.timestamp, body.usec := system_time; + + if (using nonce) then + body.nonce := nonce; + endif + + if (using s-address) then + body.s-address := sender host addresses; + endif + if (limited recipients) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher + using negotiated encryption key; + + A.19. KRB_CRED verification + + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_CRED) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if ((packet.r-address is present or required) and + (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(packet.timestamp,packet.usec)) then + error_out(KRB_AP_ERR_SKEW); + endif + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + if (packet.nonce is required or present) and + (packet.nonce != expected-nonce) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + for (ticket[n] in tickets that were forwarded) do + save_for_later(ticket[n],key[n],principal[n], + server[n],times[n],flags[n]); + return + + A.20. KRB_ERROR generation + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_ERROR */ + + get system_time; + packet.stime, packet.susec := system_time; + packet.realm, packet.sname := server name; + + if (client time available) then + packet.ctime, packet.cusec := client_time; + endif + packet.error-code := error code; + if (client name available) then + packet.cname, packet.crealm := client name; + endif + if (error text available) then + packet.e-text := error text; + endif + if (error data available) then + packet.e-data := error data; + endif + + B. Definition of common authorization data elements + + This appendix contains the definitions of common authorization data + elements. These common authorization data elements are recursivly + defined, meaning 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 they 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 which they affect. + + In the definitions that follow, the value of the ad-type for the + element will be specified in the subsection number, and the value of + the ad-data will be as shown in the ASN.1 structure that follows the + subsection heading. + + B.1. If relevant + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + 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 which may have local extensions + for authorization. + + B.2. Intended for server + + AD-INTENDED-FOR-SERVER SEQUENCE { + intended-server[0] SEQUENCE OF PrincipalName + elements[1] AuthorizationData + } + + AD elements encapsulated within the intended-for-server element may be + ignored if the application server is not in the list of principal names + of intended servers. Further, a KDC issuing a ticket for an application + server can remove this element if the application server is not in the + list of intended servers. + + Application servers should check for their principal name in the + intended-server field of this element. If their principal name is not + found, this element should be ignored. If found, then the encapsulated + elements should be evaluated in the same manner as if they were present + in the top level authorization data field. Applications and application + servers that do not implement this element should reject tickets that + contain authorization data elements of this type. + + B.3. Intended for application class + + AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { + intended-application-class[0] SEQUENCE OF GeneralString elements[1] + AuthorizationData } AD elements encapsulated within the + intended-for-application-class element may be ignored if the + application server is not in one of the named classes of application + servers. Examples of application server classes include "FILESYSTEM", + and other kinds of servers. + + This element and the elements it encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.4. KDC Issued + + AD-KDCIssued SEQUENCE { + ad-checksum[0] Checksum, + i-realm[1] Realm OPTIONAL, + i-sname[2] PrincipalName OPTIONAL, + elements[3] AuthorizationData. + } + + ad-checksum + A checksum over the elements field using a cryptographic checksum + method that is identical to the checksum used to protect the + ticket itself (i.e. using the same hash function and the same + encryption algorithm used to encrypt the ticket) and using a key + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + derived from the same key used to protect the ticket. + i-realm, i-sname + The name of the issuing principal if different from 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 priveleges of the principal beyond what can be done using a + credentials without such an a-data element. + + This can not 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 that 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 will be + ignored by the application server if this "signature" is not present. + Further, elements encapsulated within this element from a ticket + granting ticket 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 encapulates may be safely ignored by + applications, application servers, and KDCs that do not implement this + element. + + B.5. And-Or + + AD-AND-OR SEQUENCE { + condition-count[0] INTEGER, + elements[1] AuthorizationData + } + + When restrictive AD elements encapsulated within the and-or element are + encountered, only the number specified in condition-count of the + encapsulated conditions must be met in order to satisfy this element. + 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. + + B.6. Mandatory ticket extensions + + AD-Mandatory-Ticket-Extensions Checksum + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + An authorization data element of type mandatory-ticket-extensions + specifies a collision-proof checksum using the same hash algorithm used + to protect the integrity of the ticket itself. This checksum will be + calculated over an individual extension field. If there are more than + one extension, multiple Mandatory-Ticket-Extensions authorization data + elements may be present, each with a checksum for a different extension + field. This restriction indicates that the ticket should not be + accepted if a ticket extension is not present in the ticket for which + the checksum does not match that checksum specified in the + authorization data element. Application servers that do not implement + this element must reject tickets that contain authorization data + elements of this type. + + B.7. Authorization Data in ticket extensions + + AD-IN-Ticket-Extensions Checksum + + An authorization data element of type in-ticket-extensions specifies a + collision-proof checksum using the same hash algorithm used to protect + the integrity of the ticket itself. This checksum is calculated over a + separate external AuthorizationData field carried in the ticket + extensions. Application servers that do not implement this element must + reject tickets that contain authorization data elements of this type. + Application servers that do implement this element will search the + ticket extensions for authorization data fields, calculate the + specified checksum over each authorization data field and look for one + matching the checksum in this in-ticket-extensions element. If not + found, then the ticket must be rejected. If found, the corresponding + authorization data elements will be interpreted in the same manner as + if they were contained in the top level authorization data field. + + Note that if multiple external authorization data fields are present in + a ticket, each will have a corresponding element of type + in-ticket-extensions in the top level authorization data field, and the + external entries will be linked to the corresponding element by their + checksums. + + C. Definition of common ticket extensions + + This appendix contains the definitions of common ticket extensions. + Support for these extensions is optional. However, certain extensions + have associated authorization data elements that may require rejection + of a ticket containing an extension by application servers that do not + implement the particular extension. Other extensions have been defined + beyond those described in this specification. Such extensions are + described elswhere and for some of those extensions the reserved number + may be found in the list of constants. + + It is known that older versions of Kerberos did not support this field, + and that some clients will strip this field from a ticket when they + parse and then reassemble a ticket as it is passed to the application + servers. The presence of the extension will not break such clients, but + any functionaly dependent on the extensions will not work when such + tickets are handled by old clients. In such situations, some + implementation may use alternate methods to transmit the information in + the extensions field. + + C.1. Null ticket extension + + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + TE-NullExtension OctetString -- The empty Octet String + + The te-data field in the null ticket extension is an octet string of + lenght zero. This extension may be included in a ticket granting ticket + so that the KDC can determine on presentation of the ticket granting + ticket whether the client software will strip the extensions field. + + C.2. External Authorization Data + + TE-ExternalAuthorizationData AuthorizationData + + The te-data field in the external authorization data ticket extension + is field of type AuthorizationData containing one or more authorization + data elements. If present, a corresponding authorization data element + will be present in the primary authorization data for the ticket and + that element will contain a checksum of the external authorization data + ticket extension. + ----------------------------------------------------------------------- + [TM] Project Athena, Athena, and Kerberos are trademarks of the + Massachusetts Institute of Technology (MIT). No commercial use of these + trademarks may be made without prior written permission of MIT. + + [1] Note, however, that many applications use Kerberos' functions only + upon the initiation of a stream-based network connection. Unless an + application subsequently provides integrity protection for the data + stream, the identity verification applies only to the initiation of the + connection, and does not guarantee that subsequent messages on the + connection originate from the same principal. + + [2] Secret and private are often used interchangeably in the + literature. In our usage, it takes two (or more) to share a secret, + thus a shared DES key is a secret key. Something is only private when + no one but its owner knows it. Thus, in public key cryptosystems, one + has a public and a private key. + + [3] Of course, with appropriate permission the client could arrange + registration of a separately-named prin- cipal 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. + + [4] Though it is permissible to request or issue tick- ets with no + network addresses specified. + + [5] The password-changing request must not be honored unless the + requester can provide the old password (the user's current secret key). + Otherwise, it would be possible for someone to walk up to an unattended + ses- sion and change another user's password. + + [6] 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. + + [7] "Random" means that, among other things, it should be impossible to + guess the next session key based on knowledge of past session keys. + This can only be achieved in a pseudo-random number generator if it is + based on cryptographic principles. It is more desirable to use a truly + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + random number generator, such as one based on measurements of random + physical phenomena. + + [8] 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. + + [9] 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. + + [10] This is used for user-to-user authentication as described in [8]. + + [11] 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 be have their + authenticators rejected if the time and microsecond fields happen to + match some other client's authenticator. + + [12] 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. + + [13] Note that for encrypting the KRB_AP_REP message, the sub-session + key is not used, even if present in the Authenticator. + + [14] Implementations of the protocol may wish to provide routines to + choose subkeys based on session keys and random numbers and to generate + a negotiated key to be returned in the KRB_AP_REP message. + + [15]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 + configura- tion 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 authenti- cated. This might result in + the use of a realm which has been compromised, and would result in an + attacker's ability to compromise the authentication of the application + server to the client. + + [16] If the client selects a sub-session key, care must be taken to + ensure the randomness of the selected sub- session key. One approach + would be to generate a random number and XOR it with the session key + from the ticket-granting ticket. + + [17] This allows easy implementation of user-to-user authentication + [8], which uses ticket-granting ticket session keys in lieu of secret + server keys in situa- tions where such secret keys could be easily + comprom- ised. + + [18] For the purpose of appending, the realm preceding the first listed + realm is considered to be the null realm (""). + + [19] For the purpose of interpreting null subfields, the client's realm + is considered to precede those in the transited field, and the server's + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + realm is considered to follow them. + + [20] This means that a client and server running on the same host and + communicating with one another using the KRB_SAFE messages should not + share a common replay cache to detect KRB_SAFE replays. + + [21] The implementation of the Kerberos server need not combine the + database and the server on the same machine; it is feasible to store + the principal database in, say, a network name service, as long as the + entries stored therein are protected from disclosure to and + modification by unauthorized parties. However, we recommend against + such strategies, as they can make system management and threat analysis + quite complex. + + [22] See the discussion of the padata field in section 5.4.2 for + details on why this can be useful. + + [23] Warning for implementations that unpack and repack data structures + during the generation and verification of embedded checksums: Because + any checksums applied to data structures must be checked against the + original data the length of bit strings must be preserved within a data + structure between the time that a checksum is generated through + transmission to the time that the checksum is verified. + + [24] It is NOT recommended that this time value be used to adjust the + workstation's clock since the workstation cannot reliably determine + that such a KRB_AS_REP actually came from the proper KDC in a timely + manner. + + [25] Note, however, that if the time is used as the nonce, one must + make sure that the workstation time is monotonically increasing. If the + time is ever reset backwards, there is a small, but finite, probability + that a nonce will be reused. + + [27] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [29] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [31] An application code in the encrypted part of a message provides an + additional check that the message was decrypted properly. + + [32] If supported by the encryption method in use, an initialization + vector may be passed to the encryption procedure, in order to achieve + proper cipher chaining. The initialization vector might come from the + last block of the ciphertext from the previous KRB_PRIV message, but it + is the application's choice whether or not to use such an + initialization vector. If left out, the default initialization vector + for the encryption algorithm will be used. + + [33] This prevents an attacker who generates an incorrect AS request + from obtaining verifiable plaintext for use in an off-line password + guessing attack. + + [35] In the above specification, UNTAGGED OCTET STRING(length) is the + notation for an octet string with its tag and length removed. It is not + a valid ASN.1 type. The tag bits and length must be removed from the + confounder since the purpose of the confounder is so that the message + +Neuman, Ts'o, Kohl Expires: 10 September, 2000 + + + + +INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-05 June 25, 1999 + + starts with random data, but the tag and its length are fixed. For + other fields, the length and tag would be redundant if they were + included because they are specified by the encryption type. [36] The + ordering of the fields in the CipherText is important. Additionally, + messages encoded in this format must include a length as part of the + msg-seq field. This allows the recipient to verify that the message has + not been truncated. Without a length, an attacker could use a chosen + plaintext attack to generate a message which could be truncated, while + leaving the checksum intact. Note that if the msg-seq is an encoding of + an ASN.1 SEQUENCE or OCTET STRING, then the length is part of that + encoding. + + [37] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [38] In some cases, it may be necessary to use a different "mix-in" + string for compatibility reasons; see the discussion of padata in + section 5.4.2. + + [39] A variant of the key is used to limit the use of a key to a + particular function, separating the functions of generating a checksum + from other encryption performed using the session key. The constant + F0F0F0F0F0F0F0F0 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. + + [40] 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/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt similarity index 96% rename from doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt rename to doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt index 68892ac45..6f7dae0de 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt @@ -1,7 +1,7 @@ INTERNET-DRAFT Mike Swift -draft-ietf-cat-kerberos-set-passwd-01.txt Microsoft -February 2000 Jonathan Trostle +draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft +March 2000 Jonathan Trostle Cisco Systems John Brezak Microsoft @@ -132,9 +132,11 @@ Request Message } NewPasswdOrKeys :: = CHOICE { - passwords[0] KeySequence, - keyseq[1] PasswordSequence + passwords[0] PasswordSequence, + keyseq[1] KeySequences + } + KeySequences :: = SEQUENCE OF KeySequence KeySequence :: = SEQUENCE { key[0] EncryptionKey, @@ -146,7 +148,7 @@ Request Message newpasswd[0] OCTET STRING, oldpasswd[1] OCTET STRING OPTIONAL -- oldpasswd always present for change password - -- but not set password + -- but not present for set password } The server must verify the AP-REQ message, check whether the client @@ -295,7 +297,7 @@ Reply Message 5. Expiration Date - This draft expires in August 2000. + This draft expires in September 2000. 6. Authors' Addresses @@ -317,5 +319,7 @@ Reply Message Bill Gossman Cybersafe Corporation + 1605 NW Sammamish Rd. + Issaquah, WA 98027-5378 Email: bill.gossman@cybersafe.com