AD Review: draft-ietf-kink-kink [starting at section 5]

General issues:

[**] Versioning: what happens when a receiver receives a major or
minor version of the kink or qm that is inconsistent with this
document?  What about unknown payload types?


[**] U2u: I think we need to look at how u2u works at various parts of
the protocol.  In particular I'm concerned about choosing the right
u2u principal, dealing with cross-realm u2u and dealing with
recovering from reboots.  We should confirm all these work out.


Section 5:




     o  DOI (4 octets) - The domain of interpretation. All DOI's must be
	registered with the IANA in the "Assigned Numbers" RFC [STD-2].

Cite a specific registry please.  IANA registries are typically named, and a URL reference would probably be appropriate.


     o  Reserved (15 bits) --  Reserved and must be zero

Must be zero on send, must be ignored by receiver.


     o  CksumLen (2 octets) -- CksumLen is the length in octets of the
	keyed hash of the message. A CksumLen of zero implies that the
	message is unauthenticated. Note that as with payload padding, the
	length here denotes the actual number of octets of the checksum
	structure not including any padding required.


If I understand this text correctly, the length would be set to 6 if I
had a 6-byte checksum padded outto 8 bytes.  How would kink find out
about those two bytes of padding and know to skip them?

In a kcrypto universe I believe this length should just be the length
of the output of the get_mic operation.  Reading later, perhaps this
text is only talking about kink padding  not crypto-system padding.
If so, then please just clarify that you mean the padding discussed in 5.1.

[**] The checksum length is non-deterministic.


[**] The description of the checksum says that the session key of the
ticket is used.  That's a way to do it, but the working group should
explain why it has chosen to ignore the subsession key.

[**] The document claims that the transaction id is not used for
replay detection because Kerberos provides that.  How is that true?
The authenticator is protected against replays but how is the rest of
the message bound to that specific authenticator instead of to a
session key of a ticket?

The cksum field should be the output of the get_mic operation and the
verify_mic operation should be used to verify it.  I believe
appropriate text has already been suggested on the list.

Why is the next payload in the message header one byte, but the next
payload in the payload header two bytes?  If this is not a
documentation bug, it should probably be called out so people know not
to assign payload ids greater than 255.



Section 5.1.2:

[**] How do I discover the FQDN of my remote peer?   SPD
entries are configured in terms of  IP addresses.  If you  want to
store an identity in the PAD, why not store a principal instead of a
hostname.

[**] How do I authorize which service I'm talking to in the u2u case.
I.E. how do I know what principals are authorized for a particular SPD
entry?

	tion information across different restarts. The format of this
	fields is network order encoding of the standard posix four octet
	time stamp.


Perhaps you need a description of the time stamp?  I recall there
being such a description in draft-housley-binarytime-xx.


Section 5.1.4:

[**] Why should a sender send only those errors?  I'm mostly asking
for an explanation to be given to me or to be added to the document
rather than liberalization of the requirement.



     KINK implementations MUST make use of keyed Kerberos errors when  the
     appropriate  service  key  is available as specified in [KRBREVS]. In
     particular, clock  skew  errors  MUST  be  integrity  protected.  For
     unauthenticated  Kerberos  errors,  the receiver MAY choose to act on
     them, but SHOULD take precautions against make-work kinds of attacks.

Remove paragraph.


Section 5.1.5:

[**] Please Consider how this works in the cross-realm case.
I.E. make sure you end up with the right ticket on the right side.  I
believe this text assumes that you need a ticket in a realm close to
the client; I think that for things to work you actually need a realm
close to the server.  Work through the message flows and make sure the
KDC doing the decryption actually has the necessary keys and then
adjust the document if necessary so the right KDC is used.

The document needs to clearly indicate what error code is used in the
case when the responder cannot get a ticket because some cross-realm
key is missing.  In general we want it to be possible for an initiator
to try several identities until the initiator finds the right one that
has a shared key.

Section 5.1.8: [**] Please use the output of the kcrypto encrypt
operation directly.  Of most importance is to make sure that all
kcrypto enctypes will work even if it is not possible to decompose the
kcrypto checksum from the encrypted data.  This probably means that in
some cases you will have double checksums.
You also need to deal with making sure you can determine the length of
the plaintext.

Text should probably indacte that next payload must be none.

Section 6.1:


   o    IKE Quick Mode (phase 2) uses the hash algorithm used in main
        mode (phase 1) to generate the keying material. KINK MUST use
        the hashing algorithm specified in the session ticket's etype.

[**] This checksum may not be deterministic and is probably not
appropriate for use in setting up a key.  A PRF is provided, although
depending on how the hash is used the PRF may or may not be a suitable
replacement.  There has been significant discussion within krb-wg on
when the PRF is appropriate and when it is not.  This discussion
centered around key determination in pkinit.


Section 6.8:

What happens if a peer that implements the KE payloads communicates
with a peer that does not.  Specify the behavior in sufficient detail
to guarantee interoperability.


Section 7.1:

     defined in the following sections.  The checksum in the KRB-ERROR
     message is not used, since the KINK header already contains a check-
     sum field.

Drop reference to krb-error checksum.


Section 8:

I don't understand what this section says well enough to determine
whether it works with kcrypto.


Section 10.1:

This should not go in the security considartions section.  It is
really more about IPsec architectural considerations than security
considerations.

This text needs to take into account 2401bis.  In particular it needs
to be properly split between SPD considerations and PAD
considerations.


Section 11:

Needs work.  You may want to stop by tthe IANA office hours and ask
them for advice.  They are generally quite good at working with
authors to figure out how things need to be specified.