Skip to main content

Last Call Review of draft-ietf-krb-wg-cross-problem-statement-

Request Review of draft-ietf-krb-wg-cross-problem-statement
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-20
Requested 2009-08-06
Authors Ken'ichi Kamada , Masahiro Ishiyama , Shoichi Sakane , Saber Zrelli
Draft last updated 2009-10-16
Completed reviews Secdir Last Call review of -?? by Steve Hanna
Assignment Reviewer Steve Hanna
State Completed
Review review-ietf-krb-wg-cross-problem-statement-secdir-lc-hanna-2009-10-16
Completed 2009-10-16
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.

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

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.

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.

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

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

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