Subject: RFC 4430 (KINK) errata and issues [revised]

From: Alfred Hönes <[email-masked]>
Date: Thu, 6 Jul 2006 22:17:55 +0200 (MESZ)

Hello,
this is a revised edition of my 'errata and issues' report
on the recently published RFC 4430 authored by you.

I have changed the direction of many proposed corrections
to the text, to accomodate the stated intent of the authors,
as communicated to me by Jan Vilhuber <[email-masked]>
in his reply top my original mail.

The items below are presented in textual order, after a 'preface',
item (0), giving the rationale for most of the corrections suggested.

I use change bars ('|' in column 1) and (occasionally) up/down
pointing marker lines to emphasize the location of textual issues
in the snippits from the RFC text and/or the proposed modified text.
Modified text has been adjusted according to RFC formatting policy.

(0)  Rationale for most non-trivial issues listed below:
==============

The initial text of Section 4.2 (on page 16) says:

   Immediately following the header, there is a list of
   Type/Length/Value (TLV) payloads.  There can be any number of
   payloads following the header.  Each payload MUST begin with a
   payload header.  Each payload header is built on the generic payload
   header.  Any data immediately follows the generic header.  Payloads
   are all implicitly aligned to 4-octet boundaries, though the payload
   length field MUST accurately reflect the actual number of octets in
   the payload.

     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        |
    +---------------+---------------+---------------+---------------+
    |                      value (variable)                         |
    +---------------+---------------+---------------+---------------+

                    Figure 6:  Format of a KINK Payload

   Fields:

     [...]

To sum up: a KINK payload consists of a (generic) payload header
and the (payload) value field.

Unfortunately, the subsequent sub-sections 4.2.* inadvertently
seem to pretend that there exists another copy of the payload
header within the payload value, which certainly was not intended.

It was the intent of the authors to always show and describe the
full payloads in these sections.
Therefore, the repeated text stating to the contrary that it will
show the payload *value*, has to be changed.

(1)  Section 4.2.1 (page 17)

(1a)  typo (word omission)

The final sentence in the 3rd paragraph of Section 4.2.1 says:

                                                            [...].  A
   principal name is case sensitive, and "fqdn" part MUST be lowercase
   as described in [KERBEROS].

It should say:
                                        vvvvv
                                                            [...].  A
|  principal name is case sensitive, and the "fqdn" part MUST be
   lowercase as described in [KERBEROS].

(1b)  see (0) above

The subsequent text, above Figure 7,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:

(2)  Section 4.2.2 (page 18)

Like (1b) above, the text above Figure 8,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:

(3)  Section 4.2.3 (page 19)

Like (1b) above, the text above Figure 9,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:

(4)  Section 4.2.4 (page 20)

(4a) Like (1b) above, the text above Figure 10,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:

(4b) The second bullet of the subsequent explanations,

     o    PrincName -- The name of the principal that the initiator
          wants to communicate with.  It is assumed that the initiator
          knows the responder's principal name (including the realm
|         name) in the same way as the non-User-to-User case.  The TGT
          returned MUST NOT be an inter-realm TGT and its cname and
          crealm MUST match the requested principal name, so that the
          initiator can rendezvous with the responder at the responder's
          realm.

should say (filling in a missing word):

     o    PrincName -- The name of the principal that the initiator
          wants to communicate with.  It is assumed that the initiator
          knows the responder's principal name (including the realm
|         name) in the same way as in the non-User-to-User case.  The
          TGT returned MUST NOT be an inter-realm TGT and its cname and
          crealm MUST match the requested principal name, so that the
          initiator can rendezvous with the responder at the responder's
          realm.

(5)  Section 4.2.5 (page 21)

Like (1b) above, the text above Figure 11,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload contains the TGT requested in a
   previous KINK_TGT_REQ payload of a GETTGT command.

should say:

   vvvvvvvvvvvv
|  This payload contains the TGT requested in a previous KINK_TGT_REQ
   payload of a GETTGT command.

(6)  Section 4.2.6 (page 21)

Like (1b) above, the text above Figure 12,

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|  The value field of this payload has the following format:

should say:

   vvvvvvvvvvvv
|  This payload has the following format:

(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.  [...]

(8)  Section 4.2.8

The text of this section twice, and redundantly, specifies
on page 23 :

                          [...].  The error code is in network order.

and on page 24 :

     o    ErrorCode -- One of the following values in the network byte
          order:
          [...]

This looks like a big exception.  But in fact, that is the general
rule as set in the first sentence of Section 4, on page 13!
At best, the former sentence should be deleted, and the latter
bullet changed to say:

     o    ErrorCode -- One of the following values:
          [...]

If it is preferred to not delete the former sentence and the latter
clause, at least the "the" in "in the network byte order" should be
deleted.

(9)  further word omissions in running text

(9a) The first paragraph of Section 6.6, on page 32, says:

   A GETTGT command is only used to carry a Kerberos TGT and is not
   related to SA management; therefore, it contains only KINK_TGT_REQ
   payload and does not contain any DOI-specific payload.

It should say:

   A GETTGT command is only used to carry a Kerberos TGT and is not
|  related to SA management; therefore, it contains only a KINK_TGT_REQ
   payload and does not contain any DOI-specific payload.

(9b) The first paragraph of Section 7, on page 32, says:

   KINK uses the same key derivation mechanisms defined in section 5.5
   of [IKE], which is:

It should say:
                                               vvvv
|  KINK uses the same key derivation mechanisms as defined in section
   5.5 of [IKE], which is:

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.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Bob Braden <[email-masked]>
Date: Thu, 06 Jul 2006 14:20:44 -0700

I
When we get a chance, let's talk about whether it seems feasible for
the editor to catch errors of this kind in future RFCs.  I don't think we
should presume to fix it, but it would be nice if we could spot it,
since it is a "common" error.  But perhaps this is going farther into
the content than we can reasonably accomplish.

Bob

At 10:17 PM 7/6/2006 +0200, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>   Alfred HÎnes.

---

From: 坂根昌一 <[email-masked]>
Date: Fri, 07 Jul 2006 14:17:05 +0900

Hi,

Thank you for the report.  From http://www.rfc-editor.org/errata.html, 
the authors
have to verify the errors.  Kamada-san and I reviewed the report.  
Allmost of them
are correct.  However there are some reports of grammatical errors.  I 
am not certain
that my judgement will be correct in gramatical point of view.
Could someone verify 1a, 4b and 9b ?  And 13a is obviouly correct though 
I have
never seen such little redundant description.  Again, others are correct.