Subject: WG Last Call: Clarifications and AES

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 17 Mar 2003 23:03:39 -0600

The Clarifications and AES drafts is now ready for krb-wg WG last call. 
We are starting the WG Last call process, which will last three weeks
and end on April 8. (I am adding the extra week as we have two documents, 
and Clarifications is 133 pages long.) 

There is one typo in the ASN.1 in Clarifications. The line 
in Section 5.2.7.5 which reads:

ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY

Should read:

ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
 
Clarifications can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-03.txt

AES can be found at:
http://www.ietf.org/internet-drafts/draft-raeburn-krb-rijndael-krb-03.txt

I encourage all WG members to read over these document, and send in comments.
Please include the section number in the title of the e-mail to help keep
track of the comments. If there are multiple technical issues to consider, 
please send as separate e-mails. This will help keep the issues straight. 

I especially encourage those members who represent vendors and developers of 
current implementations to review the document, and to comment. This includes 
positive comments to proceed!
  
Hopefully, KCRYPTO will be ready in a few days as well. All three need to progress
together.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Mar 2003 08:51:52 -0500

I believe all the quoted text is reasonable.  That's a SHOULD not a
MUST.  It's reasonable for the document to define the common case,
which is subsession key.  And to give interoperability guidelines for
that case.  If you wish to go beyond that case, you have significant
work to guarantee that you end up with something that works.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Mar 2003 15:40:35 +0200

> I encourage all WG members to read over these document, and send in comments.

Since the last WGLC section 3.4.1 has been changed to the following:

,----
|    When an application wishes to send a KRB_SAFE message, it collects
|    its data and the appropriate control information and computes a
|    checksum over them.  The checksum algorithm should be the keyed
|    checksum mandated to be implemented along with the crypto system used
|    for the sub-session or session key. The checksum is generated using
                                                         ---------------
|    the sub-session key if present, and the session key. Some
     ---------------------------------------------------
|    implementations use a different checksum algorithm for the KRB_SAFE
|    messages but doing so in a interoperable manner is not always
|    possible.
`----

According to section 3.2.6, KRB_SAFE does not have to use a key equal
to, or generated using, the (sub-)session keys.  The application can
define other ways to derive the keys to use for KRB_SAFE.

(See also [email-masked].)