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: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
