doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt

   1
   2 INTERNET-DRAFT                                           Ari Medvinsky
   3 draft-ietf-cat-kerberos-err-msg-00.txt                        Matt Hur
   4 Updates: RFC 1510                                  Dominique Brezinski
   5 expires September 30, 1997                       CyberSafe Corporation
   6                                                            Gene Tsudik
   7                                                             Brian Tung
   8                                                                    ISI
   9
  10 Integrity Protection for the Kerberos Error Message
  11
  12 0.  Status Of this Memo
  13
  14     This document is an Internet-Draft.  Internet-Drafts are working
  15     documents of the Internet Engineering Task Force (IETF), its
  16     areas, and its working groups.  Note that other groups may also
  17     distribute working documents as Internet-Drafts.
  18
  19     Internet-Drafts are draft documents valid for a maximum of six
  20     months and may be updated, replaced, or obsoleted by other
  21     documents at any time.  It is inappropriate to use Internet-Drafts
  22     as reference material or to cite them other than as "work in
  23     progress."
  24
  25     To learn the current status of any Internet-Draft, please check
  26     the "1id-abstracts.txt" listing contained in the Internet-Drafts
  27     Shadow Directories on ds.internic.net (US East Coast),
  28     nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  29     munnari.oz.au (Pacific Rim).
  30
  31     The distribution of this memo is unlimited.  It is filed as
  32     draft-ietf-cat-kerberos-pk-init-03.txt, and expires June xx, 1997.
  33     Please send comments to the authors.
  34
  35 1.  Abstract
  36
  37     The Kerberos error message, as defined in RFC 1510, is transmitted
  38     to the client without any integrity assurance.  Therefore, the
  39     client has no means to distinguish between a valid error message
  40     sent from the KDC and one sent by an attacker.  This draft describes
  41     a method for assuring the integrity of Kerberos error messages, and
  42     proposes a consistent format for the e-data field in the KRB_ERROR
  43     message.  This e-data format enables the storage of cryptographic
  44     checksums by providing an extensible mechanism for specifying e-data
  45     types.
  46
  47
  48 2.  Motivation
  49
  50     In the Kerberos protocol [1], if an error occurs for AS_REQ,
  51     TGS_REQ, or AP_REQ, a clear text error message is returned to the
  52     client.  An attacker may exploit this vulnerability by sending a
  53     false error message as a reply to any of the above requests.  For
  54     example, an attacker may send the KDC_ERR_KEY_EXPIRED error message
  55     in order to force a user to change their password in hope that the
  56     new key will not be as strong as the current key, and thus, easier
  57     to break.
  58
  59     Since false error messages may be utilized by an attacker, a
  60     Kerberos client should have a means for determining how much trust
  61     to place in a given error message.  The rest of this draft
  62     describes a method for assuring the integrity of Kerberos error
  63     messages.
  64
  65
  66 3.  Approach
  67
  68     We propose taking a cryptographic checksum over the entire KRB-ERROR
  69     message.  This checksum would be returned as part of the error
  70     message and would enable the client to verify the integrity of the
  71     error message.  For interoperability reasons, no new fields are
  72     added to the KRB-ERROR message.  Instead, the e-data field (see
  73     figure 1) is utilized to carry the cryptographic checksum.
  74
  75
  76 3.1 Cryptographic checksums in error messages for AS_REQ,
  77     TGS_REQ & AP_REQ
  78
  79     If an error occurs for the AS request, the only key that is
  80     available to the KDC is the shared secret (the key derived from the
  81     clients password) registered in the KDCs database.  The KDC will
  82     use this key to sign the error message, if and only if, the client
  83     already proved knowledge of the shared secret in the AS request
  84     (e.g. via PA-ENC-TIMESTAMP in preauth data).  This policy is needed
  85     to prevent an attacker from getting the KDC to send a signed error
  86     message and then launching an off-line attack in order to obtain a
  87     key of a given principal.
  88
  89     If an error occurs for a TGS or an AP request, the server will use
  90     the session key sealed in the clients ticket granting ticket to
  91     compute the checksum over the error message.  If the checksum could
  92     not be computed (e.g. error while decrypting the ticket) the error
  93     message is returned to the client without the checksum.  The client
  94     then has the option to treat unprotected error messages differently.
  95
  96
  97     KRB-ERROR ::=  [APPLICATION 30] SEQUENCE {
  98             pvno       [0]  integer,
  99             msg-type   [1]  integer,
 100             ctime      [2]  KerberosTime OPTIONAL,
 101             cusec      [3]  INTEGER OPTIONAL,
 102             stime      [4]  KerberosTime,
 103             susec      [5]  INTEGER,
 104             error-code [6]  INTEGER,
 105             crealm     [7]  Realm OPTIONAL,
 106             cname      [8]  PrincipalName OPTIONAL,
 107             realm      [9]  Realm,         --Correct realm
 108             sname      [10] PrincipalName, --Correct name
 109             e-text     [11] GeneralString OPTIONAL,
 110             e-data     [12] OCTET STRING OPTIONAL
 111     }
 112     Figure 1
 113
 114
 115 3.2 Format of the e-data field
 116
 117     We propose to place the cryptographic checksum in the e-data field.
 118     First, we review the format of the e-data field, as specified in
 119     RFC 1510.  The format of e-data is specified only in two cases [2].
 120     "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
 121     field will contain an encoding of a sequence of padata fields":
 122
 123     METHOD-DATA ::=  SEQUENCE of PA-DATA
 124     PA-DATA ::= SEQUENCE {
 125                 padata-type    [1] INTEGER,
 126                 padata-value   [2] OCTET STRING
 127     }
 128
 129     The second case deals with the KRB_AP_ERR_METHOD error code.  The
 130     e-data field will contain an encoding of the following sequence:
 131
 132     METHOD-DATA ::=  SEQUENCE {
 133                      method-type    [0] INTEGER,
 134                      method-data    [1] OCTET STRING OPTIONAL
 135     }
 136
 137     method-type indicates the required alternate authentication method.
 138
 139     It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed
 140     checksum is not returned as part of the error message, since the
 141     error code indicates that the Kerberos credentials provided in the
 142     AP_REQ message are unacceptable.
 143
 144     We propose that the e-data field have the following format for all
 145     error-codes (except KRB_AP_ERR_METHOD):
 146
 147     E-DATA ::=  SEQUENCE {
 148                 data-type    [1] INTEGER,
 149                 data-value   [2] OCTET STRING,
 150     }
 151
 152     The data-type field specifies the type of information that is
 153     carried in the data-value field.  Thus, to send a cryptographic
 154     checksum back to the client, the data-type is set to CHECKSUM, the
 155     data-value is set to the ASN.1 encoding of the following sequence:
 156
 157     Checksum  ::=  SEQUENCE {
 158                    cksumtype  [0] INTEGER,
 159                    checksum   [1] OCTET STRING
 160     }
 161
 162
 163 3.3 Computing the checksum
 164
 165     After the error message is filled out, the error structure is
 166     converted into ASN.1 representation.  A cryptographic checksum is
 167     then taken over the encoded error message; the result is placed in
 168     the error message structure, as the last item in the e-data field.
 169     To send the error message, ASN.1 encoding is again performed over
 170     the error message, which now includes the cryptographic checksum.
 171
 172
 173 3.4 Verifying the integrity of the error message
 174
 175     In addition to verifying the cryptographic checksum for the error
 176     message, the client must verify that the error message is bound to
 177     its request.  This is done by comparing the ctime field in the
 178     error message to its counterpart in the request message.
 179
 180
 181 4.  E-DATA types
 182
 183     Since the e-data types must not conflict with preauthentication data
 184     types, we propose that the preauthentication data types in the range
 185     of 2048 and above be reserved for use as e-data types.
 186
 187     We define the following e-data type in support of integrity checking
 188     for the Kerberos error message:
 189
 190     CHECKSUM = 2048 -- the keyed checksum described above
 191
 192
 193 5.  Discussion
 194
 195
 196 5.1 e-data types
 197
 198     The extension for Kerberos error messages, as outlined above, is
 199     extensible to allow for definition of other error data types.
 200     We propose that the following e-data types be reserved:
 201
 202     KDCTIME = 2049
 203     The error data would consist of the KDCs time in KerberosTime.
 204     This data would be used by the client to adjust for clock skew.
 205
 206     REDIRECT = 2050
 207     The error data would consist of a hostname.  The hostname would
 208     indicate the authoritative KDC from which to obtain a TGT.
 209
 210
 211 5.2 e-data types vs. error code specific data formats
 212
 213     Since RFC 1510 does not define an error data type, the data format
 214     must be explicitly specified for each error code.  This draft has
 215     proposed an extension to RFC 1510 that would introduce the concept
 216     of error data types.  This would allow for a manageable set of data
 217     types to be used for any error message.  The authors assume that
 218     the introduction of this e-data structure will not break any
 219     existing Kerberos implementations.
 220
 221
 222 6.  Bibliography
 223
 224     [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
 225         Service (V5).  Request for Comments: 1510
 226     [2] J. Kohl, C. Neuman.  The Kerberos Network Authentication
 227         Service (V5).  Request for Comments: 1510 p.67
 228
 229
 230 7.  Authors
 231
 232     Ari Medvinsky       <ari.medvinsky@cybersafe.com>
 233     Matthew Hur         <matt.hur@cybersafe.com>
 234     Dominique Brezinski <dominique.brezinski@cybersafe.com>
 235
 236     CyberSafe Corporation
 237     1605 NW Sammamish Road
 238     Suite 310
 239     Issaquah, WA 98027-5378
 240     Phone: (206) 391-6000
 241     Fax:   (206) 391-0508
 242     http:/www.cybersafe.com
 243
 244
 245     Brian Tung  <brian@isi.edu>
 246     Gene Tsudik <gts@isi.edu>
 247
 248     USC Information Sciences Institute
 249     4676 Admiralty Way Suite 1001
 250     Marina del Rey CA 90292-6695
 251     Phone: (310) 822-1511
 252