Re: Moving forward on KINK--deadline for action

On Jan 2, 2005, at 22:29, Sam Hartman wrote:
> I said I would provide detailed comments to the WG by January 20.  I
> know Ken Raeburn has done a review of the document himself and found
> issues similar to those I found; I don't know if he plans to send that
> review to the working group.

Yes, I'll get back to this after finishing my "48 hours" on a couple of 
Kerberos RFCs.

I've only a few comments on the technical stuff so far:

1) Needs alignment with current Kerberos specs.  Forget RFC 1510, use 
kcrypto and clarifications.  In particular, (1) treat "encryption with 
integrity protection" output as a whole, don't peek under the covers to 
find a "checksum" part you can throw away, (2) 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, (3) drop references to the initialization vector, (4) use a prf 
from kcrypto, don't assume the checksum operations are deterministic 
hash functions, (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.  
Also, 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.

2) 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".)

3) Verifying remotely supplied identity, as Sam raised earlier.

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

5) Are subsession keys ignored?

6) 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.

7) Sec 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?)

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?

9) 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.

I can throw out some additional editorial comments though:

1) 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.

2) 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.

3) Spelling.  "loose" was used where "lose" should've been in at least 
one place, 6.1 says "optmistic" (but hyphenated); 7.3 says "IPspec".  
"'s" is used in some places where I'd use "s" for a plural form.

4) 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.

5) 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.

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

7) Sect 5.1.1, first item in the list, should end with a period like 
the others.

8) [KRBREVS] is referenced but not listed in the references section.

9) 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)?

10) Sec 8: "By optional, it is meant..." is badly worded.

Like I said, I'll try to get back to this soon.

> Along with the set of milestones, I'llother  need the names of specific
> reviewers from the chairs.  I'll need a qualified reviewer for
> Kerberos and for IPsec (2401 and IKE).

I'd be happy to act as a reviewer for the Kerberos aspects, though the 
fact that the document seems to be written to an audience that 
understands IPsec and might need to have Kerberos explained rather than 
the other way around will make it slow going.  Reviewers well versed in 
both protocols would be even better.

Ken