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
>