[2144] in Kerberos_V5_Development
we need a standards-track password changing protocol
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Tue Dec 24 15:08:19 1996
To: krbdev@MIT.EDU
From: Marc Horowitz <marc@cygnus.com>
Date: 24 Dec 1996 15:08:07 -0500
In order to support low-end clients, such as macos and windows 3.1,
and hardware platforms with limited code space, like terminal servers
and routers, I'd like to see a simple password changing protocol on
the standards track which involves as little overhead as possible.
Ted's old protocol is a good candidate, but with the ov admin server
in the tree, the likelyhood is small that even a small fraction of the
options in that protocol will ever be implemented. Later in the
standards process, unimplemented options must be dropped, and this
leaves a lot of overhead in the protocol simply to change passwords.
I'd like to see something very simple, structured as follows:
- a password change request packet, consisting of the concatenation of:
- an AP-REQ for the password changing server, including a subkey
in the authenticator and with the INITIAL flag set in the ticket.
- encrypted and mac'd in the authenticator subkey:
- the new password
The server must verify the ap-req, decrypt the request, do any policy
checks (password quality, history, authorization, etc.) required, then
set the password to the new value specified. The principal whose
password is to be changed is the principal which authenticated. This
protocol does not address admins who wants to change another user's
password,
- a password change reply packet, consisting of the concatenation of:
- an AP-REP
- encrypted and mac'd in the authenticator subkey:
- an ACK, or
- a NAK, with some explanatory data as to why the change failed.
This data must include a numeric code to be defined in the
spec, and may, but is not required to, include an advisory
error message.
A code isn't perfect, but if the user wants more detailed information,
a different, non-standards-track protocol can be used, including
perhaps POTS to an administrator :-)
This protocol may use UDP, for statelessness, or TCP, for
firewall access control. UDP is the required mode for
interoperability.
Comments?
Marc
