doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt

   1 INTERNET-DRAFT                                        Jonathan Trostle
   2 draft-ietf-cat-kerberos-extra-tgt-02.txt              Cisco Systems
   3 Updates: RFC 1510                                     Michael M. Swift
   4 expires January 30, 2000                              University of WA
   5
   6
   7     Extension to Kerberos V5 For Additional Initial Encryption
   8
   9 0. Status Of This Memo
  10
  11    This document is an Internet-Draft and is in full conformance
  12    with all provisions of Section 10 of RFC2026.
  13
  14    Internet-Drafts are working documents of the Internet Engineering
  15    Task Force (IETF), its areas, and its working groups.  Note that
  16    other groups may also distribute working documents as
  17    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-
  22    Drafts as reference material or to cite them other than as
  23    "work in progress."
  24
  25    The list of current Internet-Drafts can be accessed at
  26    http://www.ietf.org/ietf/1id-abstracts.txt
  27
  28    The list of Internet-Draft Shadow Directories can be accessed at
  29    http://www.ietf.org/shadow.html.
  30
  31 1. Abstract
  32
  33    This document defines an extension to the Kerberos protocol
  34    specification (RFC 1510) [1] to enable a preauthentication field in
  35    the AS_REQ message to carry a ticket granting ticket. The session
  36    key from this ticket granting ticket will be used to
  37    cryptographically strengthen the initial exchange in either the
  38    conventional Kerberos V5 case or in the case the user stores their
  39    encrypted private key on the KDC [2].
  40
  41
  42 2. Motivation
  43
  44    In Kerberos V5, the initial exchange with the KDC consists of the
  45    AS_REQ and AS_REP messages. For users, the encrypted part of the
  46    AS_REP message is encrypted in a key derived from a password.
  47    Although a password policy may be in place to prevent dictionary
  48    attacks, brute force attacks may still be a concern due to
  49    insufficient key length.
  50
  51    This draft specifies an extension to the Kerberos V5 protocol to
  52    allow a ticket granting ticket to be included in an AS_REQ message
  53    preauthentication field. The session key from this ticket granting
  54    ticket will be used to cryptographically strengthen the initial
  55
  56    exchange in either the conventional Kerberos V5 case or in the case
  57    the user stores their encrypted private key on the KDC [2]. The
  58    session key from the ticket granting ticket is combined with the
  59    user password key (key K2 in the encrypted private key on KDC
  60    option) using HMAC to obtain a new triple des key that is used in
  61    place of the user key in the initial exchange. The ticket granting
  62    ticket could be obtained by the workstation using its host key.
  63
  64 3. The Extension
  65
  66    The following new preauthentication type is proposed:
  67
  68       PA-EXTRA-TGT                         22
  69
  70    The preauthentication-data field contains a ticket granting ticket
  71    encoded as an ASN.1 octet string. The server realm of the ticket
  72    granting ticket must be equal to the realm in the KDC-REQ-BODY of
  73    the AS_REQ message. In the absence of a trust relationship, the
  74    local Kerberos client should send the AS_REQ message without this
  75    extension.
  76
  77    In the conventional (non-pkinit) case, we require the RFC 1510
  78    PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
  79    If neither it or the PA-PK-KEY-REQ preauthentication field is
  80    included in the AS_REQ message, the KDC will reply with a
  81    KDC_ERR_PREAUTH_FAILED error message.
  82
  83    We propose the following new etypes:
  84
  85      des3-cbc-md5-xor                              16
  86      des3-cbc-sha1-xor                             17
  87
  88    The encryption key is obtained by:
  89
  90    (1) Obtaining an output M from the HMAC-SHA1 function [3] using
  91        the user password key (the key K2 in the encrypted private
  92        key on KDC option of pkinit) as the text and the triple des
  93        session key as the K input in HMAC:
  94
  95        M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
  96
  97        The session key from the accompanying ticket granting ticket
  98        must be a triple des key when one of the triple des xor
  99        encryption types is used.
 100    (2) Concatenate the output M (20 bytes) with the first 8 non-parity
 101        bits of the triple-des ticket granting ticket session key to
 102        get 168 bits that will be used for the new triple-des encryption
 103        key.
 104    (3) Set the parity bits of the resulting key.
 105
 106    The resulting triple des key is used to encrypt the timestamp
 107    for the PA-ENC-TIMESTAMP preauthentication value (or in the
 108    encrypted private key on KDC option of pkinit, it is used in
 109    place of the key K2 to both sign in the PA-PK-KEY-REQ and for
 110    encryption in the PA-PK-KEY-REP preauthentication types).
 111
 112    If the KDC decrypts the encrypted timestamp and it is not within
 113    the appropriate clock skew period, the KDC will reply with the
 114    KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
 115    the above ticket granting ticket fails to decrypt properly, or if
 116    it is not a valid ticket.
 117
 118    The KDC will create the shared triple des key from the ticket
 119    granting ticket session key and the user password key (the key K2
 120    in the encrypted private key on KDC case) using HMAC as specified
 121    above and use it to validate the AS_REQ message and then to
 122    encrypt the encrypted part of the AS_REP message (use it in place
 123    of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
 124    field).
 125
 126    Local workstation policy will determine the exact behaviour of
 127    the Kerberos client with respect to the extension protocol. For
 128    example, the client should consult policy to decide when to use
 129    use the extension. This policy could be dependent on the user
 130    identity, or whether the workstation is in the same realm as the
 131    user. One possibility is for the workstation logon to fail if
 132    the extension is not used. Another possibility is for the KDC
 133    to set a flag in tickets issued when this extension is used.
 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 4. Bibliography
 145
 146    [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
 147    Service (V5). Request for Comments 1510.
 148
 149    [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
 150    Public Key Cryptography for Initial Authentication in Kerberos.
 151    ftp://ds.internic.net/internet-drafts/
 152    draft-ietf-cat-kerberos-pkinit-08.txt
 153
 154    [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
 155    Message Authentication. Request for Comments 2104.
 156
 157    [4] J. Pato. Using Pre-authentication to Avoid Password Guessing
 158    Attacks. OSF DCE SIG Request for Comments 26.0.
 159
 160 5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
 161
 162 6. Expires January 30, 2000.
 163
 164 7. Authors' Addresses
 165
 166    Jonathan Trostle
 167    170 W. Tasman Dr.
 168    San Jose, CA 95134, U.S.A.
 169
 170    Email: jtrostle@cisco.com
 171    Phone: (408) 527-6201
 172
 173    Michael Swift
 174    Email: mikesw@cs.washington.edu