Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-14
Sean Turner <turners@ieca.com> Tue, 25 September 2012 17:06 UTC
Return-Path: <turners@ieca.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335221F0CCC for <secdir@ietfa.amsl.com>; Tue, 25 Sep 2012 10:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.168
X-Spam-Level:
X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf+S+XZ0GkO4 for <secdir@ietfa.amsl.com>; Tue, 25 Sep 2012 10:06:56 -0700 (PDT)
Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [70.85.130.30]) by ietfa.amsl.com (Postfix) with ESMTP id 81B521F0CC6 for <secdir@ietf.org>; Tue, 25 Sep 2012 10:06:56 -0700 (PDT)
Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 74D8720D30A8C; Tue, 25 Sep 2012 12:06:58 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 6734E20D30A6B for <secdir@ietf.org>; Tue, 25 Sep 2012 12:06:58 -0500 (CDT)
Received: from [108.18.174.220] (port=49854 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <turners@ieca.com>) id 1TGYb1-0004Ha-IH; Tue, 25 Sep 2012 12:06:55 -0500
Message-ID: <5061E4AE.2030701@ieca.com>
Date: Tue, 25 Sep 2012 13:06:54 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>, draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org
References: <4FBFAE5F.8010305@gmail.com> <505F7514.8030908@gmail.com>
In-Reply-To: <505F7514.8030908@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [108.18.174.220]:49854
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 25 Sep 2012 17:06:57 -0000
Did these ever make it to the krb-wg mailing list? spt On 9/23/12 4:46 PM, Yaron Sheffer wrote: > I have 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. > > This document adds a "referral" mechanism to Kerberos, where a client > (e.g. an end user) can use a generic enterprise-wide name, and have it > mapped to one that is specific to its correct realm; similarly, a > generic name can be used for a service, and the KDC will respond with > the correct principal name (and realm) for the service. > > Summary > > It is obvious that the analysis in the document's Security > Considerations is very thorough. Unfortunately I do not have the > Kerberos expertise (which apparently requires knowledge of specific > implementations' quirky behavior) to determine if all relevant cases > were covered. > > A cursory reading of the Considerations is quite discouraging: several > security mechanisms exist but they are not universally applied, some > implementations do not even follow the base protocol etc. I can only > hope that modern Kerberos implementations have improved in the 11 years > since this protocol first got started. > > Details > > - Sec. 4: "trusted name service" is not well defined. In fact it can be > construed as a euphemism for "enterprise-internal DNS", which is advised > against earlier. > - 4.1, last paragraph: is there no possibility to an "issuing realm" to > "publish" ownership of some resources to the consuming realm, and thus > effectively claim those resources? > - 6. In the authorization ASN.1 snippet, what is the value of MAX? > - 7, first paragraph: when the client sends the request to example.com, > shouldn't it ensure first that it has a pre-existing (pre-configured) > trust relationship with example.com? > - 10: the last paragraph ("Accordingly") is a bit too vague and probably > does not provide implementors with sufficient advice. > - 10: overall it is not clear if this section also applies to caching of > client referrals. > - 11: surprise! FAST (which was an optional SHOULD in Sec. 6) is now a > MUST! Even if it's just FAST negotiation that's a MUST, but FAST itself > (or an equivalent) is just a SHOULD, this still doesn't make a lot of > sense, and should at least be explained. > - 11: this section defines a new structure, but only explains a few of > its members. Please mention where all the other members are defined (RFC > 4120?). By the way, key-expiration is said to be deprecated in RFC 4120, > but what do I know. > - General: the document is said to update RFC 4120. A short section with > a summary of the specific updates would be very useful, so that > implementors can find out if they need to change anything, even if they > do NOT support the Referral functionality. (This is really a shortcoming > of the IETF notion of "RFC X updates RFC Y.") > - Appendix A: in "current implementation", do you mean post-Win 2003? > Please clarify. > - Appendix A: a reference to the MS documentation might be appropriate: > http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx > > Thanks, > Yaron > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >
- [secdir] SecDir review of draft-camarillo-rai-med… Yaron Sheffer
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- [secdir] SecDir review of draft-yegin-pana-encr-a… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-krb-wg-kerbe… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sean Turner
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sam Hartman
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Tom Yu
- [secdir] SecDir and AppsDir review of draft-ietf-… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] Use of StringPrep/Unicode (was Re: SecDi… Alexey Melnikov
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] SecDir review of draft-ietf-6renum-enter… Yaron Sheffer
- [secdir] SecDir repeat review of draft-ietf-6renu… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-rtgwg-ipfrr-… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-clue-telepre… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-v6ops-64shar… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš