Subject: some comments on draft-ietf-cat-kerberos-revisions-10.txt

From: [email-masked]
Date: 09 Feb 2002 00:08:11 +0100

The notes in the text (like [24]) seems to be half-way converted
between sequential numbering and per-section numbering, but there are
lots of old references (like [24]) and the notes themselves for these
are not in the document.

A document this long should really have a table of contents.

3.1.5

the description of key-expiration should note that this field is
deprecated, and that last-req should be used instead.  The same field
is refered to as 'key_exp' in seciont 4.2.

section 5, ASN definitions

The defintions mostly seem to use INT32 and UINT32, but there are a
number of places where INTEGER is still used.  These should presumably
be changed to INT32 or UINT32.

5.4.1:

What is the difference between reserved and unused bits?  The labeling
between the ASN1 code and the text is not consistent.  The
request-anonymous flag is spelt inconsistently with and without dash.

5.4.2

last-req:, the lr-type values should really have constants and a table
for defining them instead of the paragraph of prose.  It's also
missing (7), the expiration time of the account.

5.6

The KRB_SAFE2 message is refered but never defined in the document.

5*

The document talks about keytypes, when it really should be encryption
types.

5.10

List of tags is not up-to-date.

(10 is listed twice)

what is TGT-REQ ?

22 is KRB-CRED

(and this list is also partially repeated in 8.3)

section 6:

Why is combine-keys defined in this document?

6.1:

still talks about keytypes (and sometimes about etype)

key usage 1024 and 1025 are both reserved for applications and for
using with other protocols that are defined in terms of the kerberos
encryption methods.

A table of salt types would be useful.

7.2:

has a list of principal types, which is different from the one in 8.2

section 9.1:

I suggest crc-32, and des-mac, des-mac-k be removed from the checksum
list

9.1: claims that TCP is a MUST, but in 8.2.2, it's a should

/assar

---

From: Ken Raeburn <[email-masked]>
Date: 08 Feb 2002 18:56:12 -0500

> A document this long should really have a table of contents.

According to the editor requirements, it's actually required for
anything remotely close to this size.  Since the master form is HTML
at the moment, I'm not sure how that's going to happen.

> Why is combine-keys defined in this document?

To provide a single interface for preauth mechanisms like SAM to use,
rather than specifying things like "XOR your DES keys together", which
breaks if you're not using one of the listed encryption systems.  For
our existing systems, "xor and maybe fix parity" may suffice, 

> still talks about keytypes (and sometimes about etype)

Oops.  I'll try to fix that in the next rev of the crypto draft.  (In
case it escaped your notice, draft-ietf-krb-wg-crypto-XX.txt was split
off, and kerberos-revisions will refer to it in the future.)

> using with other protocols that are defined in terms of the kerberos

Hmm, I'll look into that.

> A table of salt types would be useful.

Salt types are going away; the replacement will be a more generic and
opaque "string to key parameters" blob, the interpretation of which is
left to each cryptosystem, sent by the KDC via preauth.  The existing
preauth support for salt types would be converted to a specialized
form of the parameters.  For example, AFS3-SALT might mean the blob is
one octet with a value of 1 *if* one of the DES enctypes is used,
which the DES string-to-key function interprets to mean "I'll call the
AFS s2k function instead of using the normal code".

Using this blob lets us say things like, for AES, the blob will be an
ASCII string with decimal digits indicating the number of iterations
for the PKCS#5 key generation function.  And we don't have to do weird
hacks to the salt string to encode such info.

---

From: Sam Hartman <[email-masked]>
Date: 08 Feb 2002 22:12:19 -0500

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    >> using with other protocols that are defined in terms of the kerberos

    Ken> Hmm, I'll look into that.

You really can't distinguish between these two cases can you?

---

From: [email-masked]
Date: 09 Feb 2002 20:02:32 +0100

> at the moment, I'm not sure how that's going to happen.

How is the text version generated from the master HTML?

> our existing systems, "xor and maybe fix parity" may suffice, 

How would this work for trying to advance this to draft standard?
Would we have to show that this actually interoperates used by some
other protocol or would it be enough with having test programs?

> off, and kerberos-revisions will refer to it in the future.)

Yeah, I haven't had time to read that draft yet and I thought I should
send in my comments to the revisions first.

> left to each cryptosystem, sent by the KDC via preauth.

What preauth option is that?  I didn't find any mentioned in
draft-ietf-krb-wg-crypto-00.txt.

/assar

---

From: [email-masked]
Date: 09 Feb 2002 20:04:54 +0100

> You really can't distinguish between these two cases can you?

I don't think you can.  But I would like the document to read "if you
use a key usage value for your application, take a number
[1026,2047]." (and leaving 1024 - 1025 for the protocols that are
already defined in terms of the kerberos crypto types.  I think this
is just a clarification, and not a change of the intended meaning.

/assar

---

From: Ken Raeburn <[email-masked]>
Date: 09 Feb 2002 14:15:09 -0500

> How is the text version generated from the master HTML?

My guess: Netscape's "Save As..." function, plus some
post-processing for page breaks.

> other protocol or would it be enough with having test programs?

I'm expecting/hoping Ken Hornstein's next rev of the draft outlining
SAM preauth will use it.  But a test vector ought to be good enough, I
think, to show that an implementation of a cryptosystem is correct.
Interoperability between implementations of these preauth schemes
would indicate compatible implementations of not only the function but
also the callers.

> draft-ietf-krb-wg-crypto-00.txt.

As with all the actualy protocol messages, it's outside the scope of
the crypto draft.  I need to write up a proposal to add to
kerberos-revisions.

---

From: Sam Hartman <[email-masked]>
Date: 09 Feb 2002 16:09:04 -0500

>>>>> "assar" == assar  <[email-masked]> writes:

    >> You really can't distinguish between these two cases can you?

    assar> I don't think you can.  But I would like the document to read "if you
    assar> use a key usage value for your application, take a number
    assar> [1026,2047]." (and leaving 1024 - 1025 for the protocols that are
    assar> already defined in terms of the kerberos crypto types.  I think this
    assar> is just a clarification, and not a change of the intended meaning.

Hmm, I think the actual intent is that if you called krb5_mk_priv or
krb5_mk_safe without giving a keyusage, say because you use one of the
current APIs that doesn't use a keyusage, then you get these keyusage
numbers.  You'd get that either because you had a random application
with an unspecified protocol or because you had an old protocol spec.

Continuing to use these keyusages indefinitely for applications is
probably OK, especially when the service name is application specific.

---

From: [email-masked]
Date: 11 Feb 2002 00:19:30 +0100

> with an unspecified protocol or because you had an old protocol spec.

So that's different from 13 and 15 by having the application not
choose the keys?

/assar

---

From: Sam Hartman <[email-masked]>
Date: 10 Feb 2002 21:29:02 -0500

>> with an unspecified protocol or because you had an old protocol spec.

    assar> So that's different from 13 and 15 by having the application not
    assar> choose the keys?

O, hmm, you're right.