[secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-14
Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 23 September 2012 20:46 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 3684621F851A; Sun, 23 Sep 2012 13:46: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 TbnbluyKNrdG; Sun, 23 Sep 2012 13:46:16 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7C21F8518; Sun, 23 Sep 2012 13:46:15 -0700 (PDT)
Received: by bkty12 with SMTP id y12so2525986bkt.31 for <multiple recipients>; Sun, 23 Sep 2012 13:46: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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=I3+BTBiJZr5aoWl+1VNWAuYU5/KvhXEwaRcVqS5x2dU=; b=c1JZhl+34zgoAvPLzJc5fqfQUgsIH7VhANTkS91xjl/B+S2i4h2XBr6crbftQG7I0D P5f5rWyNNMd+E4PUhBj8aBmez4fZVk4z1edymFQCngUn87gq2o9AgcY4kVqzDouaIrLy BanCTmHmHRVbsYknsh6oSqTuHVkPf1tZHKhWLvyUtnolO0jRUIxDqI30+P4IkiTwrSPo fwNjnQ8sWs6QavAK2NhI7NR5lrKQF103TEajXmVLElaYhNutCXSj3rSCLtg/jdCcdB4j xEjqNv9Y3hE03GEOjYaoGP6Hf8CQFe0vIW3r+tLtZEAd20kHW3Yq3q3xRLnn03yHBQ5q xF2Q==
Received: by 10.204.130.11 with SMTP id q11mr4036831bks.88.1348433175079; Sun, 23 Sep 2012 13:46:15 -0700 (PDT)
Received: from [10.0.0.3] ([109.65.145.148]) by mx.google.com with ESMTPS id j24sm1946245bkv.0.2012.09.23.13.46.13 (version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 13:46:14 -0700 (PDT)
Message-ID: <505F7514.8030908@gmail.com>
Date: Sun, 23 Sep 2012 22:46: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: secdir@ietf.org, draft-ietf-krb-wg-kerberos-referrals.all@tools.ietf.org, iesg@ietf.org
References: <4FBFAE5F.8010305@gmail.com>
In-Reply-To: <4FBFAE5F.8010305@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [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: Sun, 23 Sep 2012 20:46:17 -0000
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] 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š