Re: [kitten] Non-Password Password Change

D.Rogers@gmx.net Mon, 19 October 2015 21:48 UTC

MIME-Version: 1.0
Message-ID: <trinity-2f423d5f-4c7e-4e1d-94f0-1e866352725d-1445291284061@3capp-gmx-bs18>
From: D.Rogers@gmx.net
To: Greg Hudson <ghudson@mit.edu>
Content-Type: text/html; charset="UTF-8"
Date: Mon, 19 Oct 2015 23:48:04 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <56201FF6.4070902@mit.edu>
References: <63860D22-138C-430F-B615-06CBB14654CC@oxy.edu>, <56201FF6.4070902@mit.edu>
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ADyOvnZfM6dJoqFbE9cXPooSPvw>
Cc: kitten@ietf.org
Subject: Re: [kitten] Non-Password Password Change
Precedence: list

Isnt the Server generating a random password effectively similar to many hardware Tokens, or more recently Smart Apps, generating one.

The password change protocol would then have to consider changes to the semi-static (user pwd) concatenating it with the spontaneously generated one.

Observation shows these implementations exist, though they may be proprietary.

Dean

Gesendet: Donnerstag, 15. Oktober 2015 um 23:51 Uhr
Von: "Greg Hudson" <ghudson@mit.edu>
An: "Henry B (Hank) Hotz, CISSP" <hbhotz@oxy.edu>, kitten@ietf.org
Betreff: Re: [kitten] Non-Password Password Change

On 10/15/2015 03:59 PM, Henry B (Hank) Hotz, CISSP wrote:
> There’s been work on improved password change protocols, but I’m not sure how much actually completed. I also remember once suggesting that loading a KDB entry from a keytab file would be useful, at least for handling cross-realm principals.

I believe the most recent work is:

https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08" target="_blank" rel="nofollow">https://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08

I vaguely recall an explicit decision not to continue with that work
because no one believed they were likely to implement it.

> Are there any password change protocols where you can supply the enctype and a key instead of a text password?

This is probably obvious, but any such facility allows the client to
circumvent password policies, and therefore usually require special
permissions.

I believe you are correct that in current implementations, the only way
to do that is via implementation-specific admin interfaces.

Another mode I would find interesting is one where the server makes up a
new password and tells you what it is. I don't know if it would get
much use (I've never seen passwords managed that way in any
environment), but it seems like a reasonable way to mitigate risk.

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/kitten

[kitten] Non-Password Password Change Henry B (Hank) Hotz, CISSP
Re: [kitten] Non-Password Password Change Greg Hudson
Re: [kitten] Non-Password Password Change Henry B (Hank) Hotz, CISSP
Re: [kitten] Non-Password Password Change D.Rogers
Re: [kitten] Non-Password Password Change Nico Williams