KINK issue list

Here is a merged version of KINK issues expressed till now.
If I missed some of them you noted, please let me know.


[**] Indicates an issue considered substantive.
[-] Indicates an editorial issue.


[**] user-to-user (section 3 and 4.2)

	It seems like the
	server tells the client what principal to authenticate to, but this
	principal is not properly authorized.  (Sam Hartman)

	More examination of user-to-user case, especially situations where 
	it might *not* be two PKINIT clients, which section 3 says is possible. 
	(BTW, in the Kerberos docs, it's "user-to-user", not "user-user".)
	(Ken Raeburn)

	Verifying remotely supplied identity, as Sam raised earlier.
	(Ken Raeburn)

	In the user-to-user case with TGTs, I think the KINK draft may be 
	over-specifying things that should be dealt with at the Kerberos level. 
	If things are underspecified in Kerberos Clarifications, let's deal 
	with that.  (Ken Raeburn)

	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.
	(Sam Hartman)

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


[**] CREATE Security Association from the aspect of 2401bis (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.
	(Sam Hartman)


[*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3)

	Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the 
	nonce should be used.  If the circumstances they're describing are 
	different, that's okay, but if so, I missed it on first reading.
	(Ken Raeburn)


[*] Half open (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.  (Sam Hartman)


[**] 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.


[*] CksumLen (section 5)

	Diagram indicates one octet for cksumlen, but the text (and 
	kcrypto specifications) say it should be two.


[**] etype does not directly indicate checksum type (section 5)

	a key's encryption type does not directly indicate 
	a checksum type, it indicates an encryption(-with-integrity-protection) 
	scheme, which does include a required-to-implement checksum type
	(Ken Raeburn)


[**] Kerberos allows variable length checksum (section 5)

	I'd have to go back and check, but I don't think we require that 
	a given checksum type have a fixed output size, so "leave X amount of 
	space and fill it with zero for computing the checksum" is questionable 
	too.  (Ken Raeburn)


[*] Kerberos checksum is not deterministic (section 5)

	The Kink description of how to verify a checksum assumes that
	Kerberos checksums are deterministic; this is not strictly required.
	(Sam Hartman)

	let kcrypto specify how 
	to verify a checksum, as they're not required to be deterministic, so 
	the "compute it again and compare" approach specified in section 5 is 
	wrong  (Ken Raeburn)

	The spec should describe how to verify checksum as follows.

	To verify the checksum, the checksum is saved, and the
	checksum field is zeroed out.  The resulting message and the saved
	checksum are passed to the verification function.  If the verification
	fails, the message MUST be dropped.


[*] Subsession keys (section 5 and 8)

	Are subsession keys ignored?  (Ken Raeburn)


[**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1)

	Section 7.1 says the checksum in the KRB-ERROR message is not used,
	but section 5.1.4 says that KINK implementation MUST make use of
	keyed Kerberos errors.  But KRB-ERROR does not have checksum in it (at
	least with RFC 1510 or kerberos-clarifications).
	I think a correct phrase here is "KINK implementations MUST make use of
	a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate
	service key is available."


[**] KINK_ENCRYPT format (section 5.1.8)

	The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is
	vague.  I think of using the output of raw encryption algorithms
	(i.e. E(confounder | plaintext | pad)) or using EncryptedData.

	treat "encryption with 
	integrity protection" output as a whole, don't peek under the covers to 
	find a "checksum" part you can throw away  (Ken Raeburn)

	drop references to the initialization vector  (Ken Raeburn)


[*] Kerberos PFS (section 6.8)

	Sec 6.8: "Kerberos in general does not provide FPS so it is somewhat 
	questionable whether a system which is heavily relying on Kerberos 
	benefits from PFS."  First, that sounds like it might be Security 
	Considerations material.  Second, I don't follow; explain please?
	(Ken Raeburn)


[*] MUST/SHOULD in clock skew (section 7.1)

	The time difference MUST be computed and SHOULD be stored 
	and used?  Why the different requirement levels?  (And is this sort of 
	thing in the domain of KINK or Kerberos?)  (Ken Raeburn)


[**] prf (section 8)

	Section 8 says "prf is the same hash algorithm found in the session
	ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed.
	Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK
	should use this PRF.

	Use a prf 
	from kcrypto, don't assume the checksum operations are deterministic 
	hash functions  (Ken Raeburn)



[*] Key derivation (section 8)

	The key derivation seems inconsistent with the crypto framework
	document.  (Sam Hartman)


[*] Key usage

	Usage of  kink should specify the key usage numbers for kerberos
	encryption.  (Sam Hartman)


[*] 2401bis

	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)


[*] IKEv2

	Should we adopt IKEv2?

	If we should...
	- IKEv2 does not have DOI, so how to handle the DOI field in the KINK
	  packet header should be described.
	- Use TS (Traffic Selector) instead of ID (Identification).
	- KEYMAT calculation is changed.
	- How to handle REKEY_SA Notify type.


[*] behavior on KINK_ERROR

	In implementor's point of view, I'd like to see initiator's
	behavior in receiving KINK_ERROR to be defined.
	For example:
	- When KINK_OK is received, initiator MAY act as if the KINK_ERROR
	  payload was not included in the messaged.
	- When KINK_BADQMVERS is received and the Cksum is verified,
	  initiator MAY retry in other Quick Mode version.
	- When one of other error codes is received and the Cksum is verified,
	  initiator SHOULD abort the negotiation.


[-] I-D nits

	Review the I-D nits and RFC authors docs.  I spotted a lot of 
	mechanical things (number of lines per page; avoid hyphenation; use 
	ragged right margin; need two spaces after sentence-ending period; fix 
	page numbers in table of contents; add section numbers to TOC) most of 
	which I think are specified in one of those documents.
	(Ken Raeburn)

	the document needs to meet all the ID nits when it is
	submitted.  (Sam Hartman)


[-] IANA considerations

	I think the correct terminology is "port 
	number", not "port", and they're "assigned", not "created".  This 
	section says no new registries are required in the first paragraph, and 
	the third one specifies that IANA must create one (but without the 
	associated procedural data that is required nowadays).  Are the KINK 
	payload types and ISAKMP payload types actually ever used in the same 
	field?  If not, I don't think they need to come out of the same 
	registry.  (Ken Raeburn)


[-] Wording/Terminology

	Section 2 and 10.1.
	Kerberos is now using the term user-user rather than user-to-user.
	(Sam Hartman)

	Section 2.
	Principals are not either client or service principals;
	they can and often do fill both roles.  (Sam Hartman)

	Section 2, last paragraph.  "Between" is generally non-directional, 
	but in this case, a direction seems to be intended to be inferred; try 
	"from...to" instead.  (Ken Raeburn)

	Section 3, English usage/grammar problems with the first two paragraphs.
	(Sam Hartman)

	Section 3.
	   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.
	(Sam Hartman)

	Section 4.3, discussing attributes, mixes singular and plural 
	indications.  The word "lone" appears to be popular with the author, 
	too. :-)  (Ken Raeburn)

	Sec 8: "By optional, it is meant..." is badly worded.  (Ken Raeburn)


[-] References

	The reference to [PKCROSS] is unnecessary, and only happens once, in 
	the introduction.  I'd suggest dropping it.  That's one less 
	unpublished I-D in the references section.  (Ken Raeburn)

	[KRBREVS] is referenced but not listed in the references section.
	(Ken Raeburn)

	Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the 
	protocol) fuzzy about use of different SAs, or is it "[IKE]" (the 
	document)?  (Ken Raeburn)

	Section 1:
	Remove the reference to pkcross or cite something outside the IETF.
	It's an expired ID without and active editor.  (Sam Hartman)

	Section 1:
	Add an informative reference to IKE.  (Sam Hartman)

	Section 2:
	Cite a reference for DER.  (Sam Hartman)


[-] Typos

	4.4.2. Dead Peer Detection
	In the fourth paragraph, "loose" is to be "lose".

	5.1.1. KINK Padding Rules
	In the second item, "other other" is to be "other".

	5.1.1. KINK Padding Rules
	The first item in the list should end with a period like 
	the others.  (Ken Raeburn)

	5.1.5. KINK_TGT_REQ Payload
	In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM".

	5.1.6. KINK_TGT_REP Payload
	In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP".

	7.3. CREATE
	"IPspec" is to be "IPsec".

	7.5. STATUS
	In the last paragraph, "REPLY KINK Header" should be in one line.
	In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]".

	overall:
	"'s" is used in some places where I'd use "s" for a plural form.


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