Subject: String-to-key parameters in setpasswd?

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Dec 2003 02:05:29 +0100

I can't seem to find any fields that hold the string-to-key parameter
in the setpasswd protocol draft.  Is this a known deficiency, or am I
missing something?

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Dec 2003 22:55:22 -0800

> in the setpasswd protocol draft.  Is this a known deficiency, or am I

Excellent question.

Some possible answers:

 - s2k params should be set through an admin channel
 - s2k params should be settable through the setpasswd protocol
 - both of the above

I currently hold no strong position on this.

Comments?

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Dec 2003 17:32:11 +0100 (MET)

> in the setpasswd protocol draft.  Is this a known deficiency, or am I

I'm not current on the specs, but from what I remember from the
discussion a regular user should be restricted to setting a password
(so that the KDC could do some quality checks on the password),
and only admins should be able to set truely random passwords
for servers (at least for those Kerberos implementations that fully
support strong random passwords).

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 12:53:48 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Dec 03, 2003 at 02:05:29AM +0100, Simon Josefsson
    Nicolas> wrote:
    >> I can't seem to find any fields that hold the string-to-key
    >> parameter in the setpasswd protocol draft.  Is this a known
    >> deficiency, or am I missing something?

    Nicolas> Excellent question.

    Nicolas> Some possible answers:

    Nicolas>  - s2k params should be set through an admin channel -

This is my preference.  Will the client want to know what s2kparams
are chosen though?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2003 10:09:03 -0800

On Wed, Dec 03, 2003 at 12:53:48PM -0500, Sam Hartman wrote:
> This is my preference.

In any case, presumably non-admin users of the setpasswd protocol should
be limited as to s2k params options, which argues for your position.

>                         Will the client want to know what s2kparams
> are chosen though?

Why?  It will find out what they are when it tries to get an initial
ticket.  No need to complicate setpasswd unnecessarily.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 13:31:24 -0500

>> Will the client want to know what s2kparams are chosen though?

    Nicolas> Why?  It will find out what they are when it tries to get
    Nicolas> an initial ticket.  No need to complicate setpasswd
    Nicolas> unnecessarily.

The Microsoft case where machines have a random password.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2003 10:31:04 -0800

> support strong random passwords).

Not exactly.  The setpasswd server should be able to apply to setpasswd
requests whatever access controls it cares for.  I don't think the
setpasswd spec should say what these access controls are or can be.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2003 10:33:10 -0800

> The Microsoft case where machines have a random password.

But they can do an AS exchange (they'll have to anyways).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 14:25:58 -0500

>> The Microsoft case where machines have a random password.

    Nicolas> But they can do an AS exchange (they'll have to anyways).

    Nicolas> Nico --

If that's OK with them I'm happy.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2003 11:31:58 -0800

> If that's OK with them I'm happy.

Yes, let's hear from MS on this :)

But note that if they generally do an AS exchange after changing a host
password then that's enough to convince me to not put this in setpasswd.

Nico
--

---

From: Ben Cox <[email-masked]>
Date: Wed, 3 Dec 2003 15:04:07 -0500

>>>> Will the client want to know what s2kparams are chosen though?

Yes.

>>     Nicolas> an initial ticket.  No need to complicate setpasswd

Not everyone who uses setpasswd will get initial tickets, at least 
won't necessarily have to do so before they need to use their keys.  
E.g.:

>> The Microsoft case where machines have a random password.

Some non-Microsoft implementations also use random passwords to set 
service keys.

> But they can do an AS exchange (they'll have to anyways).

Not all implementations that do this will do AS exchanges.  Some server 
implementations use randomized passwords that are used only for 
accepting client tickets.

We recently had to add a gratuitous AS exchange to our server code 
after calling the existing setpasswd, in order to determine which of a 
few possible keys the PDC had derived from the password we set.  It 
would be nice not to perpetuate the necessity for this sort of hack.

-- Ben

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2003 12:10:02 -0800

> Some non-Microsoft implementations also use random passwords to set 

Nonetheless they use those keys to get initial tickets, not just to
accept AP exchanges (AFAIU).

> accepting client tickets.

Preferably there would be no implementations that set random passwords
and use those to generate keys for accepting AP exchanges with.

> would be nice not to perpetuate the necessity for this sort of hack.

Does your implementation use the same principal's random password-
derived keys for, say, securing LDAP queries initiated by it?

At the moment I forget what we concluded at the last interim meeting,
where, as I recall, a similar issue came up.  In any case, if you and/or
MS insist I may not and I think we can reach a consensus that setpasswd
should tell the client what s2kparams it used.  

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 15:19:10 -0500

>>>>> "Ben" == Ben Cox <[email-masked]> writes:

    Ben> We recently had to add a gratuitous AS exchange to our server
    Ben> code after calling the existing setpasswd, in order to
    Ben> determine which of a few possible keys the PDC had derived
    Ben> from the password we set.  It would be nice not to perpetuate
    Ben> the necessity for this sort of hack.

I think that the working group's opinion on this is that you should
use random keys or set key in this case.  I think it is reasonable for
the IETF to tell people that using random passwords is wrong because
of complexity.

---

From: Ben Cox <[email-masked]>
Date: Wed, 3 Dec 2003 21:10:57 -0500 (EST)

> accept AP exchanges (AFAIU).

Ours didn't do that before (it does now, just to find the s2k info).  
Even if we needed to add this in the future for other purposes, we
wouldn't need to force an AS exchange between doing the setpasswd and
storing the new key(s)  in a keytab if we got the params in the setpasswd
return message.

> and use those to generate keys for accepting AP exchanges with.

Sam also said something similar, and ideally I agree.  Indeed, when we are
talking to an MIT KDC, we use the kadmin protocol to randomize the keys
(not passwords).  When talking to a MS PDC, we use the setpasswd protocol
to set random passwords.  Not having implemented the MS PDC part, I'm not
entirely sure, but I was led to believe that directly randomizing keys
with a MS PDC was impossible or impractical (I believe it had to do with
the need[?] to keep synchronized MTAP passwords for NTLM and Kerberos
authentication mechanisms).

> derived keys for, say, securing LDAP queries initiated by it?

No, but it may do so in the future.  But see my comments above regarding
forcing the AS exchange to occur at an (IMHO) unnatural time.

> should tell the client what s2kparams it used.

It would be an exaggeration to characterize my opinion as insistence. ;)

I do view it as a shortcoming in the existing protocol that this info
doesn't come back, but I don't feel *that* strongly about it (or I'd have
spoken up before now).  I'd rather set a randomized key directly anyway,
as long as it's practical to do so (I've been led to believe that it may
not be, but I plead ignorance with any NTLM issues that might cause that).

-- 
Ben Cox <[email-masked]>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Dec 2003 12:44:24 -0500

>>>>> "Ben" == Ben Cox <[email-masked]> writes:

    Ben> Sam also said something similar, and ideally I agree.
    Ben> Indeed, when we are talking to an MIT KDC, we use the kadmin
    Ben> protocol to randomize the keys (not passwords).  When talking
    Ben> to a MS PDC, we use the setpasswd protocol to set random
    Ben> passwords.  Not having implemented the MS PDC part, I'm not
    Ben> entirely sure, but I was led to believe that directly
    Ben> randomizing keys with a MS PDC was impossible or impractical
    Ben> (I believe it had to do with the need[?] to keep synchronized
    Ben> MTAP passwords for NTLM and Kerberos authentication
    Ben> mechanisms).

Do we want to require that implementations of the set password
protocol support random keys?  It seems that there may be a consensus
here that is the way to go for the future.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 08 Dec 2003 13:43:47 -0500

Yes.

I'd like to be able to use the set/change-pw protocol to basically
change a keytab entry from the client.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Ben Cox <[email-masked]>
Date: Tue, 9 Dec 2003 08:28:03 -0500 (EST)

> here that is the way to go for the future.

In principle I agree with Derek that it would be quite nice to have a
common way of setting keys, just as we have setpasswd for setting
passwords.  I'm not totally convinced that they absolutely need to be part
of the same protocol, though it seems to make sense that they should be.

Finally, for our application we will still need to set randomized
passwords (not keys) to get synchronized NTLM and Kerberos passwords in a
Windows domain controller, so it would still be nice (but not a complete
disaster if omitted) to have an in-band communication of string-to-key
parameters (and the kvno) in the setpasswd protocol, to avoid extra AS
exchanges to discover them after-the-fact.