last call on draft-ietf-krb-wg-crypto-05

[Ken Raeburn <raeburn@MIT.EDU>]

Here's what I've seen from the IETF Last Call on this document, which
hasn't all gone to the iesg or ietf lists:

Russ asked (before the last call started) for a few changes, mostly
minor text changes, and specification of an assignment mechanism for
new encryption and checksum type numbers, which we'd kind of avoided
dealing with in the submitted draft.  I've made the text changes (can
send details or a new version if desired), and the working group has
agreed on the text below for the IANA Considerations:

11. IANA Considerations

   Two registries for numeric values should be created: Kerberos
   Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
   are signed 32-bit values in twos-complement form.  Positive values up
   to 2**31-1 inclusive should be assigned only for algorithms specified
   in accordance with this specification for use with Kerberos or
   related protocols.  Negative values through -2**31 are for private
   use; local and experimental algorithms should use these values.  Zero
   is reserved and may not be assigned.

   Positive encryption and checksum type numbers may be assigned
   following either of two policies described in [BCP26].

   Standards-track specifications may be assigned values under the
   Standards Action policy.

   Specifications in Informational RFCs may be assigned values after
   Expert Review.  A non-IETF specification may be assigned values by
   publishing an Informational or standards-track RFC referencing the
   external specification; that specification must be public and
   published in some permanent record much like the IETF RFCs.  It is
   highly desirable, though not required, that the full specification be
   published as an IETF RFC.

   Smaller encryption type values, which encode to smaller octet strings
   under ASN.1, should be used for IETF standards-track mechanisms, and
   much higher values (hex 0x1000000 and above) for other mechanisms.
   No other guidance into allocation order is given.

   Draft IETF specifications should not include values for encryption
   and checksum type numbers.  Instead, they should indicate that values
   would be assigned by IANA when the document is approved as an RFC.
   For development and interoperability testing, values in the private-
   use range (negative values) may be used, but should not be included
   in the draft specification.

   Each registered value should have an associated unique name to refer
   to it by.  The lists given in section 8 should be used as an initial
   registry; they include reservations for specifications in progress in
   parallel with this document, and for certain other values believed to
   be in use already.

Related changes are also ready for the AES draft we submitted at the
same time.


Simon Josefsson noticed an inconsistency in the handling of initial
vectors for block ciphers in section 5.3, and reported it only to the
working group (so far as I'm aware).  I have sent some suggested text
to the working group for review to fix this:

  encryption function       conf = random string of length c
                            pad = shortest string to bring confounder
                                  and plaintext to a length that's a
                                  multiple of m
                            (C1, newIV) = E(Ke, conf | plaintext | pad,
                                            oldstate.ivec)
                            H1 = HMAC(Ki, conf | plaintext | pad)
                            ciphertext =  C1 | H1[1..h]
                            newstate.ivec = newIV

  decryption function       (C1,H1) = ciphertext
                            (P1, newIV) = D(Ke, C1, oldstate.ivec)
                            if (H1 != HMAC(Ki, P1)[1..h])
                               report error
                            newstate.ivec = newIV

It is a small semantic change from the current document.  The "output"
state containing the ivec for the next encryption was requested by
some of the contributors, but is not currently in use, so this change
to its calculation for triple-DES and AES should not be a problem.
(The old specification said the last c bytes of C1 were used; since
AES is using ciphertext stealing, the new text results in different
and more desirable behavior.  Other text, being retained, also says
that the specification of the functions "E" and "D" for this profile
specify the new IV, but the submitted version then went on to ignore
it.)

The change was sent to the mailing list on the 17th.  Simon agrees
with it, but I've had no other feedback, positive or negative.

Changes for the AES draft are nearly ready.


Simon has also raised some questions on the working group mailing list
concerning the use of the word "random" in places.  This email just
came through Thursday night, and the issue is still under discussion.


As far Larry Zhu's requested changes, the other contributors and I
find them to be reasonable, and would like to incorporate them, but I
do not have them written up yet.  The new constraints aren't needed
for the Kerberos protocol itself, but are reasonable constraints, and
will allow Larry to use a more compact encoding of certain information
in the updated GSSAPI Kerberos mechanism he's working on.  (He didn't
start actively participating in the Kerberos working group until after
these documents had been submitted, or we would've taken care of it
earlier.)


These are all of the issues I've seen brought up so far.

Ken