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

Stephen Hanna <shanna@juniper.net> Fri, 09 October 2009 19:37 UTC

Return-Path: <shanna@juniper.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C07B28C12F; Fri, 9 Oct 2009 12:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level:
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkX08BO0RZQQ; Fri, 9 Oct 2009 12:37:35 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 5D6233A696B; Fri, 9 Oct 2009 12:37:35 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSs+RZZ0IdsnG/SrlgnZxKad28vhypxg4@postini.com; Fri, 09 Oct 2009 12:39:21 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 9 Oct 2009 12:37:24 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 9 Oct 2009 15:37:23 -0400
From: Stephen Hanna <shanna@juniper.net>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-krb-wg-cross-problem-statement@tools.ietf.org" <draft-ietf-krb-wg-cross-problem-statement@tools.ietf.org>
Date: Fri, 9 Oct 2009 15:37:22 -0400
Thread-Topic: secdir review of draft-ietf-krb-wg-cross-problem-statement-04
Thread-Index: AcpI+qkS8jP8gG3tQPe3IferT5xYbQ==
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AE8FF3787D27@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] secdir review of draft-ietf-krb-wg-cross-problem-statement-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2009 19:37:36 -0000

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

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.

Thanks,

Steve