175 lines
7.3 KiB
Plaintext
175 lines
7.3 KiB
Plaintext
INTERNET-DRAFT Jonathan Trostle
|
|
draft-ietf-cat-kerberos-extra-tgt-02.txt Cisco Systems
|
|
Updates: RFC 1510 Michael M. Swift
|
|
expires January 30, 2000 University of WA
|
|
|
|
|
|
Extension to Kerberos V5 For Additional Initial Encryption
|
|
|
|
0. 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 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."
|
|
|
|
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.
|
|
|
|
1. Abstract
|
|
|
|
This document defines an extension to the Kerberos protocol
|
|
specification (RFC 1510) [1] to enable a preauthentication field in
|
|
the AS_REQ message to carry a ticket granting ticket. The session
|
|
key from this ticket granting ticket will be used to
|
|
cryptographically strengthen the initial exchange in either the
|
|
conventional Kerberos V5 case or in the case the user stores their
|
|
encrypted private key on the KDC [2].
|
|
|
|
|
|
2. Motivation
|
|
|
|
In Kerberos V5, the initial exchange with the KDC consists of the
|
|
AS_REQ and AS_REP messages. For users, the encrypted part of the
|
|
AS_REP message is encrypted in a key derived from a password.
|
|
Although a password policy may be in place to prevent dictionary
|
|
attacks, brute force attacks may still be a concern due to
|
|
insufficient key length.
|
|
|
|
This draft specifies an extension to the Kerberos V5 protocol to
|
|
allow a ticket granting ticket to be included in an AS_REQ message
|
|
preauthentication field. The session key from this ticket granting
|
|
ticket will be used to cryptographically strengthen the initial
|
|
|
|
exchange in either the conventional Kerberos V5 case or in the case
|
|
the user stores their encrypted private key on the KDC [2]. The
|
|
session key from the ticket granting ticket is combined with the
|
|
user password key (key K2 in the encrypted private key on KDC
|
|
option) using HMAC to obtain a new triple des key that is used in
|
|
place of the user key in the initial exchange. The ticket granting
|
|
ticket could be obtained by the workstation using its host key.
|
|
|
|
3. The Extension
|
|
|
|
The following new preauthentication type is proposed:
|
|
|
|
PA-EXTRA-TGT 22
|
|
|
|
The preauthentication-data field contains a ticket granting ticket
|
|
encoded as an ASN.1 octet string. The server realm of the ticket
|
|
granting ticket must be equal to the realm in the KDC-REQ-BODY of
|
|
the AS_REQ message. In the absence of a trust relationship, the
|
|
local Kerberos client should send the AS_REQ message without this
|
|
extension.
|
|
|
|
In the conventional (non-pkinit) case, we require the RFC 1510
|
|
PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
|
|
If neither it or the PA-PK-KEY-REQ preauthentication field is
|
|
included in the AS_REQ message, the KDC will reply with a
|
|
KDC_ERR_PREAUTH_FAILED error message.
|
|
|
|
We propose the following new etypes:
|
|
|
|
des3-cbc-md5-xor 16
|
|
des3-cbc-sha1-xor 17
|
|
|
|
The encryption key is obtained by:
|
|
|
|
(1) Obtaining an output M from the HMAC-SHA1 function [3] using
|
|
the user password key (the key K2 in the encrypted private
|
|
key on KDC option of pkinit) as the text and the triple des
|
|
session key as the K input in HMAC:
|
|
|
|
M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
|
|
|
|
The session key from the accompanying ticket granting ticket
|
|
must be a triple des key when one of the triple des xor
|
|
encryption types is used.
|
|
(2) Concatenate the output M (20 bytes) with the first 8 non-parity
|
|
bits of the triple-des ticket granting ticket session key to
|
|
get 168 bits that will be used for the new triple-des encryption
|
|
key.
|
|
(3) Set the parity bits of the resulting key.
|
|
|
|
The resulting triple des key is used to encrypt the timestamp
|
|
for the PA-ENC-TIMESTAMP preauthentication value (or in the
|
|
encrypted private key on KDC option of pkinit, it is used in
|
|
place of the key K2 to both sign in the PA-PK-KEY-REQ and for
|
|
encryption in the PA-PK-KEY-REP preauthentication types).
|
|
|
|
If the KDC decrypts the encrypted timestamp and it is not within
|
|
the appropriate clock skew period, the KDC will reply with the
|
|
KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
|
|
the above ticket granting ticket fails to decrypt properly, or if
|
|
it is not a valid ticket.
|
|
|
|
The KDC will create the shared triple des key from the ticket
|
|
granting ticket session key and the user password key (the key K2
|
|
in the encrypted private key on KDC case) using HMAC as specified
|
|
above and use it to validate the AS_REQ message and then to
|
|
encrypt the encrypted part of the AS_REP message (use it in place
|
|
of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
|
|
field).
|
|
|
|
Local workstation policy will determine the exact behaviour of
|
|
the Kerberos client with respect to the extension protocol. For
|
|
example, the client should consult policy to decide when to use
|
|
use the extension. This policy could be dependent on the user
|
|
identity, or whether the workstation is in the same realm as the
|
|
user. One possibility is for the workstation logon to fail if
|
|
the extension is not used. Another possibility is for the KDC
|
|
to set a flag in tickets issued when this extension is used.
|
|
|
|
A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
|
|
preauthentication field containing a ticket granting ticket,
|
|
a randomly generated subkey encrypted in the session key from
|
|
the ticket, and a timestamp structure encrypted in the user
|
|
password and then the randomly generated subkey was proposed.
|
|
Some advantages of the current proposal are that the KDC has two
|
|
fewer decryptions to perform per request and the client does not
|
|
have to generate a random key.
|
|
|
|
4. Bibliography
|
|
|
|
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
|
|
Service (V5). Request for Comments 1510.
|
|
|
|
[2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
|
|
Public Key Cryptography for Initial Authentication in Kerberos.
|
|
ftp://ds.internic.net/internet-drafts/
|
|
draft-ietf-cat-kerberos-pkinit-08.txt
|
|
|
|
[3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
|
|
Message Authentication. Request for Comments 2104.
|
|
|
|
[4] J. Pato. Using Pre-authentication to Avoid Password Guessing
|
|
Attacks. OSF DCE SIG Request for Comments 26.0.
|
|
|
|
5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
|
|
|
|
6. Expires January 30, 2000.
|
|
|
|
7. Authors' Addresses
|
|
|
|
Jonathan Trostle
|
|
170 W. Tasman Dr.
|
|
San Jose, CA 95134, U.S.A.
|
|
|
|
Email: jtrostle@cisco.com
|
|
Phone: (408) 527-6201
|
|
|
|
Michael Swift
|
|
Email: mikesw@cs.washington.edu
|