Re: [secdir] secdir review of draft-ietf-krb-wg-cross-problem-statement-04

[<[e-mail]>]

Stephan,

First of all, I apologize that my response is too late.
I was noticed that Tim requested me to make any response
to your message during the IETF meeting.  But, I haven't
seen your mail.  I found your mail at my spam mail box,
which my company's stupid mail system automatically dispatched.
I apologize again.

Most of your suggestion and correction is fixed in revision 05.
I attached it to this mail in case.

My response is in-line.

> I reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by
> the IESG. These comments were written primarily for the benefit
> of the security area directors.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> I apologize for submitting these comments late.
>
> This document describes issues that arise during Kerberos
> cross-realm operation, especially those related to two
> desired uses of cross-realm Kerberos at Shell.
>
> I am not a Kerberos expert although I am fairly familiar
> with the operation of the protocol. I know a good deal
> about multi-domain security since I did research in that
> area for several years at Sun (although mainly with PKI).
>
> Since this is a working group draft from the Kerberos WG,
> I assume that the document has passed WGLC and therefore
> represents WG consensus. However, I have some concerns.
>
> My main concern is that the document seems to be based
> mainly on the experiences of one customer. Surely there
> must be many more customers that have used cross-realm
> Kerberos over the years. If they have run into issues,
> those should be reflected in the document. If they have
> not had problems, then I would suggest that the issues
> are very limited in scope and probably no remedies are
> needed. We need to consider what's best for the Internet
> as a whole, not just one customer.

I agree with that we must consider to adopt technology
to a whole.  The reason why I describe two *examples* is
to help for readers who live in typical networks, not
in the industry control networks or building automation networks,
which consist of sensors, actuators or non-large bandwidth link.
The document just describes two types of networks.
I believe that the krb WG got a consensus that the requirements
in this document are enough to describe the requirements of
a whole of the Internet.  That is why the document was passed
to the WGLC.

> Here are my more detailed comments:
> 
> There is an extra period in the third paragraph of
> section 1 between "to" and "and".
> In section 2.1, "limited limit" should be "limited time"
> and "consists on" should be "consists of" (twice). Also
> "user access" should be "user accesses". And "anytime"
> should be "at all times".
>
> In section 3, after "sub systems", you need a period
> not a comma. The phrase "control center" should be "control
> centers". And "each is named" should be "each one called a".
> Also, "connected each other" should be "connected to each
> other". "In the both" should be "in both".

Most of your corrections are fixed in revision 05.
In the last correction from you, I changed to "In the both examples"
rather than "In both of the systems".  Do you agree with that ?
Whole text is below:

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

> In section 3, I suggest replacing this text:
> 
>    Because there is a requirement of the explosion-proof.  The
>    requirement restricts the amount of total energy in the device.
> 
> with this text:
> 
>    These adjustments restrict the amount of total energy in
>    the device, thereby reducing the risk of explosions.

Thank you.  I will merge it into new version.

> Also, I suggest clarification of this text:
> 
>    If it took
>    time for data to reach, they could not be associated.  The travel
>    time of data from the device to the other device is demanded within 1
>    second at least.
> 
> I think the authors may mean this:
> 
>    In order for one device to control another, the time required
>    for data to travel between the devices cannot be more than
>    one second.

I changed to the following in revision 05.

   If it takes time for data to travel
   through the network, normal operations can not be ensured.  The
   travel time of data from a device to another device in the both examples
   must be within 1 second at most.

> The requirements are not really demonstrated from the text above.
> For example, R-1 says:
> 
>    R-1  It is necessary to partition a management domain into some
>         domains.  Or it is necessary to delegate a management authority
>         to another independent management domain.
> 
> Maybe this is required due to time constraints (the less than one
> second rule), which lead to latency or performance issues if a
> single KDC is used. Maybe it is required due to a lack of trust
> between the entities responsible for managing the domains. The
> reason for this requirement is not explained so it is not
> compelling.

Agreed.  I changed R-1 in revision 05 like the following:

   R-1  For organizational reasons and scalability needs, a management
        domain typically must be partitioned into two or more sub-
        domains of management.  Therefore, any architecture and
        implementation solution to the Kerberos cross-realm problem must
        (i) support the case of cross-realm operations across multiple
        management domains and (ii) support delegation of management
        authority from one domain to another management domain.  This
        must be performed without any decrease in the security level or
        quality of those cross-realm operations and must not expose
        Kerberos entities to new types of attacks.

> Similarly, the rationale for R-2 is not described clearly.
> Couldn't two organizations manage a single Kerberos domain?

What I am saying here was that two different organizations managing
different Kerberos domains need to co-exist on the same network.
In revision 05, R-2 is changed into the following:

   R-2  Any architecture and implementation solution to the Kerberos
        cross-realm problem must support the co-existence of multiple
        independent management domains on the same network.
        Furthermore, it must allow organizations (corresponding to
        different management domains) to delegate the management of a
        part of or the totality of their system at any one time.

> The issue described in section 5.1 seems to be fundamental
> to the way that cross-realm operations are performed in
> Kerberos. If intermediary realms are involved then they need
> to be trusted.

The edge of the realm doesn't always know the relationship of other
realms on the path of the chain.  Some relationships in the path may
be weaker than the both ends are supposing.

> One could address this problem by not having
> intermediate realms (fully connecting all realms) but this
> would require many shared keys and therefore not scale well.
>
> The issue described in section 5.3 is valid but it has not
> been demonstrated that a direct trust model is needed.

The 5.3 specifies that there is an issue to reduce maintenance cost
of the direct trust model.

Regards,

===
Shoichi Sakane