Subject: Re: Kerberos clarifications

From: Clifford Neuman <[email-masked]>
Date: Mon, 16 Jun 2003 14:46:31 -0700

The two items that I am looking for final text on are from earlier
messages from Sam and Tom on the list:

Cliff
--

In 5.2.6.2, the text claims that the same checksum is used as was used
to protect the ticket.  Unfortunately, tickets are not actually
protected by Kerberos checksums so this text is misleading.  The text
should describe what key is used for the checksum (is it the service
key?  Is it the session key? I think either would be secure) and
should probably say that you use the checksum algorithm required to be
implement along with that encription type.  

--

Text in 5.2.7.3 and 5.2.7.4 confuses me.  I thought we were moving
away from pa-pw-salt for all uses but the current text seems to imply
it should still be used in AS requests Am I confused about the
direction of the protocol?

Actually, I seem to recall correctly but the text in 5.2.4.5 seems
inconsistent with itself and with the rest of the document:
 It MAY also be sent in an
    AS-REP to provide information to the client about which key salt to
    use for the string-to-key to be used by the client to obtain the key
    for decrypting the encrypted part the AS-REP.
     . . . 
    The preferred ordering of pre-authentication data that modify client
    key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by
    PW-SALT. A KDC shall send all of these pre-authentication data that
    it supports, in the preferred ordering, when issuing an AS-REP or
    when issuing a KRB-ERROR requesting additional pre-authentication.

Tom> This is probably due to failure to update section 5 to match section
Tom> 3.  Actually, I believe that KRB-ERROR requiring additional preauth
Tom> should never include a PA-PW-SALT, since there were implementation
Tom> bugs involving that.  Did we agree on whether to include
Tom> PA-ETYPE-INFO2 when no "new" enctype gets requested?

We should also use requirements language (MUST) instead of shall.  We
should clean up the other text dealing with sending elements in as
requests to be consistent with each other and with the text in section
3 that says you should send only etype-info2 (and not etype-info) if
the client request a new enctype.

Tom> Ok, so this is a case where section 5 wasn't updated to match section 3.

---

From: Clifford Neuman <[email-masked]>
Date: Mon, 16 Jun 2003 14:44:30 -0700

I have incorperated all of the pending items into Kerberos
clarifications except for a few items, for which I will be asking Tom
and Sam for specific text, since I could not figure our the final form
that was desired for these two issues.  You can find the nroff for
clarifications 4 off of the

   http://kerberos.us 

web site.  I will generate the text verions and submit to internet
drafts as soon as I get the text for these last two items, which I
hope I will get tonight.

Cliff

---

From: Clifford Neuman <[email-masked]>
Date: Wed, 18 Jun 2003 21:27:20 -0700

The new version of Kerberos clarifications has been sent to the
secretariat.  It may be found in the usual place off of 

  http://kerberos.us

Clifford Neuman