Subject: Comments on Synopsis of Kerberos Revisions Comments by sectio

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 22 Sep 2000 09:29:48 -0500

Cliff,
Can you read and comment on the responses from Brooker Bense
John Brezak and Nicolas Williams which where sent yesterday?

They all have valid points, and some suggestions for 
changes to the document.

Also are you close to releasing a new version on Section 1?

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Sep 2000 15:04:29 -0400

I thought I'd summarise my comments so far:

[no doubt I'm forgetting :) ]

 - section 2/3: name canonicalization: sounds good, needs more
                explanation (or perhaps I should re-read that thread)

 - section 4: prohibit the extraction of principal's cleartext keys
              using [future] protocols. This should not be construed as
	      prohibiting extracting keys through a password changing
	      service which are not yet active in the KDC or which the
	      password changing service. This prohibition would not
	      affect the current state of affairs, nor anything
	      envisioned in the password changing service protocol
	      discussion.

 - section 8: generalise the prohibition against loopback addresses
 - section 8: add general prohibition against multicast/broadcast addresses
 - section 8: add hostname FQDN address type so Kerberos can be used
              over local IPC
 - section 8: add wording allowing the KDC to modify the list of
              addresses sent by the client in ticket requests (think NAT)
 - section 8: add wording to section on TCP transport, that multiple
              requests made over the same TCP connection need not be
	      related

 - section 9: make it easier to add new extension/authorization data
	      types through separate RFCs without requiring a new
	      Kerberos spec and without affecting compliance with
	      Kerberos 5.1 spec by any implementation. Perhaps the same
	      should be done for pre-auth mechanisms and even, maybe,
	      address types.

Nico

--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Sep 2000 15:12:42 -0400

Ugh! Forgive my incomplete sentences in the previous version of this
message.

****

I thought I'd summarize my comments so far:

[no doubt I'm forgetting some :) ]

 - section 2/3: Name canonicalization: sounds good, needs more
                explanation (or perhaps I should re-read that thread)

 - section 4: Prohibit the extraction of principal's cleartext keys
	      using [future] protocols. This should not be construed as
	      prohibiting extracting keys through a password changing
	      service which are not yet active in the KDC or which the
	      password changing service generates as part of the
	      process of changing a principal's key. This prohibition
	      would not affect the current state of affairs, nor
	      anything envisioned in the password changing service
	      protocol discussion (e.g., random key generation, keytab
	      synchronisation through on-hold keys).

 - section 8: Generalize the prohibition against loopback addresses.
 - section 8: Add general prohibition against multicast/broadcast addresses.
 - section 8: Add hostname FQDN address type so Kerberos can be used
              over local IPC.

 - section 8: Add wording allowing the KDC to modify the list of
              addresses sent by the client in ticket requests. Not only
	      would this be useful to enable the use of Kerberos across
	      NAT routing, but it would also allow a KDC implementation
	      to prevent abuse of ticket addresses by clients attempting
	      to get around no-forwardable ticket restrictions

 - section 8: Add wording to section on TCP transport, that multiple
              requests made over the same TCP connection need not be
	      related.

 - section 9: Make it easier to add new extension/authorization data

Nico
--