Re: [Ietf-krb-wg] secdir review of draft-ietf-krb-wg-naming-04.txt
Larry Zhu <lzhu@windows.microsoft.com> Sun, 27 July 2008 13:21 UTC
Return-Path: <ietf-krb-wg-bounces@lists.anl.gov>
X-Original-To: ietfarch-krb-wg-archive@core3.amsl.com
Delivered-To: ietfarch-krb-wg-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D2328C0FA for <ietfarch-krb-wg-archive@core3.amsl.com>; Sun, 27 Jul 2008 06:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, 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 08Tg9YvCdQ7G for <ietfarch-krb-wg-archive@core3.amsl.com>; Sun, 27 Jul 2008 06:21:18 -0700 (PDT)
Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by core3.amsl.com (Postfix) with ESMTP id 3FF733A681A for <krb-wg-archive@lists.ietf.org>; Sun, 27 Jul 2008 06:21:18 -0700 (PDT)
Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 6B13044; Sun, 27 Jul 2008 08:21:24 -0500 (CDT)
Received: from lists.anl.gov (katydid.it.anl.gov [146.137.96.32]) by mailhost.anl.gov (Postfix) with ESMTP id EDB8443; Sun, 27 Jul 2008 08:21:20 -0500 (CDT)
Received: from katydid.it.anl.gov (localhost [127.0.0.1]) by lists.anl.gov (Postfix) with ESMTP id 9FDF480D96; Sun, 27 Jul 2008 08:21:20 -0500 (CDT)
X-Original-To: ietf-krb-wg@lists.anl.gov
Delivered-To: ietf-krb-wg@lists.anl.gov
Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by lists.anl.gov (Postfix) with ESMTP id 1A0AE80D8C for <ietf-krb-wg@lists.anl.gov>; Sun, 27 Jul 2008 08:21:19 -0500 (CDT)
Received: by mailhost.anl.gov (Postfix) id 0BBF921; Sun, 27 Jul 2008 08:21:19 -0500 (CDT)
Delivered-To: ietf-krb-wg@anl.gov
Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id D620728 for <ietf-krb-wg@anl.gov>; Sun, 27 Jul 2008 08:21:18 -0500 (CDT)
Received: from mailrelay.anl.gov (mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix) with ESMTP id C38E521 for <ietf-krb-wg@anl.gov>; Sun, 27 Jul 2008 08:21:18 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by localhost.it.anl.gov (Postfix) with ESMTP id A960F7CC05C; Sun, 27 Jul 2008 08:21:18 -0500 (CDT)
Received: from mailrelay.anl.gov ([127.0.0.1]) by localhost (mailrelay.anl.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07291-03; Sun, 27 Jul 2008 08:21:18 -0500 (CDT)
Received: from mailgateway.anl.gov (mailgateway.anl.gov [130.202.101.28]) by mailrelay2.anl.gov (Postfix) with ESMTP id 852D97CC059 for <ietf-krb-wg@anl.gov>; Sun, 27 Jul 2008 08:21:18 -0500 (CDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMAAKMSjEiDa3PXlGdsb2JhbACLGYc2AQEBAQkDCgcRBppC
X-IronPort-AV: E=Sophos;i="4.31,259,1215406800"; d="scan'208";a="17578644"
Received: from mailb.microsoft.com (HELO smtp.microsoft.com) ([131.107.115.215]) by mailgateway.anl.gov with ESMTP; 27 Jul 2008 08:21:17 -0500
Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.251.2; Sun, 27 Jul 2008 06:21:17 -0700
Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) with Microsoft SMTP Server id 8.1.240.5; Sun, 27 Jul 2008 06:21:17 -0700
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Sun, 27 Jul 2008 06:21:17 -0700
From: Larry Zhu <lzhu@windows.microsoft.com>
To: Stephen Hanna <shanna@juniper.net>, "ietf-krb-wg@anl.gov" <ietf-krb-wg@anl.gov>, Jeffrey Hutzelman <jhutz@cmu.edu>
Date: Sun, 27 Jul 2008 06:21:15 -0700
Thread-Topic: secdir review of draft-ietf-krb-wg-naming-04.txt
Thread-Index: Acheui/nbFF3B4ujT2WOwxcouOehPADAk3+gBCahgZADciSbAADj+bxJGw7lVdA=
Message-ID: <AB1E5627D2489D45BD01B84BD5B90046061C497D5B@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
References: <A6398B0DB62A474C82F61554EE93728704E63207@proton.jnpr.net> <E30895F8BA39B6439F5F1AAA1DBBFB52473A1EC7FF@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <E30895F8BA39B6439F5F1AAA1DBBFB52473A1EC7FF@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-Virus-Scanned: Debian amavisd-new at frigga.it.anl.gov
Cc: "secdir@mit.edu" <secdir@mit.edu>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Ietf-krb-wg] secdir review of draft-ietf-krb-wg-naming-04.txt
X-BeenThere: ietf-krb-wg@lists.anl.gov
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is a list for the IETF Kerberos Working Group. {WORLDPUB, EXTERNAL}" <ietf-krb-wg.lists.anl.gov>
List-Unsubscribe: <https://lists.anl.gov/mailman/listinfo/ietf-krb-wg>, <mailto:ietf-krb-wg-request@lists.anl.gov?subject=unsubscribe>
List-Archive: <https://lists.anl.gov/pipermail/ietf-krb-wg>
List-Post: <mailto:ietf-krb-wg@lists.anl.gov>
List-Help: <mailto:ietf-krb-wg-request@lists.anl.gov?subject=help>
List-Subscribe: <https://lists.anl.gov/mailman/listinfo/ietf-krb-wg>, <mailto:ietf-krb-wg-request@lists.anl.gov?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-krb-wg-bounces@lists.anl.gov
Errors-To: ietf-krb-wg-bounces@lists.anl.gov
Hi Stephen, thanks for the review comments. -05 has fixed the typoes and it provides an example using the anonymous well-known names as requested. Here is the relevant text in -05. It is possible to have name collision with well-known names because Kerberos as defined in [RFC4120] does not reserve names that have special meanings, consequently care MUST be taken to avoid accidental reuse of names. If a well-known name is not supported, authentication MUST fail as specified in Section 3. Otherwise, access can be granted unintentionally, resulting in a security weakness. Consider for example, a KDC that supports this specification but not the anonymous authentication described in [ANON]. Assume further that the KDC allows a principal to be created named identically to the anonymous principal. If that principal were created and given access to resources, then anonymous users might inadvertently gain access to those resources if the KDC supports anonymous authentication at some future time. Similar issues may occur with other well-known names. By requiring KDCs reject authentication with unknown well-known names, we minimize these concerns. Let me know if you have further comments. --larry ________________________________________ From: Stephen Hanna [shanna@juniper.net] Sent: Thursday, March 06, 2008 11:41 PM To: Larry Zhu; Jeffrey Hutzelman Cc: ietf@ietf.org; secdir@mit.edu Subject: secdir review of draft-ietf-krb-wg-naming-04.txt 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-krb-wg mailing list ietf-krb-wg@lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg@lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg