Re: KINK issue list

Thank you very much for compiling this list -- I have
been having a hard time following what are similar or the
same issues, and what the closure is if any. Maybe what
we can do is keep a master list here, the proposed 
resolution, or whether to close the issue due to it being
not a problem. From that, I can work on producing a new
draft.

		Mike 

On Wed, 2005-01-19 at 18:04, KAMADA Ken'ichi wrote:
> 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.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQCVAwUAQe/0ObMsDAj/Eq++AQKyVQP/SYy7InTgSviTkwj5zD3cCuhJoCY59Ejv
31NIJ2XJXVZNiTjETUx5T+x60YMczai+hCvNK6mJCiD8s3Z9DnlyOkXa6q7a4NkQ
Tf+ornB+ZcSS2WOX0O/judmbK2UcHcI3y5sK4CfvNXlrYzUzP3hHfz10nCUnk48d
UjELuRGAxL4=
=b3OQ
-----END PGP SIGNATURE-----