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 resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-krb-wg-cross-problem-statement-04.txt Reviewer: Brian Carpenter Review Date: 2008-08-04 IETF LC End Date: 2009-08-11 IESG Telechat date: (if known) Summary: This draft is on the right track, but has open issues, described in the review. -------- Major issues: ------------- 1) About 5.5. Client's performance > It > takes 195 milliseconds to perform a TGS exchange with the on-board > H/W crypto engine. Indeed, this result seems reasonable to the > requirement of the response time for the control network. ... > Also, the delays > can grow to unacceptable delays when the number of intermediary > realms increases. This analysis seems incomplete. How do we know that 195 ms is OK and that an unspecified time using intermediary KDCs is too big? There are certainly some SCADA environments where 195 ms is like infinity, and others where 20 seconds would be just fine. In fact, shouldn't timing constraints be defined in Section 4 as external requirements? The existing requirements R-6 (device performance) and R-7 (link capacity) are rather imprecise, and do not mention network latency. 2) About 5.6. Pre-authentication problem in roaming scenarios There seems to be a rather strange assumption here which is not discussed: that different realms of a SCADA system will be interconnected by the public Internet. Well, when I was working on control systems, I would never have dreamt of such a thing! Surely interconnections between sites and contractors, whether roaming or fixed, must be based 100% on a VPN approach, where the access control could be tuned perfectly to avoid a pre-authentication problem. Typically I'd expect a truly roaming user to connect into the VPN and her home realm using an IPSec tunnel, and then have exactly the same trust model as any fixed host in the same realm. In any case, use of the public network with arbitrary authentication seems to be a false assumption. In fact, in one of the Shell examples, you say: > They are connected each other by a private ATM WAN. so any roaming user would have to VPN herself right into that WAN. Minor issues: ------------- This is basically a grammatical problem but the authors need to confirm what the sentence means before it can be edited (last paragraph of section 2.2): > However, because the inter-realm trust model > is not necessarily constructing the hierarchic approach anytime, the > trust path must be specified manually. Does this mean ", because the inter-realm trust model may or may not follow the hierarchical model,"? If not, what does it mean? Editorial issues: ----------------- Just to note that the RFC Editor will have to make many grammatical corrections to this draft.