Subject: Re: Working Group Last call - draft-ietf-cat-kerberos-set-passwd-05.txt - non-ASN.1 comments :-)

From: Ken Raeburn <[email-masked]>
Date: 17 May 2001 16:33:39 -0400

Sorry to wait until the last minute...

At line 285:

   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
   message service ticket sname, srealm principal identifier is
   kadmin/changepw@REALM where REALM is the realm of the change password
   service. The same applies to a set password/key request except the
   principal identifier is kadmin/setpw@REALM. To enable setting of

Why are the server principals different, for related services accessed
through the same TCP/UDP port?

At line 352:

    KeySequence :: = SEQUENCE {
                     key[0]        EncryptionKey,
                     salt[1]       OCTET STRING OPTIONAL,
                     salt-type[2]  INTEGER OPTIONAL
    }

So the salt and type are to be retained by the KDC in its database?
Should the server be allowed to reject salts it doesn't like (possibly
with a new error code)?

I don't know if we should encourage arbitrary new salt types.  Seems
like it opens the way to proprietary, incompatible implementations.

At line 577:

       KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request-
                                        [...]
                                        discussed above. The server MUST
                                        add keylength number of bits of
                                        entropy to each key. The
                                        assumption here is that the
                                        client may have added
                                        insufficient entropy to the
                                        request keys. The server SHOULD
                                        use the client key from each
                                        KeySequence structure as input
                                        into the final keyvalue for the
                                        returned key.

First, this is a rather large paragraph to squeeze into a narrow field
description in a table.  I think I complained about that before.  Can
some of it be extracted into a paragraph outside the table?

Second, "keylength" is not defined anywhere.  Assuming it's the size
of the key encoding, well, adding "keylength number of bits of
entropy" to the key may be impossible.  Note that the DES key encoding
is 64 bits long, yet a DES key may only contain 56 bits of entropy
maximum.  Other encryption systems may not use dense key spaces, in
ways more interesting than simple parity bits.  Can you define a
useful "keylength" without a reference to the entropy the key can
contain?

Third, if the server MUST add that a certain number of bits of
entropy, compliance with the spec implies an analysis of entropy
sources sufficient to prove that that much has indeed been added, and
simply saying "read N bits from /dev/random" without examining each
OS's implementation just won't do, although it may actually be "good
enough" as far as any of us are likely to care in real life.

Fourth, if the server is required to add N bits of entropy where N is
all the key can contain, why bother with the key supplied by the
client?

I think the requirement on the server should be a SHOULD if the
entropy requirement is kept as it seems to be intended (fill key with
maximum entropy), or a MUST if the entropy quantity requirement is
weakened slightly.  (E.g., for a 256-bit Rijndael key, maybe 250 bits
of entropy is good enough, when combined with the client's data?
Maybe insert some vague wording to require that it be strong but leave
the exact interpretation to the implementor.)

       0xFFFF is returned if the request fails for some other reason.

What else is there, that can't be classified as one of the vague
"hard" or "soft" errors "in processing the request"?

Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 21 May 2001 15:36:02 -0700

>through the same TCP/UDP port?

So the server can enforce the initial flag required policy on change
operations.

>Should the server be allowed to reject salts it doesn't like (possibly

This is for future extensibility. It would depend on what was specified.

>like it opens the way to proprietary, incompatible implementations.

Anyone can add a new etype today - so I think it is already possible to do
proprietary
things with Kerberos. On the other hand, we don't have anyone saying we have a
dead protocol - so there are advantages to extensibility.

>some of it be extracted into a paragraph outside the table?

I will try to do that.

>useful "keylength" without a reference to the entropy the key can

Wouldn't keylength = number of actual key bits (minus parity and other
non-entropy
adding bits)?

>all the key can contain, why bother with the key supplied by the

Having the client contribute seems to be basic cryptographic goodness.

>"hard" or "soft" errors "in processing the request"?

Good question. Perhaps the Horowitz draft had these 3 codes as well.

Jonathan

---

From: Ken Raeburn <[email-masked]>
Date: 21 May 2001 23:25:08 -0400

> So the server can enforce the initial flag required policy on change

Yeah, I realized that later when talking with Tom.  Makes sense.

> This is for future extensibility. It would depend on what was specified.

Does this mean that for now the salt field must not be specified?

What's the meaning of that case -- salt remains unchanged, or changes
to the default constructed from the principal name?  I don't think the
draft says.

My initial concern about client-specified salt data that the server
has to retain is, well, couldn't I use it to, say, store a copy of my
undergrad thesis, or an encrypted archive of the email I got last
year?

BTW, tangentially related to this, is there a specific error code that
should be used for "you're supposed to send a password for policy
checking, you're not allowed to just set a key"?  If POLICY_REJECT is
the right code for that, the draft should say so.

> dead protocol - so there are advantages to extensibility.

That doesn't mean we should encourage it.  But I suppose in case we
discover a huge problem with a string-to-key algorithm, we could use a
new standardized salt type to work around it.

> Wouldn't keylength = number of actual key bits (minus parity and other

What if it's some other structured representation -- for example, a
number or two for use in modular arithmetic, plus the randomly
generated modulus itself to help confound an attacker in the same way
that the PDM scheme does.  There would presumably be some way of
generating all this from some number of bits, probably quite a bit
shorter than the generated numbers, but at least in the language of
the revised section 6, that n-bit string isn't likely to be considered
"the key", the collection of numbers (with whatever structure is
needed to delimit them in the wire representation) would be, any
theoretical one-to-one mapping between them notwithstanding.

I'm sort of stumbling around in the dark here, not being any sort of
cryptographer, but I've definitely gotten the impression that not all
encryption schemes use dense key spaces, and whatever other
representations are used may not be trivial to convert back and forth
to a random bit-string of a fixed length.  (Look at PDM: The hint is
desirable because finding the prime may be an expensive operation.)

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 May 2001 10:47:26 -0400

> So the server can enforce the initial flag required policy on change

But the server knows the difference between change and set operations
anyways, so why bother with having two service principal names for this?

I.e.,

decode request
if (type(request) == change-password)
    if (AP_REQ->ticket->flags & initial == 0)
	error
...

[...]

> Jonathan

Cheers,

Nico
--

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 22 May 2001 10:55:23 -0700

>anyways, so why bother with having two service principal names for this?

It's easier to control policy administratively at the level of the service
principal name. For example, if the administrator decides that the initial
flag will be required for set requests as well. Additionally, on the client
side, it becomes possible to not cache change operation tickets, but cache
set operation tickets. 

Jonathan

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 May 2001 14:09:57 -0400

> side, it becomes possible to not cache change operation tickets, but cache

Oh, I see. That's fair.

Thanks,

Nico
--

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 22 May 2001 14:53:43 -0700

>Does this mean that for now the salt field must not be specified?

Yes, for current encryption algorithms, it wouldn't be needed.

>to the default constructed from the principal name?  I don't think the

If the client is using change/set key, then the server wouldn't store salt.

>undergrad thesis, or an encrypted archive of the email I got last

It would be defined by the encryption algorithm. So the server would
make sure that it conforms to the specification. 

>the right code for that, the draft should say so.

Good point - I will add a new error code for this case.

>desirable because finding the prime may be an expensive operation.)

The idea is for the server to add enough entropy to the keys. Exactly
what should be done for each different encryption type is a function of
the encryption type.

Jonathan

---

From: Ken Raeburn <[email-masked]>
Date: 22 May 2001 18:26:48 -0400

Another use of this is to permit the user to acquire kadmin/changepw
tickets when her key is flagged as "must change" in the database
(there's a specific error code for this in the Kerberos protocol),
where you might *not* permit tickets for other services (including
kadmin/setpw and krbtgt/*) to be acquired when the flag is set.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 May 2001 18:15:07 -0400

[...]

> what should be done for each different encryption type is a function of

What about adding a new request type just to get random data (entropy)
from the server? The request would have one argument: requested length
of random bit string. The server would respond with a bit-string of upto
that many bits, possibly fewer, including possibly 0 (to allow for
situations where the server can't generate sufficient entropy).

It would be up to the client to obtain enough entropy by whatever
method it prefers (including asking the server for some) and then
generating a key from it.

As long as there is no set-me-a-new-random-key-and-tell-me-what-it-is
request type then this business of adding entropy to a key seems a bit
overdone such that a separate request to get random data from the
server seems to me like a clearer approach, but, then again, I'm no
cryptographer.

So that makes it three request types:

 - change password
 - set key
 - could you spare me some entropy?

Cheers,

Nico
--

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 22 May 2001 15:52:50 -0700

> - could you spare me some entropy?

If this is needed, then I would think it should go in a separate draft.

Jonathan