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._______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
