Subject: Re: AD review: draft-ietf-kink-kink [section 1-4]

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2005 17:06:33 -0500

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

    KAMADA> At Tue, 18 Jan 2005 17:31:08 -0500,
    KAMADA> Sam Hartman <[email-masked]> wrote:
    >>  Section 4.3:
    >> 
    >> [**] I need explicit review from the IPsec reviewer of this
    >> section to make sure it is compatible with 2401bis.  IN
    >> addition, any differences between how this works and how IKE
    >> would set up the same SA need to be called out.  It is fine for
    >> there to be differences, but I want to make sure the working
    >> group explicitly decided the differences are a good thing.
    >> 
    >> I'm somewhat concerned that 4.3 is not specific enough to
    >> describe exactly what key gets set up.  I.E. I'm concerned it
    >> may not be detailed enough for interoperable implementations.

    KAMADA> Section 4.3 describes the message flow and section 7.3
    KAMADA> describes the message structure.  Differences between KINK
    KAMADA> and IKE is described in section 7.3 (and also in section
    KAMADA> 4.4.1, 5.1.7, and 6).  I think they are enough to be
    KAMADA> interoperable (at least regarding SA setup).  Is your
    KAMADA> concern resolved if section 4 referes to section 7?

I think everything is clear except for what key ends up getting used
for the resulting SA.  I think that needs specific text.

--Sam

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 02 Feb 2005 11:28:02 +0900

> Section 4.3:
> 
> [**] I need explicit review from the IPsec reviewer of this section to
> make sure it is compatible with 2401bis.  IN addition, any differences
> between how this works and how IKE would set up the same SA need to be
> called out.  It is fine for there to be differences, but I want to
> make sure the working group explicitly decided the differences are a
> good thing.

i dont think there are differneces between them.  because KINK just
carries IKEv1 quick mode.  KINK can establish the same SA that IKEv1
do so.
note that i am supposing that KINK complies to 2401 at the first step.
if we choice 2401bis, my saying is wrong.

> I'm somewhat concerned that 4.3 is not specific enough to describe
> exactly what key gets set up.  I.E. I'm concerned it may not be
> detailed enough for interoperable implementations.

could you tell me lack of things for interoperability in this document.
i think that there is detail description in the section 7 how KINK
establish SAs.  IKEv1 specification does not describe the deatils.
that was undoubted problem for interoperability.

if the description of the section 7 is enough, then this is editorial
issue.  we need to improve the text.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2005 22:08:06 -0500

>>>>> "Shoichi" == Shoichi Sakane <[email-masked]> writes:

    Shoichi> the same SA that IKEv1 do so.  

    Shoichi> note that i am supposing
    Shoichi> that KINK complies to 2401 at the first step.  if we
    Shoichi> choice 2401bis, my saying is wrong.
I'm confused why 2401/2401bis matters for this.

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 02 Feb 2005 12:51:46 +0900

> I'm confused why 2401/2401bis matters for this.

i should say that i did not consider 2401bis manner.
if we choice 2401bis, then there might be difference between them or no.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Feb 2005 13:56:54 -0500

>> group explicitly decided the differences are a good thing.

    Shoichi> i dont think there are differneces between them.  because
    Shoichi> KINK just carries IKEv1 quick mode.  KINK can establish
    Shoichi> the same SA that IKEv1 do so.  

Section 4.3 calls out a lot of explicit detail.  For example it says
exactly when to add SAs to the SPD, etc.  This detail is presented as
Kink specific.

I am asking for review to confirm that this detail did not conflict
with anything in the IKE spec.  If section 4.3 said to just do what
IKE does, I would not have called it out.

I think section 4.3 is well written and it is good to have.  I just
want to make sure there is not an inconsistency.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 04 Feb 2005 17:04:51 +0900

At Tue, 01 Feb 2005 17:06:33 -0500,
> for the resulting SA.  I think that needs specific text.

The key used for IPsec SAs is defined in section 8, "Key Derivation".
Its definition follows IKEv1.

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

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 04 Feb 2005 17:04:54 +0900

At Wed, 02 Feb 2005 13:56:54 -0500,
> IKE does, I would not have called it out.

IKE does not unfortunately specify when an implementation adds SAs
to the SAD.  And KINK's optimistic approach (2-way handshake) is
new to IKEv1.  Therefore KINK specifies it in detail.
I think the detailed description in section 4.3 is necessary.

I think SA setup sequence in 3-way handshake should also be written,
in addition to the current descriptions.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Feb 2005 06:50:18 -0800

> in addition to the current descriptions.

Right -- this was one of the huge deficiencies of IKE
which we were very intent to deal with. KINK is actually
has a *lot* of things corrected -- things that we hopefully
also corrected in IKEv2. Which is why it's so annoying when
it is suggested that KINK do it the IKEv2 way -- KINK
led the way here, not the other way around. KINK should
have been an RFC way before IKEv2 was issued.

		Mike

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Feb 2005 16:23:47 -0500

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

    KAMADA> I think the detailed description
    KAMADA> in section 4.3 is necessary.

I like the descriptive text in 4.3 too.  I just want the person the
chairs and I select as an IPsec reviewer to confirm that nothing
conflicts with IKEv1.

--Sam