[Gen-art] Gen-ART review of draft-ietf-krb-wg-tcp-expansion-01.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-krb-wg-tcp-expansion-01.txt
Reviewer: Vijay K. Gurbani
Review Date: 2 April 2007
IESG Telechat date: 03 April 2007

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.

Comments: This draft describes a mechanism to negotiate
TCP-specific Kerberos extensions.

Most of my comments are nits except one in S5.  Please check
the comment in S5 to see if it makes sense (an "upgrade" attack.)

S3, Second paragraph:
  s/which extensions a KDC support/which extensions a KDC supports

S3, Second paragraph:
  The last sentence of the second paragraph appears to fit better
  as a second sentence to the third paragraph.

  My reasoning is that in the second paragraph, you are defining
  what a probe is, and then next sentence essentially states that a
  probe is not required if a client knows that the server supports
  a particular extension.  Not co-incidentally, that is the exact
  argument of the third paragraph.

S3, Page 4, first paragraph:
  s/a, by the client, required extension/an extension required by
  the client.

S4, first paragraph:
  I have a hard time making sense of last sentence on page 4:
  "When this was written, this problem existed in ..."
  The first "this" refers to the document at hand, I think.
  The second "this" refers to the implementations that do not
  confirm to rfc4120.  Yes?  If so, then I suggest re-writing
  the offending sentence to:

  "When this document was written, the problem described earlier
  existed in ..."

S5
  While reading the downgrade attack scenario, it struck me
  whether an "upgrade" attack can be mounted (please see if
  the following makes sense)?

  Client          MiTM             KDC
  0x00000001 --->                         # Client sends a probe
                 0x81900101 --->          # It is modified en-route
                            <--- 0x00000000 # Server agrees
            <--- 0x00000000               # Passed thru
                            <--- [additional data]
            <--- [additional data]        # Passed thru

  Here, the client sent a probe, which was turned to a
  specific request for some extensions.  The KDC, as it turns
  out, supports this specific extension (I am not sure whether
  0x81900101 is a valid extension; I simply use it as an
  example.)  So, the KDC sends a 0x00000000 followed by extension-
  specific data.  The client, meanwhile, gets its probe
  answered with a 0x00000000 followed by data and it does not
  know what to do.

Oh, one more thing: the draft needs the new boilerplate statements.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art