One document matched: draft-ietf-krb-wg-kerberos-set-passwd-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM '~/public_html/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3066 SYSTEM '~/public_html/bibxml/reference.RFC.3066.xml'>
<!ENTITY rfc3244 SYSTEM '~/public_html/bibxml/reference.RFC.3244.xml'>
<!ENTITY rfc4120 SYSTEM '~/public_html/bibxml/reference.RFC.4120.xml'>
<!ENTITY x680 SYSTEM '~/public_html/bibxml/reference.CCITT.X680.2002.xml'>
<!ENTITY x690 SYSTEM '~/public_html/bibxml/reference.CCITT.X690.2002.xml'>
]>
<!--
To make it easier to re-format from the original raw text we use
XML entities (text macros) to drop the old, pre-formatted (but
not paginated) operation description text, one macro
per-operation.
These are internal entities, meaning the text is all in the same
doc, but we could make these external entities, i.e., each one
in its own file (perhaps that would eliminate the need to escape
angle brackets, ampersands and single quotes in the text).
-->
<!ENTITY null '
NAME
null - Null or "ping" operation
DESCRIPTION
The null request is intended for use with TCP; its purpose is
similar to RPC null procedures and is akin to a "ping" operation.
ERRORS
None.
'>
<!ENTITY change-pw '
NAME
change-pw - Change password operation
SYNOPSIS
Req-change-pw(old-pw, [languages], [new-pw],
[commit], [etypes]) ->
Rep-change-pw([info-text], [new-pw], [etypes]) |
Err-change-pw([help-text], error code, [error info])
DESCRIPTION
Change a principal's password.
The change password request has one required, three optional and
one defaulted arguments: "old-pw" (required), "languages,"
"new-pw", "commit" (defaults to "TRUE") and "etypes",
corresponding to the target principal's old password, its
preferred languages, its new password, a boolean indicating
whether or not to make the new long-term key available for
immediate use, and the desired enctypes for the new long-term
keys.
The server MUST validate the old password and MUST check the
quality of the new password, if sent, according the password
quality policy associated with the target principal.
If the old and new passwords in the request are the same strings,
and the principal is not currently required to change its
password, then the server MAY permit the password change as way to
change a principal's enctypes and string-to-key parameters. This
feature provides a way to, for example, add enctypes to a
principals' password-derived long-term keys without forcing a
password change following an upgrade to the KDC that adds support
for new enctypes.
A client MAY request that the server generate a new password by
excluding the new password from its request, in which case the
server MUST either generate a new password or respond with an
error indicating that it does not support this feature.
Server-generated passwords MUST meet the target principal's
password quality policy. It is RECOMMENDED that server-generated
passwords be user-friendly, that is, memorable and that the target
principal's preferred languages be taken into account by the
password generation alogrithm used by the server.
Uncommitted password changes are commited using the commit-keys
operation.
RETURN
Upon successful password changes the server responds with a
Rep-change-pw. The fields of Rep-change-pw are all optional and
include:
- 'info-text' which the server can use to send a message to the
user such as "Your new password will expire in 90 days," for
example.
- 'new-pw' which the server MUST include if the client
requested that the server generate a new password; generated
passwords MUST pass the target principal's password quality
policy.
- 'etypes' which the server MAY include to indicate which types
of long-term keys it created for the target principal and
which the server MUST include if the client specified a set
of enctypes in its request.
ERRORS
The server may respond to change password requests with protocol
or operation errors.
All operation errors include an optional 'help-text' field by
which the server can describe the error in a human-readable,
localizaed string.
Change password error codes include:
- generic-error
- old-pw-incorrect
- wont-generate-new-pw
The server will not generate a new password for this
principal or does not support password generation in general.
- new-pw-rejected-generic
The client's proposed new password failed the target
principal's password quality policy.
The server MUST include a description of the password quality
policy or aspect of it that the client's proposed new
password failed to meet.
The server MAY generate and send a new password that the
client can then use as a new password and which is guaranteed
to pass the target principal's current password quality
policy.
The server MAY include a set of policy error code hints.
- etype-not-supported
The client requested an enctype that the KDC does not
support.
'>
<!ENTITY set-pw '
NAME
set-pw - Set password operation
SYNOPSIS
Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
Rep-set-pw([info-text], [new-pw], [etypes]) |
Err-set-pw([help-text], error code, [error info])
DESCRIPTION
Administratively set a principal's password.
The set password request has three optional and one defaulted
arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
and "etypes", corresponding to the target principal's preferred
languages, new password, a boolean indicating whether or not to
make the new long-term key available for immediate use, and the
desired enctypes for the new long-term keys.
The server MUST check the quality of the new password, if sent,
according the password quality policy associated with the target
principal.
The server SHOULD require that the client use the change-pw
operation instead of set-pw when the client principal and the
target principal are the same.
A client MAY request that the server generate a new password by
excluding the new password from its request, in which case the
server MUST either generate a new password or respond with an
error indicating that it does not support this feature.
Server-generated passwords MUST meet the target principal's
password quality policy. It is RECOMMENDED that server-generated
passwords be user-friendly, that is, memorable and that the target
principal's preferred languages be taken into account by the
password generation alogrithm used by the server.
RETURN
Upon successfully setting a password the server responds with a
Rep-set-pw. The fields of Rep-set-pw are all optional and
include:
- 'info-text' which the server can use to send a message to the
user such as "Your new password will expire in 90 days," for
example.
- 'new-pw' which the server MUST include if the client
requested that the server generate a new password; generated
passwords MUST pass the target principal's password quality
policy.
- 'etypes' which the server MAY include to indicate which types
of long-term keys it created for the target principal and
which the server MUST include if the client specified a set
of enctypes in its request.
ERRORS
The server may respond to set password requests with protocol or
operation errors.
All operation errors include an optional 'help-text' field by
which the server can describe the error in a human-readable,
localizaed string.
Set password error codes include:
- generic-error
- use-change-pw
The server demands that the client use the change-pw
operation for the target principal of the set-pw request.
- wont-generate-new-pw
The server will not generate a new password for this
principal or does not support password generation in general.
- new-pw-rejected-generic
The client's proposed new password failed the target
principal's password quality policy.
The server MUST include a description of the password quality
policy or aspect of it that the client's proposed new
password failed to meet.
The server MAY generate and send a new password that the
client can then use as a new password and which is guaranteed
to pass the target principal's current password quality
policy.
The server MAY include a set of policy error code hints.
- etype-not-supported
The client requested an enctype that the KDC does not
support.
'>
<!ENTITY set-keys '
NAME
set-keys - Set a principal's long-term keys
SYNOPSIS
Req-set-keys(new-keys, commit?, [isupport]) ->
Rep-set-keys([info-text], kvno, aliases, [isupport])
DESCRIPTION
The set-keys request consists of two required fields and one
optional field: "new-keys", "commit" (a boolean field - see below)
and "isupport", an optional field for indicating to the KDC what
Kerberos V features are supported by the target principal.
When "commit" is true the KDC makes the new keys available for
issueing tickets encrypted in them immediately. Otherwise the
client MUST follow up with a commit-keys request to make the keys
available. This feature is useful for changing keys shared by
multiple hosts, in clustered services, for example, in an atomic
manner.
If a principal has keys are awaiting commitment when a new
set-keys request for that principal s made then the KDC MUST
overwrite the deferred keys.
RETURN
For successful set-keys operations the server returns:
- Informational text, optional.
- The new kvno for the target principal.
- A list of aliases of the target principal known to the KDC
(optional).
- The set of Kerberos V features supported by the KDC
(optional).
ERRORS
The server may respond with the following errors:
- generic
- deferred-commit-no-support
- etype-no-support
'>
<!ENTITY gen-keys '
NAME
gen-keys - Generate long-term keys for a principal
SYNOPSIS
Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
Rep-set-keys([info-text], key, kvno, aliases, [isupport])
DESCRIPTION
The gen-keys is similar to the set-keys request but differs in
that the server generates keys of client-requested enctypes,
rather than the client providing specific keys.
The gen-keys request consists of two required fields and two
optional fields: "etypes" (the enctypes of the new keys),
"entropy", "commit" and "isupport".
If a principal has keys are awaiting commitment when a new
set-keys request for that principal s made then the KDC MUST
overwrite the deferred keys.
RETURN
For successful set-keys operations the server returns:
- Informational text, optional.
- The new kvno for the target principal.
- The new key (only one is needed).
- A list of aliases of the target principal known to the KDC
(optional).
- The set of Kerberos V features supported by the KDC
(optional).
ERRORS
The server may respond with the following errors:
- generic
- deferred-commit-no-support
- etype-no-support
'>
<!ENTITY get-keys '
NAME
get-keys - Retrieve a principal's uncommitted keys
SYNOPSIS
Req-get-keys(kvno) ->
Rep-get-keys([info-text], keys, aliases, [isupport]) |
Err-get-keys([help-text], error code, [error info])
DESCRIPTION
This request allows a client to get the keys set or generated in a
previous set-keys or gen-keys request with deferred commitment.
RETURN
If the target principal and kvno correspond to uncommitted keys
the server MUST respond with the actual keys that would be set by
a subsequent commit-keys request. Otherwise the server MUST
respond with an error (meaning that this operation cannot be used
to extract keys from the KDC that may be in use).
ERRORS
- generic
- kvno-committed
- no-such-kvno
'>
<!ENTITY commit-keys '
NAME
commit-keys - Commit a principal's new long-term keys
SYNOPSIS
Req-commit-keys(kvno) ->
Rep-commit-keys() |
Err-commit-keys([help-text], error code, [error info])
DESCRIPTION
The commit-keys operation allows a client to bring a principal's
new keys into use at the KDC.
Clients should make a commit-keys request corresponding to a
deferred commitment set-keys/gen-keys operation as soon as the
local key database for the target principal is updated.
The target principal name and the kvno MUST match those from a
prior set-keys or gen-keys operation.
Servers MAY expire delayed key commitments at will. Servers
SHOULD expire uncommitted new keys after a reasonable amount of
time (600 seconds is RECOMMENDED).
Servers MUST respond to new set-keys requests for principals with
pending, uncommitted new keys by expiring the uncommitted new keys
and proceeding as if there had been no expired new keys.
ERRORS
- generic
- op-kvno-expired
- op-kvno-unknown
- new-keys-conflict (A set-keys or gen-keys request succeeded
subsequent to the request that matches this
{principal, kvno} tuple.)
'>
<!ENTITY get-pw-policy '
NAME
get-pw-policy - Retrieve a principal's password policy
SYNOPSIS
Req-get-pw-policy() ->
Rep-get-pw-policy([policy name], [policy description])
DESCRIPTION
Returns a description of the target principal's associated
password quality policy, if any, as a list of localized
UTF8String values.
Clients can use this operation in conjunction with the change-pw
operation to obtain text that can be displayed to the user before
the user actually enters a new password.
It is common for sites to set policies with respect to password
quality. It is beyond the scope of this document to describe such
policies. Management of password quality policies' actual content
is also beyond the scope of this protocol.
ERRORS
No operation errors are defined.
'>
<!ENTITY get-princ-aliases '
NAME
get-princ-aliases - Retrieve a principal's aliases
SYNOPSIS
Req-get-princ-aliases() ->
Rep-get-princ-aliases(aliases)
DESCRIPTION
Returns a list of aliases of the target principal.
ERRORS
No operation-specific errors.
'>
<!ENTITY get-realm-krb5-support '
NAME
get-realm-krb5-support - List features supported by the realm
SYNOPSIS
Req-get-realm-krb5-support() ->
Rep-get-realm-krb5-support(isupport)
DESCRIPTION
Returns set of Kerberos V features support by the target
principal's realm's KDCs.
ERRORS
No operation-specific errors.
'>
<!ENTITY get-s2kparams '
NAME
get-s2kparams
SYNOPSIS
Req-get-s2kparams() ->
Rep-get-s2kparams(princ-s2kparams)
DESCRIPTION
Returns the string2key parameters for the principal's current
password-derived long-term keys, if any (if there are none then
the principal does not have a password-derived long-term key).
ERRORS
No operation-specific errors.
'>
<!ENTITY asn1module '
DEFINITIONS EXPLICIT TAGS ::= BEGIN
--
-- Note: EXPLICIT tagging is in use by default throughout this
-- module.
-- From [clarifications] with modifications
PrincipalName ::= SEQUENCE {
name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
}
Realm ::= UTF8String (IA5String, ...)
Salt ::= UTF8String (IA5String, ...)
Password ::= UTF8String (IA5String, ...)
-- NOTE WELL: Principal and realm names MUST be constrained by the
-- specification of the version of Kerberos V used by the
-- client.
--
-- [Perhaps PrincipalName should be a SEQUENCE of an optional name
-- type and a UTF8String, for simplicity.]
-- From [clarifications]
Int32 ::= INTEGER (-2147483648..2147483647)
UInt32 ::= INTEGER (0..4294967295)
-- Based on [clarifications]
Etype ::= Int32
Etype-Info-Entry ::= SEQUENCE {
etype [0] Etype,
salt [1] Salt OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL
}
Key ::= SEQUENCE {
enc-type [0] Etype, -- from Kerberos
key [1] OCTET STRING
}
Language-Tag ::= UTF8String -- Constrained by [RFC3066]
-- Empty, extensible SEQUENCEs are legal ASN.1
Extensible-NULL ::= SEQUENCE {
...
}
-- Kerberos clients negotiate some parameters relating to their peers
-- indirectly through the KDC. Today this is true of ticket session
-- key enctypes, but in the future this indirect negotiation may also
-- occur with respect to the minor version of Kerberos V to be used
-- between clients and servers. Additionally, KDCs may need to know
-- what authorization-data types are supported by service principals,
-- both, for compatibility with legacy software and for optimization.
--
-- Thesefore it is important for KDCs to know what features of
-- Kerberos V each service principal supports.
--
-- In version 2.0 of this protocol the clients and servers may notify
-- each other of their support for:
--
-- - enctypes
-- - authorization data types
-- - transited encoding data types
--
-- All authorization-data types defined in [clarifications] are
-- assumed to be supported if the minor version is 1 and do not need
-- to be included in the ad-type list.
--
-- Int32 is used for enctype and transited encoding data type
-- identifiers.
--
-- An extensible CHOICE of Int32 is used for authorization data
-- types.
KerberosV-TR-ID ::= Int32
KerberosV-AD-ID ::= CHOICE {
ad-int [0] Int32,
...
}
KerberosVSupportNego ::= SEQUENCE {
enc-types [0] SEQUENCE OF Etype,
ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
-- authorization data types
tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL
-- transited encoding types
}
Request ::= [APPLICATION 0] SEQUENCE {
pvno-minor [0] INTEGER DEFAULT 0,
languages [1] SEQUENCE OF Language-Tag OPTIONAL,
-- Should be defaulted to the SEQUENCE of "i-default"
targ-name [2] PrincipalName OPTIONAL,
targ-realm [3] Realm OPTIONAL,
-- If targ-name/realm are missing then the request
-- applies to the principal of the client
dry-run [4] BOOLEAN DEFAULT FALSE,
operation [5] Op-req,
...
}
Response ::= [APPLICATION 1] SEQUENCE {
pvno-minor [0] INTEGER DEFAULT 0,
language [1] Language-Tag DEFAULT "i-default",
result [2] Op-rep,
...
}
Error-Response ::= [APPLICATION 2] SEQUENCE {
pvno-minor [0] INTEGER DEFAULT 0,
language [1] Language-Tag DEFAULT "i-default",
error-code [2] ProtocolErrorCode,
help-text [3] UTF8String OPTIONAL,
op-error [4] Op-err OPTIONAL,
...
}
Op-req ::= CHOICE {
null [0] Req-null,
change-pw [1] Req-change-pw,
set-pw [2] Req-set-pw,
set-keys [3] Req-set-keys,
gen-keys [4] Req-gen-keys,
get-keys [5] Req-get-keys,
commit-keys [6] Req-commit-keys,
get-pw-policy [7] Req-get-pw-policy,
get-princ-aliases [8] Req-get-princ-aliases,
get-realm-krb5-support [9] Req-get-realm-krb5-support,
get-s2kparams [10] Req-get-s2kparams,
...
}
Op-rep ::= CHOICE {
null [0] Rep-null,
change-pw [1] Rep-change-pw,
set-pw [2] Rep-set-pw,
set-keys [3] Rep-set-keys,
gen-keys [4] Req-gen-keys,
get-keys [5] Req-get-keys,
commit-keys [6] Rep-commit-keys,
get-pw-policy [7] Rep-get-pw-policy,
get-princ-aliases [8] Rep-get-princ-aliases,
get-realm-krb5-support [9] Rep-get-realm-krb5-support,
get-s2kparams [10] Rep-get-s2kparams,
...
}
Op-err ::= CHOICE {
null [0] Err-null,
change-pw [1] Err-change-pw,
set-pw [2] Err-set-pw,
set-keys [3] Err-set-keys,
gen-keys [4] Err-gen-keys,
get-keys [5] Err-get-keys,
commit-keys [6] Err-commit-keys,
get-pw-policy [7] Err-get-pw-policy,
get-princ-aliases [8] Err-get-princ-aliases,
get-realm-krb5-support [9] Err-get-realm-krb5-support,
get-s2kparams [10] Err-get-s2kparams,
...
}
ProtocolErrorCode ::= ENUM {
proto-format-error,
proto-unsupported-major-version,
proto-unsupported-minor-version,
proto-unsupported-operation, -- Request CHOICE tag unknown
proto-generic-see-op-error, -- See Op-error
proto-wrong-service-principal, -- Use kadmin/setpw
proto-re-authentication-required,
proto-initial-ticket-required,
proto-client-and-target-realm-mismatch,
proto-target-principal-unknown,
proto-authorization-failed,
proto-dry-run-not-permitted,
proto-fresh-ticket-required,
...
}
-- These codes are hints for clients, primarily for when they are
-- used for changing the passwords of automated principals; error
-- replies carry password quality policy help text that is more
-- appropriate for clients to display to users.
PW-Quality-Codes ::= ENUM {
pwq-generic,
pwq-too-soon,
pwq-history,
pwq-too-short,
pwq-dictionary-words,
pwq-prohibited-codepoints,
pwq-need-more-char-classes,
...
}
--
-- Requests and responses
--
-- NULL request, much like ONC RPC's NULL procedure - NOT extensible
Req-null ::= NULL
Rep-null ::= NULL
Err-null ::= NULL
-- Change password
Req-change-pw ::= SEQUENCE {
old-pw [0] Password,
new-pw [1] Password OPTIONAL,
commit [2] BOOLEAN DEFAULT TRUE,
etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Rep-change-pw ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
new-pw [1] Password OPTIONAL,
-- generated by the server if present
-- (and requested by the client)
etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Err-change-pw ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL,
error [1] CHOICE {
op-generic-error [0] Extensible-NULL,
op-old-pw-incorrect [1] Extensible-NULL,
op-wont-generate-new-pw [2] Extensible-NULL,
op-new-pw-rejected-generic [3] SEQUENCE {
policy [1] SEQUENCE OF UTF8String,
suggested-pw [2] Password OPTIONAL,
policy-codes [3] SET OF PW-Quality-Codes
OPTIONAL
}
op-etype-not-supported [4] SEQUENCE {
supported-etypes [1] SEQUENCE OF Etype
}
}
}
-- Set password
Req-set-pw ::= SEQUENCE {
languages [0] SEQUENCE OF Language-Tag OPTIONAL,
new-pw [1] Password OPTIONAL,
commit [2] BOOLEAN DEFAULT TRUE,
etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Rep-set-pw ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
new-pw [1] Password OPTIONAL,
-- generated by the server if present
-- (and requested by the client)
etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Err-set-pw ::= Err-change-pw
-- Set keys
Req-set-keys ::= SEQUENCE {
keys [0] SEQUENCE OF Key,
commit [1] BOOLEAN DEFAULT TRUE,
-- TRUE -> install keys now
--
-- FALSE -> require set-keys-commit
-- before issuing tickets
-- encrypted with these keys.
--
-- See commit-keys op
isupport [2] KerberosVSupportNego OPTIONAL
-- For future Kerberos V extensions KDCs
-- may need to know what krb5 version is
-- supported by individual service
-- principals. This field provides a
-- way to tell the KDC what version of
-- Kerberos V the target principal
-- supports.
}
Rep-set-keys ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
kvno [1] UInt32,
aliases [2] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
},
isupport [3] KerberosVSupportNego OPTIONAL
-- Should there be ETYPE-INFO2 stuff here?
}
Err-set-keys ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL, -- Reason for rejection
error [1] CHOICE {
op-generic [0] Extensible-NULL,
op-deferred-commit-no-support [1] Extensible-NULL,
op-etype-no-support [2] SEQUENCE OF {
supported-etypes [1] SEQUENCE OF Etype
}
}
}
-- Generate keys
Req-gen-keys ::= SEQUENCE {
etypes [0] SEQUENCE (1..MAX) OF Etype,
entropy [1] OCTET STRING OPTIONAL,
commit [2] BOOLEAN DEFAULT TRUE,
-- TRUE -> install keys now
--
-- FALSE -> require set-keys-commit
-- before issuing tickets
-- encrypted with these keys.
--
-- See commit-keys op
isupport [3] KerberosVSupportNego OPTIONAL
-- For future Kerberos V extensions KDCs
-- may need to know what krb5 version is
-- supported by individual service
-- principals. This field provides a
-- way to tell the KDC what version of
-- Kerberos V the target principal
-- supports.
}
Rep-gen-keys ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
kvno [1] UInt32,
key [2] Key,
aliases [3] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
},
isupport [4] KerberosVSupportNego OPTIONAL
-- Should there be ETYPE-INFO2 stuff here?
}
Err-gen-keys ::= Err-set-keys
-- Get un-committed key request
Req-get-keys ::= SEQUENCE {
kvno [0] UInt32
}
Rep-get-keys ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
keys [1] SEQUENCE OF Key,
aliases [2] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
},
isupport [3] KerberosVSupportNego OPTIONAL
-- Should there be ETYPE-INFO2 stuff here?
}
Err-get-keys ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL, -- Reason for rejection
error [1] CHOICE {
op-generic [0] Extensible-NULL,
op-kvno-committed [1] Extensible-NULL,
op-no-such-kvno [1] Extensible-NULL
}
}
-- Commit a set keys request
Req-commit-keys ::= SEQUENCE {
kvno [0] UInt32
}
Rep-commit-keys ::= Extensible-NULL
Err-commit-keys ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL, -- Reason for rejection
error [1] CHOICE {
op-generic [0] Extensible-NULL,
op-kvno-expired [1] Extensible-NULL,
-- The client took too long to respond.
op-kvno-unknown [2] Extensible-NULL,
-- The targ princ/kvno is invalid or unknown to the
-- server (perhaps it lost track of state)
op-new-keys-conflict [3] Extensible-NULL
-- A new-keys/commit-keys request subsequent to the
-- new-keys that produced the kvno has completed
-- and incremented the principal's kvno
}
}
-- Get password policy
Req-get-pw-policy ::= Extensible-NULL
Rep-get-pw-policy ::= SEQUENCE {
policy-name [0] UTF8String OPTIONAL,
description [1] SEQUENCE OF UTF8String OPTIONAL
}
Err-get-pw-policy ::= Extensible-NULL
-- Get principal aliases
Req-get-princ-aliases ::= Extensible-NULL
Rep-get-princ-aliases ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL,
aliases [1] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
}
}
Err-get-princ-aliases ::= Extensible-NULL
-- Get list of enctypes supported by KDC for new keys
Req-get-realm-krb5-support ::= Extensible-NULL
Rep-get-realm-krb5-support ::= SEQUENCE {
isupport [0] KerberosVSupportNego
-- Version of Kerberos V supported by
-- the target realm.
}
Err-get-realm-krb5-support ::= Extensible-NULL
-- Get s2kparams
Req-get-s2kparams ::= Extensible-NULL
Rep-get-s2kparams ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL,
s2kparams [1] SEQUENCE OF Etype-Info-Entry
}
Err-get-s2kparams ::= Extensible-NULL
END
'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="full3978" docName="draft-ietf-krb-wg-kerberos-set-passwd-07.txt">
<front>
<title abbrev="Kerberos Set/Change Password v2">Kerberos
Set/Change Key/Password Protocol Version 2</title>
<author initials='N.' surname="Williams" fullname='Nicolas
Williams'>
<organization abbrev="Sun">Sun Microsystems</organization>
<address>
<postal>
<street>5300 Riata Trace Ct</street>
<city>Austin</city> <region>TX</region>
<code>78727</code> <country>US</country>
</postal>
<email>Nicolas.Williams@sun.com</email>
</address>
</author>
<date month="September" year="2007"/>
<area>Security</area>
<workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies an extensible protocol for
setting keys and changing the passwords of Kerberos V
principals.</t>
</abstract>
</front>
<middle>
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
<section title="Introduction">
<t>Up to this point Kerberos V has lacked a single, standard protocol
for changing passwords and keys. While several vendor-specific
protocols exist for changing Kerberos passwords/keys, none are
properly internationalized and all are incomplete in one respect or
another and none are sufficiently extensible to cope with new
features that may be added to Kerberos V at some future time.</t>
<t>This document defines a protocol that is somewhat backward-compatible
with the "kpasswd" protocol defined in <xref
target="RFC3244"/> that uses more or
less the same protocol framing.</t>
<t>This new protocol is designed to be extensible and properly
internationalized.</t>
</section>
<section title="The Protocol">
<t>The structure of the protocol is quite similar to that of
typical RPC protocols. Each transaction consists of a
data structure specific to an operation which is then
wrapped in a data structure which is general to all
operations of the protocol. These data structures are
defined with the Abstract Syntax Notation 1 (ASN.1)
<xref target="CCITT.X680.2002"/> and they are encoded
using the Distinguished Encoding Rules (DER) <xref
target="CCITT.X690.2002"/>.</t>
<t>All protocol data is wrapped KRB-PRIV messages, or, in
some cases, a KRB-ERROR, and framed in a header that is
backwards compatible with <xref target="RFC3244"/>.</t>
<section title="Transports ">
<t>The service supports only connection-oriented
transports, specifically TCP, and SHOULD accept
requests on TCP port 464, the same as in <xref
target="RFC3244"/>.</t>
<section anchor="protocol_framing" title="Protocol Framing">
<t>Requests and responses are exchanged using the
same framing as in <xref target="RFC3244"/>, but
with the following differences:
<list style='symbols'>
<t>the protocol number field MUST be set to
0x2 (not 0xff80 or 0x1)</t>
<t>the 'AP-REQ length' field of the request
can be set to 0x0, in which case the
'AP-REQ' field of the request is
excluded</t>
<t>the 'KRB-PRIV' field of the request and
reply is mutually
exclusive with the 'AP-REQ' field of the
request</t>
<t>the 'AP-REP length' field of the reply
can be set to 0x0, in which case the
'AP-REP' field of the reply is
excluded</t>
<t>all errors MUST be sent in a KRB-PRIV if
the client's AP-REQ can
be or has been accepted by the
server</t>
<t>any KRB-ERROR messages are framed and
sent in the 'AP-REP' field of the
reply</t>
</list>
</t>
<t>The initial message from the client MUST carry an
AP-REQ and the response to any request bearing
an AP-REQ MUST carry an AP-REP or MUST be a
KRB-ERROR.</t>
<t>Subsequent messages exchanged on the same TCP
connection MAY involve Kerberos V AP exchanges,
but generally the client SHOULD NOT initiate a
new AP exchange except when it desires to
authenticate as a different principal, when the
ticket last used for authentication expires or
when the server responds with an error
indicating that the client must
re-authenticate.</t>
</section>
</section>
<section title="Protocol Version Negotiation">
<t>There are several major versions of this protocol. Version 2 also
introduces a notion of protocol minor versions for use in negotiating
protocol extensions. As of this time only one minor version is
defined for major version 2: minor version 0, defined herein.</t>
<section title="Protocol Major Version Negotiation">
<t>Version 2 clients that also support other versions, such as 0xff80,
as in <xref target="RFC3244"/>, SHOULD attempt to use version 2 of the protocol
first.</t>
<t>Servers which do not support version 2 of this protocol typically
include their preferred version number in the reply and/or may
include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
status code of KRB5_KPASSWD_MALFORMED.</t>
<t>Note that some <xref target="RFC3244"/> server implementations close the TCP
connection without returning any other response. Note also that
there is no integrity protection for the major version number in the
protocol framing or for any data in a KRB-ERROR.</t>
<t>As a result change password protocol major version negotiation is
subject to downgrade attacks. Therefore major version negotiation is
NOT RECOMMENDED.</t>
<t>Where the server indicates that it does not support version 2, the
client MAY, but SHOULD NOT, unless configured to do so, fall back on
another major version of this protocol.</t>
<t>Version 2 servers MAY respond to non-v2 requests using whatever
response is appropriate for the versions used by the clients, but if
a server does not do this or know how to do this then it MUST respond
with an error framed as in <xref
target="protocol_framing"/>, using an AP-REP and KRB-PRIV
if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
using a ProtocolErrorCode value of unsupported-major-version.</t>
<t>It is expected that implementations of as yet unspecified future
major versions of this protocol will be required to support version 2
integrity protected error replies for properly indicating no support
for version 2 of the protocl. We also hope that no further major
versions of this protocol will be needed.</t>
</section>
<section anchor="minor_version_nego" title="Protocol Minor Version Negotiation">
<t>Version 2 clients are free to use whatever protocol minor version and
message extensions are available to them in their initial messages to
version 2 servers, provided that the minor versions (other than 0)
have been defined through IETF documents.</t>
<t>Version 2 servers MUST answer with the highest protocol minor version
number supported by the server and the client.</t>
<t>Version 2 clients MUST use the protocol minor version used in a
server's reply for any subsequent messages in the same TCP
session.</t>
<t>See <xref target="protocol_extensibility"/> for further description of the protocol's
extensibility and its relation to protocol minor versions and the
negotiation thereof.</t>
</section>
</section>
<section anchor="use_of_krb5" title="Use of Kerberos V and Key Exchange">
<t>This protocol makes use of messages defined in <xref
target="RFC4120"/>. Specifically, AP-REQ,
AP-REP, KRB-ERROR and KRB-PRIV.</t>
<t>All operations are to be performed by the server on behalf of the
client principal.</t>
<t>Clients SHOULD use "kadmin/setpw" as the principal name of the server
for all requests except when changing the client principal's own
expired password, for which they should use "kadmin/changepw". The
"kadmin/changepw" service exists to allow KDCs to limit principals
with expired passwords to getting initial tickets to the password
changing service only and only for changing expired passwords.</t>
<t>Servers MUST limit clients that used the "kadmin/changepw" service
principal name to changing the password of the client
principal.</t>
<t>The client MUST request mutual authentication and the client MUST
MUST request the use of sequence numbers.</t>
<t>Servers MAY force the use of INITIAL or fresh tickets
for any requests -- see <xref target="operations"/>.
Traditionally users with expired passwords are
allowed only INITIAL tickets for the password
changing server, therefore clients MUST support the
use of INITIAL tickets.</t>
<t>Servers MUST specify a sub-session key.</t>
<t>The encrypted part of KRB-PRIVs MUST be encrypted with the server's
sub-session key and key usage 20 (client->server) or 21
(server->client).</t>
<t>After each new AP exchange the client and server MUST destroy the
session keys, if any, resulting from the previous AP
exchange.</t>
</section>
<section title="Use of ASN.1">
<t>This protocol's messages are defined in ASN.1, using
only features from <xref target="CCITT.X680.2002"/>.
All ASN.1 types defined herein are to be encoded in
DER <xref target="CCITT.X690.2002"/>. A complete
ASN.1 module is given in <xref
target="asn1_module"/>.</t>
<t>The DER encoding of the ASN.1 PDUs are exchanged
wrapped in a KRB-PRIV as described above and/or as
e-data in KRB-ERROR messages.</t>
</section>
<section title="Internationalization">
<t>This protocol's request PDU carries an optional field indicating the
languages spoken by the client user; the client SHOULD send its list
of spoken languages to the server (once per-TCP session).</t>
<t>The server SHOULD localize all strings intended for display to users
to a language in common with the languages spoken by the client
user.</t>
<t>Strings for Kerberos principal and realm names used in this protocol
are be constrained as per <xref target="RFC4120"/>.</t>
<section title="Normalization Forms for UTF-8 Strings">
<t>Because Kerberos V <xref target="RFC4120"/> restricts principal names, realm
names and passwords to IA5String, this protocol uses UTF8String with
an extensible constraint to IA5String.</t>
<t>Future versions of Kerberos may relax this constraint; if so then a
minor version of this protocol should relax this constraint
accordingly.</t>
</section>
<section title="Language Negotiation">
<t>The server MUST pick a language from the client's
input list or the default language tag (see
<xref target="RFC3066"/>) for text in its
responses which is meant for the user to
read.</t>
<t>The server SHOULD use a language selection
algorithm such that consideration is first given
to exact matches between the client's spoken
languages and the server's available locales,
followed by "fuzzy" matches where only the first
sub-tags of the client's language tag list are
used for matching against the servers available
locales.</t>
<t>Servers MUST cache the optional language tag
lists from prior requests for use with
subsequent requests that exclude the language
tag list. Clients MAY expect such server
behaviour and send the language tag lists only
once per-TCP session. Clients SHOULD send the
server the language tag list at least once.</t>
<t>When the server has a message catalog for one of
the client's spoken languages the server SHOULD
localize any text strings intended for display
to users.</t>
</section>
</section>
<section anchor="protocol_extensibility" title="Protocol Extensibility">
<t>The protocol is defined in ASN.1 and uses extensibility markers
throughout. As such, the module presented herein can be extended
within the framework of <xref target="CCITT.X680.2002"/>.</t>
<t>Typed holes are not used in this protocol as it is very simple and
does not require the ability to deal with abstract data types defined
in different layers. For this reason, the only way to extend this
protocol is by extending the ASN.1 module within the framework of the
IETF; all future extensions to this protocol have to be defined in
IETF documents unless otherwise specified in a future IETF revision
of this protocol.</t>
<t>A protocol minor version number is used to negotiate
use of extensions. See <xref
target="minor_version_nego"/> for the minor
version negotiation.</t>
<t>Servers SHOULD ignore unknown additions to the ASN.1 types, in
initial requests, where the syntax allows them, except for extensions
to the "Op-req" type, which MUST result in an error.</t>
<t>Servers MUST respond with an error (ProtocolErrorCode value of
proto-unsupported-operation) to clients that use
operations unknown to the server.</t>
</section>
<section title="Protocol Subsets">
<t>The structure of the protocol is such that the ASN.1 syntaxes for the
various operations supported by the protocol are independent of the
each other. Client and server implementations MAY implement subsets
of the overall protocol by removing some alternatives to the Op-req,
Op-rep and Op-err CHOICEs from the ASN.1 module
given in <xref target="asn1_module"/>.</t>
<t>For example, it should be possible to have a password-change only
client that cannot set principal's keys - and vice versa.</t>
</section>
</section>
<section title="Protocol Elements">
<t>The protocol as defined herein supports the following operations
relating to the management of Kerberos principal's passwords or
keys:
<list style='symbols'>
<t>change password (or enctypes and string-to-key parameters)</t>
<t>set password (administrative)</t>
<t>set new keys</t>
<t>generate new keys</t>
<t>get new, un-committed keys</t>
<t>commit new keys</t>
<t>get password policy name and/or description of principal</t>
<t>list aliases of a principal</t>
<t>list enctypes and version of Kerberos V supported by realm</t>
</list>
</t>
<t>The operation for retrieving a list of aliases of a principal is
needed where KDCs implement aliasing of principal names and allows
clients to properly setup their key databases when principal aliasing
is in use.</t>
<t>Operations such as creation or deletion of principals are outside the
scope of this document, and should be performed via other means, such
as through directories or other Kerberos administration
protocols.</t>
<t>The individual operations are described in <xref
target="operations"/>.</t>
<section title="Password Quality Policies">
<t>Servers may reject new user passwords for failing to
meet password quality policies. When this happens
the server must be able to communicate the policy to
the user so that the user may select a better
password.</t>
<t>The protocol allows for two ways to do
this:
<list style='symbols'>
<t>through error codes that identify specific
password quality policies known;</t>
<t>through localized error strings.</t>
</list>
</t>
<t>The use of localized error strings allows servers to
convey non-standard password quality policies to
users, but it requires server-side message catalogs
for localization and support for language
negotiation. The use of error codes only allows for
standard password quality policies that clients must
be aware of a priori, therefore use of error codes
requires the distribution of new message catalogs to
clients whenever new error codes are added; this
simplifies servers at the expense of password
quality extensibility.</t>
<t>When a server would reject a password due to its
failing to meet a standard password quality policy
the the server MUST use the appropriate error codes
(see below) and the server SHOULD send a localized
error message to the user.</t>
<t>When a server would reject a password due to its
failing to meet a non-standard password quality
policy (one not described herein) the the server
MUST send a localized error message to the user.</t>
<section title="Standard Password Quality Policies">
<t>
<list style='symbols'>
<t>pwq-too-soon
<vspace blankLines='1'/>
It is too soon for the principal to
change its password or long-term keys.
<vspace blankLines='1'/></t>
<t>pwq-history
<vspace blankLines='1'/>
The new password is one that the
principal has used before or is too
similar to a password that it has used
before.
<vspace blankLines='1'/></t>
<t>pwq-too-short
<vspace blankLines='1'/>
The new password is too short.
<vspace blankLines='1'/></t>
<t>pwq-dictionary-words
<vspace blankLines='1'/>
The new password is or contains words
that are in the dictionary.
<vspace blankLines='1'/></t>
<t>pwq-prohibited-codepoints
<vspace blankLines='1'/>
The new password contains prohibited
codepoints.
<vspace blankLines='1'/></t>
<t>pwq-need-more-char-classes
<vspace blankLines='1'/>
The new password does not have
characters from enough character classes
(lower-case letters, upper-case letters,
digits, punctuation, etc...).
<vspace blankLines='1'/></t>
</list>
</t>
</section>
</section>
<section title="PDUs">
<t>The types "Request," "Response" and "Error-Response" are the ASN.1
module's PDUs.</t>
<t>The "Request" and "Response" PDUs are always to be
sent wrapped in KRB-PRIV messages, except for the
"Error-Response" PDU which MUST be sent as
KRB-ERROR e-data (see <xref
target="use_of_krb5"/>) when AP exchanges
fail, otherwise it MUST be sent wrapped in a
KRB-PRIV.</t>
<t>The ASN.1 syntax for the PDUs is given in <xref
target="asn1_module"/>.</t>
<t>Note that the first field of each PDU is the major version of the
protocol, defaulted to 2, meaning that it is never included in
version 2 exchanges. Similarly, the second field of each PDU is the
minor version, defaulted to 0.</t>
<t>The request, responses and error PDUs consist of an outer structure
("Request," "Response" and "Error-Response") containing fields common
to all requests, responses and errors, respectively, and an inner
structure for fields that are specific to each operation's
requests/responses. The inner structure is optional in the case of
the Error-Response PDU and need not be included when generic errors
occur for which there is a suitable ProtocolErrorCode.</t>
<t>Specifically, the outer Request structure has a field for passing a
client user's spoken (read) languages to the server. It also has two
optional fields for identifying the requested operation's target
principal's name and realm (if not sent then the server MUST use the
client's principal name and realm as the target). A boolean field
for indicating whether or not the request should be dry-run is also
included; dry-runs can be used to test server policies, and servers
MUST NOT modify any principals when processing dry-run requests.</t>
<t>The Response and Error PDUs' outer structures include a field
indicating the language that the server has chosen for localization
of text intended to be displayed to users; this field is defaulted to
"i-default". This language tag applies to all UTF8 strings in the
inner structure (Op-rep and Op-err) that are meant to be displayed to
users.</t>
<t>The protocol error codes are:
<list style='symbols'>
<t>proto-generic-error
<vspace blankLines='1'/>
An operation-specific error ocurred, see the inner Op-error.</t>
<t>proto-format-error
<vspace blankLines='1'/>
The server failed to parse a message sent by
the client.
</t>
<t>proto-unsupported-major-version
<vspace blankLines='1'/>
The server does not support the major
version of this protocol requested by the
client.
</t>
<t>proto-unsupported-minor-version
<vspace blankLines='1'/>
The server does not support the minor
version of this protocol requested by the
client.
</t>
<t>proto-unsupported-operation
<vspace blankLines='1'/>
The server does not support the operation
requested by the client.
</t>
<t>proto-wrong-service-principal
<vspace blankLines='1'/>
Use kadmin/setpw for the server's principal name.
</t>
<t>proto-re-authentication-required
<vspace blankLines='1'/>
The server demands that the client re-authenticate through a new
AP exchange.
</t>
<t>proto-initial-ticket-required
<vspace blankLines='1'/>
Use of an INITIAL ticket is required for the requested
operation.
</t>
<t>proto-client-and-target-realm-mismatch
<vspace blankLines='1'/>
The server requires that the client's principal name and the
target principal of the operation share the same realm name.</t>
<t>proto-target-principal-unknown
<vspace blankLines='1'/>
The target of the client's operation is not
a valid principal.
</t>
<t>proto-authorization-failed
<vspace blankLines='1'/>
The client principal is not authorized to
perform the requested operation.
</t>
<t>proto-fresh-ticket-required
<vspace blankLines='1'/>
The server would like the client to
re-authenticate using a fresh ticket.
</t>
</list>
</t>
</section>
<section anchor="operations" title="Operations">
<t>This section describes the semantics of each
operation request and response defined in the
ASN.1 module in <xref target="asn1_module"/>.</t>
<section title="Null">
<figure>
<artwork>
&null;
</artwork>
</figure>
</section>
<section title="Change Kerberos Password">
<figure>
<artwork>
&change-pw;
</artwork>
</figure>
</section>
<section title="Set Kerberos Password">
<figure>
<artwork>
&set-pw;
</artwork>
</figure>
</section>
<section title="Set Kerberos Keys">
<figure>
<artwork>
&set-keys;
</artwork>
</figure>
</section>
<section title="Generate Kerberos Keys">
<figure>
<artwork>
&gen-keys;
</artwork>
</figure>
</section>
<section title="Get New Keys">
<figure>
<artwork>
&get-keys;
</artwork>
</figure>
</section>
<section title="Commit New Keys">
<figure>
<artwork>
&commit-keys;
</artwork>
</figure>
</section>
<section title="Get Password Quality Policy">
<figure>
<artwork>
&get-pw-policy;
</artwork>
</figure>
</section>
<section title="Get Principal Aliases">
<figure>
<artwork>
&get-princ-aliases;
</artwork>
</figure>
</section>
<section title="Get Realm's Supported Kerberos V Version and Features">
<figure>
<artwork>
&get-realm-krb5-support;
</artwork>
</figure>
</section>
<section title="Retrieve Principal's S2K Params and Preferred Params">
<figure>
<artwork>
&get-s2kparams;
</artwork>
</figure>
</section>
</section>
<section title="Principal Aliases">
<t>Applications that use Kerberos often have to derive acceptor
principal names from hostnames entered by users. Such hostnames may
be aliases, they may be fully qualified, partially qualified or not
qualified at all. Some implementations have resorted to deriving
principal names from such hostnames by utilizing the names services
to canonicalize the hostname first; such practices are not secure
unless the name service are secure, which often aren't.</t>
<t>One method for securely deriving principal names from hostnames is to
alias principals at the KDC such that the KDC will issue tickets for
principal names which are aliases of others. It is helpful for
principals to know what are their aliases as known by the KDCs.</t>
<t>Note that changing a principal's aliases is out of scope for this
protocol.</t>
</section>
<section title="Kerberos V Feature Negotiation">
<t>Principals and realms' KDCs may need to know about additional
Kerberos V features and extensions that they each support. Several
operations (see above) provide a way for clients and servers to
exchange such infomration, in the form of lists of types supported
for the various typed holes used in Kerberos V.</t>
</section>
</section>
<section anchor="asn1_module" title="ASN.1 Module">
<figure>
<artwork>
&asn1module;
</artwork>
</figure>
</section>
<section title="Security Considerations">
<t>Implementors and site administrators should note that the
redundancy of UTF-8 encodings of passwords varies by
language. Password quality policies SHOULD, therefore,
take this into account when estimating the amount of
redundancy and entropy in a proposed new password.</t>
<t>Kerberos set/change password/key protocol major version
negotiation cannot be done securely; a downgrade attack
is possible against clients that attempt to negotiate
the protocol major version to use with a server. It is
not clear at this time that the attacker would gain much
from such a downgrade attack other than denial of
service (DoS) by forcing the client to use a protocol
version which does not support some feature needed by
the client (Kerberos V in general is subject to a
variety of DoS attacks anyways <xref
target="RFC4120"/>). Clients SHOULD NOT negotiate
support for legacy major versions of this protocol
unless configured otherwise.</t>
<t>This protocol does not have Perfect Forward Security
(PFS). As a result, any passive network snooper
watching password/key changing operations who has stolen
a principal's password or long-term keys can find out
what the new ones are.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;&rfc3066;&rfc4120;&x680;&x690;
</references>
<references title="Informative References">
&rfc3244;
</references>
</back>
</rfc>
<!--
1 Introduction
Up to this point Kerberos V has lacked a single, standard protocol
for changing passwords and keys. While several vendor-specific
protocols exist for changing Kerberos passwords/keys, none are
properly internationalized and all are incomplete in one respect or
another and none are sufficiently extensible to cope with new
features that may be added to Kerberos V at some future time.
This document defines a protocol that is somewhat backward-compatible
with the "kpasswd" protocol defined in [RFC3244] that uses more or
less the same protocol framing.
This new protocol is designed to be extensible and properly
internationalized.
2 The Protocol
The structure of the protocol is quite similar to that of typical RPC
protocols. Each transaction consists of a data structure specific to
an operation which is then wrapped in a data structure which is
general to all operations of the protocol. These data structures are
defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
are encoded using the Distinguished Encoding Rules (DER) [X690].
All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
KRB-ERROR, and framed in a header that is backwards compatible with
[RFC3244].
2.1 Transports
The service supports only connection-oriented transports,
specifically TCP, and MUST accept requests on TCP port 464, the same
as in [RFC3244].
2.2 Protocol Framing
Requests and responses are exchanged using the same framing as in
[RFC3244], but with the following differences:
- the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
- the 'AP-REQ length' field of the request can be set to 0x0, in
which case the 'AP-REQ' field of the request is excluded
- the 'KRB-PRIV' field of the request and reply is mutually
exclusive with the 'AP-REQ' field of the request
- the 'AP-REP length' field of the reply can be set to 0x0, in
which case the 'AP-REP' field of the reply is excluded
- all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
be or has been accepted by the server
- any KRB-ERROR messages are framed and sent in the 'AP-REP' field
of the reply
The initial message from the client MUST carry an AP-REQ and the
response to any request bearing an AP-REQ MUST carry an AP-REP or
MUST be a KRB-ERROR.
Subsequent messages exchanged on the same TCP connection MAY involve
Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
a new AP exchange except when it desires to authenticate as a
different principal, when the ticket last used for authentication
expires or when the server responds with an error indicating that the
client must re-authenticate.
2.3 Protocol Version Negotiation
There are several major versions of this protocol. Version 2 also
introduces a notion of protocol minor versions for use in negotiating
protocol extensions. As of this time only one minor version is
defined for major version 2: minor version 0, defined herein.
2.3.1 Protocol Major Version Negotiation
Version 2 clients that also support other versions, such as 0xff80,
as in [RFC3244], SHOULD attempt to use version 2 of the protocol
first.
Servers which do not support version 2 of this protocol typically
include their preferred version number in the reply and/or may
include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
status code of KRB5_KPASSWD_MALFORMED.
Note that some [RFC3244] server implementations close the TCP
connection without returning any other response. Note also that
there is no integrity protection for the major version number in the
protocol framing or for any data in a KRB-ERROR.
As a result change password protocol major version negotiation is
subject to downgrade attacks. Therefore major version negotiation is
NOT RECOMMENDED.
Where the server indicates that it does not support version 2, the
client MAY, but SHOULD NOT, unless configured to do so, fall back on
another major version of this protocol.
Version 2 servers MAY respond to non-v2 requests using whatever
response is appropriate for the versions used by the clients, but if
a server does not do this or know how to do this then it MUST respond
with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
using a ProtocolErrorCode value of unsupported-major-version.
It is expected that implementations of as yet unspecified future
major versions of this protocol will be required to support version 2
integrity protected error replies for properly indicating no support
for version 2 of the protocl. We also hope that no further major
versions of this protocol will be needed.
2.3.2 Protocol Minor Version Negotiation
Version 2 clients are free to use whatever protocol minor version and
message extensions are available to them in their initial messages to
version 2 servers, provided that the minor versions (other than 0)
have been defined through IETF documents.
Version 2 servers MUST answer with the highest protocol minor version
number supported by the server and the client.
Version 2 clients MUST use the protocol minor version used in a
server's reply for any subsequent messages in the same TCP session.
See section 2.7 for further description of the protocol's
extensibility and its relation to protocol minor versions and the
negotiation thereof.
2.4 Use of Kerberos V and Key Exchange
This protocol makes use of messages defined in [RFC1510] and
[clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and
KRB-PRIV.
All operations are to be performed by the server on behalf of the
client principal.
Clients SHOULD use "kadmin/setpw" as the principal name of the server
for all requests except when changing the client principal's own
expired password, for which they should use "kadmin/changepw". The
"kadmin/changepw" service exists to allow KDCs to limit principals
with expired passwords to getting initial tickets to the password
changing service only and only for changing expired passwords.
Servers MUST limit clients that used the "kadmin/changepw" service
principal name to changing the password of the client principal.
The client MUST request mutual authentication and the client MUST
MUST request the use of sequence numbers.
Clients SHOULD use INITIAL tickets for requests whose target
principal is the client's principal. Servers SHOULD force the use of
INITIAL tickets for such requests and MAY force the use of INITIAL
for all others - see section 3.2.
Servers MUST specify a sub-session key.
The encrypted part of KRB-PRIVs MUST be encrypted with the server's
sub-session key and key usage 20 (client->server) or 21
(server->client).
After each new AP exchange the client and server MUST destroy the
session keys, if any, resulting from the previous AP exchange.
2.5 Use of ASN.1
This protocol's messages are defined in ASN.1, using only features
from [X680]. All ASN.1 types defined herein are to be encoded in
DER [X690]. A complete ASN.1 module is given in section 4.
The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
2.6 Internationalization
This protocol's request PDU carries an optional field indicating the
languages spoken by the client user; the client SHOULD send its list
of spoken languages to the server (once per-TCP session).
The server SHOULD localize all strings intended for display to users
to a language in common with the languages spoken by the client user.
Strings for Kerberos principal and realm names used in this protocol
are be constrained as per [clarifications].
2.6.1 Normalization Forms for UTF-8 Strings
Because Kerberos V [clarifications] restricts principal names, realm
names and passwords to IA5String, this protocol uses UTF8String with
an extensible constraint to IA5String.
Future versions of Kerberos may relax this constraint; if so then a
minor version of this protocol should relax this constraint
accordingly.
2.6.2 Language Negotiation
The server MUST pick a language from the client's input list or
the default language tag (see [RFC3066]) for text in its responses
which is meant for the user to read.
The server SHOULD use a language selection algorithm such that
consideration is first given to exact matches between the client's
spoken languages and the server's available locales, followed by
"fuzzy" matches where only the first sub-tags of the client's
language tag list are used for matching against the servers available
locales.
Servers MUST cache the optional language tag lists from prior
requests for use with subsequent requests that exclude the language
tag list. Clients MAY expect such server behaviour and send the
language tag lists only once per-TCP session. Clients SHOULD send
the server the language tag list at least once.
When the server has a message catalog for one of the client's spoken
languages the server SHOULD localize any text strings intended for
display to users.
2.7 Protocol Extensibility
The protocol is defined in ASN.1 and uses extensibility markers
throughout. As such, the module presented herein can be extended
within the framework of [X680].
Typed holes are not used in this protocol as it is very simple and
does not require the ability to deal with abstract data types defined
in different layers. For this reason, the only way to extend this
protocol is by extending the ASN.1 module within the framework of the
IETF; all future extensions to this protocol have to be defined in
IETF documents unless otherwise specified in a future IETF revision
of this protocol.
A protocol minor version number is used to negotiate use of
extensions. See section 2.3.2 for the minor version negotiation.
Servers SHOULD ignore unknown additions to the ASN.1 types, in
initial requests, where the syntax allows them, except for extensions
to the "Op-req" type, which MUST result in an error.
Servers MUST respond with an error (ProtocolErrorCode value of
unsupported-minor-version) to clients that use operations unknown to
the server.
2.8 Protocol Subsets
The structure of the protocol is such that the ASN.1 syntaxes for the
various operations supported by the protocol are independent of the
each other. Client and server implementations MAY implement subsets
of the overall protocol by removing some alternatives to the Op-req,
Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
For example, it should be possible to have a password-change only
client that cannot set principal's keys - and vice versa.
3 Protocol Elements
The protocol as defined herein supports the following operations
relating to the management of Kerberos principal's passwords or keys:
[NOTE: New since last version of this I-D.]
- get principal's current and preferred string-to-key parameters
- change password (or enctypes and string-to-key parameters)
- set password (administrative)
- set new keys
- generate new keys
- get new, un-committed keys
- commit new keys
- get password policy name and/or description of principal
- list aliases of a principal
- list enctypes and version of Kerberos V supported by realm
The operation for retrieving a list of aliases of a principal is
needed where KDCs implement aliasing of principal names and allows
clients to properly setup their key databases when principal aliasing
is in use.
Operations such as creation or deletion of principals are outside the
scope of this document, and should be performed via other means, such
as through directories or other Kerberos administration protocols.
The individual operations are described in section 3.2.
3.1 PDUs
The types "Request," "Response" and "Error-Response" are the ASN.1
module's PDUs.
The "Request" and "Response" PDUs are always to be sent wrapped in
KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
otherwise it MUST be sent wrapped in a KRB-PRIV.
The ASN.1 syntax for the PDUs is given in section 4.
Note that the first field of each PDU is the major version of the
protocol, defaulted to 2, meaning that it is never included in
version 2 exchanges. Similarly, the second field of each PDU is the
minor version, defaulted to 0.
The request, responses and error PDUs consist of an outer structure
("Request," "Response" and "Error-Response") containing fields common
to all requests, responses and errors, respectively, and an inner
structure for fields that are specific to each operation's
requests/responses. The inner structure is optional in the case of
the Error-Response PDU and need not be included when generic errors
occur for which there is a suitable ProtocolErrorCode.
Specifically, the outer Request structure has a field for passing a
client user's spoken (read) languages to the server. It also has two
optional fields for identifying the requested operation's target
principal's name and realm (if not sent then the server MUST use the
client's principal name and realm as the target). A boolean field
for indicating whether or not the request should be dry-run is also
included; dry-runs can be used to test server policies, and servers
MUST NOT modify any principals when processing dry-run requests.
The Response and Error PDUs' outer structures include a field
indicating the language that the server has chosen for localization
of text intended to be displayed to users; this field is defaulted to
"i-default". This language tag applies to all UTF8 strings in the
inner structure (Op-rep and Op-err) that are meant to be displayed to
users.
The protocol error codes are:
- proto-generic-error
An operation-specific error ocurred, see the inner Op-error.
- proto-format-error
- proto-unsupported-major-version
- proto-unsupported-minor-version
- proto-unsupported-operation
N. Williams [Page 8]
DRAFT Kerberos Set/Change Password v2 Expires April 2006
- proto-wrong-service-principal
Use kadmin/setpw for the server's principal name.
- proto-re-authentication-required
The server demands that the client re-authenticate through a new
AP exchange.
- proto-initial-ticket-required
Use of an INITIAL ticket is required for the requested
operation.
- proto-client-and-target-realm-mismatch
The server requires that the client's principal name and the
target principal of the operation share the same realm name.
- proto-target-principal-unknown
- proto-authorization-failed
3.2 Operations
This section describes the semantics of each operation request and
response defined in the ASN.1 module in section 4.
3.3 Principal Aliases
Applications that use Kerberos often have to derive acceptor
principal names from hostnames entered by users. Such hostnames may
be aliases, they may be fully qualified, partially qualified or not
qualified at all. Some implementations have resorted to deriving
principal names from such hostnames by utilizing the names services
to canonicalize the hostname first; such practices are not secure
unless the name service are secure, which often aren't.
One method for securely deriving principal names from hostnames is to
alias principals at the KDC such that the KDC will issue tickets for
principal names which are aliases of others. It is helpful for
principals to know what are their aliases as known by the KDCs.
Note that changing a principal's aliases is out of scope for this
protocol.
3.4 Kerberos V Feature Negotiation
Principals and realms' KDCs may need to know about additional
Kerberos V features and extensions that they each support. Several
operations (see above) provide a way for clients and servers to
exchange such infomration, in the form of lists of types supported
for the various typed holes used in Kerberos V.
4 ASN.1 Module
DEFINITIONS EXPLICIT TAGS ::= BEGIN
--
-- Note: EXPLICIT tagging is in use by default throughout this
-- module.
-- From [clarifications] with modifications
PrincipalName ::= SEQUENCE {
name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
}
Realm ::= UTF8String (IA5String, ...)
Salt ::= UTF8String (IA5String, ...)
Password ::= UTF8String (IA5String, ...)
-- NOTE WELL: Principal and realm names MUST be constrained by the
-- specification of the version of Kerberos V used by the
-- client.
--
-- [Perhaps PrincipalName should be a SEQUENCE of an optional name
-- type and a UTF8String, for simplicity.]
-- From [clarifications]
Int32 ::= INTEGER (-2147483648..2147483647)
UInt32 ::= INTEGER (0..4294967295)
-- Based on [clarifications]
Etype ::= Int32
Etype-Info-Entry ::= SEQUENCE {
etype [0] Etype,
salt [1] Salt OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL
}
Key ::= SEQUENCE {
enc-type [0] Etype, -- from Kerberos
key [1] OCTET STRING
}
Language-Tag ::= UTF8String -- Constrained by [RFC3066]
-- Empty, extensible SEQUENCEs are legal ASN.1
Extensible-NULL ::= SEQUENCE {
...
}
-- Kerberos clients negotiate some parameters relating to their peers
-- indirectly through the KDC. Today this is true of ticket session
-- key enctypes, but in the future this indirect negotiation may also
-- occur with respect to the minor version of Kerberos V to be used
-- between clients and servers. Additionally, KDCs may need to know
-- what authorization-data types are supported by service principals,
-- both, for compatibility with legacy software and for optimization.
--
-- Thesefore it is important for KDCs to know what features of
-- Kerberos V each service principal supports.
--
-- In version 2.0 of this protocol the clients and servers may notify
-- each other of their support for:
--
-- - enctypes
-- - authorization data types
-- - transited encoding data types
--
-- All authorization-data types defined in [clarifications] are
-- assumed to be supported if the minor version is 1 and do not need
-- to be included in the ad-type list.
--
-- Int32 is used for enctype and transited encoding data type
-- identifiers.
--
-- An extensible CHOICE of Int32 is used for authorization data
-- types.
KerberosV-TR-ID ::= Int32
KerberosV-AD-ID ::= CHOICE {
ad-int [0] Int32,
...
}
KerberosVSupportNego ::= SEQUENCE {
enc-types [0] SEQUENCE OF Etype,
ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
-- authorization data types
tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
-- transited encoding types
...
}
Request ::= [APPLICATION 0] SEQUENCE {
pvno-minor [0] INTEGER DEFAULT 0,
languages [1] SEQUENCE OF Language-Tag OPTIONAL,
-- Should be defaulted to the SEQUENCE of "i-default"
targ-name [2] PrincipalName OPTIONAL,
targ-realm [3] Realm OPTIONAL,
-- If targ-name/realm are missing then the request
-- applies to the principal of the client
dry-run [4] BOOLEAN DEFAULT FALSE,
operation [5] Op-req,
...
}
Response ::= [APPLICATION 1] SEQUENCE {
pvno-minor [0] INTEGER DEFAULT 0,
language [1] Language-Tag DEFAULT "i-default",
result [2] Op-rep,
...
}
Error-Response ::= [APPLICATION 2] SEQUENCE {
pvno-minor [0] INTEGER DEFAULT 0,
language [1] Language-Tag DEFAULT "i-default",
error-code [2] ProtocolErrorCode,
help-text [3] UTF8String OPTIONAL,
op-error [4] Op-err OPTIONAL,
...
}
Op-req ::= CHOICE {
null [0] Req-null,
change-pw [1] Req-change-pw,
set-pw [2] Req-set-pw,
set-keys [3] Req-set-keys,
gen-keys [4] Req-gen-keys,
get-keys [5] Req-get-keys,
commit-keys [6] Req-commit-keys,
get-pw-policy [7] Req-get-pw-policy,
get-princ-aliases [8] Req-get-princ-aliases,
get-realm-krb5-support [9] Req-get-realm-krb5-support,
get-s2kparams [10] Req-get-s2kparams,
...
}
Op-rep ::= CHOICE {
null [0] Rep-null,
change-pw [1] Rep-change-pw,
set-pw [2] Rep-set-pw,
set-keys [3] Rep-set-keys,
gen-keys [4] Req-gen-keys,
get-keys [5] Req-get-keys,
commit-keys [6] Rep-commit-keys,
get-pw-policy [7] Rep-get-pw-policy,
get-princ-aliases [8] Rep-get-princ-aliases,
get-realm-krb5-support [9] Rep-get-realm-krb5-support,
get-s2kparams [10] Rep-get-s2kparams,
...
}
Op-err ::= CHOICE {
null [0] Err-null,
change-pw [1] Err-change-pw,
set-pw [2] Err-set-pw,
set-keys [3] Err-set-keys,
gen-keys [4] Err-gen-keys,
get-keys [5] Err-get-keys,
commit-keys [6] Err-commit-keys,
get-pw-policy [7] Err-get-pw-policy,
get-princ-aliases [8] Err-get-princ-aliases,
get-realm-krb5-support [9] Err-get-realm-krb5-support,
get-s2kparams [10] Err-get-s2kparams,
...
}
ProtocolErrorCode ::= ENUM {
proto-format-error,
proto-unsupported-major-version,
proto-unsupported-minor-version,
proto-unsupported-operation, -- Request CHOICE tag unknown
proto-generic-see-op-error, -- See Op-error
proto-wrong-service-principal, -- Use kadmin/setpw
proto-re-authentication-required,
proto-initial-ticket-required,
proto-client-and-target-realm-mismatch,
proto-target-principal-unknown,
proto-authorization-failed,
proto-dry-run-not-permitted,
proto-fresh-ticket-required,
...
}
-- These codes are hints for clients, primarily for when they are
-- used for changing the passwords of automated principals; error
-- replies carry password quality policy help text that is more
-- appropriate for clients to display to users.
PW-Quality-Codes ::= ENUM {
pwq-generic,
pwq-too-soon,
pwq-history,
pwq-too-short,
pwq-dictionary-words,
pwq-prohibited-codepoints,
pwq-need-more-char-classes,
...
}
--
-- Requests and responses
--
-- NULL request, much like ONC RPC's NULL procedure - NOT extensible
Req-null ::= NULL
Rep-null ::= NULL
Err-null ::= NULL
-- Change password
Req-change-pw ::= SEQUENCE {
old-pw [0] Password,
new-pw [1] Password OPTIONAL,
commit [2] BOOLEAN DEFAULT TRUE,
etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Rep-change-pw ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
new-pw [1] Password OPTIONAL,
-- generated by the server if present
-- (and requested by the client)
etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Err-change-pw ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL,
error [1] CHOICE {
op-generic-error [0] Extensible-NULL,
op-old-pw-incorrect [1] Extensible-NULL,
op-wont-generate-new-pw [2] Extensible-NULL,
op-new-pw-rejected-generic [3] SEQUENCE {
policy [1] SEQUENCE OF UTF8String,
suggested-pw [2] Password OPTIONAL,
policy-codes [3] SET OF PW-Quality-Codes
OPTIONAL
}
op-etype-not-supported [4] SEQUENCE {
supported-etypes [1] SEQUENCE OF Etype
}
}
}
-- Set password
Req-set-pw ::= SEQUENCE {
languages [0] SEQUENCE OF Language-Tag OPTIONAL,
new-pw [1] Password OPTIONAL,
commit [2] BOOLEAN DEFAULT TRUE,
etypes [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Rep-set-pw ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
new-pw [1] Password OPTIONAL,
-- generated by the server if present
-- (and requested by the client)
etypes [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
}
Err-set-pw ::= Err-change-pw
-- Set keys
Req-set-keys ::= SEQUENCE {
keys [0] SEQUENCE OF Key,
commit [1] BOOLEAN DEFAULT TRUE,
-- TRUE -> install keys now
--
-- FALSE -> require set-keys-commit
-- before issuing tickets
-- encrypted with these keys.
--
-- See commit-keys op
isupport [2] KerberosVSupportNego OPTIONAL
-- For future Kerberos V extensions KDCs
-- may need to know what krb5 version is
-- supported by individual service
-- principals. This field provides a
-- way to tell the KDC what version of
-- Kerberos V the target principal
-- supports.
}
Rep-set-keys ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
kvno [1] UInt32,
aliases [2] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
},
isupport [3] KerberosVSupportNego OPTIONAL
-- Should there be ETYPE-INFO2 stuff here?
}
Err-set-keys ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL, -- Reason for rejection
error [1] CHOICE {
op-generic [0] Extensible-NULL,
op-deferred-commit-no-support [1] Extensible-NULL,
op-etype-no-support [2] SEQUENCE OF {
supported-etypes [1] SEQUENCE OF Etype
}
}
}
-- Generate keys
Req-gen-keys ::= SEQUENCE {
etypes [0] SEQUENCE (1..MAX) OF Etype,
entropy [1] OCTET STRING OPTIONAL,
commit [2] BOOLEAN DEFAULT TRUE,
-- TRUE -> install keys now
--
-- FALSE -> require set-keys-commit
-- before issuing tickets
-- encrypted with these keys.
--
-- See commit-keys op
isupport [3] KerberosVSupportNego OPTIONAL
-- For future Kerberos V extensions KDCs
-- may need to know what krb5 version is
-- supported by individual service
-- principals. This field provides a
-- way to tell the KDC what version of
-- Kerberos V the target principal
-- supports.
}
Rep-gen-keys ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
kvno [1] UInt32,
key [2] Key,
aliases [3] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
},
isupport [4] KerberosVSupportNego OPTIONAL
-- Should there be ETYPE-INFO2 stuff here?
}
Err-gen-keys ::= Err-set-keys
-- Get un-committed key request
Req-get-keys ::= SEQUENCE {
kvno [0] UInt32
}
Rep-get-keys ::= SEQUENCE {
info-text [0] UTF8String OPTIONAL,
keys [1] SEQUENCE OF Key,
aliases [2] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
},
isupport [3] KerberosVSupportNego OPTIONAL
-- Should there be ETYPE-INFO2 stuff here?
}
Err-get-keys ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL, -- Reason for rejection
error [1] CHOICE {
op-generic [0] Extensible-NULL,
op-kvno-committed [1] Extensible-NULL,
op-no-such-kvno [1] Extensible-NULL
}
}
-- Commit a set keys request
Req-commit-keys ::= SEQUENCE {
kvno [0] UInt32
}
Rep-commit-keys ::= Extensible-NULL
Err-commit-keys ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL, -- Reason for rejection
error [1] CHOICE {
op-generic [0] Extensible-NULL,
op-kvno-expired [1] Extensible-NULL,
-- The client took too long to respond.
op-kvno-unknown [2] Extensible-NULL,
-- The targ princ/kvno is invalid or unknown to the
-- server (perhaps it lost track of state)
op-new-keys-conflict [3] Extensible-NULL
-- A new-keys/commit-keys request subsequent to the
-- new-keys that produced the kvno has completed
-- and incremented the principal's kvno
}
}
-- Get password policy
Req-get-pw-policy ::= Extensible-NULL
Rep-get-pw-policy ::= SEQUENCE {
policy-name [0] UTF8String OPTIONAL,
description [1] SEQUENCE OF UTF8String OPTIONAL
}
Err-get-pw-policy ::= Extensible-NULL
-- Get principal aliases
Req-get-princ-aliases ::= Extensible-NULL
Rep-get-princ-aliases ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL,
aliases [1] SEQUENCE OF SEQUENCE {
name [0] PrincipalName,
realm [1] Realm OPTIONAL
}
}
Err-get-princ-aliases ::= Extensible-NULL
-- Get list of enctypes supported by KDC for new keys
Req-get-realm-krb5-support ::= Extensible-NULL
Rep-get-realm-krb5-support ::= SEQUENCE {
isupport [0] KerberosVSupportNego
-- Version of Kerberos V supported by
-- the target realm.
}
Err-get-realm-krb5-support ::= Extensible-NULL
-- Get s2kparams
Req-get-s2kparams ::= Extensible-NULL
Rep-get-s2kparams ::= SEQUENCE {
help-text [0] UTF8String OPTIONAL,
s2kparams [1] SEQUENCE OF Etype-Info-Entry
}
Err-get-s2kparams ::= Extensible-NULL
END
6 IANA Considerations
There are no IANA considerations for this document.
7 Security Considerations
Implementors and site administrators should note that the redundancy
of UTF-8 encodings of passwords varies by language. Password quality
policies SHOULD, therefore, take this into account when estimating
the amount of redundancy and entropy in a proposed new password. [??
It's late at night - I think this is correct.]
Kerberos set/change password/key protocol major version negotiation
cannot be done securely; a downgrade attack is possible against
clients that attempt to negotiate the protocol major version to use
with a server. It is not clear at this time that the attacker would
gain much from such a downgrade attack other than denial of service
(DoS) by forcing the client to use a protocol version which does not
support some feature needed by the client (Kerberos V in general is
subject to a variety of DoS attacks anyways [RFC1510]). Clients
SHOULD NOT negotiate support for legacy major versions of this
protocol unless configured otherwise.
This protocol does not have Perfect Forward Security (PFS). As a
result, any passive network snooper watching password/key changing
operations who has stolen a principal's password or long-term keys
can find out what the new ones are.
[More text needed?]
8 Acknowledgements
The authors would like to thank original editors/authors Jonathan
Trostle, Bill Gossman, Mike Swift, John Brezak, as well as Ken
Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
Nelson, Marcus Watts, Love, Joel N. Weber II, Jeffrey Hutzelman and
other participants from the IETF Kerberos Working Group for their
assistance.
-->
| PAFTECH AB 2003-2026 | 2026-04-23 11:26:33 |