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

Errata ID: 1770
Status: Held for Document Update
Type: Editorial
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

(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:

[see errata ID 93 for item 7]

(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:

Notes:

[split everything except item 7 away from errata ID 93]

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


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.

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