5f7c277829
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@12257 ec53bebd-3082-4978-b11e-865c3cabbd6b
810 lines
30 KiB
Plaintext
810 lines
30 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group Jonathan Trostle
|
||
INTERNET-DRAFT Cisco Systems
|
||
Category: Standards Track Mike Swift
|
||
University of WA
|
||
John Brezak
|
||
Microsoft
|
||
Bill Gossman
|
||
Cisco Systems
|
||
|
||
|
||
Kerberos Set/Change Password: Version 2
|
||
<draft-ietf-cat-kerberos-set-passwd-06.txt>
|
||
|
||
|
||
|
||
|
||
Status of this Memo
|
||
|
||
This document is an Internet-Draft and is in full conformance with
|
||
all provisions of Section 10 of RFC2026 [6].
|
||
|
||
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.
|
||
|
||
This draft expires on December 31st, 2001. Please send comments to
|
||
the authors.
|
||
|
||
1. Abstract
|
||
|
||
This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
|
||
protocol and a Kerberos change/set key protocol. The protocol
|
||
consists of a single request and reply message. The request message
|
||
includes both AP-REQ and KRB-PRIV submessages; the new password is
|
||
contained in the KRB-PRIV submessage which is encrypted in the
|
||
subsession key from the AP-REQ. The original Kerberos change password
|
||
protocol did not allow for an administrator to set a password for a
|
||
new user. This functionality is useful in some environments, and this
|
||
proposal allows password setting as well as password changing. The
|
||
protocol includes fields in the request message to indicate the
|
||
principal which is having its password set. We also extend the
|
||
set/change protocol to allow a client to send a sequence of keys to
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 1]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
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 RFC2119 [7].
|
||
|
||
3. Definitions from RFC 1510
|
||
|
||
We include some of the relevant ASN.1 definitions from RFC 1510 in
|
||
this section.
|
||
|
||
Realm ::= GeneralString
|
||
|
||
PrincipalName ::= SEQUENCE {
|
||
name-type[0] INTEGER,
|
||
name-string[1] SEQUENCE OF GeneralString
|
||
}
|
||
|
||
KerberosTime ::= GeneralizedTime
|
||
-- Specifying UTC time zone (Z)
|
||
|
||
HostAddress ::= SEQUENCE {
|
||
addr-type[0] INTEGER,
|
||
address[1] OCTET STRING
|
||
}
|
||
|
||
EncryptedData ::= SEQUENCE {
|
||
etype[0] INTEGER, -- EncryptionType
|
||
kvno[1] INTEGER OPTIONAL,
|
||
cipher[2] OCTET STRING -- ciphertext
|
||
}
|
||
|
||
EncryptionKey ::= SEQUENCE {
|
||
keytype[0] INTEGER,
|
||
keyvalue[1] OCTET STRING
|
||
}
|
||
|
||
Checksum ::= SEQUENCE {
|
||
cksumtype[0] INTEGER,
|
||
checksum[1] OCTET STRING
|
||
}
|
||
|
||
|
||
AP-REQ ::= [APPLICATION 14] SEQUENCE {
|
||
pvno [0] INTEGER, -- indicates Version 5
|
||
msg-type [1] INTEGER, -- indicates KRB_AP_REQ
|
||
ap-options[2] APOptions,
|
||
ticket[3] Ticket,
|
||
authenticator[4] EncryptedData
|
||
}
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 2]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
APOptions ::= BIT STRING {
|
||
|
||
reserved (0),
|
||
use-session-key (1),
|
||
mutual-required (2)
|
||
}
|
||
|
||
Ticket ::= [APPLICATION 1] SEQUENCE {
|
||
tkt-vno [0] INTEGER, -- indicates Version 5
|
||
realm [1] Realm,
|
||
sname [2] PrincipalName,
|
||
enc-part [3] EncryptedData
|
||
}
|
||
|
||
|
||
-- Encrypted part of ticket
|
||
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
|
||
flags[0] TicketFlags,
|
||
key[1] EncryptionKey,
|
||
crealm[2] Realm,
|
||
cname[3] PrincipalName,
|
||
transited[4] TransitedEncoding,
|
||
authtime[5] KerberosTime,
|
||
starttime[6] KerberosTime OPTIONAL,
|
||
endtime[7] KerberosTime,
|
||
renew-till[8] KerberosTime OPTIONAL,
|
||
caddr[9] HostAddresses OPTIONAL,
|
||
authorization-data[10] AuthorizationData OPTIONAL
|
||
}
|
||
|
||
-- Unencrypted authenticator
|
||
Authenticator ::= [APPLICATION 2] SEQUENCE {
|
||
authenticator-vno[0] INTEGER,
|
||
crealm[1] Realm,
|
||
cname[2] PrincipalName,
|
||
cksum[3] Checksum OPTIONAL,
|
||
cusec[4] INTEGER,
|
||
ctime[5] KerberosTime,
|
||
subkey[6] EncryptionKey OPTIONAL,
|
||
seq-number[7] INTEGER OPTIONAL,
|
||
authorization-data[8] AuthorizationData OPTIONAL
|
||
}
|
||
|
||
AP-REP ::= [APPLICATION 15] SEQUENCE {
|
||
pvno [0] INTEGER, -- represents Kerberos V5
|
||
msg-type [1] INTEGER, -- represents KRB_AP_REP
|
||
enc-part [2] EncryptedData
|
||
}
|
||
|
||
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
|
||
ctime [0] KerberosTime,
|
||
cusec [1] INTEGER,
|
||
subkey [2] EncryptionKey OPTIONAL,
|
||
seq-number [3] INTEGER OPTIONAL
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 3]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
}
|
||
|
||
Here is the syntax of the KRB-ERROR message:
|
||
|
||
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
|
||
pvno[0] INTEGER,
|
||
msg-type[1] INTEGER,
|
||
ctime[2] KerberosTime OPTIONAL,
|
||
cusec[3] INTEGER OPTIONAL,
|
||
stime[4] KerberosTime,
|
||
susec[5] INTEGER,
|
||
error-code[6] INTEGER,
|
||
crealm[7] Realm OPTIONAL,
|
||
cname[8] PrincipalName OPTIONAL,
|
||
realm[9] Realm, -- Correct realm
|
||
sname[10] PrincipalName, -- Correct name
|
||
e-text[11] GeneralString OPTIONAL,
|
||
e-data[12] OCTET STRING OPTIONAL
|
||
}
|
||
|
||
The KRB-PRIV message is used to send the request and reply data:
|
||
|
||
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
|
||
pvno[0] INTEGER,
|
||
msg-type[1] INTEGER,
|
||
enc-part[3] EncryptedData
|
||
}
|
||
|
||
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
|
||
user-data[0] OCTET STRING,
|
||
timestamp[1] KerberosTime OPTIONAL,
|
||
usec[2] INTEGER OPTIONAL,
|
||
seq-number[3] INTEGER OPTIONAL,
|
||
s-address[4] HostAddress,
|
||
-- sender's addr
|
||
r-address[5] HostAddress OPTIONAL
|
||
-- recip's addr
|
||
}
|
||
|
||
|
||
4. The Protocol
|
||
|
||
The service SHOULD accept requests on UDP port 464 and TCP port 464
|
||
as well. Use of other ports can significantly increase the complexity
|
||
and size of IPSEC policy rulesets in organizations that have IPSEC
|
||
capable nodes.
|
||
|
||
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
|
||
that precedes the message and specifies the length of the message.
|
||
This requirement is consistent with the TCP transport header in
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 4]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
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]) For a change password/key request, the AP-REQ
|
||
message service ticket sname, srealm principal identifier is
|
||
kadmin/changepw@REALM where REALM is the realm of the change password
|
||
service. The same applies to a set password/key request except the
|
||
principal identifier is kadmin/setpw@REALM. The authenticator in the
|
||
AP-REQ MUST contain a subsession key (which will be used to encrypt
|
||
the KRB-PRIV user data field - see below). The KDC may have stronger
|
||
pseudorandom generating capability then the clients; thus, the client
|
||
SHOULD use the session key as an input (along with additional locally
|
||
pseudorandom generated bits) into the generation of the subsession
|
||
key. 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 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 policy (*) yes
|
||
|
||
set key: no policy (*) yes
|
||
|
||
change key: no yes no
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 5]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
policy (*): implementations SHOULD allow administrators to set the
|
||
initial flag required for set requests policy to either yes or no.
|
||
Clients MUST be able to retry set requests that fail due to error 7
|
||
(initial flag required) with an initial ticket. Clients SHOULD NOT
|
||
cache service tickets targetted at kadmin/changepw.
|
||
|
||
KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
|
||
using the subsession key from the authenticator in the AP-REQ. The
|
||
authenticator MUST contain a subsession key. The timestamp and usec
|
||
fields of the KRB-PRIV message MUST be present, and the data values
|
||
MUST be copies of the same data values from the authenticator. The
|
||
recipient should ignore the sender address field in the KRB-PRIV
|
||
message.
|
||
|
||
The user-data component of the message contains the DER encoding of
|
||
the ChangePasswdData ASN.1 type described below:
|
||
|
||
ChangePasswdData ::= SEQUENCE {
|
||
passwds [0] PasswordSequence OPTIONAL,
|
||
keys [1] KeySequences OPTIONAL,
|
||
-- exactly one of the above two will be
|
||
-- present, else KRB5_KPASSWD_MALFORMED
|
||
-- error will be returned by the server.
|
||
targname[2] PrincipalName OPTIONAL,
|
||
-- only present in set password/key: the
|
||
-- principal which will have its password
|
||
-- or keys set. Not present in a set request
|
||
-- if the client principal from the ticket is
|
||
-- the principal having its passwords or keys
|
||
-- set.
|
||
targrealm[3] Realm OPTIONAL,
|
||
-- only present in set password/key: the realm
|
||
-- for the principal which will have its
|
||
-- password or keys set. Not present in a set
|
||
-- request if the client principal from the
|
||
-- ticket is the principal having its
|
||
-- passwords or keys set.
|
||
flags[4] RequestFlags OPTIONAL
|
||
-- 32 bit string
|
||
}
|
||
|
||
KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence
|
||
|
||
KeySequence ::= SEQUENCE {
|
||
key[0] EncryptionKey,
|
||
salt[1] OCTET STRING OPTIONAL,
|
||
-- depends on enc type, not currently used
|
||
salt-type[2] INTEGER OPTIONAL
|
||
-- depends on enc type, not currently used
|
||
}
|
||
|
||
PasswordSequence ::= SEQUENCE {
|
||
newpasswd[0] OCTET STRING,
|
||
oldpasswd[1] OCTET STRING OPTIONAL
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 6]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
-- oldpasswd always present for change
|
||
-- password but not present for set
|
||
-- password, set key, or change key
|
||
-- NOTE: the passwords are UTF8 strings.
|
||
}
|
||
|
||
RequestFlags ::= BIT STRING (SIZE (32..MAX))
|
||
-- reserved(0)
|
||
-- request-srv-gen-keys(1)
|
||
-- only in change/set keys
|
||
-- if the client desires
|
||
-- server to contribute to
|
||
-- keys;
|
||
-- server will return keys
|
||
|
||
|
||
The server must verify the AP-REQ message, check whether the client
|
||
principal in the ticket is authorized to set/change the password/keys
|
||
(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.
|
||
|
||
If the passwds field is present, it contains the new cleartext
|
||
password (with the old cleartext password for a change password
|
||
operation). Otherwise the keys field is present, and it contains a
|
||
sequence of encryption keys.
|
||
|
||
In the cleartext password case, if the old password is sent in the
|
||
request, the request MUST be a change password request. If the old
|
||
password is not present in the request, the request MUST be 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 change
|
||
or set password service (kadmin/changepw or kadmin/setpw
|
||
respectively). 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 change/set password services should check that all keys are
|
||
in the proper format, returning the KRB5_KPASSWD_MALFORMED error
|
||
otherwise.
|
||
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 7]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
For change/set key, the request message may include the request flags
|
||
bit string with the request-srv-gen-keys bit set. In this case, the
|
||
client is requesting that the server add entropy to its keys in the
|
||
KeySequences field. When using this option, the client SHOULD attempt
|
||
to generate pseudorandom keys with as much entropy as possible in its
|
||
request. The server will return the final key sequence in a
|
||
KeySequences structure in the edata of the reply message. The server
|
||
does not store any of the new keys at this point. The client MUST
|
||
make a subsequent change/set key request without the request-srv-
|
||
gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
|
||
second request, then the new keys have been written into the
|
||
database. A conformant server MUST support this option.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
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 the
|
||
original Kerberos change password protocol).
|
||
|
||
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. An implementation should check this field to
|
||
determine whether a KRB-ERROR message or KRB-PRIV message has been
|
||
returned.
|
||
|
||
AP-REP data: the AP-REP is the response to the AP-REQ in the request
|
||
packet. The subkey MUST be present in the AP-REP message.
|
||
|
||
KRB-PRIV message: This KRB-PRIV message must be encrypted using the
|
||
subkey from the AP-REP message. The client should ignore the sender
|
||
address (the server's address) in the KRB-PRIV message. Reflection
|
||
attacks are prevented since the subkey is used to encrypt the user-
|
||
data field of the KRB-PRIV message. The timestamp and usec fields of
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 8]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
the KRB-PRIV message MUST be present, and the data values MUST be
|
||
copies of the same data values from the AP-REP message.
|
||
|
||
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.
|
||
|
||
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 | key version (only on success) |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| result string length | result string /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| edata /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
result code (16 bits) (result codes 0-4 are the same as in the
|
||
original Kerberos change password protocol):
|
||
|
||
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_INITIALFLAG_NEEDED 7 initial flag required
|
||
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 9]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
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_WRONG_SRV 9 policy failure: the client
|
||
sent change/set key and
|
||
should have sent change/set
|
||
passwd, or vice-versa.
|
||
|
||
KRB5_KPASSWD_BAD_PRINCIPAL 10 target principal does not
|
||
exist (only in response to
|
||
a set password or set key
|
||
request).
|
||
|
||
KRB5_KPASSWD_ETYPE_NOSUPP 11 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
|
||
DER 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, client
|
||
-- may ignore if
|
||
-- 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.
|
||
|
||
KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph.
|
||
|
||
|
||
The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when
|
||
the request has the request-srv-gen-keys flag set and the
|
||
server is returning the KeySequences structure defined above in
|
||
the edata field of the reply. The server returns one key sequence
|
||
structure of the same keytype for each key sequence structure in
|
||
the client request, unless it does not support one of the
|
||
keytypes (or etypes). In that case, it returns error
|
||
KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST
|
||
add keylength number of bits of entropy to each key, where
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 10]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
keylength is the number of actual key bits in the key (minus
|
||
any parity or non-entropy contributing bits). The assumption
|
||
here is that the client may have added insufficient entropy
|
||
to the request keys. The server SHOULD use the client key from
|
||
each KeySequence structure as input into the final keyvalue for
|
||
the returned key. The client MUST make another request after
|
||
receiving a reply with this status, since no keys have been
|
||
written into the database.
|
||
|
||
0xFFFF is returned if the request fails for some other reason.
|
||
The client must interpret any non-zero result code as a failure.
|
||
|
||
key version (16 bits - optional):
|
||
Present if and only if the result
|
||
code is KRB5_KPASSWD_SUCCESS. This contains the key version of
|
||
the new key(s).
|
||
|
||
result string length (16 bits):
|
||
Gives the length of the following result string field, in bytes.
|
||
If the result string is not present, the length is zero.
|
||
|
||
result string (optional):
|
||
This field is a UTF-8 encoded string which can be displayed
|
||
to the user. Specific reasons for a password set/change policy
|
||
failure is one possible use for this string.
|
||
|
||
edata (optional):
|
||
Used to convey additional information as defined by the
|
||
result code.
|
||
|
||
5. Acknowledgements
|
||
|
||
The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
|
||
Andrea, Nicolas Williams, and other participants from the IETF
|
||
Kerberos Working Group for their input to the document.
|
||
|
||
6. Security Considerations
|
||
|
||
Password policies should be enforced to make sure that users do not
|
||
pick passwords (for change password/key) that are vulnerable to brute
|
||
force password guessing attacks.
|
||
|
||
7. 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.
|
||
|
||
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 11]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
8. Expiration Date
|
||
|
||
This draft expires on December 31st, 2001.
|
||
|
||
9. Authors' Addresses
|
||
|
||
Jonathan Trostle
|
||
Cisco Systems
|
||
170 W. Tasman Dr.
|
||
San Jose, CA 95134
|
||
Email: jtrostle@cisco.com
|
||
|
||
Mike Swift
|
||
University of Washington
|
||
Seattle, WA
|
||
Email: mikesw@cs.washington.edu
|
||
|
||
John Brezak
|
||
Microsoft
|
||
1 Microsoft Way
|
||
Redmond, WA 98052
|
||
Email: jbrezak@microsoft.com
|
||
|
||
Bill Gossman
|
||
Cisco Systems
|
||
500 108th Ave. NE, Suite 500
|
||
Bellevue, WA 98004
|
||
Email: bgossman@cisco.com
|
||
|
||
10. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implmentation may be prepared, copied, published and
|
||
distributed, in whole or in part, without restriction of any kind,
|
||
provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 12]
|
||
|
||
INTERNET DRAFT June 2001 Expires December 2001
|
||
|
||
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Trostle, Swift, Brezak, Gossman [Page 13]
|
||
|