RE: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04.txt
Larry Zhu <lzhu@windows.microsoft.com> Sun, 27 July 2008 14:00 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBE93A6979; Sun, 27 Jul 2008 07:00:36 -0700 (PDT)
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 58E533A697C for <ietf@core3.amsl.com>; Sun, 27 Jul 2008 07:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.599
X-Spam-Level:
X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 WQMZZ+pV1HbU for <ietf@core3.amsl.com>; Sun, 27 Jul 2008 07:00:29 -0700 (PDT)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D01503A6918 for <ietf@ietf.org>; Sun, 27 Jul 2008 07:00:29 -0700 (PDT)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) 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 07:00:36 -0700
Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) with Microsoft SMTP Server id 8.1.240.5; Sun, 27 Jul 2008 07:00:36 -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 07:00:36 -0700
From: Larry Zhu <lzhu@windows.microsoft.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, "ietf@ietf.org" <ietf@ietf.org>
Date: Sun, 27 Jul 2008 07:00:35 -0700
Subject: RE: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04.txt
Thread-Topic: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04.txt
Thread-Index: AciKmr4jGbRpWLWsTS+GXvTD4KJamhlVjuJg
Message-ID: <AB1E5627D2489D45BD01B84BD5B90046061C497D5C@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
References: <tsld4ppmojl.fsf@mit.edu>
In-Reply-To: <tsld4ppmojl.fsf@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "ietf-krb-wg@anl.gov" <ietf-krb-wg@anl.gov>
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
The proposed text looks good. --larry -----Original Message----- From: ietf-krb-wg-bounces@lists.anl.gov [mailto:ietf-krb-wg-bounces@lists.anl.gov] On Behalf Of Sam Hartman Sent: Thursday, March 20, 2008 7:57 AM To: ietf@ietf.org Cc: ietf-krb-wg@anl.gov Subject: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04.txt I think there is a minor ambiguity in the naming draft: >Consequently, unless otherwise > specified, a well-known Kerberos realm name MUST NOT be present in transited encoding Who enforces this requirement? That's an important question because it controls who needs to support the specific well known realm in order for it to be used. In general using passive voice for such requirements is a really bad idea. I'd recommend something like: Unless otherwise specified, parties checking the transited realm path MUST reject a transited realm path that includes a well known realm. In the case of KDCs checking the transited realm path, this means that the transited policy checked flag MUST NOT be set in the resulting ticket. In particular, that means that a KDC that is not checking transited realm paths is not encouraged to reject a request simply because the realm in an unknown well known realm. --Sam _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg@lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf