AD review: draft-ietf-kink-kink [section 1-4]

I can tell already that I'm not going to finish up my comments by
Thursday.  My day job has decided to reorganize and this week's IESG
telechat has some documents that are taking me a wihle to go through.
I will get the rest of my comments to the group by early next week

The bad news is that most of the interesting comments I have are in
the second half of the document so this message is not all that
useful.



I'd recommend reading draft-ietf-ipsec-rfc2401bis,
draft-ietf-krb-wg-crypto and skimming
draft-ietf-krb-wg-kerberos-clarifications.

Rfc2401bis is setting before the IESG; there are some discusses
although I expect the document to be approved by IETF 62.

The Kerberos documents have been approved and are in the RFC editor
queue.  The crypto document is actually in auth48 waiting for Ken to
confirm some final edits.



[**] Indicates an issue that I consider substantive and that will
require wg consensus.

First. the document needs to meet all the ID nits when it is
submitted.

Section 1:

Remove the reference to pkcross or cite something outside the IETF.
It's an expired ID without and active editor.

Add an informative reference to IKE.
Section 2:

Kerberos is now using the term user-user rather than user-to-user.


Principals are not either client or service principals; they can and often do fill both roles.

Cite a reference for DER.

Section 3:

English usage/grammar problems with the first two paragraphs.

     which allows a final acknowledgment message when the respondent needs
        a full three-way handshake. This is only needed when the optimistic
           keying route is not taken, though it is expected that that will not
              be the norm. KINK also provides rekeying and dead peer detection as

What is expected not to be the norm?  Please reword.


Section 4.2:

[**] How will the initiator determine whether it will be able to get a
TGT?  I think policy considerations of when to use u2u and
authorization considerations of what u2u principals are authorized are
underspecified in the draft.

[**] Make sure the descriptions of u2u work correctly in the cross-realm case.


Section 4.3:

[**] I need explicit review from the IPsec reviewer of this section to
make sure it is compatible with 2401bis.  IN addition, any differences
between how this works and how IKE would set up the same SA need to be
called out.  It is fine for there to be differences, but I want to
make sure the working group explicitly decided the differences are a
good thing.


I'm somewhat concerned that 4.3 is not specific enough to describe
exactly what key gets set up.  I.E. I'm concerned it may not be
detailed enough for interoperable implementations.


Section 4.4

IPsec does not allow half-open security associations any more as far
as I can tell in 2401bis.  So it's not just for simplicity, but for
model conformance.

Section 4.4.1:

Please make sure this discussion is aligned with 2401bis.  I think it
may change small details but they seem to have adopted much of the
same strategy kink uses.  The area wher I believe they speak to this
issue is when you should rekey (timers etc)
Section 4.4.2

[**] Discuss status message, rebooting peers and u2u.  This looks a
lot like the IKE case where you lose all cryptographic context to me.