Subject: who will edit the draft ?

From: Shoichi Sakane <[email-masked]>
Date: Thu, 20 Jan 2005 10:24:50 +0900

WG chairs,

I am also interested in the KINK protocol, and have a experience
to discuss the specification, to implement it in our team.  And I
am developping a IKE daemon in the KAME project.  So I can be reviewer
from the KINK and IPsec point of view.

There are some comments about the draft in the mailing list.
Who will collect these comments and will edit the draft ?
If no one did or will do that, our team is ready to gather them
and will edit the draft.

There are some people interested in the protocol.  I think that we
should have a meeting in order to manage the KINK WG.  I am not sure
that "manage" is suitable word.  To complete the KINK specification may
be suitable.  We have two items at least.  One is to make a consensus
the modification of current draft.  Second is to discuss how to
manage the WG.  I dont mind that the scale of the meeting is
a WG meeting, a BoF, a closed meeting or a lunch meeting.
I want to know who will join the meeting.  Of course I will.

And we have to make a milestone ASAP.  Here is from "Goals and Milestones"
in the WG page,

Done	  	Reach Consensus on requirements document
Done	  	Meet at San Diego IETF to review drafts
Jan 01	  	Reach Consensus on base draft protocol
Feb 01	  	Conduct WG last call on base draft prototol
Mar 01	  	Begin Interoperability bakeoffs
Aug 01	  	Document interoperability results.
                Make decision to recycle or move forward

The items would be:

Feb 14          Submit draft kink-07 with editorial modifications.
Mar 01          Review the issue of current draft, kink-06.
Apr 01          Reach Consensus on draft.
May 01          Resubmit revised draft as Proposed Standard.
Aug 01   	Begin Interoperability bakeoffs.
Sep 01   	Document interoperability results.

If the chair has had the set already, I am sorry for my meddling,
but at least I have not seen yet.  Thease are just my opinion,
any comment welcome.  That would be help for the chairs.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 20 Jan 2005 10:36:39 +0900

At Thu, 20 Jan 2005 10:24:50 +0900,
> Who will collect these comments and will edit the draft ?

I'm now merging them.  Just a moment please.

-- 
鎌田健一 <[email-masked]>

---

From: Derek Atkins <[email-masked]>
Date: Wed, 19 Jan 2005 20:45:02 -0500

Hi,

> from the KINK and IPsec point of view.

Good to know.  Thank you for volunteering.  At this time Mike Thomas
has agreed to continue to edit the draft, so unless he becomes
unresponsive I see no reason immediately to appoint a new draft
editor.

[snip]
> any comment welcome.  That would be help for the chairs.

The dates are Month / Year, not Month / Day.  So I think you
probably mean Feb 05, Mar 05, ...

Based on the existing set of issues I do not believe that your
suggestions are reasonable -- they are way too aggresive.  I really do
not believe that we'll reach consensus by April.  I think we have way
too many issues.  Perhaps a better proposal for milestones are:

Mar 05	Review issues with kink-06
Mar 05	Submit kink-07
Jun 05	Reach consensus on necessary changes
Jul 05	Submit kink-08
Aug 05	WGLC
Sep 05	Submit draft to IESG
Jan 06	Begin Interop bakeoffs
Feb 06	Document interop results.

Even this schedule is extremely agrressive, but IMHO actually
achievable.  I don't think we can get concensus on all the open issues
and make it past the IESG before Paris.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Jan 2005 17:51:47 -0800

I'm still willing to edit the draft if we're not
talking about wholesale changes, and we're talking
about a relatively modest amount of time (eg, a 
few months). 

Has a decision been made on wg meeting in MPLS?
I'm hoping that the issues don't require a f2f 
meeting, but it would be good to know one way or
the other.

		Mike

---

From: Derek Atkins <[email-masked]>
Date: Wed, 19 Jan 2005 21:03:09 -0500

Hi,

> about a relatively modest amount of time (eg, a 

I hope it'll only take a few months, but I know Sam is going to be a
stickler for quality before the IESG.  This isn't a bad thing, but I
think it's going to put a lot more scrutiny on the document, so it may
be significantly more work than you expect at the moment.  It's hard
to say right now.

At the face of it we need to update the document to meet the new
format requirements, update to krb-clarifications and krb-crypto, and
probably update to reference IKEv2 and 2401bis.  I dont know what
other changes are going to be required.

So, if you're willing (and able) to put in the time and effort to
remain the editor I'm happy to keep you.  However if you feel that you
cannot commit to the task I'd ask that we find someone else.  I leave
that choice up to you for now.

> meeting, but it would be good to know one way or

I'm willing to go either way.  If the WG believes we need a face to
face meeting then I'll gladly arrange for one.

-derek

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 20 Jan 2005 11:04:48 +0900

Here is a merged version of KINK issues expressed till now.
If I missed some of them you noted, please let me know.

[**] Indicates an issue considered substantive.
[-] Indicates an editorial issue.

[**] user-to-user (section 3 and 4.2)

	It seems like the
	server tells the client what principal to authenticate to, but this
	principal is not properly authorized.  (Sam Hartman)

	More examination of user-to-user case, especially situations where 
	it might *not* be two PKINIT clients, which section 3 says is possible. 
	(BTW, in the Kerberos docs, it's "user-to-user", not "user-user".)
	(Ken Raeburn)

	Verifying remotely supplied identity, as Sam raised earlier.
	(Ken Raeburn)

	In the user-to-user case with TGTs, I think the KINK draft may be 
	over-specifying things that should be dealt with at the Kerberos level. 
	If things are underspecified in Kerberos Clarifications, let's deal 
	with that.  (Ken Raeburn)

	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.
	(Sam Hartman)

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

[**] CREATE Security Association from the aspect of 2401bis (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.
	(Sam Hartman)

[*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3)

	Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the 
	nonce should be used.  If the circumstances they're describing are 
	different, that's okay, but if so, I missed it on first reading.
	(Ken Raeburn)

[*] Half open (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.  (Sam Hartman)

[**] 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.

[*] CksumLen (section 5)

	Diagram indicates one octet for cksumlen, but the text (and 
	kcrypto specifications) say it should be two.

[**] etype does not directly indicate checksum type (section 5)

	a key's encryption type does not directly indicate 
	a checksum type, it indicates an encryption(-with-integrity-protection) 
	scheme, which does include a required-to-implement checksum type
	(Ken Raeburn)

[**] Kerberos allows variable length checksum (section 5)

	I'd have to go back and check, but I don't think we require that 
	a given checksum type have a fixed output size, so "leave X amount of 
	space and fill it with zero for computing the checksum" is questionable 
	too.  (Ken Raeburn)

[*] Kerberos checksum is not deterministic (section 5)

	The Kink description of how to verify a checksum assumes that
	Kerberos checksums are deterministic; this is not strictly required.
	(Sam Hartman)

	let kcrypto specify how 
	to verify a checksum, as they're not required to be deterministic, so 
	the "compute it again and compare" approach specified in section 5 is 
	wrong  (Ken Raeburn)

	The spec should describe how to verify checksum as follows.

	To verify the checksum, the checksum is saved, and the
	checksum field is zeroed out.  The resulting message and the saved
	checksum are passed to the verification function.  If the verification
	fails, the message MUST be dropped.

[*] Subsession keys (section 5 and 8)

	Are subsession keys ignored?  (Ken Raeburn)

[**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1)

	Section 7.1 says the checksum in the KRB-ERROR message is not used,
	but section 5.1.4 says that KINK implementation MUST make use of
	keyed Kerberos errors.  But KRB-ERROR does not have checksum in it (at
	least with RFC 1510 or kerberos-clarifications).
	I think a correct phrase here is "KINK implementations MUST make use of
	a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate
	service key is available."

[**] KINK_ENCRYPT format (section 5.1.8)

	The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is
	vague.  I think of using the output of raw encryption algorithms
	(i.e. E(confounder | plaintext | pad)) or using EncryptedData.

	treat "encryption with 
	integrity protection" output as a whole, don't peek under the covers to 
	find a "checksum" part you can throw away  (Ken Raeburn)

	drop references to the initialization vector  (Ken Raeburn)

[*] Kerberos PFS (section 6.8)

	Sec 6.8: "Kerberos in general does not provide FPS so it is somewhat 
	questionable whether a system which is heavily relying on Kerberos 
	benefits from PFS."  First, that sounds like it might be Security 
	Considerations material.  Second, I don't follow; explain please?
	(Ken Raeburn)

[*] MUST/SHOULD in clock skew (section 7.1)

	The time difference MUST be computed and SHOULD be stored 
	and used?  Why the different requirement levels?  (And is this sort of 
	thing in the domain of KINK or Kerberos?)  (Ken Raeburn)

[**] prf (section 8)

	Section 8 says "prf is the same hash algorithm found in the session
	ticket's etype", but krb-wg-crypto-07 defines hash as unkeyed.
	Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK
	should use this PRF.

	Use a prf 
	from kcrypto, don't assume the checksum operations are deterministic 
	hash functions  (Ken Raeburn)

[*] Key derivation (section 8)

	The key derivation seems inconsistent with the crypto framework
	document.  (Sam Hartman)

[*] Key usage

	Usage of  kink should specify the key usage numbers for kerberos
	encryption.  (Sam Hartman)

[*] 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)

[*] IKEv2

	Should we adopt IKEv2?

	If we should...
	- IKEv2 does not have DOI, so how to handle the DOI field in the KINK
	  packet header should be described.
	- Use TS (Traffic Selector) instead of ID (Identification).
	- KEYMAT calculation is changed.
	- How to handle REKEY_SA Notify type.

[*] behavior on KINK_ERROR

	In implementor's point of view, I'd like to see initiator's
	behavior in receiving KINK_ERROR to be defined.
	For example:
	- When KINK_OK is received, initiator MAY act as if the KINK_ERROR
	  payload was not included in the messaged.
	- When KINK_BADQMVERS is received and the Cksum is verified,
	  initiator MAY retry in other Quick Mode version.
	- When one of other error codes is received and the Cksum is verified,
	  initiator SHOULD abort the negotiation.

[-] I-D nits

	Review the I-D nits and RFC authors docs.  I spotted a lot of 
	mechanical things (number of lines per page; avoid hyphenation; use 
	ragged right margin; need two spaces after sentence-ending period; fix 
	page numbers in table of contents; add section numbers to TOC) most of 
	which I think are specified in one of those documents.
	(Ken Raeburn)

	the document needs to meet all the ID nits when it is
	submitted.  (Sam Hartman)

[-] IANA considerations

	I think the correct terminology is "port 
	number", not "port", and they're "assigned", not "created".  This 
	section says no new registries are required in the first paragraph, and 
	the third one specifies that IANA must create one (but without the 
	associated procedural data that is required nowadays).  Are the KINK 
	payload types and ISAKMP payload types actually ever used in the same 
	field?  If not, I don't think they need to come out of the same 
	registry.  (Ken Raeburn)

[-] Wording/Terminology

	Section 2 and 10.1.
	Kerberos is now using the term user-user rather than user-to-user.
	(Sam Hartman)

	Section 2.
	Principals are not either client or service principals;
	they can and often do fill both roles.  (Sam Hartman)

	Section 2, last paragraph.  "Between" is generally non-directional, 
	but in this case, a direction seems to be intended to be inferred; try 
	"from...to" instead.  (Ken Raeburn)

	Section 3, English usage/grammar problems with the first two paragraphs.
	(Sam Hartman)

	Section 3.
	   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.
	(Sam Hartman)

	Section 4.3, discussing attributes, mixes singular and plural 
	indications.  The word "lone" appears to be popular with the author, 
	too. :-)  (Ken Raeburn)

	Sec 8: "By optional, it is meant..." is badly worded.  (Ken Raeburn)

[-] References

	The reference to [PKCROSS] is unnecessary, and only happens once, in 
	the introduction.  I'd suggest dropping it.  That's one less 
	unpublished I-D in the references section.  (Ken Raeburn)

	[KRBREVS] is referenced but not listed in the references section.
	(Ken Raeburn)

	Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the 
	protocol) fuzzy about use of different SAs, or is it "[IKE]" (the 
	document)?  (Ken Raeburn)

	Section 1:
	Remove the reference to pkcross or cite something outside the IETF.
	It's an expired ID without and active editor.  (Sam Hartman)

	Section 1:
	Add an informative reference to IKE.  (Sam Hartman)

	Section 2:
	Cite a reference for DER.  (Sam Hartman)

[-] Typos

	4.4.2. Dead Peer Detection
	In the fourth paragraph, "loose" is to be "lose".

	5.1.1. KINK Padding Rules
	In the second item, "other other" is to be "other".

	5.1.1. KINK Padding Rules
	The first item in the list should end with a period like 
	the others.  (Ken Raeburn)

	5.1.5. KINK_TGT_REQ Payload
	In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/REALM@REALM".

	5.1.6. KINK_TGT_REP Payload
	In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP".

	7.3. CREATE
	"IPspec" is to be "IPsec".

	7.5. STATUS
	In the last paragraph, "REPLY KINK Header" should be in one line.
	In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]".

	overall:
	"'s" is used in some places where I'd use "s" for a plural form.

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

---

From: Jan Vilhuber <[email-masked]>
Date: Wed, 19 Jan 2005 20:23:34 -0800 (PST)

> other changes are going to be required.

I think I missed something: Why do we need to update to reference ikev2? The
ikev1 phase 2 exchange works just fine.

jan

---

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

From: Jan Vilhuber <[email-masked]>
Subject: Re: who will edit the draft ?
Date: Wed, 19 Jan 2005 20:23:34 -0800 (PST)

> ikev1 phase 2 exchange works just fine.

Sam should be the right person to answer the question.

However, I guess his mind .......
the point might be not the functionality of KINK
but consistency among standards issued by IETF.

I also guess that this issue might not be raised
if KINK draft fixed earlier because IKEv2 and 2401bis
were far from mature.

----- nobuo

---

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

> ikev1 phase 2 exchange works just fine.

A reasonable question. Were there any changes to
quick mode/phase 2/sa establishment payloads in
ikev2? I didn't pay much attention to that part of
the effort, but I vaguely remember that they formalized
some of the selector stuff, maybe involving port
ranges or something??

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jan 2005 10:11:05 -0800

Thank you very much for compiling this list -- I have
been having a hard time following what are similar or the
same issues, and what the closure is if any. Maybe what
we can do is keep a master list here, the proposed 
resolution, or whether to close the issue due to it being
not a problem. From that, I can work on producing a new
draft.

		Mike

---

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

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

    Michael> Has a decision been made on wg meeting in MPLS?  I'm
    Michael> hoping that the issues don't require a f2f meeting, but
    Michael> it would be good to know one way or the other.

Speaking as an individual I'd like to see an f2f meeting even if we
don't believe the issues require one.  I think it might help us get on
the same page.  Here's a proposed agenda:

* A presentation on how kcrypto differs from crypto in 1510
* A presentation on 2401bis vs 2401
* A presentation making sure we understand the difference between
     2401bis conformance   and ikev2 conformance
* Discussion of u2u and authorization
    (we may not have enough context to know whether
    we need this yet)
* A review of the issue list

I think that getting all on the same page even if we don't need f2f
time to resolve issues would benefit us.  If others disagree, then we
should not have the meeting.

---

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

>>>>> "Jan" == Jan Vilhuber <[email-masked]> writes:

    Jan> On Wed, 19 Jan 2005, Derek Atkins wrote:

    >> > I'm still willing to edit the draft if we're not > talking
    >> about wholesale changes, and we're talking > about a relatively
    >> modest amount of time (eg, a > few months).
    >> 
    >> I hope it'll only take a few months, but I know Sam is going to
    >> be a stickler for quality before the IESG.  This isn't a bad
    >> thing, but I think it's going to put a lot more scrutiny on the
    >> document, so it may be significantly more work than you expect
    >> at the moment.  It's hard to say right now.
    >> 
    >> At the face of it we need to update the document to meet the
    >> new format requirements, update to krb-clarifications and
    >> krb-crypto, and probably update to reference IKEv2 and 2401bis.
    >> I dont know what other changes are going to be required.
    >> 

    Jan> I think I missed something: Why do we need to update to
    Jan> reference ikev2? The ikev1 phase 2 exchange works just fine.

I think there was confusion.  I said that you needed to reference
2401bis rather than 2401.  (I've explained the assumptions behind that
in an earlier message)

I suggested you should consider providing the additional features that
2401bis supports/requests from a key management protocol over 2401.
You should either implement these features or explain why you chose
not to do so.

How you implement these features (referencing ikev2, etc) is up to
you.

---

From: Jan Vilhuber <[email-masked]>
Date: Thu, 20 Jan 2005 13:48:36 -0800 (PST)

> You should either implement these features or explain why you chose

I guess saying "I haven't read 2401bis" won't be a good excuse for not
implementing any features from it, is it?

jan

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jan 2005 14:22:00 -0800

> implementing any features from it, is it?

Well it's probably better than implementing
features *without* reading it ;-)

		Mike

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 21 Jan 2005 09:58:20 +0900

At Thu, 20 Jan 2005 10:11:05 -0800,
Michael Thomas <[email-masked]> wrote:
>                                              Maybe what
> not a problem.

Yes, I'll maintain this list.  I'll do that in e-mails for a
meanwhile, and if things become complicated I may prepare an
issue tracker.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jan 2005 17:53:22 -0800

> meanwhile, and if things become complicated I may prepare an

Excellent, this will be a big help. I really
appreciate the help.

		Mike

---

From: Kazunori Miyazawa <[email-masked]>
Date: Fri, 21 Jan 2005 13:51:11 +0900

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

<snip>

>      2401bis conformance   and ikev2 conformance

Excuse me, I could not understand above sentence.

RFC2401bis specifies IP security archietecture.
However, IKEv2 is the key exchange protocol.

Does it mean whether any confilict between RFC2401bis and IKEv2 is
when we implement them?

--
Kazunori Miyazawa

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Jan 2005 11:33:23 -0500

>>>>> "Kazunori" == Kazunori Miyazawa <[email-masked]> writes:

    Kazunori> RFC2401bis specifies IP security archietecture.
    Kazunori> However, IKEv2 is the key exchange protocol.

I think some people on this list have assumed that when I said we need
to comply with 2401bis that I invisioned changing our references to
ikev2 instead of ikev1.  These issues seem to be complicated because
2401bis mandates ikev2 although it still supports ikev1 as an option.

I want to make sure this distinction is untangled for the group.

--Sam

---

From: Nobuo OKABE <[email-masked]>
Date: Wed, 26 Jan 2005 10:42:54 +0900 (JST)

Dear Chairs,

From: Derek Atkins <[email-masked]>
Subject: Re: who will edit the draft ?
Date: Wed, 19 Jan 2005 21:03:09 -0500

> face meeting then I'll gladly arrange for one.

Yes please.

I also think that WG needs a meeting.
The agenda which Sam has proposed is good for the start.
It will be fixed through discussion on the ML.

I would be happy if the meeting is not held Friday
when I will go back to Japan because of my business reasons.
However, I can re-arrange my travel schedule at this moment
if necessary.
So please let me know the (possible) day of the meeting.

Thank you for your help

----- nobuo

---

From: Nobuo OKABE <[email-masked]>
Date: Wed, 26 Jan 2005 11:24:33 +0900 (JST)

From: Derek Atkins <[email-masked]>
Subject: Re: who will edit the draft ?
Date: Wed, 19 Jan 2005 20:45:02 -0500

> and make it past the IESG before Paris.

I think that the milestones are reasonable to recover the stall
even though it is very aggressive.
From implementor's viewpoint, we would like to fix the spec ASAP.

Please clear the meaning of "Mar 05 Review issues with kink-06".
I'm not sure, but we will not be able to reflect any effort
if review starts from March.

The most difficult part would be "Mar 05 Submit kink-07".
What should be the goal of draft-07?
The contents of the draft-07 can be a halfway
if we can not solve almost issues.
# and we don't have enough time to March.

thanks,

----- nobuo

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 25 Jan 2005 22:49:09 -0500

> So please let me know the (possible) day of the meeting.

The schedule typically isn't set until shortly before the conference, 
and in fact is still subject to change even then.

Ken

---

From: Nobuo OKABE <[email-masked]>
Date: Wed, 26 Jan 2005 13:00:57 +0900 (JST)

From: Ken Raeburn <[email-masked]>
Subject: Re: who will edit the draft ?
Date: Tue, 25 Jan 2005 22:49:09 -0500

> and in fact is still subject to change even then.

OK. I'll try to re-arrange my travel schedule.
Thank you for your advice.

----- nobuo

---

From: Derek Atkins <[email-masked]>
Date: Tue, 25 Jan 2005 23:18:24 -0500

> if review starts from March.

Milestones are completion dates, not commencement dates.  This means
that by March, 2005 we should have completed review of the issues with
kink-06.

> What should be the goal of draft-07?

draft 07 should have the changes that reflect the concensus of changes
based on the issues of draft-06.

> # and we don't have enough time to March.

Drafts are easy.  If it were me I'd say we should have a new draft
every 2-4 weeks.  But I'm not the editor.  Please don't get caught up
in draft numbers.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Tue, 25 Jan 2005 23:19:37 -0500

> I also think that WG needs a meeting.

An agenda slot has been requested for IETF-62.  If you have a
presentation you'd like to make I humbly request agenda items for the
meeting.

Thanks,

-derek

---

From: Nobuo OKABE <[email-masked]>
Date: Wed, 26 Jan 2005 13:40:45 +0900 (JST)

From: Derek Atkins <[email-masked]>
Subject: Agenda items (was: Re: who will edit the draft ?)
Date: Tue, 25 Jan 2005 23:19:37 -0500

> presentation you'd like to make I humbly request agenda items for the

We are considering one (or more?) of agenda items,
and will let you know when taking shape.

thanks,

----- nobuo

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 27 Jan 2005 17:14:41 +0900

At Thu, 20 Jan 2005 11:04:48 +0900,
> 	different, that's okay, but if so, I missed it on first reading.

They are talking the same situation and the requirement levels should
be aligned.  I think SHOULD is appropriate because non-returning
responder's nonce does not break interoperabilities.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 27 Jan 2005 17:16:45 +0900

> [*] Kerberos checksum is not deterministic (section 5)

With regard to these three issues, I'd propose using HMAC as a KINK
checksum.
According to kcrypto, each etype based on simplified profile and
etype based on 3DES has a HMAC as its attribute.  Let's use it as is.
DES-based etypes (des-cbc-md5, des-cbc-md4, and des-cbc-crc) have
no HMAC associated with them, so use HMAC-MD5.

My main concern with this proposal is whether all future etypes
will be based on simplified profile (have HMAC, I mean) or not.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 27 Jan 2005 17:17:03 +0900

> 	Are subsession keys ignored?  (Ken Raeburn)

I think they should not be ignored.

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 27 Jan 2005 10:34:03 -0500

> will be based on simplified profile (have HMAC, I mean) or not.

I think it's safe to say that eventually we will see new encryption 
types that do not use the simplified profile.  We may also see some 
that do, of course.  But with the variety of authenticated-encryption 
modes being produced and analyzed, it would make sense for us to stop 
constructing our own.  So I'd expect some future cryptosystem to be 
based on EAX, CCM, or some other such mode.

In order for KINK to not require updates for these future 
cryptosystems, you'd need to be able to say now how to determine what 
kind of checksum is to be used.

The only tricky issue in dealing with the required-to-implement 
checksum type should be the lack of a fixed size output.  Is it that 
hard to work around?  (Maybe omit the checksum field when computing the 
checksum?)

Ken

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 28 Jan 2005 09:15:57 +0900

At Fri, 28 Jan 2005 09:07:33 +0900 (JST),
Nobuo OKABE <[email-masked]> wrote:
> 
> However, could you please assign serial number or something identity
> to every issue? It helps discussions.

I get it and will do.  Thanks

---

From: Nobuo OKABE <[email-masked]>
Date: Fri, 28 Jan 2005 09:07:33 +0900 (JST)

kamada-san,

Sorry, this is not a comment for your mail.
However, could you please assign serial number or something identity
to every issue? It helps discussions.

From: "KAMADA Ken'ichi" <[email-masked]>
Subject: Checksum (Re: KINK issue list)
Date: Thu, 27 Jan 2005 17:16:45 +0900

----- nobuo

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 27 Jan 2005 20:47:56 -0500

On Jan 27, 2005, at 19:07, KAMADA Ken'ichi wrote:
> 1) omit the checksum field (splicing the header and payloads directly),
> 2) zero out the Length and CksumLen fields because we can't know
>    those lengthes in advance.
>
> My consern/questions are
> - 2) makes me nervous because I don't know whether it makes some
>   kinds of attacks easy (e.g. adding junk data at the end of payloads
>   in order to collide the checksum).

How about including length-without-checksum in the calculation of the 
checksum, instead of a zero?

> - Will required-to-implement checksums never change in the future?

I believe that's the case.

The required-to-implement field was intended to deal with the lack of 
checksum negotiation in Kerberos.  We assert that if you know 
encryption type X is supported, then you know that checksum type Y is 
also supported, and thus you're free to use it.  If we go back and 
change it, we'd be retroactively changing the implementation 
requirements of code (theoretically) already deployed.

It might not hurt to include the checksum type anyways.

> - Thinking about 1), placing the checksum at the end of the packet
>   is more reasonable?

It might be, yes.

> BTW, is a statement like "KINK does not support encryption types with
> such variable length checksums" reasonable in the sense of Kerberos?

I would lean towards "no", because it makes things more complex and 
treats Kerberos as less of a black box.  I suppose it's possible, but 
in my opinion should be avoided.

> Is there any such checksums at this moment?

None outside my imagination.  I could write one up if you like. :-)

This one would be easy enough:
   confounder = random 128-bit block
   h = HMAC-SHA512(confounder | key-usage | msg, key)
   len = random multiple of 8 between 128 and 512
   checksum = confounder | h[1..len]

It's non-deterministic, and the length varies from 256 to 640 bits.  
I'd have to check, but offhand I think it would comply with the 
Kerberos checksum requirements.

Ken

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 28 Jan 2005 09:07:16 +0900

Thank you for your comments.

At Thu, 27 Jan 2005 10:34:03 -0500,
> kind of checksum is to be used.

I agree.

> hard to work around?  (Maybe omit the checksum field when computing the 

I think it's not so hard in itself.  When computing the checksum,
we will need to
1) omit the checksum field (splicing the header and payloads directly),
2) zero out the Length and CksumLen fields because we can't know
   those lengthes in advance.

My consern/questions are

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Mon, 31 Jan 2005 09:35:09 +0900

At Thu, 27 Jan 2005 20:47:56 -0500,
> checksum, instead of a zero?

This seems to work.

So current proposed solution is:
- Use required-to-implement checksum type determined by the etype.
- Use get_mic or verify_mic function to generate or verify the checksum.
- Omit the checksum field before calculation.
- The Length field is filled with the packet length without checksum and
  the CksumLen field is zeroed out before the calculation.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 31 Jan 2005 16:43:29 -0800

> I think they should not be ignored.

I'm hopelessly behind here, but I don't think I saw
a response to this... why should they be taken into
account? We're already mixing in entropy from the kdc
and the ipsec peers. What is more entropy in the form
of subsession keys buying us? Or am I missing the point?

		Mike

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 31 Jan 2005 19:54:59 -0500

> of subsession keys buying us? Or am I missing the point?

the kerberos session key tends to be pretty long-lived and will be the same
from authentication to authentication between the same set of peers until
the ticket expires.  subsession keys are different every time.  it's low cost
and gets cryptographers off your back.

but it's not really all that different from a per-exchange nonce.

							- Bill

---

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Jan 2005 20:41:30 -0500

>> I think they should not be ignored.

    Michael> I'm hopelessly behind here, but I don't think I saw a
    Michael> response to this... why should they be taken into
    Michael> account? We're already mixing in entropy from the kdc and
    Michael> the ipsec peers. What is more entropy in the form of
    Michael> subsession keys buying us? Or am I missing the point?

What Bill said is one reason.

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.

--Sam

---

From: Kazunori Miyazawa <[email-masked]>
Date: Tue, 01 Feb 2005 10:54:45 +0900

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.

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.

<snip>

--
Kazunori Miyazawa