Subject: [Ietf-krb-wg] PROTO review comments on draft-ietf-krb-wg-kerberos-set-passwd-07.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 7 Nov 2007 15:03:08 -0500 (EST)

The following are some issues I identified while reviewing the set-passwd
draft in preparation for asking Sam to take it to the IESG.  There are a
total of 20 items here, some fairly trivial and some more complicated.
Seven of these (marked with *) are items that I believe must be addressed
before the document can progress.

-- Jeff

[JTH.1] Consider putting the introduction before conventions.

[JTH.2] * (Section 3) Expand "RPC" at first use, or drop the sentence.

[JTH.3] * (Section 3.3) This section specifies use of key usage numbers 20
and 21, which are listed in RFC4120 as reserved.  Please consult with Tom
to verify his records reserve these numbers for set-passwd.

[JTH.4] (Section 3.5) "The server SHOULD localize...".  This should
probably say "... when possible" or some such.  Every implementation will
have cases where it cannot localize.

[JTH.5] * (Section 3.5.2) This section refers to RFC3066, which is
obsoleted by 4646 and 4647; the reference needs to be updated.  In
addition, instead of including an imprecise definition of a matching
algorithm inline, the present document should recommend one of of the
approaches discussed in RFC4747.

[JTH.6] (Section 3.6) The protocol no longer uses extensibility markers
throughout.

[JTH.7] * (Section 3.7) Which operations are REQUIRED to implement?

[JTH.8] (Section 3.7) Do we need a capability mechanism to discover which
operations are implemented?  I've seen RPC-based protocols go through
multiple updates involving new versions of RPC's, with the effect that a
new client must first try the newest op, then the next older version, then
the one before that, and so on, leading to a large number of round trips
for a relatively simple operation like "I've never heard of you; tell me
your UUID and forget anything I've ever promised you".

[JTH.9] (Section 4.2) What effect does defaulting the version to 2 have on
implementations of olver protocols?

[JTH.10] (Section 4.3.2 - change-pw) Is the 'languages' argument a list of
languages to be permanently associated with this principal in the KDB, or
a restatement of the client's language list that is included with every
request?  If the former, the corresponding element is not present in the
ASN.1 module, and there is no text describing it.  If the latter, it should
be removed from the description as it is not actually an argument to the
operation.

[JTH.11] (Section 4.3.3 - set-pw) See JTH.10.

[JTH.12] (Section 4.3.4 - set-keys) The description for this operation does
not indicate that the 'commit' argument is optional, though it is declared
as DEFAULTed in the ASN.1.  The descriptions for change-pw and set-pw have
no information on the purpose of the 'commit' flag.  Some consistency would
be good.

[JTH.13] (Section 4.3.6 - get-keys) While this feature can be used only to
retrieve uncommitted keys, a compliant implementation should be allowed to
omit this feature entirely or allow an administrator to disable it.  I
would suggest changing the first MUST in this section to a SHOULD.

[JTH.14] * (Section 5) I need verification from someone that the ASN.1
module actually compiles, preferably on more than one compiler.

[JTH.15] (Section 5) References in the ASN.1 module should be directly to
RFC's or other stable targets, rather than using the document's reference
tags.  That way, when someone extracts the module and uses it, the
references still are useful.

[JTH.16] What ever happened with this comment?
   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
   --  type and a UTF8String, for simplicity.]

[JTH.17] (Section 6) The second paragraph states:
   Clients SHOULD NOT negotiate support for legacy major versions
   of this protocol unless configured otherwise.

I think you mean "unless configured to do so".

[JTH.18] (Section 6) The security considerations section seems awfully
short.  Are you sure all considerations have been addressed?  It might
be worthwhile to do a pass through RFC3552 to make sure nothing has been
missed.

[JTH.19] * (Section 7.1) Update RFC3066 reference.

[JTH.20] * (Section 7.2) Framing is incorporated by reference from
RFC3244; thus, this is a normative reference.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg