Subject: draft-ietf-cat-kerberos-revisions-01.txt

From: Clifford Neuman <[email-masked]>
Date: Tue, 25 Nov 1997 08:44:45 -0800 (PST)

All,

Since I haven't seen the announcement yet and experience from the last
IETF tells me it may take a while.  Anyway, on Friday I submitted a
new draft of the Kerberos revisions.  You can find the submitted copy
as: 

  http://gost.isi.edu/people/bcn/draft-ietf-cat-kerberos-r-01.txt

There is also an HTML version of the draft available as:

  http://gost.isi.edu/people/bcn/draft-ietf-cat-kerberos-r-01.html

There is a link to the working copy of -02.html at the top of -01.html
and I plan to continue to make updates to this version prior to the
IETF.  There is currently time allocated for discussion of this draft
during the cat meeting.  I would like to collect topics to be
discussed prior to the meeting, and to promote some discussion of
those topics prior to the meeting as well.  To do this, I request that
those interested visit http://gost.isi.edu/info/kerberos.  The open
issues page reaching from there allows you to add items for
discussion, and to add comments on existing topics.

During the next week, I will be adding items to these pages listing
some of the issues that I feel still need to be resolved.  These will
include suggestions for changes that I received from others, but which
did not make it into the draft because I didn't feel we had reached
consensus on the items.  But please add comments and issues yourself
to these pages now, there is no need to wait for me to open an item if
you feel a topic is important.

Cliff

---

From: [email-masked] (Johan Danielsson)
Date: 01 Dec 1997 02:21:03 +0100

>   http://gost.isi.edu/people/bcn/draft-ietf-cat-kerberos-r-01.txt

Some comments.

> name-type
>      This field specifies the type of name that follows. Pre-defined values
>      for this field are specified in section 7.2. The name-type should be
>      treated as a hint. Ignoring the name type, no two names can be the same
>      (i.e. at least one of the components, or the realm, must be different).
>      This constraint may be eliminated in the future.

Is anyone ever going to remove that constraint? Remove the last
sentence.

> The two forms differ slightly. HostAddress contains exactly one address;
> HostAddresses contains a sequence of possibly many addresses.

This is a left-over from the former definition of HostAddresses.

> lr-type
>      This field indicates how the following lr-value field is to be
>      interpreted. Negative values indicate that the information pertains
>      only to the responding server. Non-negative values pertain to all
>      servers for the realm. If the lr-type field is zero (0), then no
>      information is conveyed by the lr-value subfield. If the absolute value
>      of the lr-type field is one (1), then the lr-value subfield is the time
>      of last initial request for a TGT. If it is two (2), then the lr-value
>      subfield is the time of last initial request. If it is three (3), then
>      the lr-value subfield is the time of issue for the newest
>      ticket-granting ticket used. If it is four (4), then the lr-value
>      subfield is the time of the last renewal. If it is five (5), then the
>      lr-value subfield is the time of last request (of any type).

Add (6) as the expiration of the client's key, and (7) as the
expiration of the client principal itself. (I think this was what's
agreed on). (I also suggest making this into a table.)

> One generates a random confounder of the appropriate length, placing it in
> confounder; zeroes out check; calculates the appropriate checksum over
> confounder, check, and msg-seq, placing the result in check; adds the
> necessary padding; then encrypts using the specified encryption type and the
> appropriate key.

Since it can be difficult to figure out where the message ends and the
pad starts, you have to include the pad in what you checksum. This is
also what everybody seem to be doing.

> 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)

Should specify the key as ivec?

> The use of the CRC-32 as the checksum for ticket or authenticator is
> no longer mandated as an interoperability requirement for Kerberos
> Version 5 Specification 1 (See section 9.1 for specific details).

Specification 2.

> 6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-sum (des3-cbc-sha1)
...

> The first 8 octets of the data to be encrypted (the confounder) is
> exclusive-ored with an initialization vector of zero and then ECB
> encrypted using triple DES as described above.
...
> Encryption under Triple DES using cipher block chaining requires an
> additional input in the form of an initialization vector. Unless
> otherwise specified, zero should be used as the initialization
> vector. Kerberos' use of DES requires an 8 octet confounder.

Duplicate code.

> String to key transformation
> 
> To generate a DES key from a text string (password),

"Triple DES key" or something.

> 8.3. Protocol constants and associated values
> 
> The following tables list constants used in the protocol and defines their
> meanings.
> 
> Encryption type  etype value  block size    minimum pad size  confounder size

What is the `minimum pad size'?

> hmac-sha1-des3             10                  20  (I had this as 10, is it 12)

Ten or twelve?

A quick scan finds that (at least) the following types are really the
same: TransitedEncoding, PA-DATA, ETypedData, Checksum,
AuthorixationData, and TicketExtensions (the last two being SEQUENCE
OFs). Wouldn't is be a good idea to merge these into one TypedData or
something?

And really, a few of these should perhaps have been CHOICEs in the
first place.

/Johan

---

From: "Todd D. Ellner" <[email-masked]>
Date: Sun, 30 Nov 1997 18:41:12 -0800

Sorry to waste folks` time, but I'm trying to get off this list
and lost the original instructions. mails to listserv, cat-ietf-request,
and majordomo at mit.edu have come up dry. Does anyone know how to
unsubscribe?

Thanks,
Todd