Subject: Re: servers, passwords, and key generation

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 31 Jul 2003 10:36:26 -0700

>>Nicolas Williams <[email-masked]> writes:
>> I'm not terribly enthused about services with non-random passwords  
>>instead of randomized keys.  If you randomize the password you might 
>>as  well store randomized keys.

>Ken Raeburn <[email-masked]> writes:
>I don't know that they're non-random in the Microsoft case, only that 
>they're stored as passwords.  Larry or someone else from the Microsoft 
>team might be able to provide more specifics.  Even in the MIT case, 
>one could generate a long, random printable-ASCII password and save it 
>away.

Localsystem/networkservice passwords are truly random, we basically call
CryptGenRandom() to get the new passwords and these passwords got
changed rather frequently. Each machine password is 28 octets long in
ws2k3, 240 octets in LH, and mostly is not print-able. 

the popular myth that MS stores cleartext passwords perhaps originates
from tools like lsadump2, which dumps so called "LSA secrets", one of
which, named "$MACHINE.ACC", is the cleartext version of the machine
password. This is only stored on each individual machine, not to be
confused with stored keys on the KDC. We have one current key per each
supported etype, we also do store previous copies for enforcing account
lockout policy etc.

Larry

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 31 Jul 2003 11:08:04 -0700

In general we only store keys for account objects. We do have a special
case where we store password, that is the domain trust password, and
this is where getting the etype_info2 can help. This came up naturally
when we started interop testing, our current implementation does support
more than the default iteration count value.

We also have the notation of explicitly supplied credentials for
AcceptSecurityContext/gss_accept_sec_context where this is applicable.

If the KDC has multiple keys for the same etype, either receiving end of
a ticket (a referral TGT or service ticket) will need either have the
same set of keys of the ticket issuer/KDC, or we leave the burden to the
KDC selecting a suitable key.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Thursday, July 31, 2003 10:14 AM
To: Ken Raeburn
Cc: Joel N. Weber II; IETF Kerberos Working Group
Subject: Re: servers, passwords, and key generation

I just realized that if we add a change service password operation to
the change password protocol that returns a SEQUENCE OF etype-info2
entries then any service that stores passwords instead of keys will now
have to store passwords *and* etype-info2 data.

What's the difference between storing keys and storing passwords +
etype-info2?  I don't see any.  You can't use the passwords as passwords
anymore.

So if anyone wants to store service passwords they'll have to use AS
exchanges to discover the etype-info2 data and cache it, or we'll have
to specify default s2kparams for use with service passwords, or we'll
have to say no more storing of service passwords instead of keys.

Cheers,

Nico
--