doc/specifications/draft-ietf-cat-kerberos-extra-tgt-00.txt

   1
   2 INTERNET-DRAFT                                        Jonathan Trostle
   3 draft-ietf-cat-kerberos-extra-tgt-00.txt              Cisco Systems
   4 Updates: RFC 1510                                     Michael M. Swift
   5 expires December 24, 1998                             Microsoft
   6
   7
   8     Extension to Kerberos V5 For Additional Initial Encryption
   9
  10
  11 0. Status Of This Memo
  12
  13    This document is an Internet-Draft.   Internet-Drafts  are  working
  14    documents of the Internet Engineering Task Force (IETF), its areas,
  15    and its working groups.  Note that other groups may also distribute
  16    working documents as Internet-Drafts.
  17
  18    Internet-Drafts are draft documents valid  for  a  maximum  of  six
  19    months  and  may  be updated, replaced, or obsoleted by other docu-
  20    ments at any time.  It is inappropriate to use  Internet-Drafts  as
  21    reference  material  or  to  cite them other than as ``work in pro-
  22    gress.''
  23
  24    To view the entire list of current Internet-Drafts, please check
  25    the "1id-abstracts.txt" listing contained in the Internet-Drafts
  26    Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  27    (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
  28    (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
  29    (US West Coast).
  30
  31    The distribution of  this  memo  is  unlimited.   It  is  filed  as
  32    draft-ietf-cat-kerberos-extra-tgt-00.txt, and expires December 24,
  33    1998. Please send comments to the authors.
  34
  35
  36 1. Abstract
  37
  38    This document defines an extension to the Kerberos protocol
  39    specification (RFC 1510) [1] to enable a preauthentication field in
  40    the AS_REQ message to carry a ticket granting ticket. The session
  41    key from this ticket granting ticket will be used to
  42    cryptographically strengthen the initial exchange in either the
  43    conventional Kerberos V5 case or in the case the user stores their
  44    encrypted private key on the KDC [2].
  45
  46
  47 2. Motivation
  48
  49    In Kerberos V5, the initial exchange with the KDC consists of the
  50    AS_REQ and AS_REP messages. For users, the encrypted part of the
  51    AS_REP message is encrypted in a key derived from a password.
  52    Although a password policy may be in place to prevent dictionary
  53    attacks, brute force attacks may still be a concern due to
  54    insufficient key length.
  55
  56    This draft specifies an extension to the Kerberos V5 protocol to
  57    allow a ticket granting ticket to be included in an AS_REQ message
  58    preauthentication field. The session key from this ticket granting
  59    ticket will be used to cryptographically strengthen the initial
  60 \f
  61    exchange in either the conventional Kerberos V5 case or in the case
  62    the user stores their encrypted private key on the KDC [2]. The
  63    session key from the ticket granting ticket is combined with the
  64    user password key (key K2 in the encrypted private key on KDC
  65    option) using HMAC to obtain a new triple des key that is used in
  66    place of the user key in the initial exchange. The ticket granting
  67    ticket could be obtained by the workstation using its host key.
  68
  69
  70 3. The Extension
  71
  72    The following new preauthentication type is proposed:
  73
  74       PA-EXTRA-TGT                         22
  75
  76    The preauthentication-data field contains a ticket granting ticket
  77    encoded as an ASN.1 octet string. The server realm of the ticket
  78    granting ticket must be equal to the realm in the KDC-REQ-BODY of
  79    the AS_REQ message. In the absence of a trust relationship, the
  80    local Kerberos client should send the AS_REQ message without this
  81    extension.
  82
  83    In the conventional (non-pkinit) case, we require the RFC 1510
  84    PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
  85    If neither it or the PA-PK-KEY-REQ preauthentication field is
  86    included in the AS_REQ message, the KDC will reply with a
  87    KDC_ERR_PREAUTH_FAILED error message.
  88
  89    We propose the following new etypes:
  90
  91      des3-cbc-md5-xor                              16
  92      des3-cbc-sha1-xor                             17
  93
  94    The encryption key is obtained by:
  95
  96    (1) Obtaining an output M from the HMAC-SHA1 function [3] using
  97        the user password key (the key K2 in the encrypted private
  98        key on KDC option of pkinit) as the text and the triple des
  99        session key as the K input in HMAC:
 100
 101        M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
 102
 103        The session key from the accompanying ticket granting ticket
 104        must be a triple des key when one of the triple des xor
 105        encryption types is used.
 106    (2) Concatenate the output M (20 bytes) with the first 8 non-parity
 107        bits of the triple-des ticket granting ticket session key to
 108        get 168 bits that will be used for the new triple-des encryption
 109        key.
 110    (3) Set the parity bits of the resulting key.
 111
 112    The resulting triple des key is used to encrypt the timestamp
 113    for the PA-ENC-TIMESTAMP preauthentication value (or in the
 114    encrypted private key on KDC option of pkinit, it is used in
 115    place of the key K2 to both sign in the PA-PK-KEY-REQ and for
 116    encryption in the PA-PK-KEY-REP preauthentication types).
 117 \f
 118    If the KDC decrypts the encrypted timestamp and it is not within
 119    the appropriate clock skew period, the KDC will reply with the
 120    KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
 121    the above ticket granting ticket fails to decrypt properly, or if
 122    it is not a valid ticket.
 123
 124    The KDC will create the shared triple des key from the ticket
 125    granting ticket session key and the user password key (the key K2
 126    in the encrypted private key on KDC case) using HMAC as specified
 127    above and use it to validate the AS_REQ message and then to
 128    encrypt the encrypted part of the AS_REP message (use it in place
 129    of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
 130    field).
 131
 132    We propose to add an optional bit to the KDC database for each user
 133    to indicate whether the new preauthentication type is required.
 134
 135    A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
 136    preauthentication field containing a ticket granting ticket,
 137    a randomly generated subkey encrypted in the session key from
 138    the ticket, and a timestamp structure encrypted in the user
 139    password and then the randomly generated subkey was proposed.
 140    Some advantages of the current proposal are that the KDC has two
 141    fewer decryptions to perform per request and the client does not
 142    have to generate a random key.
 143
 144
 145 4. Bibliography
 146
 147    [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
 148    Service (V5). Request for Comments 1510.
 149
 150    [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
 151    Public Key Cryptography for Initial Authentication in Kerberos.
 152    ftp://ds.internic.net/internet-drafts/
 153    draft-ietf-cat-kerberos-pkinit-06.txt
 154
 155    [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
 156    Message Authentication. Request for Comments 2104.
 157
 158    [4] J. Pato. Using Pre-authentication to Avoid Password Guessing
 159    Attacks. OSF DCE SIG Request for Comments 26.0.
 160
 161
 162 5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
 163
 164
 165 6. Authors' Addresses
 166
 167    Jonathan Trostle
 168    170 W. Tasman Dr.
 169    San Jose, CA 95134, U.S.A.
 170
 171    Email: jtrostle@cisco.com
 172    Phone: (408) 527-6201
 173
 174    Michael Swift
 175    Microsoft
 176 \f
 177    One Microsoft Way
 178    Redmond, Washington, 98052, U.S.A.
 179
 180    Email: mikesw@microsoft.com
 181