Sufficient Energy to finish KINK--comments by 2005-01-06

Hi.  Recently, Steve Bellovin resigned from the IESG and I replaced
him as a security AD.  I happen to be the AD responsible for this
working group.

I'm soliciting comments to determine whether there is sufficient
interest to finish the KINK work.  We need to show that we have an
active editor for the core document, have active reviewers and have
someone interested in implementing.  Comments should be sent to the
list or to me individually by 2005-01-06.

Why this message?  Where is Kink now?

After taking over the working group from Steve, I reviewed the
document and found a number of problems (generally described below).
I contacted the chairs; they believe that going forward with the work
is a good idea if we have sufficient interest.  We have not heard from
the current document editor.

If you are interested in acting as an editor, reviewer or implementer
please let us know.  If you are interested in reviewing let us know
what your experience is.  Experience with Kerberos (particularly
draft-ietf-krb-wg-kerberos-crypto-xx or
draft-ietf-krb-wg-kerberos-clarifications-xx), IPsec (particularly
2401bis or IKEv1) greatly appreciated.  You should also indicate
whether you believe the work is still valuable: willingness to help
with an effort does not always imply that the effort in question is
the right direction.

I hope that there is sufficient interest to go forward.  If there is,
I will commit to doing my job as an AD responsibily and efficiently.

Here's a general overview of my concerns.  Another reviewer from the
Kerberos working group also found similar issues.
----------------------------------------


Hi.  I just got done doing a quick read through of the kink draft.  My
goal was to figure out if the draft was ready to go back to the IESG.
My initial conclusion is that there are several issues the working
group would need to resolve before the draft could be considered.

The IANA considerations section needs work.  IT sounds like the
current text wants to define the KINK payloads but doesn't actually
register them because there is no registry to put them in.  I don't
think that will be acceptable to IANA.  IT may be that you need to
create and populate the appropriate registry to make forward progress.
It actually looks like the registry has been created recently, so you
might just need to register your entries.


The security section needs some additional work; I can write up
comments on that.

I do want to insist on better conformance to id-nits before the
document is considered.  The particular complaint I have is that the
draft does not have consistent page breaks; that makes it hard to
print.  A potential reviewer pointed to this and indicated that
conformance to id-nits made the job of reviewing drafts easier.  My
own experience agrees; page numbers are useful for citations and for
searching.  Please make sure that the document complies with id-nits
including modern IPR disclosures, appropriately numbered sections, etc
before resubmitting.

Unfortunately, there is a deeper issue.  Kink and Kerberos have
drifted apart.  The IESG has approved a new crypto framework for
Kerberos and a new version of the base protocol.  Here are some ways
in which kink does not fit modern Kerberos:

* Kink assumes that Kerberos EncryptedData can be decomposed and the
  integrity protection removed

* Kink requires  that Kerberos has integrity protected errors.  The
  current and past versions of Kerberos do not support this feature
  although the working group is specifying a version that will support
  this behavior.

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

* Descriptions of how to   deal with Kerberos crypto operations should
  be written in terms of the crypto framework document.

* The key derivation seems inconsistent with the crypto framework
  document.

* Usage of  kink should specify the key usage numbers for kerberos
encryption.  

I would consider it important to fix these problems even if it were
possible to treat KINK as a protocol referencing an old version of
Kerberos.  However KINK needs to support the new crypto framework in
order to support AES which is the current mandatory to implement
encryption type for Kerberos.  I will not bring a document to the IESG
that only supports DES.

I'm also concerned that KINK and IPsec have drifted as well.  The
current document discusses parts of the SPD that seem like they belong
more in the PAD.  There may be other realignments required.

The text discussing U2U Kerberos seems broken.  It seems like the
server tells the client what principal to authenticate to, but this
principal is not properly authorized.

--Sam