Subject: Moving forward on KINK--deadline for action

From: Sam Hartman <[email-masked]>
Date: Sun, 2 Jan 2005 16:51:20 -0500 (EST)

Several people have expressed interest in helping with the KINK
effort.  That's great to hear.  It looks like we have or are close to
having sufficient interest to do adequate review.  We also clearly
have interest in implementing the results of the working group.

Assuming fairly dedicated effort, I suspect that we can get the
document into shape within six months and get IESG approval shortly
after that.

I'd like to ask the working group chairs to prepare a new set of
milestones for getting from our current position to a completed
document.  The milestones should include identifying the issues we're
going to fix, coming to consensus on fixes and confirming adequate
review of the result.

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 expect the results to work will with Kerberos clarifications and
draft-ietf-ipsec-rfc2401bis.

I will have my specific comments on the kink draft to the working
group by January 20; the working group has already received the
general areas I'm concerned about.

In order to set a concrete deadline, I am requesting the milestones
and reviewers from the chairs by February 7, 2005.  I'm picking the
deadline because it is the first scheduling deadline for IETf 62.  If
someone has a preference for another deadline speak up now.  Otherwise
I'll treat February 7 as a hard deadline: if the milestones and
reviewers are submitted by then, we'll continue, but otherwise, the
working group will conclude.

I'd also suggest that KINK consider meeting at IETF 62.  If we can get
enough of the people together it will be useful to discuss the issues
and hopefully come to quick resolution.  Naturally, the decision of
whether to meet is up to the chairs.

Sam Hartman,

Security Area Director

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Jan 2005 17:15:10 -0800

I think there's some amount of cart before 
horse going on here: before we set milestones,
etc, etc, it would be nice to know if there
are actual issues or just another round of
editorial clarifications/nits.

		Mike

---

From: Sam Hartman <[email-masked]>
Date: Sun, 02 Jan 2005 22:29:34 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael> I think there's some amount of cart before horse going on
    Michael> here: before we set milestones, etc, etc, it would be
    Michael> nice to know if there are actual issues or just another
    Michael> round of editorial clarifications/nits.

I'm fairly sure there are some real issues; I don't expect it to be
horribly complicated to fix them and I don't know of any issues that I
expect to require difficult consensus calls.  

I definitely do know that I want more review of the document before I
take it back to the IESG.

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.  I'm hoping that others who have tried to
implement the protocol will bring forward at least general information
about their concerns while we're trying to set milestones so that we
can take them into account.

If the chairs believe that my timeline for a decision is too
aggressive I expect them to object.

Keep in mind that setting milestones does not preclude us moving
faster than those milestones.

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 3 Jan 2005 00:20:00 -0500

On Jan 2, 2005, at 22:29, Sam Hartman wrote:
> 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.

> 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

---

From: Nobuo OKABE <[email-masked]>
Date: Wed, 05 Jan 2005 11:20:33 +0900 (JST)

From: Sam Hartman <[email-masked]>
Subject: Moving forward on KINK--deadline for action
Date: Sun,  2 Jan 2005 16:51:20 -0500 (EST)

> working group will conclude.

If fixing new milestones
we will have to estimate the effort which should be
needed for fixing the ID.
So our group is going to show comments as Ken did.
But please wait for a while because it is new-year-holidays
in Japan now :-)

----- nobuo