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

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Jan 2005 17:31:08 -0500

I can tell already that I'm not going to finish up my comments by
Thursday.  My day job has decided to reorganize and this week's IESG
telechat has some documents that are taking me a wihle to go through.
I will get the rest of my comments to the group by early next week

The bad news is that most of the interesting comments I have are in
the second half of the document so this message is not all that
useful.

I'd recommend reading draft-ietf-ipsec-rfc2401bis,
draft-ietf-krb-wg-crypto and skimming
draft-ietf-krb-wg-kerberos-clarifications.

Rfc2401bis is setting before the IESG; there are some discusses
although I expect the document to be approved by IETF 62.

The Kerberos documents have been approved and are in the RFC editor
queue.  The crypto document is actually in auth48 waiting for Ken to
confirm some final edits.

[**] Indicates an issue that I consider substantive and that will
require wg consensus.

First. the document needs to meet all the ID nits when it is
submitted.

Section 1:

Remove the reference to pkcross or cite something outside the IETF.
It's an expired ID without and active editor.

Add an informative reference to IKE.
Section 2:

Kerberos is now using the term user-user rather than user-to-user.

Principals are not either client or service principals; they can and often do fill both roles.

Cite a reference for DER.

Section 3:

English usage/grammar problems with the first two paragraphs.

     which allows a final acknowledgment message when the respondent needs
        a full three-way handshake. This is only needed when the optimistic
           keying route is not taken, though it is expected that that will not
              be the norm. KINK also provides rekeying and dead peer detection as

What is expected not to be the norm?  Please reword.

Section 4.2:

[**] How will the initiator determine whether it will be able to get a
TGT?  I think policy considerations of when to use u2u and
authorization considerations of what u2u principals are authorized are
underspecified in the draft.

[**] Make sure the descriptions of u2u work correctly in the cross-realm case.

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.

Section 4.4

IPsec does not allow half-open security associations any more as far
as I can tell in 2401bis.  So it's not just for simplicity, but for
model conformance.

Section 4.4.1:

Please make sure this discussion is aligned with 2401bis.  I think it
may change small details but they seem to have adopted much of the
same strategy kink uses.  The area wher I believe they speak to this
issue is when you should rekey (timers etc)
Section 4.4.2

[**] Discuss status message, rebooting peers and u2u.  This looks a
lot like the IKE case where you lose all cryptographic context to me.

---

From: Nobuo OKABE <[email-masked]>
Date: Thu, 20 Jan 2005 10:22:07 +0900 (JST)

From: Sam Hartman <[email-masked]>
Subject: AD review: draft-ietf-kink-kink [section 1-4]
Date: Tue, 18 Jan 2005 17:31:08 -0500

> confirm some final edits.

I agree if 2401bis is fixed soon.
However, we can have another way if it is not fixed by IETF62.

    From implementor's viewpoint,
    it seems good to improve/fix the draft based upon 2401,
    then to write another draft based upon 2401bis
    because we need to fix the draft ASAP.

It seems fair to me to postpone the date of fixing the milestones
from February 7 to after IETF62.
Because the progress of 1401bis has impact against the KINK draft.

So I would like to ask chairs to have a meeting in IETF62.

    The deadlines (and/or basic direction like the above)
    seems to need face2face meeting,
    though detail technical discussion can be done on the ML.

    Official meeting might be unnecessary.
    # There might be a low attendance, I guess...

thanks,

----- nobuo

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 19 Jan 2005 23:11:08 -0500

> Kerberos is now using the term user-user rather than user-to-user.

You've got this backwards, Sam.  Both RFC 1510 and 
draft-ietf-krb-wg-kerberos-clarifications use "user-to-user".

Ken

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jan 2005 11:19:26 -0500

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    >> Kerberos is now using the term user-user rather than

    Ken> You've got this backwards, Sam.  Both RFC 1510 and
    Ken> draft-ietf-krb-wg-kerberos-clarifications use "user-to-user".

Yeah.  KINK uses user-user; Kerberos uses user-to-user.  My comment
was confused.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jan 2005 11:22:04 -0500

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

    Nobuo> It seems fair to me to postpone the date of fixing the
    Nobuo> milestones from February 7 to after IETF62.  Because the
    Nobuo> progress of 1401bis has impact against the KINK draft.

I'm uncomfortable with doing this.  I think that we can set deadlines
now.  If we find interesting new facts we can change the deadlines.

I'll listen to concerns from the chairs if they believe they will not
be able to get milestones ready by February 7 and evaluate those
concerns.

--Sam

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jan 2005 08:57:32 -0800

> as I can tell in 2401bis.  So it's not just for simplicity, but for

Where is this "model conformance"? This is a kernel 
level suggestion at best, and if 2401bis forbids this,
nothing actually changes with the KINK protocol except
for the fact that it loses data which isn't KINK's fault,
but 2401bis' notion of "conformance". In any case, I 
don't see why we should change this especially since 2401
isn't broken in this way.

> issue is when you should rekey (timers etc)

This is a classic case of KINK being the _actual_ start
of IKEv2 and 2401bis. The main question I have is whether
there is something _wrong_ here. I really don't think it's
fair to just be sending us off on work assignments if there's
no reason to believe that what the draft states is incorrect.

> lot like the IKE case where you lose all cryptographic context to me.

I don't understand what you want here. Are you saying that
this doesn't work in the u-u case? I don't understand what
u-u has to do with anything here.

		Mike

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jan 2005 14:20:02 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael> On Tue, 2005-01-18 at 14:31, Sam Hartman wrote:
    >> Section 4.4
    >> 
    >> IPsec does not allow half-open security associations any more
    >> as far as I can tell in 2401bis.  So it's not just for
    >> simplicity, but for model conformance.

    Michael> Where is this "model conformance"? This is a kernel level
    Michael> suggestion at best, and if 2401bis forbids this, nothing
    Michael> actually changes with the KINK protocol except for the
    Michael> fact that it loses data which isn't KINK's fault, but
    Michael> 2401bis' notion of "conformance". 

I do not understand this sentence.  What I was trying to say is that
there may now be additional reasons having to do with 2401bis that
kink does not allow half open security associations.
I'd like the text to reflect this.

I believe the easiest way to do this is to drop the phrase "for simplicity."

    Michael> In any case, I don't
    Michael> see why we should change this especially since 2401 isn't
    Michael> broken in this way.

I believe it is important that IETF specs be clear.  If you claim that
you do something like disallow one-way SAs for simplicity, then it
needs to be true that you had an option in the matter.  As it stands,
I believe your behavior will be dictated by 2401bis.

    >> Section 4.4.1:
    >> 
    >> Please make sure this discussion is aligned with 2401bis.  I
    >> think it may change small details but they seem to have adopted
    >> much of the same strategy kink uses.  The area wher I believe
    >> they speak to this issue is when you should rekey (timers etc)

    Michael> This is a classic case of KINK being the _actual_ start
    Michael> of IKEv2 and 2401bis. The main question I have is whether
    Michael> there is something _wrong_ here. 

I do not believe there is something wrong at the protocol, although I
believe it is important to confirm that is the case.  I believe there
may be small textual alignment issues.

    Michael> I really don't think
    Michael> it's fair to just be sending us off on work assignments
    Michael> if there's no reason to believe that what the draft
    Michael> states is incorrect.

I'd like to draw your attention to section 6.7 of RFC 2418, working
group procedures:

  6.7. Area Director

     Area Directors are responsible for ensuring that working groups in
        their area produce coherent, coordinated, architecturally consistent
           and timely output as a contribution to the overall results of the
              IETF.

As part of my responsibility for producing coordinated specifications
I'm asking that the Kink draft be coordinated with RFC 2401bis.  In
particular when I notice that the Kink draft discusses the same issue
as 2401bis, I will either determine that both documents are consistent
myself or ask someone else to do so.  A response to such a question
could be of the form "I looked at the text dealing with rekeying in
2401bis; it says foo.  I Looked at kink which says barr.  These are
consistent."  A more abbreviated response of "I looked at rekeying in
2401bis and Kink and they are consistent," is appropriate in some
circumstances.

If you object to me delegating part of this review to the working
group rather than doing it all myself, I think we have a fundamental
disagreement.  I'm fairly sure that is within the set of things it is
appropriate and reasonable for me to do as an AD.

If you are concerned that you personally don't want to do all this
alignment checking, then work with the chairs to see if someone else
does.

    >> Section 4.4.2
    >> 
    >> [**] Discuss status message, rebooting peers and u2u.  This
    >> looks a lot like the IKE case where you lose all cryptographic
    >> context to me.

    Michael> I don't understand what you want here. Are you saying
    Michael> that this doesn't work in the u-u case? I don't
    Michael> understand what u-u has to do with anything here.

OK.  I was unclear .  When sending a status message, what happens if
the peer has gotten a new TGT?  How do I realize I need to use this
TGT rather than the one I have?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jan 2005 15:13:02 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Sam> If you are concerned that you personally don't want to do all
    Sam> this alignment checking, then work with the chairs to see if
    Sam> someone else does.

This might have come out sounding like I was asking you to step down
as editor.  That was not my intent at all.  I simply meant that it is
reasonable to ask others to look into issues for you and if it turns
out changes need to be made then you as editor get involved.

---

From: Nobuo OKABE <[email-masked]>
Date: Fri, 21 Jan 2005 09:08:04 +0900 (JST)

From: Sam Hartman <[email-masked]>
Subject: Re: AD review: draft-ietf-kink-kink [section 1-4]
Date: Thu, 20 Jan 2005 11:22:04 -0500

> be able to get milestones ready by February 7 and evaluate those

My concern has resolved by the new milestones
proposed by the chair (Jan 19, 2005).
So I don't object to what you are saying here.

----- nobuo

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Tue, 01 Feb 2005 11:54:00 +0900

At Tue, 18 Jan 2005 17:31:08 -0500,
> detailed enough for interoperable implementations.

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

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