Subject: [kitten] Comments on draft-ietf-kitten-iakerb-01

From: Greg Hudson <[email-masked]>
Date: Sun, 16 Feb 2014 12:14:26 -0500

Content comments:

> Exts field in the GSS-API authenticator [RFC6542] MUST contain an
> extension of the type GSS_EXTS_IAKERB_FINISHED

The rest of the draft uses GSS_EXTS_FINISHED.

> and the extension data contains the ASN.1 DER encoding of the
> structure IAKERB-FINISHED.

The rest of the draft uses KRB-FINISHED.

> Initiators behave as follows:
>
> o  If the acceptor token is framed, then use the protocol as defined
>    above.

I suggest:

  o  If the first acceptor token begins with generic token framing as
     described in section 3.1 of [RFC 2743], then use the protocol as
     defined in this document.

> o  Else

I suggest:

  o  If the first acceptor token is missing the generic token framing
     (i.e. the token begins with the two-byte token ID 05 01), then

>    *  All future tokens sent to the acceptor are to be unframed.

This bullet is unnecessary and should be removed.  All versions of the
MIT IAKERB acceptor will process framed messages, as I said here:

  http://www.ietf.org/mail-archive/web/kitten/current/msg03993.html

> Acceptors behave as follows:
>
> o  If you framed the response token, use the finish extension
>    processing defined in the main document.
>
> o  If you did not frame the response token, use the finish extension
>    processing defined in the previous paragraph.

This doesn't provide useful advice for interoperating with an MIT
initiator, as a standard acceptor will always frame the response token.
I suggest:

  Acceptors behave as follows:

  o  If the AP-REQ authenticator contains an extension of type 1
     containing a KRB-FINISHED message, then process the extension as if
     it were of type GSS_EXTS_FINISHED, except with a key usage of
     KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41).

Editorial comments (only on the new text):

> MIT implemented an earlier draft of this specification, details on how
> to inter operate with that implementation can be found in Appendix A.

This is a run-on sentence.  Using a semicolon instead of a comma would
fix it.

> pnp The gss-mic field in the KRB-FINISHED structure contains

There is a stray "pnp" at the beginning here.

> concatenated in chronological order (note that GSS-API context token
> exchanges are synchronous.)

The period should be outside the parens, or the parenthetical should be
a separate sentence (in which case the period stays inside the parens).

> MIT implemented an early draft version of this document, this section
> gives a method for detecting and interoperating with that version.

This is another run-on sentence.  It's probably best to split it into
two sentences at the comma.

---

From: Greg Hudson <[email-masked]>
Date: Sun, 16 Feb 2014 14:39:49 -0500

>      KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41).

I missed a necessary bullet point here.  Before the AP-REQ bullet point,
I suggest:

  o  After the first initiator token, allow initiator tokens to omit
generic token framing.  This allowance is required only for IAKERB_PROXY
messages (those using token ID 05 01), not for tokens defined in [RFC4121].

It might also be worthwhile to say that, for the purpose of computing
the KRB-FINISHED checksum, initiators and acceptors should both use the
tokens they sent or received without modification--that is, don't insert
synthetic generic token framing or modify the token to have the
standardized extension type.  But I don't have suggested wording, and it
should be fairly obvious even if we don't say it.