Subject: RE: servers, passwords, and key generation

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 4 Aug 2003 10:44:40 -0700

Martin, your list is exhaustive; there are only two exceptions I can
think of: one is the use of "credential manager" on winxp or later,
which is so called "initiator only" and is dynamically looked up based
on target_name; another is an lsacallauthenitcationpackage dispatch
function entry that enables multiple instances of the same service
principal (not to be confused with "instanced principals"), let's say,
in web-farm environments. 

The problem Ken and I tried to solve is that we need to know the salt
and string to key parameters in order to decrypt the service tickets in
some cases; one of such cases is when explicit credentials are supplied
via AUTH_IDENTITY for the acceptor. 

As Ken and Sam pointed out the current MIT implementation allows for
more than one entry per etype in etype_info and etype_info2, therefore
such information can be discovered via as_req.

The use of "default"/well-known values is one of the first solutions
that came up when Ken and I discussed this issue.

>>> Nicolas Williams <[email-masked]> wrote:
>>> I see you didn't address solution (2) :)
>>>

would you prefer to enforce a high iteration count for the strong/random
service passwords? Or would you rather have different iteration counts
for user and service principals? U2U can have the cost of
extra-round-trips.

Furthermore, not dealing with it would imply throwing away the idea of
"random salts", "variable iteration counts", and service/channel
specific keys. I would rather not until we have exhausted all options.

>>> I think we'll need input from Microsoft in order to reach consensus
on this.

Sorry for the slow start, I can see that both 1a and 1b can be used at
the same time: one can optimistically use a set of default values first,
and do "as_req" discovery when needed. This should be applicable to both
"random" salt and "variable" iteration counts. What do you think?

Thx. Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, August 04, 2003 6:33 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: servers, passwords, and key generation

Liqiang wrote:
> 
> 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.

Now that's a funny way to put it.

It's not a popular myth, it is the rule.  The localsystem account seems
to use a special hack and make a single exception to this rule.

What ways are there to use credentials for a specific (not the current)
user on Microsoft Platforms?

- when using SSPI, one can pass an AUTH_IDENTITY structure filled
  with user, domain and *tadaa* printable password.

- when using the "default" SSPI credentials, one needs to create
  an access token for that other user first, either using
  "LogonUser", which requires user, domain and *tadaa*" printable
password

- or when running a service under a special service account,
  open the "Service" snap-in (Administrative Tools->Services),
  change to "Log on" tab and what do you need to enter?
   user, domain and *tadaa* printable password

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 4 Aug 2003 11:14:03 -0700

> for user and service principals? U2U can have the cost of

No, my take is that not dealing with this problem means not storing
service principal passwords but storing service principal keys instead.

I am yet to be convinced of why it is desirable to store passwords
rather than keys, particularly given that MS' implementation has no
problem storing high-entropy service passwords.

One possible reason for storing passwords rather than keys, which we've
not discussed so far, relates to principal aliasing at the KDC.  That
is, a service principal may not know all of the aliases by which it will
be referenced and for which tickets will be issued.  The change password
protocol tries to address this by having the server tell the client of
the target principal's *known* aliases.  Of course, in a very dynamic
environment this may not suffice, as adding and removing principal
aliases might require changing a service's keys each time; but even so,
unless one intends to use keys for the aliases which are derived, with
random salts, from the canonical principal's keys, this should not be a
problem.

Further, I doubt that changing from storing passwords to storing keys
should represent too significant a software architecture change for MS
since I can't imagine the interfaces that access the raw machine
password being anything other than private interfaces.

That said, see below.

> specific keys. I would rather not until we have exhausted all options.

No.  See above.

> "random" salt and "variable" iteration counts. What do you think?

I think you misunderstood 1a, but, yes, this sounds good to me.

I think ETYPE-INFO2 discovery through AS exchanges, for service
principals that know their [high-entropy] password rather than their
keys, is the best approach here.

Note:  There's been some comments about the desirability (and MIT krb5
       support for) disallowing the issuance of tickets to service
       principals.  I don't think allowing ticket issuance to service
       principals with high-entropy passwords/keys is a big deal, and it
       is useful for other purposes anyways (e.g., secure time
       distribution via Kerberos).

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Aug 2003 15:09:48 -0400

Nico, as martin has pointed out, MS has several APIs that accept
passwords from applications for use as service principals.  They need
something to do in these cases.

I do hope they decide to add a mechanism for dealing with keys as
well, but the APIs for accepting passwords are public and they need to
deal with code written to these APIs.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 4 Aug 2003 12:27:30 -0700

> something to do in these cases.

It was far from clear from Martin's post that those APIs involve service
principal passwords, rather than user passwords.

> deal with code written to these APIs.

Fair enough.

Then I am in favor of having such service principals discover their
etype-info2 parameters through AS exchanges (and they should also cache
those parameters, for not more than the lifetime of the particular
service password).

Yes, this means that such principals would have to be allowed as AS
client principals, at least once after each password change - a rather
minor trade off, IMO.

(And forget modifying the change password protocol and/or specifying
 default etype-info2 parameters for use with password-derived service
 principals' ticket decryption keys.)

Cheers,

Nico
--