Re: [KAMADA Ken'ichi] Re: [Gen-art] Gen-Art LC Review: draft-ietf-kink-kink-11.txt

At Wed, 14 Dec 2005 18:06:14 -0800,
Michael Thomas <[email protected]> wrote:
> 
> > 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.
> 
> It was intentional that KINK_ENCRYPT was optional -- for everything.
> I don't really feel very strongly about it at this point other than
> general nervousness about making big changes in the document at
> this point with a good possibility that the document will be
> inconsistent.

OK, I withdraw the latter part of the changes.
New proposal is here.


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.


-- 
KAMADA Ken'ichi <[email protected]>