Subject: [kitten] Non-Password Password Change

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 15 Oct 2015 12:59:46 -0700

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.

Are there any password change protocols where you can supply the enctype and a key instead of a text password? Or is the only way to do that via the kdc’s kadmin interface.

Personal:  [email-masked]
Business: [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Thu, 15 Oct 2015 17:51:50 -0400

> 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, a…

I believe the most recent work is:

    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.

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 15 Oct 2015 16:19:34 -0700

> On Oct 15, 2015, at 2:51 PM, Greg Hudson <[email-masked]> wrote:
> 

I see a set_keys() operation in there. I don’t think I’m likely to implement it though.

> circumvent password policies, and therefore usually require special

Given PKINIT and FAST/OTP, all you need is a policy which says NO-PASSWORDS. ;-)

> environment), but it seems like a reasonable way to mitigate risk.

I once built a service which chose users’ passwords and emailed them to them. I didn’t have to implement any set/change password functionality and the reset function was dead simple.

The above draft supports it. What would be nice is if you could update application servers' keytabs *before* the kdc started issuing tickets with the new keys.

Personal:  [email-masked]

---

From: [email-masked]
Date: Mon, 19 Oct 2015 23:48:04 +0200

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" <[email-masked]>

An: "Henry B (Hank) Hotz, CISSP" <[email-masked]>, [email-masked]

Betreff: Re: [kitten] Non-Password Password Change

permissions.

_______________________________________________

Kitten mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/kitten