[kitten] Non-Password Password Change

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] Non-Password Password Change

Henry B Hotz
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:  [hidden email]
Business: [hidden email]

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Non-Password Password Change

Greg Hudson
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

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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Non-Password Password Change

Henry B Hotz

> On Oct 15, 2015, at 2:51 PM, Greg Hudson <[hidden email]> wrote:
>
> 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
>
> I vaguely recall an explicit decision not to continue with that work
> because no one believed they were likely to implement it.

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

>> 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.

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

> 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.

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:  [hidden email]
Business: [hidden email]

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Non-Password Password Change

D.Rogers
In reply to this post by Greg Hudson
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" <[hidden email]>
An: "Henry B (Hank) Hotz, CISSP" <[hidden email]>, [hidden email]
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

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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Non-Password Password Change

Nico Williams
In reply to this post by Greg Hudson
On Thu, Oct 15, 2015 at 05:51:50PM -0400, Greg Hudson wrote:
> 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
>
> I vaguely recall an explicit decision not to continue with that work
> because no one believed they were likely to implement it.

Yes.

> > 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.

Roland Dowdeswell's krb5_admin has a method for setting principal keys
with a multi-party DH exchange where the KDC is one of the parties.
This works *very* well.  I strongly recommend it.  https://github.com/elric1/

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten