Subject: RE: Synopsis of Kerberos Revisions Comments by section

From: "John Brezak" <[email-masked]>
Date: Thu, 21 Sep 2000 13:38:18 -0700

below.

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Thursday, September 21, 2000 12:51 PM
> To: Douglas E. Engert
> Cc: [email-masked]
> Subject: Re: Synopsis of Kerberos Revisions Comments by section
> 
> 
> On Thu, Sep 21, 2000 at 10:51:22AM -0500, Douglas E. Engert wrote:
> > 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.) 

I'd like to see a roll-up of the issues with name-canonicalization and
referrals from the discussions.

> >   
> > 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. 
> 
> I agree that consensus has not been reached on name 
> canonicalization. I
> do see its value though.

Can the issues for name-canonicalization be summarized?

> 
> > Section 4:
> 
> ...
> 
> >   (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? )
> 
> 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.

The suggestion to add returning the service key via the change password
protocol to address the issue that the server side of the change
password protocol is the best source for a random password. I still not
very comfortable that the "random" key is now returned to the caller,
but the point was well taken as to the ability to generate a good
quality random key.

> 
> > Section 5:
> >     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: "Booker C. Bense" <[email-masked]>
Date: Thu, 21 Sep 2000 17:24:10 -0700 (PDT)

> > synchronisation, perhaps by allowing the extraction of "on hold" keys.

- This to me is 

1. Controversial

2. Well outside the scope of this document. 

- I think there are some strong tradeoffs both ways and that this
should be discussed in the scope of another document. This document
is not about the administrative protocol at all. This document is 
the wrong place to have this discussion. We need to move forward
on this document and leave this debate to other documents. 

- I think Section 4 should read like a "Best Current Practice"
document for KDC programmers. Something like : 

<Introduction> 

	The security of the KDC database is the security of the entire 
kerberos system. (More stuff about how important is it to keep the
keys secure ). This section outlines the minimum data and operational
requirements a KDC must support to fulfill the protocol and then
gives a specific example of how the Project Athena design meets these
requirements.  

<Things you must implement to support the protocol> 

	In order to implement the protocol you should(must?) support
at least the following kinds of data. 

	(The first paragraph of section 4.1 and Section 4.4)

<Operational Requirements>

	( The remaining paragraphs of Section 4.1 and  4.3) 

	I have some objections to this paragraph in Section 4.1.  

When more than one key is active for a particular principal, the
principal will have more than one record in the Kerberos database.
The keys and key version numbers will differ between the records (the
rest of the fields may or may not be the same). Whenever Kerberos
issues a ticket, or responds to a request for initial authentication,
the most recent key (known by the Kerberos server) will be used for
encryption.  This is the key with the highest key version number.

	A strict reading of this paragraph would preclude the kind
	of "store but do not use until notified" scheme that we have
	been discussing. I think this illustrates a problem with 
	much of the language in this section, it's too tightly coupled
	to the current Project Athena KDC design. Perhaps better
	language would be

When more than one key is active for a particular principal,
there must be a means for choosing which key the KDC will 
use in response to a request for initial authentication or
for issuing a ticket. This key should be the key with the highest
version number. In the general case this will be the most
recent key, but other criteria may be used in special circumstances.  

<An example implementation> 

	 ( Expand section 4.2 with a brief overview of the Project
	   Athena KDC database design. i.e. list all the fields 
	   and how they are used to accomplish the requirements
	   above. )

- Booker C. Bense

---

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

On Thu, Sep 21, 2000 at 05:24:10PM -0700, Booker C. Bense wrote:

[much deleted]

> 	to the current Project Athena KDC design. Perhaps better

Not really. I envisioned that the password changing service, which is
not [necessarily] the same thing as the KDC, would not install any "on
hold" keys in the Kerberos database until the keys are released. And if
on hold keys were installed in the KDC then the KDC could know they are
not valid, thus, as fasr as the principals are concerned the highest
kvno visible to them would be the last one not on hold

Also, there's a way to specify which kvno to use in pre-authentication.

> recent key, but other criteria may be used in special circumstances.  

Such as the client specifying a particular kvno to use in
pre-authentication.

Nico
--