| blob | a25d8096ca4ac8dbcb733b0a53e3a67e2e223756 |
2 Kerberos Working Group Nicolas Williams
3 INTERNET-DRAFT Sun Microsystems
4 Category: Standards Track Jonathan Trostle
5 Cisco Systems
9 Kerberos Set/Change Password: Version 2
10 <draft-ietf-krb-wg-kerberos-set-passwd-02.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 January 12, 2005.
37 Copyright Notice
39 Copyright (C) The Internet Society (2004). 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 et. al. [Page 1]\f
59 DRAFT Kerberos Set/Change Password v2 Expires January 2005
61 2.5 Use of ASN.1
62 2.6 Internationalization
63 2.6.1 Normalization Forms for UTF-8 Strings
64 2.6.2 Language Negotiation
65 2.7 Protocol Extensibility
66 2.8 Protocol Subsets
67 3 Protocol Elements
68 3.1 PDUs
69 3.2 Operations
70 3.2.1 Null
71 3.2.2 Change Kerberos Password
72 3.2.3 Set Kerberos Password
73 3.2.4 Set Kerberos Keys
74 3.2.5 Generate Kerberos Keys
75 3.2.6 Get New Keys
76 3.2.7 Commit New Keys
77 3.2.8 Get Password Quality Policy
78 3.2.9 Get Principal Aliases
79 3.2.10 Get Realm's Supported Kerberos V Version and Features
80 4 ASN.1 Module
81 6 IANA Considerations
82 7 Security Considerations
83 8 Acknowledgements
84 9 References
85 9.1 Normative References
86 9.2 Informative References
87 10 Authors' Addresses
88 11 Notes to the RFC Editor
90 Conventions used in this document
92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
94 document are to be interpreted as described in [RFC2119].
96 1 Introduction
98 Up to this point Kerberos V has lacked a single, standard protocol
99 for changing passwords and keys. While several vendor-specific
100 protocols exist for changing Kerberos passwords/keys, none are
101 properly internationalized and all are incomplete in one respect or
102 another and none are sufficiently extensible to cope with new
103 features that may be added to Kerberos V at some future time.
105 This document defines a protocol that is somewhat backward-compatible
106 with the "kpasswd" protocol defined in [RFC3244] that uses more or
107 less the same protocol framing.
109 This new protocol is designed to be extensible and properly
110 internationalized.
112 2 The Protocol
115 N. Williams et. al. [Page 2]\f
117 DRAFT Kerberos Set/Change Password v2 Expires January 2005
119 The structure of the protocol is quite similar to that of typical RPC
120 protocols. Each transaction consists of a data structure specific to
121 an operation which is then wrapped in a data structure which is
122 general to all operations of the protocol. These data structures are
123 defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
124 are encoded using the Distinguished Encoding Rules (DER) [X690].
126 All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
127 KRB-ERROR, and framed in a header that is backwards compatible with
128 [RFC3244].
130 2.1 Transports
132 The service supports only connection-oriented transports,
133 specifically TCP, and MUST accept requests on TCP port 464, the same
134 as in [RFC3244].
136 2.2 Protocol Framing
138 Requests and responses are exchanged using the same framing as in
139 [RFC3244], but with the following differences:
141 - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
143 - the 'AP-REQ length' field of the request can be set to 0x0, in
144 which case the 'AP-REQ' field of the request is excluded
146 - the 'KRB-PRIV' field of the request and reply is mutually
147 exclusive with the 'AP-REQ' field of the request
149 - the 'AP-REP length' field of the reply can be set to 0x0, in
150 which case the 'AP-REP' field of the reply is excluded
152 - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
153 be or has been accepted by the server
155 - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
156 of the reply
158 The initial message from the client MUST carry an AP-REQ and the
159 response to any request bearing an AP-REQ MUST carry an AP-REP or
160 MUST be a KRB-ERROR.
162 Subsequent messages exchanged on the same TCP connection MAY involve
163 Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
164 a new AP exchange except when it desires to authenticate as a
165 different principal, when the ticket last used for authentication
166 expires or when the server responds with an error indicating that the
167 client must re-authenticate.
169 2.3 Protocol Version Negotiation
171 There are several major versions of this protocol. Version 2 also
173 N. Williams et. al. [Page 3]\f
175 DRAFT Kerberos Set/Change Password v2 Expires January 2005
177 introduces a notion of protocol minor versions for use in negotiating
178 protocol extensions. As of this time only one minor version is
179 defined for major version 2: minor version 0, defined herein.
181 2.3.1 Protocol Major Version Negotiation
183 Version 2 clients that also support other versions, such as 0xff80,
184 as in [RFC3244], SHOULD attempt to use version 2 of the protocol
185 first.
187 Servers which do not support version 2 of this protocol typically
188 include their preferred version number in the reply and/or may
189 include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
190 status code of KRB5_KPASSWD_MALFORMED.
192 Note that some [RFC3244] server implementations close the TCP
193 connection without returning any other response. Note also that
194 there is no integrity protection for the major version number in the
195 protocol framing or for any data in a KRB-ERROR.
197 As a result change password protocol major version negotiation is
198 subject to downgrade attacks. Therefore major version negotiation is
199 NOT RECOMMENDED.
201 Where the server indicates that it does not support version 2, the
202 client MAY, but SHOULD NOT, unless configured to do so, fall back on
203 another major version of this protocol.
205 Version 2 servers MAY respond to non-v2 requests using whatever
206 response is appropriate for the versions used by the clients, but if
207 a server does not do this or know how to do this then it MUST respond
208 with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
209 if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
210 using a ProtocolErrorCode value of unsupported-major-version.
212 It is expected that implementations of as yet unspecified future
213 major versions of this protocol will be required to support version 2
214 integrity protected error replies for properly indicating no support
215 for version 2 of the protocl. We also hope that no further major
216 versions of this protocol will be needed.
218 2.3.2 Protocol Minor Version Negotiation
220 Version 2 clients are free to use whatever protocol minor version and
221 message extensions are available to them in their initial messages to
222 version 2 servers, provided that the minor versions (other than 0)
223 have been defined through IETF documents.
225 Version 2 servers MUST answer with the highest protocol minor version
226 number supported by the server and the client.
228 Version 2 clients MUST use the protocol minor version used in a
229 server's reply for any subsequent messages in the same TCP session.
231 N. Williams et. al. [Page 4]\f
233 DRAFT Kerberos Set/Change Password v2 Expires January 2005
236 See section 2.7 for further description of the protocol's
237 extensibility and its relation to protocol minor versions and the
238 negotiation thereof.
240 2.4 Use of Kerberos V and Key Exchange
242 This protocol makes use of messages defined in [RFC1510] and
243 [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and
244 KRB-PRIV.
246 All operations are to be performed by the server on behalf of the
247 client principal.
249 Clients SHOULD use "kadmin/setpw" as the principal name of the server
250 for all requests except when changing the client principal's own
251 expired password, for which they should use "kadmin/changepw". The
252 "kadmin/changepw" service exists to allow KDCs to limit principals
253 with expired passwords to getting initial tickets to the password
254 changing service only and only for changing expired passwords.
256 Servers MUST limit clients that used the "kadmin/changepw" service
257 principal name to changing the password of the client principal.
259 The client MUST request mutual authentication and the client MUST
260 MUST request the use of sequence numbers.
262 Clients SHOULD use INITIAL tickets for requests whose target
263 principal is the client's principal. Servers SHOULD force the use of
264 INITIAL tickets for such requests and MAY force the use of INITIAL
265 for all others - see section 3.2.
267 Servers MUST specify a sub-session key.
269 The encrypted part of KRB-PRIVs MUST be encrypted with the server's
270 sub-session key and key usage 20 (client->server) or 21
271 (server->client).
273 After each new AP exchange the client and server MUST destroy the
274 session keys, if any, resulting from the previous AP exchange.
276 2.5 Use of ASN.1
278 This protocol's messages are defined in ASN.1, using only features
279 from [X680]. All ASN.1 types defined herein are to be encoded in
280 DER [X690]. A complete ASN.1 module is given in section 4.
282 The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
283 KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
285 2.6 Internationalization
287 This protocol's request PDU carries an optional field indicating the
289 N. Williams et. al. [Page 5]\f
291 DRAFT Kerberos Set/Change Password v2 Expires January 2005
293 languages spoken by the client user; the client SHOULD send its list
294 of spoken languages to the server (once per-TCP session).
296 The server SHOULD localize all strings intended for display to users
297 to a language in common with the languages spoken by the client user.
299 Strings for Kerberos principal and realm names used in this protocol
300 are be constrained as per [clarifications].
302 2.6.1 Normalization Forms for UTF-8 Strings
304 Because Kerberos V [clarifications] restricts principal names, realm
305 names and passwords to IA5String, this protocol uses UTF8String with
306 an extensible constraint to IA5String.
308 Future versions of Kerberos may relax this constraint; if so then a
309 minor version of this protocol should relax this constraint
310 accordingly.
312 2.6.2 Language Negotiation
314 The server MUST pick a language from the client's input list or
315 the default language tag (see [RFC3066]) for text in its responses
316 which is meant for the user to read.
318 The server SHOULD use a language selection algorithm such that
319 consideration is first given to exact matches between the client's
320 spoken languages and the server's available locales, followed by
321 "fuzzy" matches where only the first sub-tags of the client's
322 language tag list are used for matching against the servers available
323 locales.
325 Servers MUST cache the optional language tag lists from prior
326 requests for use with subsequent requests that exclude the language
327 tag list. Clients MAY expect such server behaviour and send the
328 language tag lists only once per-TCP session. Clients SHOULD send
329 the server the language tag list at least once.
331 When the server has a message catalog for one of the client's spoken
332 languages the server SHOULD localize any text strings intended for
333 display to users.
335 2.7 Protocol Extensibility
337 The protocol is defined in ASN.1 and uses extensibility markers
338 throughout. As such, the module presented herein can be extended
339 within the framework of [X680].
341 Typed holes are not used in this protocol as it is very simple and
342 does not require the ability to deal with abstract data types defined
343 in different layers. For this reason, the only way to extend this
344 protocol is by extending the ASN.1 module within the framework of the
345 IETF; all future extensions to this protocol have to be defined in
347 N. Williams et. al. [Page 6]\f
349 DRAFT Kerberos Set/Change Password v2 Expires January 2005
351 IETF documents unless otherwise specified in a future IETF revision
352 of this protocol.
354 A protocol minor version number is used to negotiate use of
355 extensions. See section 2.3.2 for the minor version negotiation.
357 Servers SHOULD ignore unknown additions to the ASN.1 types, in
358 initial requests, where the syntax allows them, except for extensions
359 to the "Op-req" type, which MUST result in an error.
361 Servers MUST respond with an error (ProtocolErrorCode value of
362 unsupported-minor-version) to clients that use operations unknown to
363 the server.
365 2.8 Protocol Subsets
367 The structure of the protocol is such that the ASN.1 syntaxes for the
368 various operations supported by the protocol are independent of the
369 each other. Client and server implementations MAY implement subsets
370 of the overall protocol by removing some alternatives to the Op-req,
371 Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
373 For example, it should be possible to have a password-change only
374 client that cannot set principal's keys - and vice versa.
376 3 Protocol Elements
378 The protocol as defined herein supports the following operations
379 relating to the management of Kerberos principal's passwords or keys:
381 [NOTE: New since last version of this I-D.]
382 - get principal's current and preferred string-to-key parameters
384 - change password (or enctypes and string-to-key parameters)
385 - set password (administrative)
386 - set new keys
387 - generate new keys
388 - get new, un-committed keys
389 - commit new keys
390 - get password policy name and/or description of principal
391 - list aliases of a principal
392 - list enctypes and version of Kerberos V supported by realm
394 The operation for retrieving a list of aliases of a principal is
395 needed where KDCs implement aliasing of principal names and allows
396 clients to properly setup their key databases when principal aliasing
397 is in use.
399 Operations such as creation or deletion of principals are outside the
400 scope of this document, and should be performed via other means, such
401 as through directories or other Kerberos administration protocols.
403 The individual operations are described in section 3.2.
405 N. Williams et. al. [Page 7]\f
407 DRAFT Kerberos Set/Change Password v2 Expires January 2005
410 3.1 PDUs
412 The types "Request," "Response" and "Error-Response" are the ASN.1
413 module's PDUs.
415 The "Request" and "Response" PDUs are always to be sent wrapped in
416 KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
417 sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
418 otherwise it MUST be sent wrapped in a KRB-PRIV.
420 The ASN.1 syntax for the PDUs is given in section 4.
422 Note that the first field of each PDU is the major version of the
423 protocol, defaulted to 2, meaning that it is never included in
424 version 2 exchanges. Similarly, the second field of each PDU is the
425 minor version, defaulted to 0.
427 The request, responses and error PDUs consist of an outer structure
428 ("Request," "Response" and "Error-Response") containing fields common
429 to all requests, responses and errors, respectively, and an inner
430 structure for fields that are specific to each operation's
431 requests/responses. The inner structure is optional in the case of
432 the Error-Response PDU and need not be included when generic errors
433 occur for which there is a suitable ProtocolErrorCode.
435 Specifically, the outer Request structure has a field for passing a
436 client user's spoken (read) languages to the server. It also has two
437 optional fields for identifying the requested operation's target
438 principal's name and realm (if not sent then the server MUST use the
439 client's principal name and realm as the target). A boolean field
440 for indicating whether or not the request should be dry-run is also
441 included; dry-runs can be used to test server policies, and servers
442 MUST NOT modify any principals when processing dry-run requests.
444 The Response and Error PDUs' outer structures include a field
445 indicating the language that the server has chosen for localization
446 of text intended to be displayed to users; this field is defaulted to
447 "i-default". This language tag applies to all UTF8 strings in the
448 inner structure (Op-rep and Op-err) that are meant to be displayed to
449 users.
451 The protocol error codes are:
453 - proto-generic-error
455 An operation-specific error ocurred, see the inner Op-error.
457 - proto-format-error
458 - proto-unsupported-major-version
459 - proto-unsupported-minor-version
460 - proto-unsupported-operation
463 N. Williams et. al. [Page 8]\f
465 DRAFT Kerberos Set/Change Password v2 Expires January 2005
467 - proto-wrong-service-principal
469 Use kadmin/setpw for the server's principal name.
471 - proto-re-authentication-required
473 The server demands that the client re-authenticate through a new
474 AP exchange.
476 - proto-initial-ticket-required
478 Use of an INITIAL ticket is required for the requested
479 operation.
481 - proto-client-and-target-realm-mismatch
483 The server requires that the client's principal name and the
484 target principal of the operation share the same realm name.
486 - proto-target-principal-unknown
487 - proto-authorization-failed
489 3.2 Operations
491 This section describes the semantics of each operation request and
492 response defined in the ASN.1 module in section 4.
494 3.2.1 Null
496 NAME
498 null - Null or "ping" operation
500 DESCRIPTION
502 The null request is intended for use with TCP; its purpose is
503 similar to RPC null procedures and is akin to a "ping" operation.
505 ERRORS
507 None.
509 3.2.2 Change Kerberos Password
511 NAME
513 change-pw - Change password operation
515 SYNOPSIS
517 Req-change-pw(old-pw, [languages], [new-pw],
518 [commit], [etypes]) ->
519 Rep-change-pw([info-text], [new-pw], [etypes]) |
521 N. Williams et. al. [Page 9]\f
523 DRAFT Kerberos Set/Change Password v2 Expires January 2005
525 Err-change-pw([help-text], error code, [error info])
527 DESCRIPTION
529 Change a principal's password.
531 The change password request has one required, three optional and
532 one defaulted arguments: "old-pw" (required), "languages,"
533 "new-pw", "commit" (defaults to "TRUE") and "etypes",
534 corresponding to the target principal's old password, its
535 preferred languages, its new password, a boolean indicating
536 whether or not to make the new long-term key available for
537 immediate use, and the desired enctypes for the new long-term
538 keys.
540 The server MUST validate the old password and MUST check the
541 quality of the new password, if sent, according the password
542 quality policy associated with the target principal.
544 If the old and new passwords in the request are the same strings,
545 and the principal is not currently required to change its
546 password, then the server MAY permit the password change as way to
547 change a principal's enctypes and string-to-key parameters. This
548 feature provides a way to, for example, add enctypes to a
549 principals' password-derived long-term keys without forcing a
550 password change following an upgrade to the KDC that adds support
551 for new enctypes.
553 A client MAY request that the server generate a new password by
554 excluding the new password from its request, in which case the
555 server MUST either generate a new password or respond with an
556 error indicating that it does not support this feature.
558 Server-generated passwords MUST meet the target principal's
559 password quality policy. It is RECOMMENDED that server-generated
560 passwords be user-friendly, that is, memorable and that the target
561 principal's preferred languages be taken into account by the
562 password generation alogrithm used by the server.
564 Uncommitted password changes are commited using the commit-keys
565 operation.
567 RETURN
569 Upon successful password changes the server responds with a
570 Rep-change-pw. The fields of Rep-change-pw are all optional and
571 include:
573 - 'info-text' which the server can use to send a message to the
574 user such as "Your new password will expire in 90 days," for
575 example.
577 - 'new-pw' which the server MUST include if the client
579 N. Williams et. al. [Page 10]\f
581 DRAFT Kerberos Set/Change Password v2 Expires January 2005
583 requested that the server generate a new password; generated
584 passwords MUST pass the target principal's password quality
585 policy.
587 - 'etypes' which the server MAY include to indicate which types
588 of long-term keys it created for the target principal and
589 which the server MUST include if the client specified a set
590 of enctypes in its request.
592 ERRORS
594 The server may respond to change password requests with protocol
595 or operation errors. See section 3.1 for a description of
596 protocol error codes.
598 All operation errors include an optional 'help-text' field by
599 which the server can describe the error in a human-readable,
600 localizaed string.
602 Change password error codes include:
604 - generic-error
606 - old-pw-incorrect
608 - wont-generate-new-pw
610 The server will not generate a new password for this
611 principal or does not support password generation in general.
613 - new-pw-rejected-generic
615 The client's proposed new password failed the target
616 principal's password quality policy.
618 The server MUST include a description of the password quality
619 policy or aspect of it that the client's proposed new
620 password failed to meet.
622 The server MAY generate and send a new password that the
623 client can then use as a new password and which is guaranteed
624 to pass the target principal's current password quality
625 policy.
627 The server MAY include a set of policy error code hints.
629 - etype-not-supported
631 The client requested an enctype that the KDC does not
632 support.
634 3.2.3 Set Kerberos Password
637 N. Williams et. al. [Page 11]\f
639 DRAFT Kerberos Set/Change Password v2 Expires January 2005
641 NAME
643 set-pw - Set password operation
645 SYNOPSIS
647 Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
648 Rep-set-pw([info-text], [new-pw], [etypes]) |
649 Err-set-pw([help-text], error code, [error info])
651 DESCRIPTION
653 Administratively set a principal's password.
655 The set password request has three optional and one defaulted
656 arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
657 and "etypes", corresponding to the target principal's preferred
658 languages, new password, a boolean indicating whether or not to
659 make the new long-term key available for immediate use, and the
660 desired enctypes for the new long-term keys.
662 The server MUST check the quality of the new password, if sent,
663 according the password quality policy associated with the target
664 principal.
666 The server SHOULD require that the client use the change-pw
667 operation instead of set-pw when the client principal and the
668 target principal are the same.
670 A client MAY request that the server generate a new password by
671 excluding the new password from its request, in which case the
672 server MUST either generate a new password or respond with an
673 error indicating that it does not support this feature.
675 Server-generated passwords MUST meet the target principal's
676 password quality policy. It is RECOMMENDED that server-generated
677 passwords be user-friendly, that is, memorable and that the target
678 principal's preferred languages be taken into account by the
679 password generation alogrithm used by the server.
681 RETURN
683 Upon successfully setting a password the server responds with a
684 Rep-set-pw. The fields of Rep-set-pw are all optional and
685 include:
687 - 'info-text' which the server can use to send a message to the
688 user such as "Your new password will expire in 90 days," for
689 example.
691 - 'new-pw' which the server MUST include if the client
692 requested that the server generate a new password; generated
693 passwords MUST pass the target principal's password quality
695 N. Williams et. al. [Page 12]\f
697 DRAFT Kerberos Set/Change Password v2 Expires January 2005
699 policy.
701 - 'etypes' which the server MAY include to indicate which types
702 of long-term keys it created for the target principal and
703 which the server MUST include if the client specified a set
704 of enctypes in its request.
706 ERRORS
708 The server may respond to set password requests with protocol or
709 operation errors. See section XYZ for a description of protocol
710 error codes.
712 All operation errors include an optional 'help-text' field by
713 which the server can describe the error in a human-readable,
714 localizaed string.
716 Set password error codes include:
718 - generic-error
720 - use-change-pw
722 The server demands that the client use the change-pw
723 operation for the target principal of the set-pw request.
725 - wont-generate-new-pw
727 The server will not generate a new password for this
728 principal or does not support password generation in general.
730 - new-pw-rejected-generic
732 The client's proposed new password failed the target
733 principal's password quality policy.
735 The server MUST include a description of the password quality
736 policy or aspect of it that the client's proposed new
737 password failed to meet.
739 The server MAY generate and send a new password that the
740 client can then use as a new password and which is guaranteed
741 to pass the target principal's current password quality
742 policy.
744 The server MAY include a set of policy error code hints.
746 - etype-not-supported
748 The client requested an enctype that the KDC does not
749 support.
751 3.2.4 Set Kerberos Keys
753 N. Williams et. al. [Page 13]\f
755 DRAFT Kerberos Set/Change Password v2 Expires January 2005
758 NAME
760 set-keys
762 SYNOPSIS
764 Req-set-keys(new-keys, commit?, [isupport]) ->
765 Rep-set-keys([info-text], kvno, aliases, [isupport])
767 DESCRIPTION
769 The set-keys request consists of two required fields and one
770 optional field: "new-keys", "commit" (a boolean field - see below)
771 and "isupport", an optional field for indicating to the KDC what
772 Kerberos V features are supported by the target principal.
774 When "commit" is true the KDC makes the new keys available for
775 issueing tickets encrypted in them immediately. Otherwise the
776 client MUST follow up with a commit-keys request to make the keys
777 available. This feature is useful for changing keys shared by
778 multiple hosts, in clustered services, for example, in an atomic
779 manner; see section 3.2.6 and 3.2.7.
781 If a principal has keys are awaiting commitment when a new
782 set-keys request for that principal s made then the KDC MUST
783 overwrite the deferred keys.
785 RETURN
787 For successful set-keys operations the server returns:
789 - Informational text, optional.
791 - The new kvno for the target principal.
793 - A list of aliases of the target principal known to the KDC
794 (optional).
796 - The set of Kerberos V features supported by the KDC
797 (optional).
799 ERRORS
801 The server may respond with the following errors:
803 - generic
804 - deferred-commit-no-support
805 - etype-no-support
807 3.2.5 Generate Kerberos Keys
809 NAME
811 N. Williams et. al. [Page 14]\f
813 DRAFT Kerberos Set/Change Password v2 Expires January 2005
816 gen-keys
818 SYNOPSIS
820 Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
821 Rep-set-keys([info-text], key, kvno, aliases, [isupport])
823 DESCRIPTION
825 The gen-keys is similar to the set-keys request (see section
826 3.2.4) but differs in that the server generates keys of
827 client-requested enctypes, rather than the client providing
828 specific keys.
830 The gen-keys request consists of two required fields and two
831 optional fields: "etypes" (the enctypes of the new keys),
832 "entropy", "commit" and "isupport" (see section 3.2.4).
834 If a principal has keys are awaiting commitment when a new
835 set-keys request for that principal s made then the KDC MUST
836 overwrite the deferred keys.
838 RETURN
840 For successful set-keys operations the server returns:
842 - Informational text, optional.
844 - The new kvno for the target principal.
846 - The new key (only one is needed).
848 - A list of aliases of the target principal known to the KDC
849 (optional).
851 - The set of Kerberos V features supported by the KDC
852 (optional).
854 ERRORS
856 The server may respond with the following errors:
858 - generic
859 - deferred-commit-no-support
860 - etype-no-support
862 3.2.6 Get New Keys
864 NAME
866 get-keys
869 N. Williams et. al. [Page 15]\f
871 DRAFT Kerberos Set/Change Password v2 Expires January 2005
873 SYNOPSIS
875 Req-get-keys(kvno) ->
876 Rep-get-keys([info-text], keys, aliases, [isupport]) |
877 Err-get-keys([help-text], error code, [error info])
879 DESCRIPTION
881 This request allows a client to get the keys set or generated in a
882 previous set-keys or gen-keys request with deferred commitment..
884 RETURN
886 If the target principal and kvno correspond to uncommitted keys
887 the server MUST respond with the actual keys that would be set by
888 a subsequent commit-keys request. Otherwise the server MUST
889 respond with an error (meaning that this operation cannot be used
890 to extract keys from the KDC that may be in use).
892 ERRORS
894 - generic
895 - kvno-committed
896 - no-such-kvno
898 3.2.7 Commit New Keys
900 NAME
902 commit-keys
904 SYNOPSIS
906 Req-commit-keys(kvno) ->
907 Rep-commit-keys() |
908 Err-commit-keys([help-text], error code, [error info])
910 DESCRIPTION
912 The commit-keys operation allows a client to bring a principal's
913 new keys into use at the KDC.
915 Clients should make a commit-keys request corresponding to a
916 deferred commitment set-keys/gen-keys operation as soon as the
917 local key database for the target principal is updated.
919 The target principal name and the kvno MUST match those from a
920 prior set-keys or gen-keys operation.
922 Servers MAY expire delayed key commitments at will. Servers
923 SHOULD expire uncommitted new keys after a reasonable amount of
924 time (600 seconds is RECOMMENDED).
927 N. Williams et. al. [Page 16]\f
929 DRAFT Kerberos Set/Change Password v2 Expires January 2005
931 Servers MUST respond to new set-keys requests for principals with
932 pending, uncommitted new keys by expiring the uncommitted new keys
933 and proceeding as if there had been no expired new keys.
935 ERRORS
937 - generic
938 - op-kvno-expired
939 - op-kvno-unknown
940 - new-keys-conflict (A set-keys or gen-keys request succeeded
941 subsequent to the request that matches this
942 {principal, kvno} tuple.)
944 3.2.8 Get Password Quality Policy
946 NAME
948 get-pw-policy
950 SYNOPSIS
952 Req-get-pw-policy() ->
953 Rep-get-pw-policy([policy name], [policy description])
955 DESCRIPTION
957 Returns a description of the target principal's associated
958 password quality policy, if any, as a list of localized
959 UTF8String values.
961 Clients can use this operation in conjunction with the change-pw
962 operation to obtain text that can be displayed to the user before
963 the user actually enters a new password.
965 It is common for sites to set policies with respect to password
966 quality. It is beyond the scope of this document to describe such
967 policies. Management of password quality policies' actual content
968 is also beyond the scope of this protocol.
970 ERRORS
972 No operation errors are defined.
975 3.2.9 Get Principal Aliases
977 NAME
979 get-print-aliases
981 SYNOPSIS
983 Req-get-princ-aliases() ->
985 N. Williams et. al. [Page 17]\f
987 DRAFT Kerberos Set/Change Password v2 Expires January 2005
989 Rep-get-princ-aliases(aliases)
991 DESCRIPTION
993 Returns a list of aliases of the target principal.
995 ERRORS
997 No operation-specific errors.
999 3.2.10 Get Realm's Supported Kerberos V Version and Features
1001 NAME
1003 get-realm-krb5-support
1005 SYNOPSIS
1007 Req-get-realm-krb5-support() ->
1008 Rep-get-realm-krb5-support(isupport)
1010 DESCRIPTION
1012 Returns set of Kerberos V features support by the target
1013 principal's realm's KDCs.
1015 ERRORS
1017 No operation-specific errors.
1019 3.2.11 Retrieve Principal's S2K Params and Preferred Params
1021 NAME
1023 get-s2kparams
1025 SYNOPSIS
1027 Req-get-s2kparams() ->
1028 Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
1030 DESCRIPTION
1032 Returns the string2key parameters for the principal's current
1033 password-derived long-term keys, if any, and the parameters that
1034 the realm would prefer, if they differ from the former.
1036 This operation is intended for use with the change-pw() operation.
1037 When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
1038 the principal's long-term secret keys' string2key parameters (and
1039 enctype list) should be changed and, if so, change them.
1041 If the 'princ-s2kparams' return value is missing then the
1043 N. Williams et. al. [Page 18]\f
1045 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1047 principal does not have a password-derived long-term key.
1049 The 'preferred-s2kparams' MUST be excluded if the principal's
1050 string2key parameters satisfy the realm's policy.
1052 ERRORS
1054 No operation-specific errors.
1056 3.3 Principal Aliases
1058 Applications that use Kerberos often have to derive acceptor
1059 principal names from hostnames entered by users. Such hostnames may
1060 be aliases, they may be fully qualified, partially qualified or not
1061 qualified at all. Some implementations have resorted to deriving
1062 principal names from such hostnames by utilizing the names services
1063 to canonicalize the hostname first; such practices are not secure
1064 unless the name service are secure, which often aren't.
1066 One method for securely deriving principal names from hostnames is to
1067 alias principals at the KDC such that the KDC will issue tickets for
1068 principal names which are aliases of others. It is helpful for
1069 principals to know what are their aliases as known by the KDCs.
1071 Note that changing a principal's aliases is out of scope for this
1072 protocol.
1074 3.4 Kerberos V Feature Negotiation
1076 Principals and realms' KDCs may need to know about additional
1077 Kerberos V features and extensions that they each support. Several
1078 operations (see above) provide a way for clients and servers to
1079 exchange such infomration, in the form of lists of types supported
1080 for the various typed holes used in Kerberos V.
1082 4 ASN.1 Module
1084 DEFINITIONS EXPLICIT TAGS ::= BEGIN
1085 --
1086 -- Note: EXPLICIT tagging is in use by default throughout this
1087 -- module.
1089 -- From [clarifications] with modifications
1090 PrincipalName ::= SEQUENCE {
1091 name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
1092 }
1093 Realm ::= UTF8String (IA5String, ...)
1094 Salt ::= UTF8String (IA5String, ...)
1095 Password ::= UTF8String (IA5String, ...)
1097 -- NOTE WELL: Principal and realm names MUST be constrained by the
1098 -- specification of the version of Kerberos V used by the
1099 -- client.
1101 N. Williams et. al. [Page 19]\f
1103 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1105 --
1106 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
1107 -- type and a UTF8String, for simplicity.]
1109 -- From [clarifications]
1110 Int32 ::= INTEGER (-2147483648..2147483647)
1111 UInt32 ::= INTEGER (0..4294967295)
1113 -- Based on [clarifications]
1114 Etype ::= Int32
1115 Etype-Info-Entry ::= SEQUENCE {
1116 etype [0] Etype,
1117 salt [1] Salt OPTIONAL,
1118 s2kparams [2] OCTET STRING OPTIONAL,
1119 ...
1120 }
1121 Key ::= SEQUENCE {
1122 enc-type [0] Etype, -- from Kerberos
1123 key [1] OCTET STRING,
1124 ...
1125 }
1127 Language-Tag ::= UTF8String -- Constrained by [RFC3066]
1129 -- Empty, extensible SEQUENCEs are legal ASN.1
1130 Extensible-NULL ::= SEQUENCE {
1131 ...
1132 }
1134 -- Kerberos clients negotiate some parameters relating to their peers
1135 -- indirectly through the KDC. Today this is true of ticket session
1136 -- key enctypes, but in the future this indirect negotiation may also
1137 -- occur with respect to the minor version of Kerberos V to be used
1138 -- between clients and servers. Additionally, KDCs may need to know
1139 -- what authorization-data types are supported by service principals,
1140 -- both, for compatibility with legacy software and for optimization.
1141 --
1142 -- Thesefore it is important for KDCs to know what features of
1143 -- Kerberos V each service principal supports.
1144 --
1145 -- In version 2.0 of this protocol the clients and servers may notify
1146 -- each other of their support for:
1147 --
1148 -- - enctypes
1149 -- - authorization data types
1150 -- - transited encoding data types
1151 --
1152 -- All authorization-data types defined in [clarifications] are
1153 -- assumed to be supported if the minor version is 1 and do not need
1154 -- to be included in the ad-type list.
1155 --
1156 -- Int32 is used for enctype and transited encoding data type
1157 -- identifiers.
1159 N. Williams et. al. [Page 20]\f
1161 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1163 --
1164 -- An extensible CHOICE of Int32 is used for authorization data
1165 -- types.
1167 KerberosV-TR-ID ::= Int32
1169 KerberosV-AD-ID ::= CHOICE {
1170 ad-int [0] Int32,
1171 ...
1172 }
1174 KerberosVSupportNego ::= SEQUENCE {
1175 enc-types [0] SEQUENCE OF Etype,
1176 ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
1177 -- authorization data types
1178 tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
1179 -- transited encoding types
1180 ...
1181 }
1183 Request ::= [APPLICATION 0] SEQUENCE {
1184 pvno-minor [0] INTEGER DEFAULT 0,
1185 languages [1] SEQUENCE OF Language-Tag OPTIONAL,
1186 -- Should be defaulted to the SEQUENCE of "i-default"
1187 targ-name [2] PrincipalName OPTIONAL,
1188 targ-realm [3] Realm OPTIONAL,
1189 -- If targ-name/realm are missing then the request
1190 -- applies to the principal of the client
1191 dry-run [4] BOOLEAN DEFAULT FALSE,
1192 operation [5] Op-req,
1193 ...
1194 }
1196 Response ::= [APPLICATION 1] SEQUENCE {
1197 pvno-minor [0] INTEGER DEFAULT 0,
1198 language [1] Language-Tag DEFAULT "i-default",
1199 result [2] Op-rep,
1200 ...
1201 }
1203 Error-Response ::= [APPLICATION 2] SEQUENCE {
1204 pvno-minor [0] INTEGER DEFAULT 0,
1205 language [1] Language-Tag DEFAULT "i-default",
1206 error-code [2] ProtocolErrorCode,
1207 help-text [3] UTF8String OPTIONAL,
1208 op-error [4] Op-err OPTIONAL,
1209 ...
1210 }
1212 Op-req ::= CHOICE {
1213 null [0] Req-null,
1214 change-pw [1] Req-change-pw,
1215 set-pw [2] Req-set-pw,
1217 N. Williams et. al. [Page 21]\f
1219 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1221 set-keys [3] Req-set-keys,
1222 gen-keys [4] Req-gen-keys,
1223 get-keys [5] Req-get-keys,
1224 commit-keys [6] Req-commit-keys,
1225 get-pw-policy [7] Req-get-pw-policy,
1226 get-princ-aliases [8] Req-get-princ-aliases,
1227 get-realm-krb5-support [9] Req-get-realm-krb5-support,
1228 get-s2kparams [10] Req-get-s2kparams,
1229 ...
1230 }
1232 Op-rep ::= CHOICE {
1233 null [0] Rep-null,
1234 change-pw [1] Rep-change-pw,
1235 set-pw [2] Rep-set-pw,
1236 set-keys [3] Rep-set-keys,
1237 gen-keys [4] Req-gen-keys,
1238 get-keys [5] Req-get-keys,
1239 commit-keys [6] Rep-commit-keys,
1240 get-pw-policy [7] Rep-get-pw-policy,
1241 get-princ-aliases [8] Rep-get-princ-aliases,
1242 get-realm-krb5-support [9] Rep-get-realm-krb5-support,
1243 get-s2kparams [10] Rep-get-s2kparams,
1244 ...
1245 }
1247 Op-err ::= CHOICE {
1248 null [0] Err-null,
1249 change-pw [1] Err-change-pw,
1250 set-pw [2] Err-set-pw,
1251 set-keys [3] Err-set-keys,
1252 gen-keys [4] Err-gen-keys,
1253 get-keys [5] Err-get-keys,
1254 commit-keys [6] Err-commit-keys,
1255 get-pw-policy [7] Err-get-pw-policy,
1256 get-princ-aliases [8] Err-get-princ-aliases,
1257 get-realm-krb5-support [9] Err-get-realm-krb5-support,
1258 get-s2kparams [10] Err-get-s2kparams,
1259 ...
1260 }
1262 ProtocolErrorCode ::= ENUM {
1263 proto-format-error,
1264 proto-unsupported-major-version,
1265 proto-unsupported-minor-version,
1266 proto-unsupported-operation, -- Request CHOICE tag unknown
1267 proto-generic-see-op-error, -- See Op-error
1268 proto-wrong-service-principal, -- Use kadmin/setpw
1269 proto-re-authentication-required,
1270 proto-initial-ticket-required,
1271 proto-client-and-target-realm-mismatch,
1272 proto-target-principal-unknown,
1273 proto-authorization-failed,
1275 N. Williams et. al. [Page 22]\f
1277 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1279 proto-dry-run-not-permitted,
1280 ...
1281 }
1283 -- These codes are hints for clients, primarily for when they are
1284 -- used for changing the passwords of automated principals; error
1285 -- replies carry password quality policy help text that is more
1286 -- appropriate for clients to display to users.
1287 PW-Quality-Codes ::= ENUM {
1288 pwq-generic,
1289 pwq-too-soon,
1290 pwq-repeated,
1291 pwq-too-short,
1292 pwq-dictionary-words,
1293 pwq-prohibited-codepoints,
1294 pwq-need-more-char-classes,
1295 ...
1296 }
1298 --
1299 -- Requests and responses
1300 --
1302 -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
1303 Req-null ::= NULL
1305 Rep-null ::= NULL
1307 Err-null ::= NULL
1309 -- Change password
1310 Req-change-pw ::= SEQUENCE {
1311 old-pw [0] Password,
1312 new-pw [1] Password OPTIONAL,
1313 commit [2] BOOLEAN DEFAULT TRUE,
1314 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL,
1315 ...
1316 }
1318 Rep-change-pw ::= SEQUENCE {
1319 info-text [0] UTF8String OPTIONAL,
1320 new-pw [1] Password OPTIONAL,
1321 -- generated by the server if present
1322 -- (and requested by the client)
1323 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL,
1324 ...
1325 }
1327 Err-change-pw ::= SEQUENCE {
1328 help-text [0] UTF8String OPTIONAL,
1329 error [1] CHOICE {
1330 op-generic-error [0] Extensible-NULL,
1331 op-old-pw-incorrect [1] Extensible-NULL,
1333 N. Williams et. al. [Page 23]\f
1335 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1337 op-wont-generate-new-pw [2] Extensible-NULL,
1338 op-new-pw-rejected-generic [3] SEQUENCE {
1339 policy [1] SEQUENCE OF UTF8String,
1340 suggested-pw [2] Password OPTIONAL,
1341 policy-codes [3] SET OF PW-Quality-Codes
1342 OPTIONAL,
1343 ...
1344 }
1345 op-etype-not-supported [4] SEQUENCE {
1346 supported-etypes [1] SEQUENCE OF Etype,
1347 ...
1348 },
1349 ...
1350 },
1351 ...
1352 }
1354 -- Set password
1355 Req-set-pw ::= SEQUENCE {
1356 languages [0] SEQUENCE OF Language-Tag OPTIONAL,
1357 new-pw [1] Password OPTIONAL,
1358 commit [2] BOOLEAN DEFAULT TRUE,
1359 etypes [3] SEQUENCE (1..) OF Etype OPTIONAL,
1360 ...
1361 }
1363 Rep-set-pw ::= SEQUENCE {
1364 info-text [0] UTF8String OPTIONAL,
1365 new-pw [1] Password OPTIONAL,
1366 -- generated by the server if present
1367 -- (and requested by the client)
1368 etypes [2] SEQUENCE (1..) OF Etype OPTIONAL,
1369 ...
1370 }
1372 Err-set-pw ::= Err-change-pw
1374 -- Set keys
1375 Req-set-keys ::= SEQUENCE {
1376 keys [0] SEQUENCE OF Key,
1377 commit [1] BOOLEAN DEFAULT TRUE,
1378 -- TRUE -> install keys now
1379 --
1380 -- FALSE -> require set-keys-commit
1381 -- before issuing tickets
1382 -- encrypted with these keys.
1383 --
1384 -- See commit-keys op
1385 isupport [2] KerberosVSupportNego OPTIONAL,
1386 -- For future Kerberos V extensions KDCs
1387 -- may need to know what krb5 version is
1388 -- supported by individual service
1389 -- principals. This field provides a
1391 N. Williams et. al. [Page 24]\f
1393 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1395 -- way to tell the KDC what version of
1396 -- Kerberos V the target principal
1397 -- supports.
1398 ...
1399 }
1401 Rep-set-keys ::= SEQUENCE {
1402 info-text [0] UTF8String OPTIONAL,
1403 kvno [1] UInt32,
1404 aliases [2] SEQUENCE OF SEQUENCE {
1405 name [0] PrincipalName,
1406 realm [1] Realm OPTIONAL,
1407 ...
1408 },
1409 isupport [3] KerberosVSupportNego OPTIONAL,
1410 ...
1411 -- Should there be ETYPE-INFO2 stuff here?
1412 }
1414 Err-set-keys ::= SEQUENCE {
1415 help-text [0] UTF8String OPTIONAL, -- Reason for rejection
1416 error [1] CHOICE {
1417 op-generic [0] Extensible-NULL,
1418 op-deferred-commit-no-support [1] Extensible-NULL,
1419 op-etype-no-support [2] SEQUENCE OF {
1420 supported-etypes [1] SEQUENCE OF Etype,
1421 ...
1422 }
1423 ...
1424 }
1425 }
1427 -- Generate keys
1428 Req-gen-keys ::= SEQUENCE {
1429 etypes [0] SEQUENCE (1..) OF Etype,
1430 entropy [1] OCTET STRING OPTIONAL,
1431 commit [2] BOOLEAN DEFAULT TRUE,
1432 -- TRUE -> install keys now
1433 --
1434 -- FALSE -> require set-keys-commit
1435 -- before issuing tickets
1436 -- encrypted with these keys.
1437 --
1438 -- See commit-keys op
1439 isupport [3] KerberosVSupportNego OPTIONAL,
1440 -- For future Kerberos V extensions KDCs
1441 -- may need to know what krb5 version is
1442 -- supported by individual service
1443 -- principals. This field provides a
1444 -- way to tell the KDC what version of
1445 -- Kerberos V the target principal
1446 -- supports.
1447 ...
1449 N. Williams et. al. [Page 25]\f
1451 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1453 }
1455 Rep-gen-keys ::= SEQUENCE {
1456 info-text [0] UTF8String OPTIONAL,
1457 kvno [1] UInt32,
1458 key [2] Key,
1459 aliases [3] SEQUENCE OF SEQUENCE {
1460 name [0] PrincipalName,
1461 realm [1] Realm OPTIONAL,
1462 ...
1463 },
1464 isupport [4] KerberosVSupportNego OPTIONAL,
1465 ...
1466 -- Should there be ETYPE-INFO2 stuff here?
1467 }
1469 Err-gen-keys ::= Err-set-keys
1471 -- Get un-committed key request
1472 Req-get-keys ::= SEQUENCE {
1473 kvno [0] UInt32,
1474 ...
1475 }
1477 Rep-get-keys ::= SEQUENCE {
1478 info-text [0] UTF8String OPTIONAL,
1479 keys [1] SEQUENCE OF Key,
1480 aliases [2] SEQUENCE OF SEQUENCE {
1481 name [0] PrincipalName,
1482 realm [1] Realm OPTIONAL,
1483 ...
1484 },
1485 isupport [3] KerberosVSupportNego OPTIONAL,
1486 ...
1487 -- Should there be ETYPE-INFO2 stuff here?
1488 }
1490 Err-get-keys ::= SEQUENCE {
1491 help-text [0] UTF8String OPTIONAL, -- Reason for rejection
1492 error [1] CHOICE {
1493 op-generic [0] Extensible-NULL,
1494 op-kvno-committed [1] Extensible-NULL,
1495 op-no-such-kvno [1] Extensible-NULL,
1496 ...
1497 }
1498 }
1500 -- Commit a set keys request
1501 Req-commit-keys ::= SEQUENCE {
1502 kvno [0] UInt32,
1503 ...
1504 }
1507 N. Williams et. al. [Page 26]\f
1509 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1511 Rep-commit-keys ::= Extensible-NULL
1513 Err-commit-keys ::= SEQUENCE {
1514 help-text [0] UTF8String OPTIONAL, -- Reason for rejection
1515 error [1] CHOICE {
1516 op-generic [0] Extensible-NULL,
1517 op-kvno-expired [1] Extensible-NULL,
1518 -- The client took too long to respond.
1519 op-kvno-unknown [2] Extensible-NULL,
1520 -- The targ princ/kvno is invalid or unknown to the
1521 -- server (perhaps it lost track of state)
1522 op-new-keys-conflict [3] Extensible-NULL,
1523 -- A new-keys/commit-keys request subsequent to the
1524 -- new-keys that produced the kvno has completed
1525 -- and incremented the principal's kvno
1526 ...
1527 }
1528 ...
1529 }
1531 -- Get password policy
1532 Req-get-pw-policy ::= Extensible-NULL
1534 Rep-get-pw-policy ::= SEQUENCE {
1535 policy-name [0] UTF8String OPTIONAL,
1536 description [1] SEQUENCE OF UTF8String OPTIONAL,
1537 ...
1538 }
1540 Err-get-pw-policy ::= Extensible-NULL
1542 -- Get principal aliases
1543 Req-get-princ-aliases ::= Extensible-NULL
1545 Rep-get-princ-aliases ::= SEQUENCE {
1546 help-text [0] UTF8String OPTIONAL,
1547 aliases [1] SEQUENCE OF SEQUENCE {
1548 name [0] PrincipalName,
1549 realm [1] Realm OPTIONAL,
1550 ...
1551 },
1552 ...
1553 }
1555 Err-get-princ-aliases ::= Extensible-NULL
1557 -- Get list of enctypes supported by KDC for new keys
1558 Req-get-realm-krb5-support ::= Extensible-NULL
1560 Rep-get-realm-krb5-support ::= SEQUENCE {
1561 isupport [0] KerberosVSupportNego,
1562 -- Version of Kerberos V supported by
1563 -- the target realm.
1565 N. Williams et. al. [Page 27]\f
1567 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1569 ...
1570 }
1572 Err-get-realm-krb5-support ::= Extensible-NULL
1574 -- Get s2kparams
1575 Req-get-s2kparams ::= Extensible-NULL
1577 Rep-get-s2kparams ::= SEQUENCE {
1578 help-text [0] UTF8String OPTIONAL,
1579 s2kparams [1] SEQUENCE OF Etype-Info-Entry,
1580 ...
1581 }
1583 Err-get-s2kparams ::= Extensible-NULL
1585 END
1588 6 IANA Considerations
1590 There are no IANA considerations for this document.
1592 7 Security Considerations
1594 Implementors and site administrators should note that the redundancy
1595 of UTF-8 encodings of passwords varies by language. Password quality
1596 policies SHOULD, therefore, take this into account when estimating
1597 the amount of redundancy and entropy in a proposed new password. [??
1598 It's late at night - I think this is correct.]
1600 Kerberos set/change password/key protocol major version negotiation
1601 cannot be done securely; a downgrade attack is possible against
1602 clients that attempt to negotiate the protocol major version to use
1603 with a server. It is not clear at this time that the attacker would
1604 gain much from such a downgrade attack other than denial of service
1605 (DoS) by forcing the client to use a protocol version which does not
1606 support some feature needed by the client (Kerberos V in general is
1607 subject to a variety of DoS attacks anyways [RFC1510]). Clients
1608 SHOULD NOT negotiate support for legacy major versions of this
1609 protocol unless configured otherwise.
1611 This protocol does not have Perfect Forward Security (PFS). As a
1612 result, any passive network snooper watching password/key changing
1613 operations who has stolen a principal's password or long-term keys
1614 can find out what the new ones are.
1616 [More text needed?]
1618 8 Acknowledgements
1620 The authors would like to thank Bill GossmanMike Swift, John Brezak,
1621 Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
1623 N. Williams et. al. [Page 28]\f
1625 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1627 Nelson, Marcus Watts, Love, Joel N. Weber II, Jeffrey Hutzelman and
1628 other participants from the IETF Kerberos Working Group for their
1629 assistance.
1631 9 References
1633 9.1 Normative References
1635 [RFC2026]
1636 S. Bradner, RFC2026: "The Internet Standard Process - Revision
1637 3," October 1996, Obsoletes - RFC 1602, Status: Best Current
1638 Practice.
1640 [RFC2119]
1641 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to
1642 Indicate Requirement Levels," March 1997, Status: Best Current
1643 Practice.
1645 [X680]
1646 Abstract Syntax Notation One (ASN.1): Specification of Basic
1647 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
1648 International Standard 8824-1:1998.
1649 http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
1651 [X690]
1652 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
1653 Canonical Encoding Rules (CER) and Distinguished Encoding Rules
1654 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
1655 Standard 8825-1:1998.
1656 http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
1658 [clarifications]
1659 RFC-Editor: To be replaced by RFC number for
1660 draft-ietf-krb-wg-kerberos-clarifications.
1662 [RFC3066]
1663 H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
1664 Languages," January 2001, Obsoletes RFC1766, Status: Best Current
1665 Practice.
1667 9.2 Informative References
1669 [RFC3244]
1670 M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
1671 Kerberos Change Password and Set Password Protocols," February
1672 2002, Status: Informational.
1674 10 Authors' Addresses
1676 Nicolas Williams
1677 Sun Microsystems
1678 5300 Riata Trace Ct
1679 Austin, TX 78727
1681 N. Williams et. al. [Page 29]\f
1683 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1685 Email: nicolas.williams@sun.com
1687 Jonathan Trostle
1688 Cisco Systems
1689 170 W. Tasman Dr.
1690 San Jose, CA 95134
1691 Email: jtrostle@cisco.com
1693 11 Notes to the RFC Editor
1695 This document has two KRB WG drafts as normative references and
1696 cannot progress until those drafts progress, but no other draft
1697 depends on this one.
1699 12 Change History
1701 -01 -> -02
1703 - Removed Bill Gossman, Mike Swift and John Brezak as authors.
1705 - Removed UDP as a transport for this protocol.
1707 - Replaced redundant copies of framing ASCII art with reference to
1708 RFC3244.
1710 - Made all name/password strings UTF8String with an extensible
1711 constraint to IA5String.
1713 - Added a method for doing dry runs of operations. This is helpful
1714 in testing passwords against password quality policies.
1716 - Added an operation for retrieving a principal's current and
1717 preferred string-to-key parameters, and a way to change them
1718 without changing the principal's password.
1720 - Added password quality codes as hints for smart clients, but
1721 these are optional and not to be used instead of messages to be
1722 displayed to useds.
1724 - Added a 'commit' option to change-pw and set-pw (as requested by
1725 Larry).
1727 - Removed "version" field of the Kerberos V feature negotiation
1728 struture.
1732 N. Williams et. al. [Page 30]\f
1734 DRAFT Kerberos Set/Change Password v2 Expires January 2005
1738 Intellectual Property Statement
1740 The IETF takes no position regarding the validity or scope of any
1741 Intellectual Property Rights or other rights that might be claimed to
1742 pertain to the implementation or use of the technology described in
1743 this document or the extent to which any license under such rights
1744 might or might not be available; nor does it represent that it has
1745 made any independent effort to identify any such rights. Information
1746 on the procedures with respect to rights in RFC documents can be
1747 found in BCP 78 and BCP 79.
1749 Copies of IPR disclosures made to the IETF Secretariat and any
1750 assurances of licenses to be made available, or the result of an
1751 attempt made to obtain a general license or permission for the use of
1752 such proprietary rights by implementers or users of this
1753 specification can be obtained from the IETF on-line IPR repository at
1754 http://www.ietf.org/ipr.
1756 The IETF invites any interested party to bring to its attention any
1757 copyrights, patents or patent applications, or other proprietary
1758 rights that may cover technology that may be required to implement
1759 this standard. Please address the information to the IETF at
1760 ietf-ipr@ietf.org.
1763 Disclaimer of Validity
1765 This document and the information contained herein are provided on an
1766 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1767 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1768 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1769 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1770 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1771 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1774 Copyright Statement
1776 Copyright (C) The Internet Society (2004). This document is subject
1777 to the rights, licenses and restrictions contained in BCP 78, and
1778 except as set forth therein, the authors retain all their rights.
1780 Acknowledgment
1782 Funding for the RFC Editor function is currently provided by the
1783 Internet Society.
1792 N. Williams et. al. [Page 31]\f