Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-14

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 25 September 2012 17:13 UTC

Return-Path: <yaronf.ietf@gmail.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 2D9D121F87E5 for <secdir@ietfa.amsl.com>; Tue, 25 Sep 2012 10:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 wDaY5WXc2yf7 for <secdir@ietfa.amsl.com>; Tue, 25 Sep 2012 10:13:16 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA821F87A2 for <secdir@ietf.org>; Tue, 25 Sep 2012 10:13:15 -0700 (PDT)
Received: by eaak13 with SMTP id k13so882240eaa.31 for <secdir@ietf.org>; Tue, 25 Sep 2012 10:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K1aHdYalcl8bVZru0jVznNS6wZSMF7KnQJ364OW7d0c=; b=R9BXgTHJPp5N46XjQk63XMAVM9zfUUPqzC1uahtpWh/LuO/G2MYY4R6WTcXEiYy90N baKUYBEuEDgg+ewDgBJRt5waULs370J8A3+WJdidjemT22SahU/MY1OiLGbs1qvlLcs7 zopZpEEup9fUg7wWt3eMLvHhjPsiRhbY6M/mGFWLWnEflhCABmjnxaKv43ggRkj+XWJg Zk5OXB5fj/Aj/EfTW3sr7OUgOoJWMsbQPUXbuLwdtceC9s5YwY3L4B2wKSk+WSZ5hFHu +NirWW5X/A3SN8QKMHiT5A4Uk7kERCpjcogZNjdUj6GZYLWOhUNId96gOspKsLYNMegl 1E0Q==
Received: by 10.14.205.9 with SMTP id i9mr10095618eeo.21.1348593195348; Tue, 25 Sep 2012 10:13:15 -0700 (PDT)
Received: from [10.0.0.3] ([109.65.145.148]) by mx.google.com with ESMTPS id z25sm966805bkz.15.2012.09.25.10.13.13 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 10:13:14 -0700 (PDT)
Message-ID: <5061E628.2070708@gmail.com>
Date: Tue, 25 Sep 2012 19:13:12 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Sean Turner <turners@ieca.com>
References: <4FBFAE5F.8010305@gmail.com> <505F7514.8030908@gmail.com> <5061E4AE.2030701@ieca.com>
In-Reply-To: <5061E4AE.2030701@ieca.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org, 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:13:17 -0000

Nope, but that's per the process described in 
http://trac.tools.ietf.org/area/sec/trac/wiki/SecDirReview. The WG 
chairs are supposedly on the ".all" alias.

Thanks,
	Yaron

On 09/25/2012 07:06 PM, Sean Turner wrote:
> 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
>>