diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt | 252 |
1 files changed, 252 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt new file mode 100644 index 00000000000..c5e4d05e7e3 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt @@ -0,0 +1,252 @@ + +INTERNET-DRAFT Ari Medvinsky +draft-ietf-cat-kerberos-err-msg-00.txt Matt Hur +Updates: RFC 1510 Dominique Brezinski +expires September 30, 1997 CyberSafe Corporation + Gene Tsudik + Brian Tung + ISI + +Integrity Protection for the Kerberos Error Message + +0. Status Of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ds.internic.net (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-03.txt, and expires June xx, 1997. + Please send comments to the authors. + +1. Abstract + + The Kerberos error message, as defined in RFC 1510, is transmitted + to the client without any integrity assurance. Therefore, the + client has no means to distinguish between a valid error message + sent from the KDC and one sent by an attacker. This draft describes + a method for assuring the integrity of Kerberos error messages, and + proposes a consistent format for the e-data field in the KRB_ERROR + message. This e-data format enables the storage of cryptographic + checksums by providing an extensible mechanism for specifying e-data + types. + + +2. Motivation + + In the Kerberos protocol [1], if an error occurs for AS_REQ, + TGS_REQ, or AP_REQ, a clear text error message is returned to the + client. An attacker may exploit this vulnerability by sending a + false error message as a reply to any of the above requests. For + example, an attacker may send the KDC_ERR_KEY_EXPIRED error message + in order to force a user to change their password in hope that the + new key will not be as strong as the current key, and thus, easier + to break. + + Since false error messages may be utilized by an attacker, a + Kerberos client should have a means for determining how much trust + to place in a given error message. The rest of this draft + describes a method for assuring the integrity of Kerberos error + messages. + + +3. Approach + + We propose taking a cryptographic checksum over the entire KRB-ERROR + message. This checksum would be returned as part of the error + message and would enable the client to verify the integrity of the + error message. For interoperability reasons, no new fields are + added to the KRB-ERROR message. Instead, the e-data field (see + figure 1) is utilized to carry the cryptographic checksum. + + +3.1 Cryptographic checksums in error messages for AS_REQ, + TGS_REQ & AP_REQ + + If an error occurs for the AS request, the only key that is + available to the KDC is the shared secret (the key derived from the + clients password) registered in the KDCs database. The KDC will + use this key to sign the error message, if and only if, the client + already proved knowledge of the shared secret in the AS request + (e.g. via PA-ENC-TIMESTAMP in preauth data). This policy is needed + to prevent an attacker from getting the KDC to send a signed error + message and then launching an off-line attack in order to obtain a + key of a given principal. + + If an error occurs for a TGS or an AP request, the server will use + the session key sealed in the clients ticket granting ticket to + compute the checksum over the error message. If the checksum could + not be computed (e.g. error while decrypting the ticket) the error + message is returned to the client without the checksum. The client + then has the option to treat unprotected error messages differently. + + + KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno [0] integer, + msg-type [1] integer, + ctime [2] KerberosTime OPTIONAL, + cusec [3] INTEGER OPTIONAL, + stime [4] KerberosTime, + susec [5] INTEGER, + error-code [6] INTEGER, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm, --Correct realm + sname [10] PrincipalName, --Correct name + e-text [11] GeneralString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL + } + Figure 1 + + +3.2 Format of the e-data field + + We propose to place the cryptographic checksum in the e-data field. + First, we review the format of the e-data field, as specified in + RFC 1510. The format of e-data is specified only in two cases [2]. + "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data + field will contain an encoding of a sequence of padata fields": + + METHOD-DATA ::= SEQUENCE of PA-DATA + PA-DATA ::= SEQUENCE { + padata-type [1] INTEGER, + padata-value [2] OCTET STRING + } + + The second case deals with the KRB_AP_ERR_METHOD error code. The + e-data field will contain an encoding of the following sequence: + + METHOD-DATA ::= SEQUENCE { + method-type [0] INTEGER, + method-data [1] OCTET STRING OPTIONAL + } + + method-type indicates the required alternate authentication method. + + It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed + checksum is not returned as part of the error message, since the + error code indicates that the Kerberos credentials provided in the + AP_REQ message are unacceptable. + + We propose that the e-data field have the following format for all + error-codes (except KRB_AP_ERR_METHOD): + + E-DATA ::= SEQUENCE { + data-type [1] INTEGER, + data-value [2] OCTET STRING, + } + + The data-type field specifies the type of information that is + carried in the data-value field. Thus, to send a cryptographic + checksum back to the client, the data-type is set to CHECKSUM, the + data-value is set to the ASN.1 encoding of the following sequence: + + Checksum ::= SEQUENCE { + cksumtype [0] INTEGER, + checksum [1] OCTET STRING + } + + +3.3 Computing the checksum + + After the error message is filled out, the error structure is + converted into ASN.1 representation. A cryptographic checksum is + then taken over the encoded error message; the result is placed in + the error message structure, as the last item in the e-data field. + To send the error message, ASN.1 encoding is again performed over + the error message, which now includes the cryptographic checksum. + + +3.4 Verifying the integrity of the error message + + In addition to verifying the cryptographic checksum for the error + message, the client must verify that the error message is bound to + its request. This is done by comparing the ctime field in the + error message to its counterpart in the request message. + + +4. E-DATA types + + Since the e-data types must not conflict with preauthentication data + types, we propose that the preauthentication data types in the range + of 2048 and above be reserved for use as e-data types. + + We define the following e-data type in support of integrity checking + for the Kerberos error message: + + CHECKSUM = 2048 -- the keyed checksum described above + + +5. Discussion + + +5.1 e-data types + + The extension for Kerberos error messages, as outlined above, is + extensible to allow for definition of other error data types. + We propose that the following e-data types be reserved: + + KDCTIME = 2049 + The error data would consist of the KDCs time in KerberosTime. + This data would be used by the client to adjust for clock skew. + + REDIRECT = 2050 + The error data would consist of a hostname. The hostname would + indicate the authoritative KDC from which to obtain a TGT. + + +5.2 e-data types vs. error code specific data formats + + Since RFC 1510 does not define an error data type, the data format + must be explicitly specified for each error code. This draft has + proposed an extension to RFC 1510 that would introduce the concept + of error data types. This would allow for a manageable set of data + types to be used for any error message. The authors assume that + the introduction of this e-data structure will not break any + existing Kerberos implementations. + + +6. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments: 1510 + [2] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments: 1510 p.67 + + +7. Authors + + Ari Medvinsky <ari.medvinsky@cybersafe.com> + Matthew Hur <matt.hur@cybersafe.com> + Dominique Brezinski <dominique.brezinski@cybersafe.com> + + CyberSafe Corporation + 1605 NW Sammamish Road + Suite 310 + Issaquah, WA 98027-5378 + Phone: (206) 391-6000 + Fax: (206) 391-0508 + http:/www.cybersafe.com + + + Brian Tung <brian@isi.edu> + Gene Tsudik <gts@isi.edu> + + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: (310) 822-1511 + |