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

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jan 2008 15:55:48 -0600

On Wed, Nov 07, 2007 at 03:03:08PM -0500, Jeffrey Hutzelman wrote:
> [JTH.1] Consider putting the introduction before conventions.

OK.

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

Sure (this is the sort of thing that the RFC-Editor excels at).

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

Will do (that was always the intention).

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

Isn't "SHOULD" sufficient?  Why does it need a qualifier?  Why not "MUST
... where possible"?  That would seem stronger in just the right way.

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

Ah, yes, thank you.  I'll update and re-submit.

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

Indeed.  We had a discussion about this.

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

Null, Change Kerberos Password, Set Kerberos Password, Generate Kerberos
Keys, Get Password Quality Policy, at least.

I'll make this explicit.  Good catch!

> [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".

The minor version number is intended to provide this capability.

Should we have an operation for listing available operations?

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

None on the implementations.  However, for client deployment this is one
more thing to think about (do I have v2 servers? no? then turn on
v1/rfc3244 support on the client).

> [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

Yes.

> 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.

Ah, yes, I'll fix that.

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

I'll fix that.

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

I agree.  I'll make this explicit.

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

OK.

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

I think that comment is in error.  The name-type is part of the
principal creation operation, which is not part of this protocol, and
only a hint.

> [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".

Same thing.

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

I'll do a second pass.

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

But you repeat yourself.

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

But RFC3244 is Informational.  What to do?

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Jan 2008 17:14:03 -0500

> ... where possible"?  That would seem stronger in just the right way.

SHOULD is actually pretty strong.  I don't recall what I was getting at 
here, but I suspect I was trying to make it a bit weaker by providing 
conditions in which the SHOULD does not apply.

> Indeed.  We had a discussion about this.

Yup.  I believe the intent of the comment was "... but this section still 
_claims_ it uses them throughout".

>> 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".
>

Hm, OK.

> Should we have an operation for listing available operations?

Possibly.  I think that only becomes relevant when we start having multiple 
extensions that add different operations.

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

IMHO my formulation is clearer.

> But RFC3244 is Informational.  What to do?

The nature of the reference is normative; the type of document being 
referenced is not relevant to this fact.  The reference should be moved.

Then you can ask whether it is OK for a standards track document to have a 
normative reference to an informational RFC.  The answer is "yes", but it 
will have to be called out explicitly in the last call.

An alternative would be to repeat the framing description in this document, 
avoiding the need for the normative reference.

I look forward to your responses, discussion from the WG on the issues 
we've raised, and perhaps a new version of the document.

-- Jeff