Subject: Re: Subsession keys (Re: KINK issue list)

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Feb 2005 08:21:24 -0800

On Mon, 2005-01-31 at 17:41, Sam Hartman wrote:
> >>>>> "Michael" == Michael Thomas <[email-masked]> writes:

> My reason for bringing up the issue is that you are behaving
> differently than all other Kerberos applications.  Kerberos libraries
> are actually flexible enough to do what your spec currently asks but
> it requires implementers to specifically handle subkeys that way.
> 
> If you don't have a reason for being different then please be the same
> as everyone else.  If you do have a reason, explain it and I'll be
> happy.

I'm sorry, but I'm having a real problem with this guilty
until proven innocent stance. This document was through
several iterations of review from the IESG and just got
dropped on the floor by the IESG. I think it's incumbent 
on those who are throwing darts here to say if there are
REAL PROBLEMS, not just harmonization with the universe.
In this particular case, I had *zero* problem coding this
up. Is there an _actual_ cryptographical problem here, or
is this another trip to the beauty shop? There are people
who have been writing to *this* spec for several years now --
why should we force them to change just because the
aesthetics seem better to people who have no stake in 
that code and work?

And FWIW, the key generation was discussed at long, long length
before last call. I doubt that Jeff remembers it, but he
was part of the discussion as I recall.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Feb 2005 15:09:35 -0800

On Mon, 2005-01-31 at 17:54, Kazunori Miyazawa wrote:
> Hello,
> 
> I have read the mails and I think these issues could be closed.
> 
> Kamada-san described the checksum calculation and verification in
> this mail.
> http://www.vpnc.org/ietf-kink/mail-archive/msg00336.html
> 
> If KINK adopts this, check sum length in KINK header will be two
> octets because kcrypto specifies that the output of get_mic is
> no longer than 65535 octets in the section 4.

Yes, there is an inconsistency in the draft in this
regard... the diagram which shows it as being one
octet actually more closely reflects reality (unfortunately).
I haven't thought very hard about how to resolve this.

> BTW, if there are no strong reason, I like to move the check sum
> field from the header to the end of message, because we could
> be easy to access KINK_AP_REQ/REP payload and forget it after
> verification.

Am I understanding you as saying that you'd like this
to not be in the KINK header at all? And instead be, 
like, in one of the payloads following the header? That
might be problematic given the KINK_ENCRYPT payload and
some other odd things that might surface.

		Mike