Subject: Synopsis of Kerberos Revisions Comments by section

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 21 Sep 2000 10:51:22 -0500

Cliff asked me to summarize the comments sent in so far
for the Kerberos Revisions. This will help him in his editing.
If I have misinterpreted anyone's notes, please let me know.

Section 1:
(Cliff has already started editing this section, So I will not
summarize the comments. Name canonicalization and referrals where
the main discussion points.) 

Section 2:
  Doug Engert: 8/8/00 2.9.1 Minor editing. What are "common Names"

  Jeffrey Hutzelman 8/8/00 2.9 Name canonicalization is to vague,
    implying it could be used as substitute for DNS. This should be 
    avoided. 
  
Section 3:
  Martin Rex: 8/24/00 (2 notes) Worried about KERB_ERROR message
    being checksumed using user's private key, might be easier to 
    mount a dictionary attack. 

  Cliff Nueman 8/24/00 responded that 5.9.1 addresses the issue.
   (DEE: Maybe Section 3.1 should had a reference to 5.9.1)

   Ken Raeburn 8/24/00 Comments on the mark-up language use in these
     
Section 4:
  Nicolas Williams 9/11/00 Section 4 must be a guideline only. 
   
  Booker C. Bense and Nicolas Williams 9/13/00 discussed a number of issues
    with allowing key to be retrieved from the database for servers
    which share the same key. They also discussed the use of hardware
    encryption devices to store keys. 

  Ken Hornstein 9/13/00 Has no problems with transferring for a key for 
   servers which share the same key.  
 
 Broker C. Bense 9/15/00 Concerns about synchronizing the distribution
  of shared keys. If client password/key change code could store to local 
  disk before the updating KDC database he could live with this. 

  (DEE: This discussion is not complete, and no specific changes to the
   draft where proposed. Would Nicolas and Brooker (and anyone else) care 
   to continue the discussion, with regard to Hardware encryption,
   servers with shared keys, and replicated KDCs and suggest any changes 
   to the document if changes are needed to support these devices? )

Section 5:
    No comments

Section 6:
    Not released yet

Section 7:
   Pat Moore 7/14/00 Needs support for SRV_HST where the service name
     is separated by / and the host is the final component. The current 
     draft does not support this. Pat gave updated text for the Revisions,
     and suggested as an alternative a NT_CPLXSRV_HST. Compatibility with GSSAPI
     is critical, and SRV_HST could map gss_nt_servoce_name to NT_SRV_HST.

  Sam Hartman 9/18/00 Commented on the use of name types as specified in the
     document.  He could send text on this, but would argue they should not
     be used at all. 

    (DEE: Further discussion on this is welcome.)

Section 8:
    Released yesterday.
    Ken Raeburn 9/20/00 COmments on not allowing IPv4 loopback address. 
    Port 88 should be the suggest stand port, but others could be used.
    Questions on ow TCP connections to the KDC should be closed. Questions
    on the extension of the length field used with TCP. Pointed out
    inconsistencies with name types table. He also questions why internal
    errors in the database have separate error code and sent to the client.
 
Section 9:
    Released yesterday, no comments yet. 

Section 9: 
    Released yesterday.

  

-- 

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

---

From: Ken Raeburn <[email-masked]>
Date: 21 Sep 2000 12:58:03 -0400

Thanks for the summary.

> the main discussion points.) 

Did we actually reach any conclusions?  Do we even have consensus on
the need for these as part of Kerberos?  Some of my questions have
tried to refine the specification, but I think I've made it clear I've
never been convinced it was needed.  And I think a number of the
questions (mine and others') were just never answered.

If we don't have consensus, should it be removed and reexamined later
after a less contentious Kerberos spec gets approved?

>    Ken Raeburn 8/24/00 Comments on the mark-up language use in these

...and more non-markup comments coming.  I'm a bit behind. :-(

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Sep 2000 15:51:22 -0400

>     implying it could be used as substitute for DNS. This should be 

I agree that consensus has not been reached on name canonicalization. I
do see its value though.

> Section 4:

...

>    to the document if changes are needed to support these devices? )

I would like to, yes.

My specific request is that neither kadmin, nor password changing
services, nor LDAP interfaces to KDCs should make it possible to
extract active keys from KDC's databases. We subsequently discussed
adding features to the password changing protocol to facilitate keytab
synchronisation, perhaps by allowing the extraction of "on hold" keys.

If we can agree that this problem should be solved externally to the KDC
or through appropriate features in the password changing protocol then
we can probably come to an agreement quickly on Section 4.

Note that with MIT's kadmin protocol you cannot extract a key from the
KDC anyways. The ktadd command sets a new random key for the given
principal before adding the new key to the named keytab, or so I
understand -- somewhat confusing, of course, and a fact I was not aware
of until it was pointed out on the MIT lists recently.

>     No comments

There must be some comment to make here, it's a large section :)

I just added some comments on section 8 as well.

Nico
--

---

From: Tom Yu <[email-masked]>
Date: 22 Sep 2000 00:21:05 -0400

>>>>> "deengert" == Douglas E Engert <[email-masked]> writes:

deengert> Section 5:
deengert>     No comments

I'm working on quite a few comments for this section.  Hopefully I'll
send them out before the end of the week.

---Tom

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 22 Sep 2000 13:10:23 -0700

I'd like to see the following ASN.1 structure included in the ticket extension
types:

KRB-TE-REFERRAL  :: =  SEQUENCE { 
      referred-realm[0]                   Realm, 
      referred-server-names[1]    SEQUENCE OF PrincipalNames OPTIONAL 
} 

The ASN.1 encoded data should be encrypted using the same key that encrypts the
encrypted part of the KDC reply message.

Jonathan