Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-krb-wg-cross-problem-statement-04.txt

From: <[email-masked]>
Date: Tue, 6 Oct 2009 07:47:42 +0900

Hi Brian,

I got your double comment, but I had made a response it on 8th Aug.
I attached my response below in case.

Regards,

Shoichi Sakane

________________________________________
From: Sakane, Shouichi ([email-masked])
Sent: Saturday, August 08, 2009 10:50 PM
To: Brian E Carpenter; [email-masked]; General Area Review Team
Cc: [email-masked]; Tim Polk
Subject: RE: Gen-ART LC review of draft-ietf-krb-wg-cross-problem-statement-04.txt

Hi Brian,

First of all, thank you for your taking time to review our document.
We really appreciate your help.

> 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.

We explained DCS of the petro-chemical plant, not general
SCADA.  The real time performance of DCS is more severe than SCADA
in general.  Typical DCS in the petro-chemical plant requires that:

   The travel
   time of data from the device to the other device is demanded within 1
   second at least.

which is described in section 3.  It relates to R-6.
The explosion proof is very severe in some area of the petro-chemical
plant.  It means that total energy of the system is limited.
We described:

   Because there is a requirement of the explosion-proof.  The
   requirement restricts the amount of total energy in the device.

It relates both R-6 and R-7.

However, we don't intend to eliminate the SCADA system.  In general,
we think that it is better for requirements to be suite to the severe
system.

In SCADA system, latency of 195 (ms) may or may not be enough.
We can say that 195 (ms) is enough for DCS.
An issue here is that the latency would take 195 x n (ms)
before the node begin to communicate with the peer node.
when there are 4 realms between the local and the remote,
the latency will take more than 1 (s).

> 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.

As we described in section 3:

   Furthermore, to
   suppress power consumption, these CPU may be lowered the number of
   clocks.  Because there is a requirement of the explosion-proof.  The
   requirement restricts the amount of total energy in the device.

client processing performance and power consumption are important.

About R-7, we described the following in section 3:

   In the both of the systems, the end devices are basically connected
   to a local network by a twisted pair cable, which is a low band-width
   of 32 kbps.

DCS uses a certain cable that is standardized in the Fieldbus Foundation.
The constraint of band-width is derived from here.
However, we agree that we need add a text about network latency to R-7.
Please give a time to consider it.

> 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.

Before a roaming user establishes VPN with its home network,
the roaming user needs the right to connect to the network
that the user is present, and needs the right to cross over the FW.
In order to get these rights, the user is required to be identified
by the home KDC of the user.  There is a chicken-and-egg problem.

As you mentioned:

   the access control could be tuned perfectly to avoid a
   pre-authentication problem.

It means that the maintenance cost increases.

> 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?

Yes, it does.

> Editorial issues:
> -----------------
>
> Just to note that the RFC Editor will have to make many grammatical
> corrections to this draft.

Now, we are making effort to improve text.

Best regards and thank you very much for your valuable comments.

----
Shoichi Sakane

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Oct 2009 14:31:09 +1300

Hi Shoichi,

I am sorry, I have checked my email and can find no record of receiving your
message of 8th August. Perhaps I made a mistake, or perhaps the network made
a mistake!

Some comments in line...

> I attached my response below in case.

Yes, and I have worked on control systems at CERN where the scientists
wanted millisecond response times. The point is that there is a very wide
range of requirements, and I suppose that the IETF is trying to produce
general solutions. So 195 milliseconds may be reasonable for some
control applications and not for others. I would rather say that this
performance sets a limit, and the Kerberos solution *cannot* be used
for control systems with a tighter requirement.

> It relates both R-6 and R-7.

That may be true, but R-6 and R-7 are quite imprecise. If there
is a safety standard for power or power density, that is presumably
very precise and the actual requirement here is to meet that standard,
not to limit performance and bandwidth. Anyway, my point was not
that. It was that if the performance of Kerberos is too slow for
a given application, you can't use Kerberos.

> the latency will take more than 1 (s).

Exactly. You could describe that very precisely and make R-6 and R-7
much more useful.

Thanks
    Brian

> However, we agree that we need add a text about network latency to R-7.

Right. Other people might build control systems using
100Mb optical fibre systems. I think you can consider a whole
range of scenarios.

> It means that the maintenance cost increases.

Oh yes. Security costs money, and with roaming clients you may
not be able to bootstrap the security using only Kerberos.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Oct 2009 14:58:38 +1300

Hi Brian,

Regards,

Shoichi Sakane

Hi Brian,

   The travel

   Furthermore, to

As you mentioned:

Yes, it does.

----
Shoichi Sakane

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Oct 2009 14:59:45 +1300

Hi Shoichi,

Some comments in line...

Thanks
    Brian