Subject: RFC 4430 (KINK) errata and issues

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

Hello,
after reading the recently published RFC 4430 authored by you
I would like to submit a few notes on textual issues I found
in that memo.

The items below are presented in textual order, after a 'preface'
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 most remarkable inconsistencies I have found are in Section 4.2.
The initial text of that section (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.

Most of the corrections given below are needed to correct this
misconception, leaving the breakdown and all details of the payload
header in Section 4.2, while deleting all these (repeated) details
from the sections 4.2.*.

(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, Figure 7, and the explanations,

       vvvvvvvvvvv
|  The value field of this payload has 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
|   +---------------+---------------+---------------+---------------+
|   | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
    |                         EPOCH                                 |
    +---------------------------------------------------------------+
    |                                                               |
    ~                        AP-REQ                                 ~
    |                                                               |
    +---------------------------------------------------------------+

|                     Figure 7:  KINK_AP_REQ Payload

   Fields:

|    o    Next Payload, RESERVED, Payload Length -- Defined in the
|         beginning of this section.

     o    EPOCH -- The absolute time [...]

should be corrected to say:

   The value field of this payload has 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
    +---------------+---------------+---------------+---------------+
    |                         EPOCH                                 |
    +---------------------------------------------------------------+
    |                                                               |
    ~                        AP-REQ                                 ~
    |                                                               |
    +---------------------------------------------------------------+

|                  Figure 7:  KINK_AP_REQ Payload value

   Fields:

     o    EPOCH -- The absolute time [...]

(I.e. the payload header -- not being part of the value field --,
 must be deleted from Figure 7, and the redundant explanation of the
 payload header fields must be removed from the list of explanations
 of the sub-fields of the payload value field.)

(2)  Section 4.2.2 (page 18)

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

       vvvvvvvvvvv
|  The value field of this payload has 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
|   +---------------+---------------+---------------+---------------+
|   | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
    |                         EPOCH                                 |
    +---------------------------------------------------------------+
    |                                                               |
    ~                        AP-REP                                 ~
    |                                                               |
    +---------------------------------------------------------------+

|                     Figure 8:  KINK_AP_REP Payload

   Fields:

|    o    Next Payload, RESERVED, Payload Length -- Defined in the
|         beginning of this section.

     o    EPOCH -- The absolute time [...]

should be corrected to say:

   The value field of this payload has 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
    +---------------+---------------+---------------+---------------+
    |                         EPOCH                                 |
    +---------------------------------------------------------------+
    |                                                               |
    ~                        AP-REP                                 ~
    |                                                               |
    +---------------------------------------------------------------+

|                  Figure 8:  KINK_AP_REP Payload value

   Fields:

     o    EPOCH -- The absolute time [...]

(3)  Section 4.2.3 (page 19)

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

       vvvvvvvvvvv
|  The value field of this payload has 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
|   +---------------+---------------+---------------+---------------+
|   | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                      KRB-ERROR                                ~
    |                                                               |
    +---------------------------------------------------------------+

|                    Figure 9:  KINK_KRB_ERROR Payload

   Fields:

|    o    Next Payload, RESERVED, Payload Length -- Defined in the
|         beginning of this section.

|    o    KRB-ERROR -- The value field of this payload contains a raw
|         Kerberos KRB-ERROR.

should be corrected to say:

   The value field of this payload has 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
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                      KRB-ERROR                                ~
    |                                                               |
    +---------------------------------------------------------------+

|                 Figure 9:  KINK_KRB_ERROR Payload value

   Fields:

|    o    KRB-ERROR -- a raw Kerberos KRB-ERROR.

(4)  Section 4.2.4 (page 20)

Like (1b) above, the text and Figure 10,

       vvvvvvvvvvv
|  The value field of this payload has 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
|   +---------------+---------------+---------------+---------------+
|   | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                     PrincName (variable)                      ~
    |                                                               |
    +---------------------------------------------------------------+

|                    Figure 10:  KINK_TGT_REQ Payload

   Fields:

|    o    Next Payload, RESERVED, Payload Length -- Defined in the
|         beginning of this section.

     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 be corrected (also filling in a missing word) to say:

   The value field of this payload has 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
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                     PrincName (variable)                      ~
    |                                                               |
    +---------------------------------------------------------------+

|                 Figure 10:  KINK_TGT_REQ Payload value

   Fields:

     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 and Figure 11,

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

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

|                    Figure 11:  KINK_TGT_REP Payload

   Fields:

|    o    Next Payload, RESERVED, Payload Length -- Defined in the
|         beginning of this section.

     o    TGT -- The Distinguished Encoding Rules (DER)-encoded TGT of
          the responder.

should be corrected to say:

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

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

|                 Figure 11:  KINK_TGT_REP Payload value

   Fields:

     o    TGT -- The Distinguished Encoding Rules (DER)-encoded TGT of
          the responder.

(6)  Section 4.2.6 (page 21)

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

       vvvvvvvvvvv
|  The value field of this payload has 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
|   +---------------+---------------+---------------+---------------+
|   | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+-------+-------+---------------+---------------+
    | InnerNextPload| QMMaj | QMMin |            RESERVED           |
    +---------------+-------+-------+---------------+---------------+
    |                Quick Mode Payloads (variable)                 |
    +---------------+---------------+---------------+---------------+

|                     Figure 12:  KINK_ISAKMP Payload

   Fields:

|    o    Next Payload, RESERVED, Payload Length -- Defined in the
|         beginning of this section.

     o    InnerNextPload -- First payload type [...]

should be corrected to say:

   The value field of this payload has 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| QMMaj | QMMin |            RESERVED           |
    +---------------+-------+-------+---------------+---------------+
    |                Quick Mode Payloads (variable)                 |
    +---------------+---------------+---------------+---------------+

|                  Figure 12:  KINK_ISAKMP Payload value

   Fields:

     o    InnerNextPload -- First payload type [...]

(7)  Section 4.2.7 (page 22/23)

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 better say, incorporating text from the 1st bullet on page 23:

|  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, and accordingly, the Next Payload
|  field in its payload header must be KINK_DONE(0).  The 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
    +---------------+---------------+---------------+---------------+
    | InnerNextPload|                   RESERVED2                   |
    +---------------+---------------+---------------+---------------+
    |                         Payload (variable)                    |
    +---------------+---------------+---------------+---------------+

|          Figure 13:  KINK_ENCRYPT Payload value (unencrypted)

On page 23, the first bullet,

|    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).

should be deleted.
(Part of the text is incorporated above; see (1b) for the remainder.)

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

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

                            vvv
|  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.  The encrypt function may have padding in
   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:

                            vv        vvvvvv
|  The format of the encrypted 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.  The encrypt function may have padding in
   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.
   [...]

(8)  Section 4.2.8

As this section is self-consistent with respect to the terminology
posed in the RFC, I omit recommending a change similar to item (2)
etc. above, but that should be considered for any update to this RFC
in the future, to make the subsections 4.2.* as similar as possible.

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 exeption.  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:

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

Please comment.
To address these issues, I recommend that you submit an Author's
Errata Note to the RFC-Ed's RFC Errata web pages, making freely
use of the material presented above.
But if you prefer, I can also submit a formal Errata Note
on my own, with your approval.

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: Jan Vilhuber <[email-masked]>
Date: Thu, 6 Jul 2006 10:19:51 -0700

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

This is common practice when writing RFC's, and is intended to show  
the complete payload WITH THE HEADER. This does not mean that there  
is a duplicate header there, but instead the header is shown for  
completeness.

jan

>   Alfred HÎnes.
> +------------------------ 
> +--------------------------------------------+
> +------------------------ 
> +--------------------------------------------+

---

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

Jan,
thanks for your very quick response.

> On Jul 6, 2006, at 7:21 AM, Alfred Hönes wrote:
> 
>> ...
>>
>> ...

Thus, if the full payloads have been presented intentionally
(including the repeated specification of the payload header),   (*)
why does the RFC text constantly say it is talking about the
payload *values* ???

I will immediately prepare a revised version of my original
mail that will try to change that instead, to get rid of the
inconsistencies in the text, in a manner that accomodates your
intent as stated above, and leaving all other things untouched.

BTW: (*) This practice has a significant drawback.
  Having multiple places in the text that specifying the same
  thing is very dangerous when it comes to updates, because all
  these places must be kept synchronized correctly.
  One of the latest examples where this became apparent is the
  set of SSH RFCs recently published.  There are some details
  in syntax and semantics specified repeatedly throughout these
  documents, and there obviously have been late changes that
  have not been applied consistently, leading to significant
  inconsistencies and contradictions in the published document
  set.

Best regards,
  Alfred.

---

From: Bob Braden <[email-masked]>
Date: Thu, 06 Jul 2006 13:41:01 -0700

>is a duplicate header there, but instead the header is shown for

Jan.

Speaking as a long-time member of the Internet technical
community, I would say that such a "common practice" is
quite wrong and misleading.  I agree that it happens,
unfortunately, and perhaps the RFC Editor should catch
it.

For example, when I wrote RFC 2205 on RSVP, I was
quite careful to get this right, while subsequent mods to
2205 have gotten it wrong.

But wrong is wrong, and "common:". is not an excuse. You
could all it pedantic, but if we do not maintain technical
accuracy, what claim can we have to standards making?

Bob Braden

---

From: Jan Vilhuber <[email-masked]>
Date: Thu, 6 Jul 2006 14:06:27 -0700

Well maybe I spoke too hastily, then. It's the style I'm familiar  
with, and the one that first comes to mind. I can't say for sure if  
I've ever seen other styles or not (my memory is notoriously bad), so  
I suppose I'll withdraw the comment...

Note I'm not religious about it. I'm perfectly fine removing the  
redundant header information (though at this stage in the game, do we  
revise rfc's?).

jan