Subject: some comments on newest kerberos-clarifications

From: Ken Raeburn <[email-masked]>
Date: Fri, 01 Nov 2002 23:30:56 -0500

I'll try to get in to the meat of the material in the next few days,
but here are some things that came to me while flipping through the
copy I just printed up and doing some simple checking of mechanics for
a little while, er, or maybe it's been a few hours....  Fortunately,
most of this is form, not substance.

Ken

----------------

RFC 2223 and other RFC Editor recommendations:

Both draft-rfc-editor-author-lists-00.txt and
draft-rfc-editor-rfc2223bis-03.txt are just I-Ds at this time, but I'd
consider trying to comply anyways.  And yes, kerberos-clarifications
is only a draft at this point, but if we want to go through last call
and submit it, we would be nicer to the RFC Editor if we had a
document that actually follows their guidelines and requirements at
submission time.

In draft-rfc-editor-author-lists-00.txt, the RFC Editor recommends
listing only an editor on the front page if the author list exceeds
about five people (not a fixed limit).  The breakdown between
"Contributors" and "Acknowledgements" sections if both are included is
not specified.  Presumably some of the "acknowledged" people
contributed small amounts of text, but bear little or no
responsibility for the document in its final form.  For the crypto
draft, I just put everything into Acknowledgements and tried to say
who contributed what text.

Mechanical:

The table of contents would be more helpful if it had page numbers,
and if page numbers were in the page footers.  (Yes, this is at odds
with putting an HTML version without page breaks on the web.  So what?
The text version is what we should care about.)  Also, it would
probably be more readable if it only went, say, 3 levels deep, perhaps
even just 2.

The footer line would look a lot better if it were on the same line
number on each page, rather than jumping up and down.  It should also
always be separated from the text by at least one blank line.  A
header line would be good too.  RFC 2223 (and rfc2223bis) specifies
the format to be used for page headers and footers for an RFC.

Why only one space after each sentence?  Isn't two standard?

Section 4, last paragraph, the footnote [4.1] reference has periods
before and after it, as though it's supposed to be a sentence.  Get
rid of the period before it, making it part of the previous sentence.

Some section numbers have a trailing dot, some don't:
    7.2. KDC messaging
    7.2.1 IP Transports
    7.2.1.1. UDP/IP transport
They should all be consistent.

The author list does not list the authors' organizations, as indicated
by RFC 2223.

RFC2223bis indicates a specific order for various sections of the
document, which we're not following.  (The crypto and AES drafts
probably need updating to fix this as well.)

References:

Several of the references are no longer used, because the crypto stuff
was split off.  I think we can drop Blumenthal96, Bellare98, DES77,
DESM80, Dolev91, DS90, Horowitz96, HorowitzB96, IS3309, KBC96,
Krawczyk96, LGDSR87, MD4-92, MD5-92, SG92, X509-88.

According to draft-rfc-editor-rfc2223bis-03.txt, informative and
normative references must be listed separately.

Various references to the ISO specs in the text are not enclosed in
brackets.  The entries in the references section should probably have
a little more information.

No entry is made in the references section for the references to
[RFC1510], [RFC1884], [RFC1964], [RFC2373], [RFC 1035], [RFC 1779],
[RFC 2222] (note the spaces, which should perhaps be removed), and
"[ref to GSSAPI RFC]".  Other mentions of RFC 1510, RFC 2052, RFC 2253
and probably other RFCs use varying syntax and should perhaps be
normalized.  (Some of these would probably be informative references.)

The entry for RFC 2279 has bad indentation.  On the other hand, it's
not actually referenced from anywhere in the UTF-8 text.  Reference it
and fix the indentation, or delete it.

[KCRYTPO] is not listed in the reference section.  I'd move the note
to the RFC Editor to the references section from the third paragraph
in section 4, and just use [KCRYTPO] in the section 4 text, unless you
want to globally replace it with an RFC number reference.

The AES draft isn't listed or referenced either, although the AES
algorithm is listed as required.

Some entries have hyphenated words, DS81 among others.  When that
doesn't coincide with the actual line breaks, it looks terrible.  And
RFC 2223 forbids hyphenation.  (In fact, I'd recommend scanning the
entire document source for hyphenation -- look for a regular
expression like "[A-Za-z0-9]-" before whitespace or end-of-line.)

Footnotes:

Number [3.6] was skipped.

There are what appears to be references to footnotes [18], [19], [20],
[24], [32], [40], but there are no associated footnotes.  In the cases
in section 3.3.3.2, it appears that parenthetical statements in RFC
1510 were removed, and the information in those statements is
important for the interpretation of the field.  For example, if the
transited-realm field starts with "/COM", the lack of a leading space
indicates that "/COM" should be appended to the previous realm name;
however, we no longer indicate what that means at the start of the
string.

Considering their location, "End notes" might be a better name.

Attributions in section titles:

Does "[Westerlund,Danielsson]" belong in the title of section 7.2.1.2,
or in the acknowledgements?  Similarly for "[Westerlund]" in the IPv6
address format specification.  (I happened to notice this while
grepping for words in brackets, checking for issues with footnotes.)

Acknowledgements:

Spelling error: "Brezak".

Presumably Danielsson should be included here too.

Misc:

Flatten section 7.2 a bit.  There is nothing in 7.2 besides 7.2.1; no
7.2.2, and no introductory text.  Pull 7.2.1 and everything under it
up a level to 7.2 etc.

Obviously the type number for directional addresses still needs to be
filled in in sections 7.1 and 7.5.3.

Appendix B: When it says, "changes to section N", does that mean the
section numbered N in RFC 1510, or the section numbered N in
Clarifications?  Thanks to the renumbering, it's not clear, and some
subsections in this appendix describe both.  Pick one interpretation,
or give up on the breakdown by section.

7.5.2, spelling: "deprecated"

7.5.3, typically "IPv4" and "IPv6" are written in mixed-case, in my
experience, unless the context indicates a preference for single-case
type.

7.1, the reference to RFC2373 should probably be after the first
mention of IPv6, instead of looking like a separate sentence of its
own (with periods both before and after).  Both RFC2373 and RFC1884
are referenced, but RFC 2373 obsoletes RFC 1884.  Remove the reference
to 1884.

Sections 1.4, 2.7, 5.2.7.3 and 5.2.7.4 are missing from the TOC.  This
may not be an exhaustive list; it's just the gaps I noticed skimming
the TOC.

Sections 5.2.6.2, 5.2.6.3, 5.2.6.6, 5.2.6.7 and B.10 don't exist at
all; the higher-numbered sections should be renumbered to remove the
gap.

"Acknowledgements" and "References" are both numbered 11.1.  I see no
reason for them to be in the same section; make them 11 and 12.

"Changes to Section 1" and "Changes to Section 2" are both numbered
B.1.  Presumably the latter, and B.2 and B.3, should be renumbered
upwards; this will fill in the missing B.4.

---

From: "Nicolas Williams [RU-CENTRAL]" <[email-masked]>
Date: Mon, 11 Nov 2002 10:29:22 -0800

Some of my comments and questions:

 - Should must/should/may in the original text be capitalized in
   clarifications? I think so. Certainly new text should, such as in
   paragraph 7 of section 5.2.1.

 - For "older" enctypes the KDC should use PA-ETYPE-INFO in preference
   to PA-ETYPE-INFO2 unless the KDC has some indication that the client
   supports PA-ETYPE-INFO2 (e.g., if the client references a "newer"
   enctype in the AS-REQ then it must support PA-ETYPE-INFO2). Or am I
   missing something?  Is there any value to the use of PA-ETYPE-INFO2
   w/ "older" enctypes?  Older enctypes, in this context, are enctypes
   deployed before the advent of PA-ETYPE-INFO2.

 - PA-ETYPE-INFO2 is not defined in the ASN.1 module in the appendix
 - PA-ETYPE-INFO  is not defined in the ASN.1 module in the appendix
 - PA-TGS-REQ     is not defined in the ASN.1 module in the appendix

 - Section 3.1.3, paragraph 4 refers to PA-S2K-PARAMS, an alias for
   PA-ETYPE-INFO2?

 - Section 1.1, paragraph 6, fourth sentence, remove the apostrophe
   after "KDC" - plural, not posessive.

 - Section 1.2, paragraph 3, spelling: "while" not "wile".

 - Are KDCOptions critical? I think they ought to be.

 - Section 3.6.2, paragraph 1, what's with that lonely 'v' letter?

 - Section 3.6.2, paragraph 2, the fifth sentence runs into the sixth
   and the intended meaning is not clear.

 - Sextion 3.7, technically there can be five messages, the first
   possibily being from the client asking for the server's TGT or
   otherwise negotiating Kerberos V, the response to which might
   indicate that the server wishes to use u2u auth.

 - Sections 5.2.7.4 and 5.2.7.5, paragraph 1, first sentence, read "is
   sent" whereas MUST/SHOULD/MAY ought to be used.  Only one of
   PA-ETYPE-INFO/PA-ETYPE-INFO2 can be sent in KRB-ERROR, unless
   Typed-Data is used (but Typed-Data is not to be used for
   KDC_ERR_PREAUTH_REQUIRED errors).  See above.  Requires
   clarification.

 - Section 6.2, paragraph 4, first sentence has a grammar error ("If
   instance is a single ...")

 - Section 8.2, add a recommended value for the acceptable clock skew?

 - Footnote 4.1 says "While Kerberos directly provides no facility for
   negotiating encryption types between the application client and the
   server, there are other means for accomplishing similar goals." and
   goes on to establish the KDC exchanges as the facility for
   negotiation of enctypes for use in the AP exchange.  This principle
   deserves more than a footnote as it: a) seems too obvious to describe
   as an afterthought to rfc1510, b) is crucial to the Kerberos
   extensions proposals made in this WG.

I may add more comments later.

Cheers,

Nico
--

---

From: Tom Yu <[email-masked]>
Date: Tue, 12 Nov 2002 12:05:15 -0500

>>>>> "Nicolas" == Nicolas Williams [RU-CENTRAL] <Nicolas> writes:

Nicolas> Some of my comments and questions:

Nicolas>  - PA-ETYPE-INFO2 is not defined in the ASN.1 module in the appendix
Nicolas>  - PA-ETYPE-INFO  is not defined in the ASN.1 module in the appendix
Nicolas>  - PA-TGS-REQ     is not defined in the ASN.1 module in the appendix

This is symptomatic of a general confusion within the document between
different uses of the word "type".  The word "type" may be used to
refer to an ASN.1 type.  It may also be used to refer to an integer or
OID that identifies the contents of a "hole" in the protocol.  The
symbolic names attached to the numbers used to identify the contents
of a protocol "hole" aren't used consistently.  Sometimes they're
written like C preprocessor macros -- all caps, with underscores;
sometimes they're written as ASN.1 value references -- initial
lowercase letter, with hyphens; sometimes, as in the PA-* names,
they're written in all caps with hyphens (valid in neither syntax!).

The PA-* names appear to name integers identifying the contents of the
PA-DATA ASN.1 type.  The ASN.1 type (if it is in fact an ASN.1 type;
some contents are not ASN.1 encoded...) often has a different name,
possibly not beginning with "PA-".  The table in 5.2.7 maps between
numeric identifiers and the associated contents of
PA-DATA.padata-value.  There does appear to be an error in that
pa-etype-info and pa-etype-info2 refer to the ASN.1 types
PA-ETYPE-INFO and PA-ETYPE-INFO2, respectively, when they should
probably instead refer to ETYPE-INFO and ETYPE-INFO2.

---Tom

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Nov 2002 17:06:32 -0500

>>>>> "Nicolas" == Nicolas Williams [RU-CENTRAL] <Nicolas> writes:

    Nicolas>  - Are KDCOptions critical? I think they ought to be.

No, and I think we have consensus on this and I believe the text in
section 2 is clear on this point.

If a client wants an option to be treated as critical it should reject
the response if the option is not honored.

You only really need criticality when you have an exchange where the
party that cares about criticality will not have an opportunity to see
whether the option is understood.

    Nicolas>  - Sections 5.2.7.4 and 5.2.7.5, paragraph 1, first
    Nicolas> sentence, read "is sent" whereas MUST/SHOULD/MAY ought to
    Nicolas> be used.  Only one of PA-ETYPE-INFO/PA-ETYPE-INFO2 can be
    Nicolas> sent in KRB-ERROR, unless Typed-Data is used (but
    Nicolas> Typed-Data is not to be used for KDC_ERR_PREAUTH_REQUIRED
    Nicolas> errors).  See above.  Requires clarification.

No, both can be sent.  The edata for preauth required is sequence of
padata.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Nov 2002 11:20:40 -0600

<[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Nov 12,
2002 at 05:06:32PM -0500
X-Spam-Status: No, hits=-102.3 required=6.0
	tests=IN_REP_TO,DOUBLE_CAPSWORD,USER_IN_WHITELIST
	version=2.31
Sender: [email-masked]
Precedence: bulk

> whether the option is understood.

Oh, I remember now. Got it. Thanks.

> No, both can be sent.  The edata for preauth required is sequence of

Well, yes, both can be sent, but for pre-etype-info2 enctypes etype-info
ought to be sent for those enctypes regardless of whether etype-info2
entries are also sent for the same enctypes.

My complaint was that the draft says "such and such is sent" instead of
"such and such MUST be sent in cases where ..." and that 'MUST' ought to
be used to require the use of etype-info for older enctypes.

Re-reading the draft I see that between section 8.1 and the last
paragraph of section 5.2.7.5 my concerns are mostly taken care of.
Section 8.1 mandates support for etype-info2 and recommends support for
etype-info for interop with older client implementations.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Nov 2002 19:23:55 -0500 (EST)

>    paragraph 7 of section 5.2.1.

Yes; if we intend to use these terms as formal requirements language, then
they should be capitalized for clarity.  In addition, if the intent is
that the formal definitions in RFC2119 are to be used, then those
definitions must be explicitly incorporated by reference, as described in
the abstract of that document.

>    after "KDC" - plural, not posessive.

I disagree.  KDC is an abbreviation; while using an apostrophe in its
plural makes no logical sense, it is nonetheless correct.

>    indicate that the server wishes to use u2u auth.

Indeed, the whole "step 0" line in that table really represents an
arbitrarily complex negotiation between client and server, at the end of
which both have agreed to u2u and the client has the server's TGT.  The
text should probably be reworded to indicate this, but this is IMHO not a
critical problem.

>    KDC_ERR_PREAUTH_REQUIRED errors).  See above.  Requires

No.  These sections are descriptive, not prescriptive.  They tell you what
the messages are about and when they are used; requirements language is
inappropriate here.  However, section 3.1.3 should probably be updated to
reflect the existence of PA-ETYPE-INFO2 and be more specific about when
these messages must be used.

>    instance is a single ...")

Read 'instance' as a variable name, and it becomes OK.  This sentence is
poorly worded (it would be better if it were more similar to the first
sentence of the previous paragraph), but IMHO the meaning is clear.

>  - Section 8.2, add a recommended value for the acceptable clock skew?

Section 3.2.3 implicitly suggests a value of 5 minutes.  I believe this is
consistent with current practice, and I agree it would be appropriate to
add this item to section 8.2.

>    extensions proposals made in this WG.

This is a little tricky.  I agree the technique is important, and it is
worth mentioning since it is not necessarily obvious to those not already
familiar with the Kerberos protocol and common usage.  However, I think
including it in the main text would interrupt the flow somewhat.  If
someone can come up with wording that allows this text to appear inline
rather than as a footnote, I would support such a change.  However, I
don't think it's worth holding up the document over.

Note that this text is not actually needed to legitimize the use of
this technique in other protocols defined in this working group or
elsewhere.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 14 Nov 2002 15:16:49 -0500

> plural makes no logical sense, it is nonetheless correct.

I've never heard that, and I disagree with it.

In fact, every reference I've just pulled up (via Google, so mostly
they're random style guides) says no apostrophe for the plural of an
acronym, abbreviation or initialism (and "KDC" is actually an
initialism), except (one says) with an abbreviation that already has
internal punctuation ("Ph.D.'s", but "CPUs"), or (another says) when
forming "the plural of letters, numbers, and signs, and of words
referred to as words"; there are disagreements on the exceptions, the
case we're dealing with isn't one of them in any guide I've seen so
far.

If you want something a little more formal, Webster's II New Riverside
University Dictionary (1984) lists only one case where an apostrophe
is used for a plural form -- "of words, letters, and figures used as
such".  (I suppose: "Our must's and should's should have been upper
case when the RFC was published in the 90's."  But I'd probably try
quoting the words, and perhaps rephrasing to avoid making them
plural.)  Nothing about abbreviations, acronyms or initialisms.

Regardless of the chosen style, it should be consistent throughout the
document.  Apostrophes, hyphenation of things like "sub-session" and
"pre-authentication" ... I'm sure there are quite a few things we
could check, for both correctness and consistency.

> sentence of the previous paragraph), but IMHO the meaning is clear.

Might work if "instance" weren't used later with "the" in the same
sentence.  Needs rewording.  Perhaps:

    If the instance is identified by a single component following the
    service name, identifying the host on which the server is running,

> don't think it's worth holding up the document over.

I'll take a closer look at this in a little while, if no one else
suggests new wording first.

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 15 Nov 2002 18:35:13 -0500 (EST)

> I've never heard that, and I disagree with it.

After doing some research, I agree with you.  And of course, consistency
is important.