Subject: Comments on draft-ietf-krb-wg-gss-cb-hash-agility-00.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Feb 2007 12:30:32 -0500

+ The introduction could do a better job of explaining the motivations
  for this work.  Particularly...
  - MD5 is not based on SHA1
  - The weaknesses in MD5 and SHA1 create a need to move to a stronger
    hash, but do not directly create the need for agility (the ability
    to select from a variety of algorithms).
  - The reason for the algorithm agility mandate is not only to reduce
    the time required to update the standard, but to allow deployment
    of new algorithms to be done incrementally, rather than requring a
    "flag day" on which the change must be deployed everywhere at the
    same time in order to maintain interoperability.

+ EncAPRepPart is a type defined by Kerberos; it is inappropriate for
  this specification to change its definition as described on page 5.
  In addition, the change in question is impermissible because it adds
  new elements to a sequence which does not have an extension marker.

  If it is necessary to allow the acceptor to reply to an extension,
  you will probably need to define a new context token type to be used
  in place of the existing '02 00' type.  Presumably this would contain
  an AP-REP followed by a KRB-SAFE or KRB-PRIV message.

+ New initiators should only be required to compute an MD5 checksum if
  they desire interoperability with old acceptors.  There should be some
  alternative available to initiators which are unwilling to use MD5-based
  channel bindings (for example, due to security policy).

+ The RFC3961 get_mic operation accepts a key usage number as an argument;
  the actual derivation of a specific key is mechanism-dependent and is
  described in RFC3961 and in the documents which define each mechanism.
  It is not necessary or appropriate in section 3 to describe the details
  of key derivation; simply indicate which key and key usage value are
  used when calling the RFC3961 get_mic operation.

+ The security considerations section needs to be expanded quite a bit.
  The phrase "Servers can use a down-grade attack..." is unclear.  At a
  minimum, please describe the potential downgrade and what can be done
  by clients and servers to avoid it.

+ If you are creating a new typed hole, then your IANA considerations
  needs to describe the registry and registration policy for this hole.
  This should include initial contents for the registry, including any
  entries allocated in the same document - you don't need to ask IANA
  to assign those.

  In addition, you need to call out any instances where you need IANA to
  register a new value in an existing registry.  Note that Kerberos key
  usage values are not currently managed by IANA; please contact Tom Yu
  for assistance in selecting a key usage number.

+ Add a reference to RFC2119 and the boilerplate required by that
  document, and then use its keywords to describe requirements.

+ Instead of talking about "older" and "newer" implementations, simply
  describe what is required of implementations of the present spec.  For
  example (from section 2):

          Initiators SHOULD populate the Bnd field as described
          in RFC4121, in order to maintain interoperability with
          existing acceptors.

+ Don't talk about what "would" be - the document is not a discussion
  of how the protocol might be changed; it is the specification of how
  the new protocol works.  Talk about what "is", or what "MUST" be.

+ Section 2 says the computation of the extended channel binding is
  described in section 2.2; it is actually defined in section 3.

+ The header should indicate that this document updates RFC4121.