RFC Errata
Found 2 records.
Status: Held for Document Update (2)
RFC 4430, "Kerberized Internet Negotiation of Keys (KINK)", March 2006
Source of RFC: kink (sec)
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
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