--- Begin Message ---
At Tue, 13 Dec 2005 19:49:41 -0500,
"Joel M. Halpern" <joel@xxxxxxxxxxxxxxxx> wrote:
>
> But the document never actually states that encapsulation rule.
> I could tell from the examples that was what you intended.
> But the words need to actually say it.
>
> The current text of KINK_ENCRYPT just states that it carries some
> sub-values. It does not state what the sub-values are, nor that if used it
> should carry all content except the KINK_AP_REQ.
I see your point.
I added a paragraph about the content of KINK_ENCRYPT in section 6.
Some notes:
1) As I also think message construction is suitable for section 6
(as with Sakane-san), I added the paragraph there.
2) DELETE and STATUS messages may also contain a KINK_ENCRYPT
payload. I'd like to add the description in the generic part of
section 6 rather than in the subsection of each command/reply.
BTW, when clarifying KINK_ENCRYPT, I noticed that section 6.3
indicates that KINK_ENCRYPT in a CREATE message is optional.
I suspect this is a mistake.
Mike, could you confirm this is not intentional?
If not, I'd like to change that as well.
Section 4.2.7., para. 1:
OLD:
The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
using the encryption algorithm specified by the etype of the session
key. This payload MUST be the final payload in the message. KINK
encrypt payloads MUST be encrypted before the final KINK checksum is
applied.
NEW:
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.
Section 6., para. 1:
OLD:
All commands, responses, and acknowledgments are bound together by
the XID field of the message header. The XID is normally a
monotonically incrementing field, and is used by the initiator to
differentiate between outstanding requests to a responder. The XID
field does not provide replay protection as that functionality is
provided by the Kerberos mechanisms. In addition, commands and
responses MUST use a cryptographic checksum over the entire message
if the two peers share a key via a ticket exchange.
NEW:
All commands, responses, and acknowledgments are bound together by
the XID field of the message header. The XID is normally a
monotonically incrementing field, and is used by the initiator to
differentiate between outstanding requests to a responder. The XID
field does not provide replay protection as that functionality is
provided by the Kerberos mechanisms. In addition, commands and
responses MUST use a cryptographic checksum over the entire message
In all cases in this section, if a message contains a KINK_AP_REQ or
KINK_AP_REP payload, other KINK payloads MAY be encapsulated in a
KINK_ENCRYPT payload. KINK_ISAKMP payloads in a CREATE message and
in a successful REPLY message MUST be encapsulated.
Section 6.3., para. 2:
OLD:
CREATE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]
NEW:
CREATE KINK Header
KINK_AP_REQ
KINK_ENCRYPT
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]
Section 6.3., para. 4:
OLD:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payload
[Nonce Payload (Nr)]
[KE]
[IDci, IDcr]
[Notification Payloads]
NEW:
REPLY KINK Header
KINK_AP_REP
KINK_ENCRYPT
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payload
[Nonce Payload (Nr)]
[KE]
[IDci, IDcr]
[Notification Payloads]
--
KAMADA Ken'ichi <kamada@xxxxxxxxxx>
--- End Message ---