Subject: [Ietf-krb-wg] PROTO review of draft-ietf-krb-wg-gss-cb-hash-agility-03.txt

From: Larry Zhu <[email-masked]>
Date: Sun, 27 Jan 2008 18:47:37 -0800

The following are my review comments on draft-ietf-krb-wg-gss-cb-hash-agility-03.txt. These were produced while completing my PROTO write-up as the PROTO shepherd of this document.

I have a total of 17 comments. Except comment 2 and 16, please treat them as from an individual.  Naturally, I'd like to see them all addressed, but particularly I believe that the items mentioned in comments 1, 8, 12, 14, and 16, 6 should be addressed before moving forward.

1. in the abstract, the terminology is inconsistent with RFC2743.

   Currently, the Kerberos Version 5 Generic Security Services
   Application Programming Interface (GSS-API) mechanism [RFC4121] does
   not have the ability to utilize better hash algorithms used to
   generate channel binding identities. ...

 RFC2743 describes channel bindings as relevant characteristics, not "identities". I suggest the following text.

   Currently, channel bindings are implemented using a MD5 hash in the Kerberos Version 5 Generic Security Services
   Application Programming Interface (GSS-API) mechanism [RFC4121]. This document updates RFC4121 to allow
   the channel binding restriction to be carried using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961.
   In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange
   message, extensions are defined to allow future protocol extensions.

2. in the abstract. Nits.

It needs to mention it updates RFc4121.

3, Section 1. Nits.
  " With the recently discovered weaknesses in the MD5 hash algorithm
   there is a need to move stronger hash alogrithms."

There are two problems in this sentence:

 alogrithms should spell algorithms.

  s/move/use/

4. various portions in section 1. Same as comment #1.

Channel bindings are restrictions against reuse of the authentication tokens, they are not identities.

Quote from RFc2743,
"The GSS-API accommodates the concept of caller-provided channel
   binding ("chan_binding") information.  Channel bindings are used to
   strengthen the quality with which peer entity authentication is
   provided during context establishment, by limiting the scope within
   which an intercepted context establishment token can be reused by an
   attacker. Specifically, they enable GSS-API callers to bind the
   establishment of a security context to relevant characteristics
   (e.g., addresses, transformed representations of encryption keys) of
   the underlying communications channel, of protection mechanisms
   applied to that communications channel, and to application-specific
   data."

5. section 1, nits.

Kerberos Version 5
   Generic Security Services Application Programming Interface (GSS-API)
   mechanism [RFC4121] uses MD5 to calculate channel binding identities
   that are required to be unique.

It is unclear to me why the uniqueness is required. I suggest

   Kerberos Version 5
   Generic Security Services Application Programming Interface (GSS-API)
   mechanism [RFC4121] uses MD5 to compute channel binding verifiers.

6. section 1, nits.

  This will prevent lengthy
   standardizations in the future when new attacks arise and will allow
   an incremental update to the protocol so that this will interoperate
   with older implementations.

I do not agree with this prevents standardizations. I suggest

  This will allow deploying newer algorithms incrementally without breaking the interop with older implementations, when new attacks arise in the future.

7. section 3. Nits.

Replace the "identifier" with "verifier".

8. section 3, it says "TYPED_DATA", but the description immediately after it saying a totally different  encoding.

9. section 3, the indenting of the following text is funny, can you check?

  where Exts is the concatenation of zero, one or more individual
      extensions, each of which consists of:
        type -- big endian order unsigned integer, 32-bits
        length -- big endian order unsigned integer, 32-bits
        data -- octet string of length octets
      in that order

10. Section 3, the GSS-checksum type does not have anything new till the "Exts" field from RFC4121. Can you clarify this?

11. section 3,  'octet string of length octets", I found this hard to read, how about "extension data encoded as a stream of octets"?

Can you add a structure definition so that this is easier to refer to.

Can you change the description of the "length" to

length -- big endian order unsigned integer, 32-bits, this contains the length of the extension data in octets.

And change the description of the "type" to

type -- big endian order unsigned integer, 32-bits, this contains the type of the extensions.

12. section 3, can you add "there must be at most one instance of a given instance type". This simplifies processing of the extensions.

13. section 3, the following text is imprecise.

  Initiators that are unwilling to use a MD5 hash of the channel
   bindings should set the Bnd field to all ones (1).

An implementer would interpret this to 16 bytes of ones, vs 16 bytes of 0xFF.

And change "should" to all upper case "MUST".

14. section 6, this section must have meaningful exploration of security issues raised by the proposal. In particular the solution is incomplete. if the client does not send the get_mic channel binding, can you define an error to return to the application? This is because in your security considerations section, you specify "it is up to applications to decide", but you did not define a way to allow the applications know what happens (then how can they decide?).

15. please update "TBD" key usage number since it is already assigned.

16. update the number assignment policy in the Section 5 per Vancouver meeting/consensus.

17. section 5, the verifier for the channel bindings is not always computed with a hash function. RFC3961 does not define a hash in the generic profile. I suggest, replace OLD
"Extension for hash function-agile channel binding," with "Extension for the verifier of the channel bindings,"

--larry

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