Subject: Re: [Ietf-krb-wg] krb-wg report

From: KAMADA Ken'ichi <[email-masked]>
Date: Fri, 03 Apr 2009 13:53:43 -0500

Just for a record...

At Fri, 27 Mar 2009 12:05:41 -0400, Greg Hudson wrote:
> 
> On Fri, 2009-03-27 at 11:43 +0100, Simon Josefsson wrote:
> > > It specifies "multiple of m", not _which_ multiple of m.  There are
> > > several reasonable interpretations of how to do this.
> > 
> > Is there any reasonable interpretation that does not involve truncation?
> 
> I think the *only* reasonable interpretation of RFC 3961 is to truncate
> to the nearest multiple of m, which is no truncation at all if m is 1
> byte.  It's pretty obvious that the purpose of the truncation is to make
> E(..., tmp2, ...) work, not because truncation is good for the heart.

When I implemented RFC 3961 PRF for racoon2 kinkd around 3 years ago,
the above was exactly how I implemeted it (actually other
interpretations did not come to me)...

That is, truncating to (hashlen / m * m) in C language.

> 
> That said, the wording is ambiguous and we've seen multiple examples of
> people reading it to mean "truncate to m", so clearly the wording is
> bad, which is another reason to throw away that particular construction
> and pretend that it was never specified.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Apr 2009 10:07:34 -0400

>>>>> "KAMADA" == KAMADA Ken'ichi <[email-masked]> writes:

    KAMADA> Just for a record...
    KAMADA> At Fri, 27 Mar 2009 12:05:41 -0400, Greg Hudson wrote:
> > > It specifies "multiple of m", not _which_ multiple of m.  There
    >> are > > several reasonable interpretations of how to do this.
    >> > 
    >> I think the *only* reasonable interpretation of RFC 3961 is to
    >> truncate to the nearest multiple of m, which is no truncation
    >> at all if m is 1 byte.  It's pretty obvious that the purpose of
    >> the truncation is to make E(..., tmp2, ...) work, not because
    >> truncation is good for the heart.

    KAMADA> When I implemented RFC 3961 PRF for racoon2 kinkd around 3
    KAMADA> years ago, the above was exactly how I implemeted it
    KAMADA> (actually other interpretations did not come to me)...

    KAMADA> That is, truncating to (hashlen / m * m) in C language.

You were implementing the PRF in an application not a library, right?
And this was presumably KINK specific?

Although presumably if someone else implemented KINK  by calling into a Kerberos implementation's PRF, we would have an interop problem.

As an aside, did that KINK implementation ever ship?  Is it is something I can use today?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: KAMADA Ken'ichi <[email-masked]>
Date: Mon, 13 Apr 2009 13:43:36 -0500

> And this was presumably KINK specific?

Yes to the first question.
IIRC, neither MIT nor Heimdal released a version with PRF at that time.
I regret my laziness to implement it in my application instead of
doing that in libraries and feeding that back to MIT and Heimdal.

I am not sure about the second question, because I do not know
if other protocols depend on PRFs.
KINK does not define PRFs by itself; it refers to RFC 3961.

> Although presumably if someone else implemented KINK  by calling into a Kerberos implementation's PRF, we would have an interop problem.

Yes, it IS a problem.

> As an aside, did that KINK implementation ever ship?  Is it is something I can use today?

It has been shipped as a part of racoon2.

-- 
Ken'ichi