Subject: comments on kerberos-revisions-05.txt

From: Ken Raeburn <[email-masked]>
Date: Thu, 16 Mar 2000 17:48:01 -0500 (EST)

Mostly without even looking at Kerberos stuff per se, some initial
complaints:

This tome has no table of contents or index, making it hard to find
anything in printed copy.  (Okay, call me old-fashioned, I print some
of these suckers out.)

There's no change history, indicating what's changed from the previous
draft, or more importantly, from RFC1510.  I'm starting to do some
diffs against -04, filtering out formatting changes...

Starting in section 6, everything is indented too far.  (A minor
thing, but it's messing up my diffs beyond that point.)

It still refers to draft-horowitz-key-derivation-02.txt, but that has
long since expired.

Ken
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 16 Mar 2000 18:52:14 -0500

After a couple hours or so of reindenting, refilling, filtering of
whitespace changes, and manual edits, I've finally got a description
of what's changed since -04.  All hail Emacs! :-)

Of course, a description of what's changed since RFC 1510 would be
good too, but I don't feel up to trying that today.

Here are what I consider the semantically significant changes to the
text:

In 1.2 (Authorization):

Added: "Separately authenticated authorization credentials may be
embedded in a tickets authorization data when encapsulated by the
kdc-issued authorization data element."

In 5.3.1 (Tickets):

The addition of the "extensions" field is no longer "still subject to
discussion".

Authorization-data field can now be used to amplify privileges "when
an entry is separately authenticated by encap[s]ulation in the
kdc-issued element".

As an alternative to the authorization grantor using
authorization_data to add restrictions to authority delegated to a
proxy, "such authorization credentials may be embedded in the ticket
authenticating the authorized entity, when the authorization is
separately authenticated using the kdc-issued authorization data
element (see B.4)".  (Section B.4 hasn't changed.)

In 5.9.1 (KRB_ERROR definition):

Optional field e-typed-data of KRB_ERROR, previously marked for
deletion, has been deleted.

In 6 (Encryption and Checksum Specifications):

The description of using block ciphers to simulate stream ciphers now
mentions "triple DES variants" as well as DES.

In 6.1 (Encryption Specifications):

The format of the data to be encrypted is no longer required to be the
one given, but any other "methods" (meaning encryption mechanisms, I
assume) that do otherwise must indicate the layout they use as part of
their definitions.

In 6.3.5 (Triple DES...):

Incorporates revisions by David Miller.

Not using key derivation is now an option.  The previously assigned
numbers are for the KD form, new numbers assigned for non-KD.

String-to-key conversion is now specified.  Input string is UNICODE.

HMAC is required, not merely recommended, as the hash.

Lots of changes; look it up yourself.  :-)

In 8.3 (Protocol constants and associated values):

Encryption types: sign-dsa-generate deleted, des3 and rc4 values
assigned.

Checksum types: RSA values commented with "(drop rsa?)", added non-kd
des3.

Preauth data types: PA-ENC-UNIX-TYPE commented as deprecated, "PA-"
prefix added to several entries, PA-SAM-ETYPE-INFO and several PA-PK
values added.

Authorization-data types: AD-OSF-DCE-PKI-CERTID added.

Several entries now "<reserved>" numbers were previously just badly
formatted table entries.  (Broken HTML source?)

In 9.1 (Specification 2):

Added "one triple des variant (tbd)" to required encryption types.
Added "(tbd)" to required checksum types?
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 19 Mar 2000 02:53:24 -0500

Is the key-derivation draft going to get re-issued?  Marc?

Considering the operations described in
draft-ietf-cat-kerberos-passwords-04 (is this gonna get updated?),
perhaps we should also add descriptions on how to generate keys given
two independent keys as input, rather than a key and a small-integer
usage value?  I.e., make it part of the complete specification of a
Kerberos cryptosystem?

Ken

---

From: Booker Bense <[email-masked]>
Date: Thu, 30 Mar 2000 11:56:30 -0800 (PST)

- I have some quibble with Section 7.1 realm names. 

     Domain names must look like domain names: they consist of components
     separated by periods (.) and they contain neither colons (:) nor
     slashes (/). Domain names must be converted to upper case when used as
     realm names.

- This is going to make my life very difficult, ( and perhaps other sites
foolish enough to get trapped in DCE ). I think that there is a pretty 
strong case that for user inaction, a principal should just 
"look like an email address". 99.99999% of the world is used to using 
lower case for the domain part of email addresses. 

- It's a whole lot easier to tell some one over the phone "just type in
your email address" than to explain the oddities of some RFC. While this
issue can be addressed in software, I think it would be better to simply
state that 
	
	"Domain based realm names are case-insentive and follow the rules
for DNS names (see RFCXXXX)". 

- This halfway position (i.e. realm names are case-sensitive, but you
can't use lower case ) makes very little sense to me. 

- Booker C. Bense