oysteikt/heimdal
0
0
Fork 0
Code Issues5 Pull Requests Releases Activity

new stuff

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@7970 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Assar Westerlund
2000-02-20 22:20:49 +00:00
parent 1ca3f99bad
commit bb0a23547e
2 changed files with 495 additions and 0 deletions

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

@ -0,0 +1,174 @@
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

321
doc/standardisation/draft-ietf-cat-kerberos-set-passwd-01.txt Normal file

@ -0,0 +1,321 @@
INTERNET-DRAFT Mike Swift
draft-ietf-cat-kerberos-set-passwd-01.txt Microsoft
February 2000 Jonathan Trostle
Cisco Systems
John Brezak
Microsoft
Bill Gossman
Cybersafe
Kerberos Set/Change Password: Version 2
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Comments and suggestions on this document are encouraged. Comments
on this document should be sent to the CAT working group discussion
list:
ietf-cat-wg@stanford.edu
1. Abstract
The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]),
does not allow for an administrator to set a password for a new user.
This functionality is useful in some environments, and this proposal
extends [4] to allow password setting. The changes are: adding new
fields to the request message to indicate the principal which is
having its password set, not requiring the initial flag in the service
ticket, using a new protocol version number, and adding three new
result codes. We also extend the set/change protocol to allow a
client to send a sequence of keys to the KDC instead of a cleartext
password. If in the cleartext password case, the cleartext password
fails to satisfy password policy, the server should use the result
code KRB5_KPASSWD_POLICY_REJECT.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. The Protocol
The service must accept requests on UDP port 464 and TCP port 464 as
well. The protocol consists of a single request message followed by
a single reply message. For UDP transport, each message must be fully
contained in a single UDP packet.
For TCP transport, there is a 4 octet header in network byte order
precedes the message and specifies the length of the message. This
requirement is consistent with the TCP transport header in 1510bis.
Request Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REQ length | AP-REQ data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0x0002 (network
byte order).
AP-REQ length: length of AP-REQ data, in bytes. If the length is zero,
then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message.
AP-REQ data: (see [3]) The AP-REQ message must be for the service
principal kadmin/changepw@REALM, where REALM is the REALM of the user
who wishes to change/set his password. The ticket in the AP-REQ must
must include a subkey in the Authenticator. To enable setting of
passwords/keys, it is not required that the initial flag be set in the
Kerberos service ticket. The initial flag is required for change requests,
but not for set password requests. We have the following definitions:
old passwd initial flag target principal can be
in request? required? distinct from
authenticating principal?
change password: yes yes no
set password: no no yes
set key: no policy yes
determined
KRB-PRIV message (see [3]) This KRB-PRIV message must be generated
using the subkey from the authenticator in the AP-REQ data.
The user-data component of the message consists of the following ASN.1
structure encoded as an OCTET STRING:
ChangePasswdData :: = SEQUENCE {
newpasswdorkeys[0] NewPasswdOrKeys,
targname[1] PrincipalName OPTIONAL,
-- only present in set password: the principal
-- which will have its password set
targrealm[2] Realm OPTIONAL,
-- only present in set password: the realm for
-- the principal which will have its password set
}
NewPasswdOrKeys :: = CHOICE {
passwords[0] KeySequence,
keyseq[1] PasswordSequence
KeySequence :: = SEQUENCE {
key[0] EncryptionKey,
salt[1] OCTET STRING OPTIONAL,
salt-type[2] INTEGER OPTIONAL
}
PasswordSequence :: = SEQUENCE {
newpasswd[0] OCTET STRING,
oldpasswd[1] OCTET STRING OPTIONAL
-- oldpasswd always present for change password
-- but not set password
}
The server must verify the AP-REQ message, check whether the client
principal in the ticket is authorized to set or change the password
(either for that principal, or for the principal in the targname
field if present), and decrypt the new password/keys. The server
also checks whether the initial flag is required for this request,
replying with status 0x0007 if it is not set and should be. An
authorization failure is cause to respond with status 0x0005. For
forward compatibility, the server should be prepared to ignore fields
after targrealm in the structure that it does not understand.
The newpasswdorkeys field contains either the new cleartext password
(with the old cleartext password for a change password operation),
or a sequence of encryption keys with their respective salts.
In the cleartext password case, if the old password is sent in the
request, the request is defined to be a change password request. If
the old password is not present in the request, the request is a set
password request. The server should apply policy checks to the old
and new password after verifying that the old password is valid.
The server can check validity by obtaining a key from the old
password with a keytype that is present in the KDC database for the
user and comparing the keys for equality. The server then generates
the appropriate keytypes from the password and stores them in the KDC
database. If all goes well, status 0x0000 is returned to the client
in the reply message (see below). For a change password operation,
the initial flag in the service ticket MUST be set.
In the key sequence case, the sequence of keys is sent to the set
password service. For a principal that can act as a server, its
preferred keytype should be sent as the first key in the sequence,
but the KDC is not required to honor this preference. Application
servers should use the key sequence option for changing/setting their
keys. The set password service should check that all keys are in the
proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise.
Reply Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length | protocol version number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP_REP length | AP-REP data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ KRB-PRIV message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All 16 bit fields are in network byte order.
message length field: contains the number of bytes in the message
including this field.
protocol version number: contains the hex constant 0x0002 (network
byte order). (The reply message has the same format as in [4]).
AP-REP length: length of AP-REP data, in bytes. If the length is zero,
then the last field contains a KRB-ERROR message instead of a KRB-PRIV
message.
AP-REP data: the AP-REP is the response to the AP-REQ in the request
packet.
KRB-PRIV from [4]: This KRB-PRIV message must be generated using the
subkey in the authenticator in the AP-REQ data.
The server will respond with a KRB-PRIV message unless it cannot
validate the client AP-REQ or KRB-PRIV message, in which case it will
respond with a KRB-ERROR message. NOTE: Unlike change password version
1, the KRB-ERROR message will be sent back without any encapsulation.
The user-data component of the KRB-PRIV message, or e-data component
of the KRB-ERROR message, must consist of the following data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| result code | result string /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| edata /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
result code (16 bits) (result codes 0-4 are from [4]):
The result code must have one of the following values (network
byte order):
KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not
allowed in a KRB-ERROR message)
KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed
KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in
processing the request (for example,
there is a resource or other problem
causing the request to fail)
KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in
authentication processing
KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error
in processing the request
KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported
KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
the result string should include a text message to be presented
to the user.
KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
(only in response to a set password request).
KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
containing at least one etype that is not supported by the KDC.
The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO
type that specifies the etypes that the KDC supports:
KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
encryption-type[0] INTEGER,
salt[1] OCTET STRING OPTIONAL -- not sent
}
PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
The client should retry the request using only etypes (keytypes)
that are contained within the PKERB-ETYPE-INFO structure in the
previous response.
0xFFFF if the request fails for some other reason.
The client must interpret any non-zero result code as a failure.
result string - from [4]:
This field is a UTF-8 encoded string which should be displayed
to the user by the client. Specific reasons for a password
set/change policy failure is one use for this string.
edata: used to convey additional information as defined by the
result code.
4. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] J. Kohl, C. Neuman. The Kerberos Network Authentication
Service (V5), Request for Comments 1510.
[4] M. Horowitz. Kerberos Change Password Protocol,
ftp://ds.internic.net/internet-drafts/
draft-ietf-cat-kerb-chg-password-02.txt
5. Expiration Date
This draft expires in August 2000.
6. Authors' Addresses
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@cisco.com
Mike Swift
1 Microsoft Way
Redmond, WA 98052
Email: mikesw@microsoft.com
John Brezak
1 Microsoft Way
Redmond, WA 98052
Email: jbrezak@microsoft.com
Bill Gossman
Cybersafe Corporation
Email: bill.gossman@cybersafe.com