| blob | 3a923d00d408853f0bffd98d0890da6645fb011c |
2 Kerberos Working Group Nicolas Williams
3 INTERNET-DRAFT Sun Microsystems
4 Expires: August 22, 2005 February 21, 2005
9 Kerberos Set/Change Password: Version 2
10 <draft-ietf-krb-wg-kerberos-set-passwd-03.txt>
12 Status of this Memo
14 By submitting this Internet-Draft, I certify that any applicable
15 patent or other IPR claims of which I am aware have been disclosed,
16 and any of which I become aware will be disclosed, in accordance with
17 RFC 3668.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as
22 Internet-Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on August 22, 2005.
37 Copyright Notice
39 Copyright (C) The Internet Society (2005). All Rights Reserved.
41 Abstract
43 This document specifies an extensible protocol for setting keys and
44 changing the passwords of Kerberos V principals.
46 Table of Contents
48 1 Introduction
49 2 The Protocol
50 2.1 Transports
51 2.2 Protocol Framing
52 2.3 Protocol version negotiation
53 2.3.1 Protocol Major Version Negotiation
54 2.3.2 Protocol Minor Version Negotiation
55 2.4 Use of Kerberos V
57 N. Williams [Page 1]
58 \f
60 DRAFT Kerberos Set/Change Password v2 Expires January 2005
62 2.5 Use of ASN.1
63 2.6 Internationalization
64 2.6.1 Normalization Forms for UTF-8 Strings
65 2.6.2 Language Negotiation
66 2.7 Protocol Extensibility
67 2.8 Protocol Subsets
68 3 Protocol Elements
69 3.1 PDUs
70 3.2 Operations
71 3.2.1 Null
72 3.2.2 Change Kerberos Password
73 3.2.3 Set Kerberos Password
74 3.2.4 Set Kerberos Keys
75 3.2.5 Generate Kerberos Keys
76 3.2.6 Get New Keys
77 3.2.7 Commit New Keys
78 3.2.8 Get Password Quality Policy
79 3.2.9 Get Principal Aliases
80 3.2.10 Get Realm's Supported Kerberos V Version and Features
81 4 ASN.1 Module
82 6 IANA Considerations
83 7 Security Considerations
84 8 Acknowledgements
85 9 References
86 9.1 Normative References
87 9.2 Informative References
88 10 Authors' Addresses
89 11 Notes to the RFC Editor
91 Conventions used in this document
93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
95 document are to be interpreted as described in [RFC2119].
97 1 Introduction
99 Up to this point Kerberos V has lacked a single, standard protocol
100 for changing passwords and keys. While several vendor-specific
101 protocols exist for changing Kerberos passwords/keys, none are
102 properly internationalized and all are incomplete in one respect or
103 another and none are sufficiently extensible to cope with new
104 features that may be added to Kerberos V at some future time.
106 This document defines a protocol that is somewhat backward-compatible
107 with the "kpasswd" protocol defined in [RFC3244] that uses more or
108 less the same protocol framing.
110 This new protocol is designed to be extensible and properly
111 internationalized.
113 2 The Protocol
116 N. Williams [Page 2]
117 \f
119 DRAFT Kerberos Set/Change Password v2 Expires January 2005
121 The structure of the protocol is quite similar to that of typical RPC
122 protocols. Each transaction consists of a data structure specific to
123 an operation which is then wrapped in a data structure which is
124 general to all operations of the protocol. These data structures are
125 defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
126 are encoded using the Distinguished Encoding Rules (DER) [X690].
128 All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
129 KRB-ERROR, and framed in a header that is backwards compatible with
130 [RFC3244].
132 2.1 Transports
134 The service supports only connection-oriented transports,
135 specifically TCP, and MUST accept requests on TCP port 464, the same
136 as in [RFC3244].
138 2.2 Protocol Framing
140 Requests and responses are exchanged using the same framing as in
141 [RFC3244], but with the following differences:
143 - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
145 - the 'AP-REQ length' field of the request can be set to 0x0, in
146 which case the 'AP-REQ' field of the request is excluded
148 - the 'KRB-PRIV' field of the request and reply is mutually
149 exclusive with the 'AP-REQ' field of the request
151 - the 'AP-REP length' field of the reply can be set to 0x0, in
152 which case the 'AP-REP' field of the reply is excluded
154 - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
155 be or has been accepted by the server
157 - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
158 of the reply
160 The initial message from the client MUST carry an AP-REQ and the
161 response to any request bearing an AP-REQ MUST carry an AP-REP or
162 MUST be a KRB-ERROR.
164 Subsequent messages exchanged on the same TCP connection MAY involve
165 Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
166 a new AP exchange except when it desires to authenticate as a
167 different principal, when the ticket last used for authentication
168 expires or when the server responds with an error indicating that the
169 client must re-authenticate.
171 2.3 Protocol Version Negotiation
173 There are several major versions of this protocol. Version 2 also
175 N. Williams [Page 3]
176 \f
178 DRAFT Kerberos Set/Change Password v2 Expires January 2005
180 introduces a notion of protocol minor versions for use in negotiating
181 protocol extensions. As of this time only one minor version is
182 defined for major version 2: minor version 0, defined herein.
184 2.3.1 Protocol Major Version Negotiation
186 Version 2 clients that also support other versions, such as 0xff80,
187 as in [RFC3244], SHOULD attempt to use version 2 of the protocol
188 first.
190 Servers which do not support version 2 of this protocol typically
191 include their preferred version number in the reply and/or may
192 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
193 status code of KRB5_KPASSWD_MALFORMED.
195 Note that some [RFC3244] server implementations close the TCP
196 connection without returning any other response. Note also that
197 there is no integrity protection for the major version number in the
198 protocol framing or for any data in a KRB-ERROR.
200 As a result change password protocol major version negotiation is
201 subject to downgrade attacks. Therefore major version negotiation is
202 NOT RECOMMENDED.
204 Where the server indicates that it does not support version 2, the
205 client MAY, but SHOULD NOT, unless configured to do so, fall back on
206 another major version of this protocol.
208 Version 2 servers MAY respond to non-v2 requests using whatever
209 response is appropriate for the versions used by the clients, but if
210 a server does not do this or know how to do this then it MUST respond
211 with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
212 if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
213 using a ProtocolErrorCode value of unsupported-major-version.
215 It is expected that implementations of as yet unspecified future
216 major versions of this protocol will be required to support version 2
217 integrity protected error replies for properly indicating no support
218 for version 2 of the protocl. We also hope that no further major
219 versions of this protocol will be needed.
221 2.3.2 Protocol Minor Version Negotiation
223 Version 2 clients are free to use whatever protocol minor version and
224 message extensions are available to them in their initial messages to
225 version 2 servers, provided that the minor versions (other than 0)
226 have been defined through IETF documents.
228 Version 2 servers MUST answer with the highest protocol minor version
229 number supported by the server and the client.
231 Version 2 clients MUST use the protocol minor version used in a
232 server's reply for any subsequent messages in the same TCP session.
234 N. Williams [Page 4]
235 \f
237 DRAFT Kerberos Set/Change Password v2 Expires January 2005
240 See section 2.7 for further description of the protocol's
241 extensibility and its relation to protocol minor versions and the
242 negotiation thereof.
244 2.4 Use of Kerberos V and Key Exchange
246 This protocol makes use of messages defined in [RFC1510] and
247 [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and
248 KRB-PRIV.
250 All operations are to be performed by the server on behalf of the
251 client principal.
253 Clients SHOULD use "kadmin/setpw" as the principal name of the server
254 for all requests except when changing the client principal's own
255 expired password, for which they should use "kadmin/changepw". The
256 "kadmin/changepw" service exists to allow KDCs to limit principals
257 with expired passwords to getting initial tickets to the password
258 changing service only and only for changing expired passwords.
260 Servers MUST limit clients that used the "kadmin/changepw" service
261 principal name to changing the password of the client principal.
263 The client MUST request mutual authentication and the client MUST
264 MUST request the use of sequence numbers.
266 Clients SHOULD use INITIAL tickets for requests whose target
267 principal is the client's principal. Servers SHOULD force the use of
268 INITIAL tickets for such requests and MAY force the use of INITIAL
269 for all others - see section 3.2.
271 Servers MUST specify a sub-session key.
273 The encrypted part of KRB-PRIVs MUST be encrypted with the server's
274 sub-session key and key usage 20 (client->server) or 21
275 (server->client).
277 After each new AP exchange the client and server MUST destroy the
278 session keys, if any, resulting from the previous AP exchange.
280 2.5 Use of ASN.1
282 This protocol's messages are defined in ASN.1, using only features
283 from [X680]. All ASN.1 types defined herein are to be encoded in
284 DER [X690]. A complete ASN.1 module is given in section 4.
286 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
287 KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
289 2.6 Internationalization
291 This protocol's request PDU carries an optional field indicating the
293 N. Williams [Page 5]
294 \f
296 DRAFT Kerberos Set/Change Password v2 Expires January 2005
298 languages spoken by the client user; the client SHOULD send its list
299 of spoken languages to the server (once per-TCP session).
301 The server SHOULD localize all strings intended for display to users
302 to a language in common with the languages spoken by the client user.
304 Strings for Kerberos principal and realm names used in this protocol
305 are be constrained as per [clarifications].
307 2.6.1 Normalization Forms for UTF-8 Strings
309 Because Kerberos V [clarifications] restricts principal names, realm
310 names and passwords to IA5String, this protocol uses UTF8String with
311 an extensible constraint to IA5String.
313 Future versions of Kerberos may relax this constraint; if so then a
314 minor version of this protocol should relax this constraint
315 accordingly.
317 2.6.2 Language Negotiation
319 The server MUST pick a language from the client's input list or
320 the default language tag (see [RFC3066]) for text in its responses
321 which is meant for the user to read.
323 The server SHOULD use a language selection algorithm such that
324 consideration is first given to exact matches between the client's
325 spoken languages and the server's available locales, followed by
326 "fuzzy" matches where only the first sub-tags of the client's
327 language tag list are used for matching against the servers available
328 locales.
330 Servers MUST cache the optional language tag lists from prior
331 requests for use with subsequent requests that exclude the language
332 tag list. Clients MAY expect such server behaviour and send the
333 language tag lists only once per-TCP session. Clients SHOULD send
334 the server the language tag list at least once.
336 When the server has a message catalog for one of the client's spoken
337 languages the server SHOULD localize any text strings intended for
338 display to users.
340 2.7 Protocol Extensibility
342 The protocol is defined in ASN.1 and uses extensibility markers
343 throughout. As such, the module presented herein can be extended
344 within the framework of [X680].
346 Typed holes are not used in this protocol as it is very simple and
347 does not require the ability to deal with abstract data types defined
348 in different layers. For this reason, the only way to extend this
349 protocol is by extending the ASN.1 module within the framework of the
350 IETF; all future extensions to this protocol have to be defined in
352 N. Williams [Page 6]
353 \f
355 DRAFT Kerberos Set/Change Password v2 Expires January 2005
357 IETF documents unless otherwise specified in a future IETF revision
358 of this protocol.
360 A protocol minor version number is used to negotiate use of
361 extensions. See section 2.3.2 for the minor version negotiation.
363 Servers SHOULD ignore unknown additions to the ASN.1 types, in
364 initial requests, where the syntax allows them, except for extensions
365 to the "Op-req" type, which MUST result in an error.
367 Servers MUST respond with an error (ProtocolErrorCode value of
368 unsupported-minor-version) to clients that use operations unknown to
369 the server.
371 2.8 Protocol Subsets
373 The structure of the protocol is such that the ASN.1 syntaxes for the
374 various operations supported by the protocol are independent of the
375 each other. Client and server implementations MAY implement subsets
376 of the overall protocol by removing some alternatives to the Op-req,
377 Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
379 For example, it should be possible to have a password-change only
380 client that cannot set principal's keys - and vice versa.
382 3 Protocol Elements
384 The protocol as defined herein supports the following operations
385 relating to the management of Kerberos principal's passwords or keys:
387 [NOTE: New since last version of this I-D.]
388 - get principal's current and preferred string-to-key parameters
390 - change password (or enctypes and string-to-key parameters)
391 - set password (administrative)
392 - set new keys
393 - generate new keys
394 - get new, un-committed keys
395 - commit new keys
396 - get password policy name and/or description of principal
397 - list aliases of a principal
398 - list enctypes and version of Kerberos V supported by realm
400 The operation for retrieving a list of aliases of a principal is
401 needed where KDCs implement aliasing of principal names and allows
402 clients to properly setup their key databases when principal aliasing
403 is in use.
405 Operations such as creation or deletion of principals are outside the
406 scope of this document, and should be performed via other means, such
407 as through directories or other Kerberos administration protocols.
409 The individual operations are described in section 3.2.
411 N. Williams [Page 7]
412 \f
414 DRAFT Kerberos Set/Change Password v2 Expires January 2005
417 3.1 PDUs
419 The types "Request," "Response" and "Error-Response" are the ASN.1
420 module's PDUs.
422 The "Request" and "Response" PDUs are always to be sent wrapped in
423 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
424 sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
425 otherwise it MUST be sent wrapped in a KRB-PRIV.
427 The ASN.1 syntax for the PDUs is given in section 4.
429 Note that the first field of each PDU is the major version of the
430 protocol, defaulted to 2, meaning that it is never included in
431 version 2 exchanges. Similarly, the second field of each PDU is the
432 minor version, defaulted to 0.
434 The request, responses and error PDUs consist of an outer structure
435 ("Request," "Response" and "Error-Response") containing fields common
436 to all requests, responses and errors, respectively, and an inner
437 structure for fields that are specific to each operation's
438 requests/responses. The inner structure is optional in the case of
439 the Error-Response PDU and need not be included when generic errors
440 occur for which there is a suitable ProtocolErrorCode.
442 Specifically, the outer Request structure has a field for passing a
443 client user's spoken (read) languages to the server. It also has two
444 optional fields for identifying the requested operation's target
445 principal's name and realm (if not sent then the server MUST use the
446 client's principal name and realm as the target). A boolean field
447 for indicating whether or not the request should be dry-run is also
448 included; dry-runs can be used to test server policies, and servers
449 MUST NOT modify any principals when processing dry-run requests.
451 The Response and Error PDUs' outer structures include a field
452 indicating the language that the server has chosen for localization
453 of text intended to be displayed to users; this field is defaulted to
454 "i-default". This language tag applies to all UTF8 strings in the
455 inner structure (Op-rep and Op-err) that are meant to be displayed to
456 users.
458 The protocol error codes are:
460 - proto-generic-error
462 An operation-specific error ocurred, see the inner Op-error.
464 - proto-format-error
465 - proto-unsupported-major-version
466 - proto-unsupported-minor-version
467 - proto-unsupported-operation
470 N. Williams [Page 8]
471 \f
473 DRAFT Kerberos Set/Change Password v2 Expires January 2005
475 - proto-wrong-service-principal
477 Use kadmin/setpw for the server's principal name.
479 - proto-re-authentication-required
481 The server demands that the client re-authenticate through a new
482 AP exchange.
484 - proto-initial-ticket-required
486 Use of an INITIAL ticket is required for the requested
487 operation.
489 - proto-client-and-target-realm-mismatch
491 The server requires that the client's principal name and the
492 target principal of the operation share the same realm name.
494 - proto-target-principal-unknown
495 - proto-authorization-failed
497 3.2 Operations
499 This section describes the semantics of each operation request and
500 response defined in the ASN.1 module in section 4.
502 3.2.1 Null
504 NAME
506 null - Null or "ping" operation
508 DESCRIPTION
510 The null request is intended for use with TCP; its purpose is
511 similar to RPC null procedures and is akin to a "ping" operation.
513 ERRORS
515 None.
517 3.2.2 Change Kerberos Password
519 NAME
521 change-pw - Change password operation
523 SYNOPSIS
525 Req-change-pw(old-pw, [languages], [new-pw],
526 [commit], [etypes]) ->
527 Rep-change-pw([info-text], [new-pw], [etypes]) |
529 N. Williams [Page 9]
530 \f
532 DRAFT Kerberos Set/Change Password v2 Expires January 2005
534 Err-change-pw([help-text], error code, [error info])
536 DESCRIPTION
538 Change a principal's password.
540 The change password request has one required, three optional and
541 one defaulted arguments: "old-pw" (required), "languages,"
542 "new-pw", "commit" (defaults to "TRUE") and "etypes",
543 corresponding to the target principal's old password, its
544 preferred languages, its new password, a boolean indicating
545 whether or not to make the new long-term key available for
546 immediate use, and the desired enctypes for the new long-term
547 keys.
549 The server MUST validate the old password and MUST check the
550 quality of the new password, if sent, according the password
551 quality policy associated with the target principal.
553 If the old and new passwords in the request are the same strings,
554 and the principal is not currently required to change its
555 password, then the server MAY permit the password change as way to
556 change a principal's enctypes and string-to-key parameters. This
557 feature provides a way to, for example, add enctypes to a
558 principals' password-derived long-term keys without forcing a
559 password change following an upgrade to the KDC that adds support
560 for new enctypes.
562 A client MAY request that the server generate a new password by
563 excluding the new password from its request, in which case the
564 server MUST either generate a new password or respond with an
565 error indicating that it does not support this feature.
567 Server-generated passwords MUST meet the target principal's
568 password quality policy. It is RECOMMENDED that server-generated
569 passwords be user-friendly, that is, memorable and that the target
570 principal's preferred languages be taken into account by the
571 password generation alogrithm used by the server.
573 Uncommitted password changes are commited using the commit-keys
574 operation.
576 RETURN
578 Upon successful password changes the server responds with a
579 Rep-change-pw. The fields of Rep-change-pw are all optional and
580 include:
582 - 'info-text' which the server can use to send a message to the
583 user such as "Your new password will expire in 90 days," for
584 example.
586 - 'new-pw' which the server MUST include if the client
588 N. Williams [Page 10]
589 \f
591 DRAFT Kerberos Set/Change Password v2 Expires January 2005
593 requested that the server generate a new password; generated
594 passwords MUST pass the target principal's password quality
595 policy.
597 - 'etypes' which the server MAY include to indicate which types
598 of long-term keys it created for the target principal and
599 which the server MUST include if the client specified a set
600 of enctypes in its request.
602 ERRORS
604 The server may respond to change password requests with protocol
605 or operation errors. See section 3.1 for a description of
606 protocol error codes.
608 All operation errors include an optional 'help-text' field by
609 which the server can describe the error in a human-readable,
610 localizaed string.
612 Change password error codes include:
614 - generic-error
616 - old-pw-incorrect
618 - wont-generate-new-pw
620 The server will not generate a new password for this
621 principal or does not support password generation in general.
623 - new-pw-rejected-generic
625 The client's proposed new password failed the target
626 principal's password quality policy.
628 The server MUST include a description of the password quality
629 policy or aspect of it that the client's proposed new
630 password failed to meet.
632 The server MAY generate and send a new password that the
633 client can then use as a new password and which is guaranteed
634 to pass the target principal's current password quality
635 policy.
637 The server MAY include a set of policy error code hints.
639 - etype-not-supported
641 The client requested an enctype that the KDC does not
642 support.
644 3.2.3 Set Kerberos Password
647 N. Williams [Page 11]
648 \f
650 DRAFT Kerberos Set/Change Password v2 Expires January 2005
652 NAME
654 set-pw - Set password operation
656 SYNOPSIS
658 Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
659 Rep-set-pw([info-text], [new-pw], [etypes]) |
660 Err-set-pw([help-text], error code, [error info])
662 DESCRIPTION
664 Administratively set a principal's password.
666 The set password request has three optional and one defaulted
667 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
668 and "etypes", corresponding to the target principal's preferred
669 languages, new password, a boolean indicating whether or not to
670 make the new long-term key available for immediate use, and the
671 desired enctypes for the new long-term keys.
673 The server MUST check the quality of the new password, if sent,
674 according the password quality policy associated with the target
675 principal.
677 The server SHOULD require that the client use the change-pw
678 operation instead of set-pw when the client principal and the
679 target principal are the same.
681 A client MAY request that the server generate a new password by
682 excluding the new password from its request, in which case the
683 server MUST either generate a new password or respond with an
684 error indicating that it does not support this feature.
686 Server-generated passwords MUST meet the target principal's
687 password quality policy. It is RECOMMENDED that server-generated
688 passwords be user-friendly, that is, memorable and that the target
689 principal's preferred languages be taken into account by the
690 password generation alogrithm used by the server.
692 RETURN
694 Upon successfully setting a password the server responds with a
695 Rep-set-pw. The fields of Rep-set-pw are all optional and
696 include:
698 - 'info-text' which the server can use to send a message to the
699 user such as "Your new password will expire in 90 days," for
700 example.
702 - 'new-pw' which the server MUST include if the client
703 requested that the server generate a new password; generated
704 passwords MUST pass the target principal's password quality
706 N. Williams [Page 12]
707 \f
709 DRAFT Kerberos Set/Change Password v2 Expires January 2005
711 policy.
713 - 'etypes' which the server MAY include to indicate which types
714 of long-term keys it created for the target principal and
715 which the server MUST include if the client specified a set
716 of enctypes in its request.
718 ERRORS
720 The server may respond to set password requests with protocol or
721 operation errors. See section XYZ for a description of protocol
722 error codes.
724 All operation errors include an optional 'help-text' field by
725 which the server can describe the error in a human-readable,
726 localizaed string.
728 Set password error codes include:
730 - generic-error
732 - use-change-pw
734 The server demands that the client use the change-pw
735 operation for the target principal of the set-pw request.
737 - wont-generate-new-pw
739 The server will not generate a new password for this
740 principal or does not support password generation in general.
742 - new-pw-rejected-generic
744 The client's proposed new password failed the target
745 principal's password quality policy.
747 The server MUST include a description of the password quality
748 policy or aspect of it that the client's proposed new
749 password failed to meet.
751 The server MAY generate and send a new password that the
752 client can then use as a new password and which is guaranteed
753 to pass the target principal's current password quality
754 policy.
756 The server MAY include a set of policy error code hints.
758 - etype-not-supported
760 The client requested an enctype that the KDC does not
761 support.
763 3.2.4 Set Kerberos Keys
765 N. Williams [Page 13]
766 \f
768 DRAFT Kerberos Set/Change Password v2 Expires January 2005
771 NAME
773 set-keys
775 SYNOPSIS
777 Req-set-keys(new-keys, commit?, [isupport]) ->
778 Rep-set-keys([info-text], kvno, aliases, [isupport])
780 DESCRIPTION
782 The set-keys request consists of two required fields and one
783 optional field: "new-keys", "commit" (a boolean field - see below)
784 and "isupport", an optional field for indicating to the KDC what
785 Kerberos V features are supported by the target principal.
787 When "commit" is true the KDC makes the new keys available for
788 issueing tickets encrypted in them immediately. Otherwise the
789 client MUST follow up with a commit-keys request to make the keys
790 available. This feature is useful for changing keys shared by
791 multiple hosts, in clustered services, for example, in an atomic
792 manner; see section 3.2.6 and 3.2.7.
794 If a principal has keys are awaiting commitment when a new
795 set-keys request for that principal s made then the KDC MUST
796 overwrite the deferred keys.
798 RETURN
800 For successful set-keys operations the server returns:
802 - Informational text, optional.
804 - The new kvno for the target principal.
806 - A list of aliases of the target principal known to the KDC
807 (optional).
809 - The set of Kerberos V features supported by the KDC
810 (optional).
812 ERRORS
814 The server may respond with the following errors:
816 - generic
817 - deferred-commit-no-support
818 - etype-no-support
820 3.2.5 Generate Kerberos Keys
822 NAME
824 N. Williams [Page 14]
825 \f
827 DRAFT Kerberos Set/Change Password v2 Expires January 2005
830 gen-keys
832 SYNOPSIS
834 Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
835 Rep-set-keys([info-text], key, kvno, aliases, [isupport])
837 DESCRIPTION
839 The gen-keys is similar to the set-keys request (see section
840 3.2.4) but differs in that the server generates keys of
841 client-requested enctypes, rather than the client providing
842 specific keys.
844 The gen-keys request consists of two required fields and two
845 optional fields: "etypes" (the enctypes of the new keys),
846 "entropy", "commit" and "isupport" (see section 3.2.4).
848 If a principal has keys are awaiting commitment when a new
849 set-keys request for that principal s made then the KDC MUST
850 overwrite the deferred keys.
852 RETURN
854 For successful set-keys operations the server returns:
856 - Informational text, optional.
858 - The new kvno for the target principal.
860 - The new key (only one is needed).
862 - A list of aliases of the target principal known to the KDC
863 (optional).
865 - The set of Kerberos V features supported by the KDC
866 (optional).
868 ERRORS
870 The server may respond with the following errors:
872 - generic
873 - deferred-commit-no-support
874 - etype-no-support
876 3.2.6 Get New Keys
878 NAME
880 get-keys
883 N. Williams [Page 15]
884 \f
886 DRAFT Kerberos Set/Change Password v2 Expires January 2005
888 SYNOPSIS
890 Req-get-keys(kvno) ->
891 Rep-get-keys([info-text], keys, aliases, [isupport]) |
892 Err-get-keys([help-text], error code, [error info])
894 DESCRIPTION
896 This request allows a client to get the keys set or generated in a
897 previous set-keys or gen-keys request with deferred commitment..
899 RETURN
901 If the target principal and kvno correspond to uncommitted keys
902 the server MUST respond with the actual keys that would be set by
903 a subsequent commit-keys request. Otherwise the server MUST
904 respond with an error (meaning that this operation cannot be used
905 to extract keys from the KDC that may be in use).
907 ERRORS
909 - generic
910 - kvno-committed
911 - no-such-kvno
913 3.2.7 Commit New Keys
915 NAME
917 commit-keys
919 SYNOPSIS
921 Req-commit-keys(kvno) ->
922 Rep-commit-keys() |
923 Err-commit-keys([help-text], error code, [error info])
925 DESCRIPTION
927 The commit-keys operation allows a client to bring a principal's
928 new keys into use at the KDC.
930 Clients should make a commit-keys request corresponding to a
931 deferred commitment set-keys/gen-keys operation as soon as the
932 local key database for the target principal is updated.
934 The target principal name and the kvno MUST match those from a
935 prior set-keys or gen-keys operation.
937 Servers MAY expire delayed key commitments at will. Servers
938 SHOULD expire uncommitted new keys after a reasonable amount of
939 time (600 seconds is RECOMMENDED).
942 N. Williams [Page 16]
943 \f
945 DRAFT Kerberos Set/Change Password v2 Expires January 2005
947 Servers MUST respond to new set-keys requests for principals with
948 pending, uncommitted new keys by expiring the uncommitted new keys
949 and proceeding as if there had been no expired new keys.
951 ERRORS
953 - generic
954 - op-kvno-expired
955 - op-kvno-unknown
956 - new-keys-conflict (A set-keys or gen-keys request succeeded
957 subsequent to the request that matches this
958 {principal, kvno} tuple.)
960 3.2.8 Get Password Quality Policy
962 NAME
964 get-pw-policy
966 SYNOPSIS
968 Req-get-pw-policy() ->
969 Rep-get-pw-policy([policy name], [policy description])
971 DESCRIPTION
973 Returns a description of the target principal's associated
974 password quality policy, if any, as a list of localized
975 UTF8String values.
977 Clients can use this operation in conjunction with the change-pw
978 operation to obtain text that can be displayed to the user before
979 the user actually enters a new password.
981 It is common for sites to set policies with respect to password
982 quality. It is beyond the scope of this document to describe such
983 policies. Management of password quality policies' actual content
984 is also beyond the scope of this protocol.
986 ERRORS
988 No operation errors are defined.
991 3.2.9 Get Principal Aliases
993 NAME
995 get-print-aliases
997 SYNOPSIS
999 Req-get-princ-aliases() ->
1001 N. Williams [Page 17]
1002 \f
1004 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1006 Rep-get-princ-aliases(aliases)
1008 DESCRIPTION
1010 Returns a list of aliases of the target principal.
1012 ERRORS
1014 No operation-specific errors.
1016 3.2.10 Get Realm's Supported Kerberos V Version and Features
1018 NAME
1020 get-realm-krb5-support
1022 SYNOPSIS
1024 Req-get-realm-krb5-support() ->
1025 Rep-get-realm-krb5-support(isupport)
1027 DESCRIPTION
1029 Returns set of Kerberos V features support by the target
1030 principal's realm's KDCs.
1032 ERRORS
1034 No operation-specific errors.
1036 3.2.11 Retrieve Principal's S2K Params and Preferred Params
1038 NAME
1040 get-s2kparams
1042 SYNOPSIS
1044 Req-get-s2kparams() ->
1045 Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
1047 DESCRIPTION
1049 Returns the string2key parameters for the principal's current
1050 password-derived long-term keys, if any, and the parameters that
1051 the realm would prefer, if they differ from the former.
1053 This operation is intended for use with the change-pw() operation.
1054 When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
1055 the principal's long-term secret keys' string2key parameters (and
1056 enctype list) should be changed and, if so, change them.
1058 If the 'princ-s2kparams' return value is missing then the
1060 N. Williams [Page 18]
1061 \f
1063 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1065 principal does not have a password-derived long-term key.
1067 The 'preferred-s2kparams' MUST be excluded if the principal's
1068 string2key parameters satisfy the realm's policy.
1070 ERRORS
1072 No operation-specific errors.
1074 3.3 Principal Aliases
1076 Applications that use Kerberos often have to derive acceptor
1077 principal names from hostnames entered by users. Such hostnames may
1078 be aliases, they may be fully qualified, partially qualified or not
1079 qualified at all. Some implementations have resorted to deriving
1080 principal names from such hostnames by utilizing the names services
1081 to canonicalize the hostname first; such practices are not secure
1082 unless the name service are secure, which often aren't.
1084 One method for securely deriving principal names from hostnames is to
1085 alias principals at the KDC such that the KDC will issue tickets for
1086 principal names which are aliases of others. It is helpful for
1087 principals to know what are their aliases as known by the KDCs.
1089 Note that changing a principal's aliases is out of scope for this
1090 protocol.
1092 3.4 Kerberos V Feature Negotiation
1094 Principals and realms' KDCs may need to know about additional
1095 Kerberos V features and extensions that they each support. Several
1096 operations (see above) provide a way for clients and servers to
1097 exchange such infomration, in the form of lists of types supported
1098 for the various typed holes used in Kerberos V.
1100 4 ASN.1 Module
1102 DEFINITIONS EXPLICIT TAGS ::= BEGIN
1103 --
1104 -- Note: EXPLICIT tagging is in use by default throughout this
1105 -- module.
1107 -- From [clarifications] with modifications
1108 PrincipalName ::= SEQUENCE {
1109 name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
1110 }
1111 Realm ::= UTF8String (IA5String, ...)
1112 Salt ::= UTF8String (IA5String, ...)
1113 Password ::= UTF8String (IA5String, ...)
1115 -- NOTE WELL: Principal and realm names MUST be constrained by the
1116 -- specification of the version of Kerberos V used by the
1117 -- client.
1119 N. Williams [Page 19]
1120 \f
1122 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1124 --
1125 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
1126 -- type and a UTF8String, for simplicity.]
1128 -- From [clarifications]
1129 Int32 ::= INTEGER (-2147483648..2147483647)
1130 UInt32 ::= INTEGER (0..4294967295)
1132 -- Based on [clarifications]
1133 Etype ::= Int32
1134 Etype-Info-Entry ::= SEQUENCE {
1135 etype [0] Etype,
1136 salt [1] Salt OPTIONAL,
1137 s2kparams [2] OCTET STRING OPTIONAL,
1138 ...
1139 }
1140 Key ::= SEQUENCE {
1141 enc-type [0] Etype, -- from Kerberos
1142 key [1] OCTET STRING,
1143 ...
1144 }
1146 Language-Tag ::= UTF8String -- Constrained by [RFC3066]
1148 -- Empty, extensible SEQUENCEs are legal ASN.1
1149 Extensible-NULL ::= SEQUENCE {
1150 ...
1151 }
1153 -- Kerberos clients negotiate some parameters relating to their peers
1154 -- indirectly through the KDC. Today this is true of ticket session
1155 -- key enctypes, but in the future this indirect negotiation may also
1156 -- occur with respect to the minor version of Kerberos V to be used
1157 -- between clients and servers. Additionally, KDCs may need to know
1158 -- what authorization-data types are supported by service principals,
1159 -- both, for compatibility with legacy software and for optimization.
1160 --
1161 -- Thesefore it is important for KDCs to know what features of
1162 -- Kerberos V each service principal supports.
1163 --
1164 -- In version 2.0 of this protocol the clients and servers may notify
1165 -- each other of their support for:
1166 --
1167 -- - enctypes
1168 -- - authorization data types
1169 -- - transited encoding data types
1170 --
1171 -- All authorization-data types defined in [clarifications] are
1172 -- assumed to be supported if the minor version is 1 and do not need
1173 -- to be included in the ad-type list.
1174 --
1175 -- Int32 is used for enctype and transited encoding data type
1176 -- identifiers.
1178 N. Williams [Page 20]
1179 \f
1181 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1183 --
1184 -- An extensible CHOICE of Int32 is used for authorization data
1185 -- types.
1187 KerberosV-TR-ID ::= Int32
1189 KerberosV-AD-ID ::= CHOICE {
1190 ad-int [0] Int32,
1191 ...
1192 }
1194 KerberosVSupportNego ::= SEQUENCE {
1195 enc-types [0] SEQUENCE OF Etype,
1196 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
1197 -- authorization data types
1198 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
1199 -- transited encoding types
1200 ...
1201 }
1203 Request ::= [APPLICATION 0] SEQUENCE {
1204 pvno-minor [0] INTEGER DEFAULT 0,
1205 languages [1] SEQUENCE OF Language-Tag OPTIONAL,
1206 -- Should be defaulted to the SEQUENCE of "i-default"
1207 targ-name [2] PrincipalName OPTIONAL,
1208 targ-realm [3] Realm OPTIONAL,
1209 -- If targ-name/realm are missing then the request
1210 -- applies to the principal of the client
1211 dry-run [4] BOOLEAN DEFAULT FALSE,
1212 operation [5] Op-req,
1213 ...
1214 }
1216 Response ::= [APPLICATION 1] SEQUENCE {
1217 pvno-minor [0] INTEGER DEFAULT 0,
1218 language [1] Language-Tag DEFAULT "i-default",
1219 result [2] Op-rep,
1220 ...
1221 }
1223 Error-Response ::= [APPLICATION 2] SEQUENCE {
1224 pvno-minor [0] INTEGER DEFAULT 0,
1225 language [1] Language-Tag DEFAULT "i-default",
1226 error-code [2] ProtocolErrorCode,
1227 help-text [3] UTF8String OPTIONAL,
1228 op-error [4] Op-err OPTIONAL,
1229 ...
1230 }
1232 Op-req ::= CHOICE {
1233 null [0] Req-null,
1234 change-pw [1] Req-change-pw,
1235 set-pw [2] Req-set-pw,
1237 N. Williams [Page 21]
1238 \f
1240 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1242 set-keys [3] Req-set-keys,
1243 gen-keys [4] Req-gen-keys,
1244 get-keys [5] Req-get-keys,
1245 commit-keys [6] Req-commit-keys,
1246 get-pw-policy [7] Req-get-pw-policy,
1247 get-princ-aliases [8] Req-get-princ-aliases,
1248 get-realm-krb5-support [9] Req-get-realm-krb5-support,
1249 get-s2kparams [10] Req-get-s2kparams,
1250 ...
1251 }
1253 Op-rep ::= CHOICE {
1254 null [0] Rep-null,
1255 change-pw [1] Rep-change-pw,
1256 set-pw [2] Rep-set-pw,
1257 set-keys [3] Rep-set-keys,
1258 gen-keys [4] Req-gen-keys,
1259 get-keys [5] Req-get-keys,
1260 commit-keys [6] Rep-commit-keys,
1261 get-pw-policy [7] Rep-get-pw-policy,
1262 get-princ-aliases [8] Rep-get-princ-aliases,
1263 get-realm-krb5-support [9] Rep-get-realm-krb5-support,
1264 get-s2kparams [10] Rep-get-s2kparams,
1265 ...
1266 }
1268 Op-err ::= CHOICE {
1269 null [0] Err-null,
1270 change-pw [1] Err-change-pw,
1271 set-pw [2] Err-set-pw,
1272 set-keys [3] Err-set-keys,
1273 gen-keys [4] Err-gen-keys,
1274 get-keys [5] Err-get-keys,
1275 commit-keys [6] Err-commit-keys,
1276 get-pw-policy [7] Err-get-pw-policy,
1277 get-princ-aliases [8] Err-get-princ-aliases,
1278 get-realm-krb5-support [9] Err-get-realm-krb5-support,
1279 get-s2kparams [10] Err-get-s2kparams,
1280 ...
1281 }
1283 ProtocolErrorCode ::= ENUM {
1284 proto-format-error,
1285 proto-unsupported-major-version,
1286 proto-unsupported-minor-version,
1287 proto-unsupported-operation, -- Request CHOICE tag unknown
1288 proto-generic-see-op-error, -- See Op-error
1289 proto-wrong-service-principal, -- Use kadmin/setpw
1290 proto-re-authentication-required,
1291 proto-initial-ticket-required,
1292 proto-client-and-target-realm-mismatch,
1293 proto-target-principal-unknown,
1294 proto-authorization-failed,
1296 N. Williams [Page 22]
1297 \f
1299 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1301 proto-dry-run-not-permitted,
1302 ...
1303 }
1305 -- These codes are hints for clients, primarily for when they are
1306 -- used for changing the passwords of automated principals; error
1307 -- replies carry password quality policy help text that is more
1308 -- appropriate for clients to display to users.
1309 PW-Quality-Codes ::= ENUM {
1310 pwq-generic,
1311 pwq-too-soon,
1312 pwq-repeated,
1313 pwq-too-short,
1314 pwq-dictionary-words,
1315 pwq-prohibited-codepoints,
1316 pwq-need-more-char-classes,
1317 ...
1318 }
1320 --
1321 -- Requests and responses
1322 --
1324 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
1325 Req-null ::= NULL
1327 Rep-null ::= NULL
1329 Err-null ::= NULL
1331 -- Change password
1332 Req-change-pw ::= SEQUENCE {
1333 old-pw [0] Password,
1334 new-pw [1] Password OPTIONAL,
1335 commit [2] BOOLEAN DEFAULT TRUE,
1336 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL,
1337 ...
1338 }
1340 Rep-change-pw ::= SEQUENCE {
1341 info-text [0] UTF8String OPTIONAL,
1342 new-pw [1] Password OPTIONAL,
1343 -- generated by the server if present
1344 -- (and requested by the client)
1345 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL,
1346 ...
1347 }
1349 Err-change-pw ::= SEQUENCE {
1350 help-text [0] UTF8String OPTIONAL,
1351 error [1] CHOICE {
1352 op-generic-error [0] Extensible-NULL,
1353 op-old-pw-incorrect [1] Extensible-NULL,
1355 N. Williams [Page 23]
1356 \f
1358 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1360 op-wont-generate-new-pw [2] Extensible-NULL,
1361 op-new-pw-rejected-generic [3] SEQUENCE {
1362 policy [1] SEQUENCE OF UTF8String,
1363 suggested-pw [2] Password OPTIONAL,
1364 policy-codes [3] SET OF PW-Quality-Codes
1365 OPTIONAL,
1366 ...
1367 }
1368 op-etype-not-supported [4] SEQUENCE {
1369 supported-etypes [1] SEQUENCE OF Etype,
1370 ...
1371 },
1372 ...
1373 },
1374 ...
1375 }
1377 -- Set password
1378 Req-set-pw ::= SEQUENCE {
1379 languages [0] SEQUENCE OF Language-Tag OPTIONAL,
1380 new-pw [1] Password OPTIONAL,
1381 commit [2] BOOLEAN DEFAULT TRUE,
1382 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL,
1383 ...
1384 }
1386 Rep-set-pw ::= SEQUENCE {
1387 info-text [0] UTF8String OPTIONAL,
1388 new-pw [1] Password OPTIONAL,
1389 -- generated by the server if present
1390 -- (and requested by the client)
1391 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL,
1392 ...
1393 }
1395 Err-set-pw ::= Err-change-pw
1397 -- Set keys
1398 Req-set-keys ::= SEQUENCE {
1399 keys [0] SEQUENCE OF Key,
1400 commit [1] BOOLEAN DEFAULT TRUE,
1401 -- TRUE -> install keys now
1402 --
1403 -- FALSE -> require set-keys-commit
1404 -- before issuing tickets
1405 -- encrypted with these keys.
1406 --
1407 -- See commit-keys op
1408 isupport [2] KerberosVSupportNego OPTIONAL,
1409 -- For future Kerberos V extensions KDCs
1410 -- may need to know what krb5 version is
1411 -- supported by individual service
1412 -- principals. This field provides a
1414 N. Williams [Page 24]
1415 \f
1417 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1419 -- way to tell the KDC what version of
1420 -- Kerberos V the target principal
1421 -- supports.
1422 ...
1423 }
1425 Rep-set-keys ::= SEQUENCE {
1426 info-text [0] UTF8String OPTIONAL,
1427 kvno [1] UInt32,
1428 aliases [2] SEQUENCE OF SEQUENCE {
1429 name [0] PrincipalName,
1430 realm [1] Realm OPTIONAL,
1431 ...
1432 },
1433 isupport [3] KerberosVSupportNego OPTIONAL,
1434 ...
1435 -- Should there be ETYPE-INFO2 stuff here?
1436 }
1438 Err-set-keys ::= SEQUENCE {
1439 help-text [0] UTF8String OPTIONAL, -- Reason for rejection
1440 error [1] CHOICE {
1441 op-generic [0] Extensible-NULL,
1442 op-deferred-commit-no-support [1] Extensible-NULL,
1443 op-etype-no-support [2] SEQUENCE OF {
1444 supported-etypes [1] SEQUENCE OF Etype,
1445 ...
1446 }
1447 ...
1448 }
1449 }
1451 -- Generate keys
1452 Req-gen-keys ::= SEQUENCE {
1453 etypes [0] SEQUENCE (1..) OF Etype,
1454 entropy [1] OCTET STRING OPTIONAL,
1455 commit [2] BOOLEAN DEFAULT TRUE,
1456 -- TRUE -> install keys now
1457 --
1458 -- FALSE -> require set-keys-commit
1459 -- before issuing tickets
1460 -- encrypted with these keys.
1461 --
1462 -- See commit-keys op
1463 isupport [3] KerberosVSupportNego OPTIONAL,
1464 -- For future Kerberos V extensions KDCs
1465 -- may need to know what krb5 version is
1466 -- supported by individual service
1467 -- principals. This field provides a
1468 -- way to tell the KDC what version of
1469 -- Kerberos V the target principal
1470 -- supports.
1471 ...
1473 N. Williams [Page 25]
1474 \f
1476 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1478 }
1480 Rep-gen-keys ::= SEQUENCE {
1481 info-text [0] UTF8String OPTIONAL,
1482 kvno [1] UInt32,
1483 key [2] Key,
1484 aliases [3] SEQUENCE OF SEQUENCE {
1485 name [0] PrincipalName,
1486 realm [1] Realm OPTIONAL,
1487 ...
1488 },
1489 isupport [4] KerberosVSupportNego OPTIONAL,
1490 ...
1491 -- Should there be ETYPE-INFO2 stuff here?
1492 }
1494 Err-gen-keys ::= Err-set-keys
1496 -- Get un-committed key request
1497 Req-get-keys ::= SEQUENCE {
1498 kvno [0] UInt32,
1499 ...
1500 }
1502 Rep-get-keys ::= SEQUENCE {
1503 info-text [0] UTF8String OPTIONAL,
1504 keys [1] SEQUENCE OF Key,
1505 aliases [2] SEQUENCE OF SEQUENCE {
1506 name [0] PrincipalName,
1507 realm [1] Realm OPTIONAL,
1508 ...
1509 },
1510 isupport [3] KerberosVSupportNego OPTIONAL,
1511 ...
1512 -- Should there be ETYPE-INFO2 stuff here?
1513 }
1515 Err-get-keys ::= SEQUENCE {
1516 help-text [0] UTF8String OPTIONAL, -- Reason for rejection
1517 error [1] CHOICE {
1518 op-generic [0] Extensible-NULL,
1519 op-kvno-committed [1] Extensible-NULL,
1520 op-no-such-kvno [1] Extensible-NULL,
1521 ...
1522 }
1523 }
1525 -- Commit a set keys request
1526 Req-commit-keys ::= SEQUENCE {
1527 kvno [0] UInt32,
1528 ...
1529 }
1532 N. Williams [Page 26]
1533 \f
1535 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1537 Rep-commit-keys ::= Extensible-NULL
1539 Err-commit-keys ::= SEQUENCE {
1540 help-text [0] UTF8String OPTIONAL, -- Reason for rejection
1541 error [1] CHOICE {
1542 op-generic [0] Extensible-NULL,
1543 op-kvno-expired [1] Extensible-NULL,
1544 -- The client took too long to respond.
1545 op-kvno-unknown [2] Extensible-NULL,
1546 -- The targ princ/kvno is invalid or unknown to the
1547 -- server (perhaps it lost track of state)
1548 op-new-keys-conflict [3] Extensible-NULL,
1549 -- A new-keys/commit-keys request subsequent to the
1550 -- new-keys that produced the kvno has completed
1551 -- and incremented the principal's kvno
1552 ...
1553 }
1554 ...
1555 }
1557 -- Get password policy
1558 Req-get-pw-policy ::= Extensible-NULL
1560 Rep-get-pw-policy ::= SEQUENCE {
1561 policy-name [0] UTF8String OPTIONAL,
1562 description [1] SEQUENCE OF UTF8String OPTIONAL,
1563 ...
1564 }
1566 Err-get-pw-policy ::= Extensible-NULL
1568 -- Get principal aliases
1569 Req-get-princ-aliases ::= Extensible-NULL
1571 Rep-get-princ-aliases ::= SEQUENCE {
1572 help-text [0] UTF8String OPTIONAL,
1573 aliases [1] SEQUENCE OF SEQUENCE {
1574 name [0] PrincipalName,
1575 realm [1] Realm OPTIONAL,
1576 ...
1577 },
1578 ...
1579 }
1581 Err-get-princ-aliases ::= Extensible-NULL
1583 -- Get list of enctypes supported by KDC for new keys
1584 Req-get-realm-krb5-support ::= Extensible-NULL
1586 Rep-get-realm-krb5-support ::= SEQUENCE {
1587 isupport [0] KerberosVSupportNego,
1588 -- Version of Kerberos V supported by
1589 -- the target realm.
1591 N. Williams [Page 27]
1592 \f
1594 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1596 ...
1597 }
1599 Err-get-realm-krb5-support ::= Extensible-NULL
1601 -- Get s2kparams
1602 Req-get-s2kparams ::= Extensible-NULL
1604 Rep-get-s2kparams ::= SEQUENCE {
1605 help-text [0] UTF8String OPTIONAL,
1606 s2kparams [1] SEQUENCE OF Etype-Info-Entry,
1607 ...
1608 }
1610 Err-get-s2kparams ::= Extensible-NULL
1612 END
1615 6 IANA Considerations
1617 There are no IANA considerations for this document.
1619 7 Security Considerations
1621 Implementors and site administrators should note that the redundancy
1622 of UTF-8 encodings of passwords varies by language. Password quality
1623 policies SHOULD, therefore, take this into account when estimating
1624 the amount of redundancy and entropy in a proposed new password. [??
1625 It's late at night - I think this is correct.]
1627 Kerberos set/change password/key protocol major version negotiation
1628 cannot be done securely; a downgrade attack is possible against
1629 clients that attempt to negotiate the protocol major version to use
1630 with a server. It is not clear at this time that the attacker would
1631 gain much from such a downgrade attack other than denial of service
1632 (DoS) by forcing the client to use a protocol version which does not
1633 support some feature needed by the client (Kerberos V in general is
1634 subject to a variety of DoS attacks anyways [RFC1510]). Clients
1635 SHOULD NOT negotiate support for legacy major versions of this
1636 protocol unless configured otherwise.
1638 This protocol does not have Perfect Forward Security (PFS). As a
1639 result, any passive network snooper watching password/key changing
1640 operations who has stolen a principal's password or long-term keys
1641 can find out what the new ones are.
1643 [More text needed?]
1645 8 Acknowledgements
1647 The authors would like to thank Bill GossmanMike Swift, John Brezak,
1648 Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
1650 N. Williams [Page 28]
1651 \f
1653 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1655 Nelson, Marcus Watts, Love, Joel N. Weber II, Jeffrey Hutzelman and
1656 other participants from the IETF Kerberos Working Group for their
1657 assistance.
1659 9 References
1661 9.1 Normative References
1663 [RFC2026]
1664 S. Bradner, RFC2026: "The Internet Standard Process - Revision
1665 3," October 1996, Obsoletes - RFC 1602, Status: Best Current
1666 Practice.
1668 [RFC2119]
1669 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to
1670 Indicate Requirement Levels," March 1997, Status: Best Current
1671 Practice.
1673 [X680]
1674 Abstract Syntax Notation One (ASN.1): Specification of Basic
1675 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
1676 International Standard 8824-1:1998.
1677 http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
1679 [X690]
1680 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
1681 Canonical Encoding Rules (CER) and Distinguished Encoding Rules
1682 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
1683 Standard 8825-1:1998.
1684 http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
1686 [clarifications]
1687 RFC-Editor: To be replaced by RFC number for
1688 draft-ietf-krb-wg-kerberos-clarifications.
1690 [RFC3066]
1691 H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
1692 Languages," January 2001, Obsoletes RFC1766, Status: Best Current
1693 Practice.
1695 9.2 Informative References
1697 [RFC3244]
1698 M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
1699 Kerberos Change Password and Set Password Protocols," February
1700 2002, Status: Informational.
1702 10 Authors' Addresses
1704 Nicolas Williams
1705 Sun Microsystems
1706 5300 Riata Trace Ct
1707 Austin, TX 78727
1709 N. Williams [Page 29]
1710 \f
1712 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1714 Email: nicolas.williams@sun.com
1717 11 Notes to the RFC Editor
1719 This document has two KRB WG drafts as normative references and
1720 cannot progress until those drafts progress, but no other draft
1721 depends on this one.
1723 12 Change History
1725 -01 -> -02
1727 - Removed Bill Gossman, Mike Swift and John Brezak as authors.
1729 - Removed UDP as a transport for this protocol.
1731 - Replaced redundant copies of framing ASCII art with reference to
1732 RFC3244.
1734 - Made all name/password strings UTF8String with an extensible
1735 constraint to IA5String.
1737 - Added a method for doing dry runs of operations. This is helpful
1738 in testing passwords against password quality policies.
1740 - Added an operation for retrieving a principal's current and
1741 preferred string-to-key parameters, and a way to change them
1742 without changing the principal's password.
1744 - Added password quality codes as hints for smart clients, but
1745 these are optional and not to be used instead of messages to be
1746 displayed to useds.
1748 - Added a 'commit' option to change-pw and set-pw (as requested by
1749 Larry).
1751 - Removed "version" field of the Kerberos V feature negotiation
1752 struture.
1756 N. Williams [Page 30]
1757 \f
1759 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1763 Intellectual Property Statement
1765 The IETF takes no position regarding the validity or scope of any
1766 Intellectual Property Rights or other rights that might be claimed to
1767 pertain to the implementation or use of the technology described in
1768 this document or the extent to which any license under such rights
1769 might or might not be available; nor does it represent that it has
1770 made any independent effort to identify any such rights. Information
1771 on the procedures with respect to rights in RFC documents can be
1772 found in BCP 78 and BCP 79.
1774 Copies of IPR disclosures made to the IETF Secretariat and any
1775 assurances of licenses to be made available, or the result of an
1776 attempt made to obtain a general license or permission for the use of
1777 such proprietary rights by implementers or users of this
1778 specification can be obtained from the IETF on-line IPR repository at
1779 http://www.ietf.org/ipr.
1781 The IETF invites any interested party to bring to its attention any
1782 copyrights, patents or patent applications, or other proprietary
1783 rights that may cover technology that may be required to implement
1784 this standard. Please address the information to the IETF at
1785 ietf-ipr@ietf.org.
1788 Disclaimer of Validity
1790 This document and the information contained herein are provided on an
1791 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1792 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1793 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1794 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1795 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1799 Copyright Statement
1801 Copyright (C) The Internet Society (2005). This document is subject
1802 to the rights, licenses and restrictions contained in BCP 78, and
1803 except as set forth therein, the authors retain all their rights.
1806 Acknowledgment
1808 Funding for the RFC Editor function is currently provided by the
1809 Internet Society.
1814 Williams Expires August 22, 2005 [Page 31]
1815 \f