secdir review of draft-ietf-krb-wg-naming-04.txt

"Stephen Hanna" <shanna@juniper.net> Fri, 07 March 2008 07:55 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C4C3A6E35; Thu, 6 Mar 2008 23:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.3
X-Spam-Level:
X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 Ke3gfqynIGZw; Thu, 6 Mar 2008 23:55:22 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3255D28C9E0; Thu, 6 Mar 2008 23:53:34 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A0E28CA0B for <ietf@core3.amsl.com>; Thu, 6 Mar 2008 23:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 46h322hdwAO5 for <ietf@core3.amsl.com>; Thu, 6 Mar 2008 23:53:31 -0800 (PST)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 722BC3A6920 for <ietf@ietf.org>; Thu, 6 Mar 2008 23:53:04 -0800 (PST)
Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 06 Mar 2008 23:52:27 PST
Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 23:52:33 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: secdir review of draft-ietf-krb-wg-naming-04.txt
Date: Fri, 07 Mar 2008 02:41:37 -0500
Message-ID: <A6398B0DB62A474C82F61554EE93728704E63207@proton.jnpr.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: secdir review of draft-ietf-krb-wg-naming-04.txt
Thread-Index: Acheui/nbFF3B4ujT2WOwxcouOehPADAk3+gBCahgZADciSbAA==
From: Stephen Hanna <shanna@juniper.net>
To: lzhu@microsoft.com, Jeffrey Hutzelman <jhutz@cmu.edu>
X-OriginalArrivalTime: 07 Mar 2008 07:52:33.0160 (UTC) FILETIME=[33872080:01C88028]
Cc: secdir@mit.edu, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG. Document editors should treat these comments just like any
other comments.

This document defines conventions for well-known Kerberos principal
names and well-known Kerberos realm names.

While the document seems to be pretty thorough, the Security
Considerations section is too brief. This is especially true
for a document whose main purpose is to modify a criticial
security protocol such as Kerberos. The Security Considerations
section could provide an example of how unintended access
could be granted if an authentication with an unsupported
well-known name is allowed to succeed. More important, it
should explain why it is permissible for the TGS to allow
an authentication to succeed even if the client and/or
server principal name is an unsupported well-known name.
The reasoning for allowing this is not clear to me but
perhaps it is that the TGS can assume that the AS must
have supported the client name or it would have failed the
authentication. I'm not sure how this helps to address the
case where the server name is an unsupported well-known
name. I would like to see that explained, preferably
in the document.

I also noticed a few typos:

At the end of section 1, "remedy these" should be "remedy these
issues" or something similar. Otherwise, it's not clear what is
to be remedied.

In the last paragraph of section 3.1, the first word "is" in the
phrase "is a well-known principal name is used" should be "if".
Similarly, in the second paragraph of section 3.2, the first word
"is" should be "if" in the phrase "is a well-known realm name is used".

Other than these issues, the document seems to be OK.

Thanks,

Steve
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf