RFC 4430, "Kerberized Internet Negotiation of Keys (KINK)", March 2006

Errata ID: 93
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-06
Held for Document Update by: Pasi Eronen
Date Held: 2009-04-30

[editorial nits moved to errata ID 1770]

(7)  Section 4.2.7 (page 22/23)

(7a) Item (1b) above applies, and plaintext vs. ciphertext is unclear.

The initial text and Figure 13 unfortunately do not properly make
the distinction between unencrypted (plaintext) and encrypted
(ciphertext) values and fields.
The presentation on page 22 needs clarification, according to the
note given on page 23:

   The coverage of the encrypted data begins at InnerNextPload so that
   the first payload's type is kept confidential.  Thus, the number of
   encrypted octets is PayloadLength - 4.

On page 22, the text and Figure 13,

|  The KINK_ENCRYPT payload encapsulates other KINK payloads and is
|  encrypted using the session key and the algorithm specified by its
   etype.  This payload MUST be the final one in the outer payload chain
|  of the message.  The KINK_ENCRYPT payload MUST be encrypted before
   the final KINK checksum is applied.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|   +---------------+---------------+---------------+---------------+
|   | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
    | InnerNextPload|                   RESERVED2                   |
    +---------------+---------------+---------------+---------------+
    |                         Payload (variable)                    |
    +---------------+---------------+---------------+---------------+

|                    Figure 13:  KINK_ENCRYPT Payload

should say:

|  The KINK_ENCRYPT payload encapsulates other KINK payloads and its
|  value is encrypted using the session key and the algorithm specified
   by its etype.  This payload MUST be the final one in the outer
|  payload chain of the message.  The plaintext KINK_ENCRYPT payload
|  value MUST be encrypted before the final KINK checksum is applied.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
|   |                                                               |
|   ~       encrypted KINK_ENCRYPT Payload value (variable)         ~
|   |                                                               |
    +---------------+---------------+---------------+---------------+

|                    Figure 13a:  KINK_ENCRYPT Payload

(I have chosen the more descriptive filed name,
'encrypted KINK_ENCRYPT Payload value' over the more fuzzy term,
'encryption payload' used in the text on page 23.)

After the first bullet on page 23,

     o    Next Payload, RESERVED, Payload Length -- Defined in the
          beginning of this section.  This payload is the last one in a
          message, and accordingly, the Next Payload field must be
          KINK_DONE (0).

The following text and figure should be inserted:

     o    encrypted KINK_ENCRYPT Payload value -- This is the
          encrypted form of the plaintext form of the KINK_ENCRYPT
          Payload value in the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    | InnerNextPload|                   RESERVED2                   |
    +---------------+---------------+---------------+---------------+
    |                   KINK Payloads (variable)                    |
    +---------------+---------------+---------------+---------------+

|          Figure 13b:  unencrypted KINK_ENCRYPT Payload value

   Fields:


(7b)  typo, and (7a) continued

The final paragraph of Section 4.2.7, on page 23, says:

                     vvvvvvvvvvvvvvvvvv
|  The format of the encryption payload follows the normal Kerberos
   semantics.  Its content is the output of an encrypt function defined
   in the Encryption Algorithm Profile section of [KCRYPTO].  Parameters
   such as encrypt function itself, specific-key, and initial state are
   defined with the etype.  [...]
   itself and there may be some garbage data at the end of the decrypted
   plaintext.  A KINK implementation MUST be prepared to ignore such
   padding after the last sub-payload inside the KINK_ENCRYPT payload.
   [...]

It should say:

                     vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The format of the encrypted KINK_ENCRYPT Payload value follows the
   normal Kerberos semantics.  Its content is the output of an encrypt
   function defined in the Encryption Algorithm Profile section of
|  [KCRYPTO].  Parameters such as the encrypt function itself, specific-
   key, and initial state are defined with the etype.  [...]

Notes:

Items (1)..(7) have been revised on the author's comments received.
In particular, item (7) has been revised substantially to achieve
a selfconsistent presentation in accordance with the author's intent.
I propose to incorporate the above items (1)..(7) and (9) directly
into an RFC Errata Note.
Item (8), and perhaps item (7) as well, still needs judgement from
the RFC authors.

------------------------------------------------
ERRATA RESPONSE:
From: Unknown Name (though from this email: Shouichi.Sakane@jp.yokogawa.com)
Could someone verify 1a, 4b and 9b ?

from pending

Report New Errata