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

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Dec 2004 14:57:00 -0500

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

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 17 Dec 2004 11:17:50 +0900

[Reposting because my previous post doesn't have appeared on the list
within 24 hours.]

At Wed, 15 Dec 2004 14:57:00 -0500,
Sam Hartman <[email-masked]> wrote:
> interest to finish the KINK work.

Hi, I'm much interested in KINK and implementing it for *BSD and Linux
as a member of racoon2 project.  A prototype implementation (with
pre-alpha quality) will be released in this year.

I think the work is still valuable (and also willing to continue to
implement it), because I think KINK is suitable for well managed
environments which have a lot of devices with limited computational
power.

When this work is decided to go forward, I will commit my experiences
in implementing KINK to revising the draft.

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Dec 2004 19:25:16 -0800

Ken'ichi-san, 

I've been very busy lately on other things and haven't
had a chance to digest Sam's comments very well, but
some help for KINK to move it forward would be 
appreciated. If there's really interest, I'm willing
to do my part to finalize KINK.

		Mike

---

From: Nobuo OKABE <[email-masked]>
Date: Fri, 17 Dec 2004 12:55:21 +0900 (JST)

FYI

Some people outside IETF are also interested in KINK.

   http://fire.nist.gov/bfrlpubs/build03/art034.html

So I believe KINK is important for industrial area
where there are a lot of low-end devices
mentioned by Kamada-san.

Thanks,

From: "KAMADA Ken'ichi" <[email-masked]>
Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06
Date: Fri, 17 Dec 2004 11:17:50 +0900

> in implementing KINK to revising the draft.

----- nobuo

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 16 Dec 2004 23:25:56 -0500

> where there are a lot of low-end devices

Thanks for that pointer, I hadn't seen that before.

Looks like they're recommending Kerberos as one of their options, 
though their complaints about it include: still uses DES (being 
addressed); no role-based authorization; hard to set up and administer.

>> in implementing KINK to revising the draft.

That's great, thank you!

I also would like to see this work happen, but coming from the Kerberos 
side and not the IPsec world, I don't think I can be of the greatest 
help in implementing it.  I was trying to follow the WG discussions for 
a while, but as the general tendency seemed to be to explain some 
Kerberos bits and assume knowledge of IPsec, I got a bit lost...  I'm 
happy to help with the Kerberos aspects of the spec, though, and any 
problems with use of the MIT implementation, and I've started looking 
over the current draft again myself.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Dec 2004 18:08:36 -0500

>>>>> "Nobuo" == Nobuo OKABE <[email-masked]> writes:

    Nobuo> FYI

    Nobuo> Some people outside IETF are also interested in KINK.

    Nobuo>    http://fire.nist.gov/bfrlpubs/build03/art034.html

    Nobuo> So I believe KINK is important for industrial area where
    Nobuo> there are a lot of low-end devices mentioned by Kamada-san.

Sure, but if we cannot get enough people within the IETF to be
interested then we cannot do adequate review and so we will not do the
work.

If you have contacts in any of these areas and can convince people to
join this working group, rewiev specs, etc, then that would be greatly
appreciated.

People don't need to attend meetings to review drafts.

--Sam

---

From: Nobuo OKABE <[email-masked]>
Date: Thu, 30 Dec 2004 14:13:34 +0900 (JST)

From: Sam Hartman <[email-masked]>
Subject: Re: Sufficient Energy to finish KINK--comments by 2005-01-06
Date: Fri, 17 Dec 2004 18:08:36 -0500

> People don't need to attend meetings to review drafts.

The followings are what we can do for the WG now:

1) Our group will contribute this WG
   because we are also working for those area
   (e.g. building, factory, plants) and implementing KINK.
   We will show the details later.
   # FYI: Kamada-san is a member of our group.

2) I don't have a concrete connection with the author of the above URL.
   However, I will contact him anyhow....I'm not sure the result though....

----- nobuo

---

From: Atsushi Inoue <[email-masked]>
Date: Sat, 01 Jan 2005 01:13:10 +0900

Nobuo OKABEさんの<[email-masked]>から
>   However, I will contact him anyhow....I'm not sure the result though....

We have two groups in WIDE project which have interest in 
standardization of KINK.

One is TACA-WG (which Okabe-san mentioned above), who is developing 
security framework for facility networks. These facility network 
consists of huge number of low-capability (such as 8bit MPU) nodes. 
So, we need to make a scheme which can work not using public key 
cryptography. That's the reason why KINK is the key technical element 
in this work. TACA-WG has already made rough idea of the security 
framework and now in the prototyping stage.

Another group is IPSEC group, which is also known as the developer of 
racoon key management deamon in KAME IPv6 stack. This group is now 
implementing Racoon2, which supports both IKEv2 and KINK as IPSEC key 
management protocols. So, we have aready implemented KINK for this 
Racoon2 work (Kamada-san is the main contributor for KINK part of 
Racoon2).

Because these two groups has experience on implementing and using 
KINK, we can call for reviewer of KINK draft in these groups.
Also, we have aready itemize several issues in implementing KINK, we 
(maybe Kamada-san and some other guys) will write individual I-D on 
this implementation issue soon. I think this I-D will be a good start 
point for discussing how to do on KINK work. How about that ?

-- Atsushi INOUE   

-- 
Atsushi Inoue mailto:[email-masked]