The Kerberos Network Authentication Service (V5)
draft-ietf-krb-wg-kerberos-clarifications-07

Reference to RFC2273 must be changed to RFC3413
2273 has been obsoleted for MANY MANY years already

Reviewed by Joel Halpern, Gen-ART

His review:

As far as I can tell, this draft is ready for publication as a
Propsoed Standard RFC

nit: 2026 rather than 3667, and no intellectual property disclosure
statement.
nit: The title claims this is a clarification, while the document is an overview and specification.  The abstract indicates that the reason for redoing the specification is to clarify the previous version, but it is a full specification, not a "clarification", and ought to be titled as such.
nit: In section 6.1 in describing the provision for the currently unused "other" types of realms, the construct "All prefixes expect those beginning with used."
appears.  While typographically a sentence, even in context I can not parse it at all.

No objection, but a bunch of nits:

Really small stuff:

  References not split into normative and informative groups
  MUST/SHOULD/etc. used but not defined
  No copyright boilerplate
  No IPR boilerplate

The abstract talks about how this document "updates" RFC 1510. (The
I-D also implies that this is an updates. But it quickly becomes clear
that this document obsoletes RFC 1510, it doesn't just add to it. Suggest
that this be clarified.

Section 7.2.3.1 seems a bit dated in light of where IDN ended up. In
particular, the notion that the DNS is going to shift to using
case-sensitive labels seems a bit unlikely given that IDN does
stringprep-based case normalization.

More generally, no mention is given of IDN. Addressing IDN issues here
is almost certainly inappropriate, but perhaps a note saying they will
be looked at in a future revision is in order.

-- end of nits --

The trick of switching from namedbits to a BITSTRING (32..MAX) in order
to work around implementations not doing zero bit truncation is a hack
only ASN.1 could possibly deserve.

I also have to say that I find the ISO-2022 G0 restriction conflicting
with DER's G0-only policy to be quite amusing.

Section 1.1


---> KDCs are SHOULD honor this flag.

The "are" looks spurious.

Section 1.2

The text uses "canonicalize" in a way that may cause confusion.  The text seems to mean:
"don't use the DNS to map one name to another as a way of determining who to talk to",
but "canonicalize" has a common reading of 'shift "NeXT.com" to "next.com" for matching'
that might get in the way here.

Informative reference to the documents for PKTAPP needed. 

This is not a discuss, but this note in 3.2.3 concerns me:

   Implementation note: If a client generates multiple requests to the
   KDC with the same timestamp, including the microsecond field, all but
   the first of the requests received will be rejected as replays. This
   might happen, for example, if the resolution of the client's clock is
   too coarse.  Implementations SHOULD ensure that the timestamps are
   not reused, possibly by incrementing the microseconds field in the
   time stamp when the clock returns the same time for multiple
   requests.

I'm not sure that I understand why simply accepting the rejection as a
valid rejection of replays isn't the right answer here.  In situations where
a client is using a shared system clock, it seems possible that the repeated
timestamp might be due to externally-applied corrections to skew of
the system clock.  More generally, though, I'm not sure how the client
is to know the cause of the timestamp repeat, and without that knowledge,
suggesting this course of action seems a bit off.

Section 3.3.1

--->(This paragraph changed) 
Text above probably not needed.


Section 4.

-->if not key usage values are specified then key usages 1024 and 1025 
Should be "if no key usage values"?

The text here in Section 5:

   Note that elsewhere in this document, nomenclature for various
   message types is inconsistent, but seems to largely follow C language
   conventions, including use of underscore (_) characters and all-caps
   spelling of names intended to be numeric constants.

seems odd. I assume it means "draft-ietf-krb-wg-kerberos-clarifications...seems
to largely follow", but that distancing from the current draft made me wonder
if it meant 1510 or 1964 (referenced just above).  I'd suggest rewording it
to avoid the "seems"

In 7.4, the draft says "assignment of OIDs beneath the id-krb5 arc must be obtained by
 contacting krb5-oid-registrar@mit.edu."  Do we want that fixed in
the draft, or have the contact listed somehow at IANA, so it could change
if mit.edu needed to put it in a sub-domain or otherwise move it?

None of the protocol constants are maintained by IANA? This seems like
a disaster waiting to happen. Recommendation: start effort to create
an IANA considerations for Kerberos RFC, outlining the various name
spaces, getting a definitive registry maintained by IANA, and
specifying what the policies are for future assignments. Note: WG
should have a look at RFC 2434 and also
draft-narten-iana-experimental-allocations-05.txt for background.