Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Jeffrey Hutzelman <jhutz@cmu.edu> Thu, 24 May 2012 17:50 UTC
Return-Path: <jhutz@cmu.edu>
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 3AA7621F8595; Thu, 24 May 2012 10:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IiD-2Ivl0cG; Thu, 24 May 2012 10:50:40 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9FC21F847D; Thu, 24 May 2012 10:50:40 -0700 (PDT)
Received: from [128.2.210.96] (destiny.pc.cs.cmu.edu [128.2.210.96]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q4OHoc3l014311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2012 13:50:38 -0400 (EDT)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Samuel Weiler <weiler+secdir@watson.org>
In-Reply-To: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org>
References: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 24 May 2012 13:50:37 -0400
Message-ID: <1337881837.3279.45.camel@destiny.pc.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, secdir@ietf.org, ietf@ietf.org, jhutz@cmu.edu
Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
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: Thu, 24 May 2012 17:50:41 -0000
On Wed, 2012-05-23 at 19:12 -0400, Samuel Weiler wrote: > With that said, there are some things that need clarification, and the > doc sorely needs an editorial pass. As-is, the doc is not ready for > publication. I will be happy to review the doc again once it's been > thoroughly edited. It does need copy-editing. As far as I know, the IETF does not have a team of volunteer copy-editors, and multiple attempts to get help from within the working group have met with only limited success (most notably in the form of help from Stephen, who did quite a bit of work on this before starting on his AD review). If anyone wants to volunteer to spend some time on helping to clean up this document, let me know. Otherwise, I think our only options are either to ask the paid editors at the RFC production center to take a stab, or block an otherwise completed document on cycles that may never appear. > Section 7 uses the term "TGT" without expansion. In the Kerberos > world I can't imagine someone not knowing what this is, but it's not > clear to the layman. It probably needs to be expanded. It does; I somehow missed that in my review. > The algorithm in section 4.1 needs work. The obvious thing is to read > it linearly. Doing that, one would prefer DHCP over DNS SVR info (per > step 2), which is not what step 6 and the graphic say. The algorithm is fine, but the description requires careful reading. Step 2 kicks in only if you get a DHCP response containing Kerberos configuration but no nameservers. > Saying "no answer from the DNS server" is probably not the desired > semantic. There are only two branches here. Either you get a response containing one or more relevant SRV RRs, or you don't. The latter is phrased as "no answer from the DNS server", but is meant to also include errors and empty responses. A suggestion for how to word this better would be welcome. > In 3.4, the option-len field is ambiguous. It says "24-octet + the > length of the realm-name field in octets." But it looks to me like > this option is 27 octets + length of realm name. Perhaps it would be > better to just count the length of the realm name? Yes, the description is wrong; the correct length is _23_ plus the length of the realm. The 16-bit option code and length are part of the DHCPv6 protocol; unless I'm misremembering, the length is the length of the option payload (that is, excluding the two header fields). Thanks for taking the time to review this. -- Jeff
- [secdir] secdir review of draft-sakane-dhc-dhcpv6… Samuel Weiler
- Re: [secdir] secdir review of draft-sakane-dhc-dh… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-sakane-dhc-dh… t.p.
- Re: [secdir] secdir review of draft-sakane-dhc-dh… tglassey
- Re: [secdir] secdir review of draft-sakane-dhc-dh… t.p.
- Re: [secdir] secdir review of draft-sakane-dhc-dh… t.p.
- Re: [secdir] secdir review of draft-sakane-dhc-dh… Sam Hartman
- Re: [secdir] secdir review of draft-sakane-dhc-dh… Masahiro =Rhythm Drive= Ishiyama
- Re: [secdir] secdir review of draft-sakane-dhc-dh… Jeffrey Hutzelman
- Re: [secdir] secdir review of draft-sakane-dhc-dh… Masahiro =Rhythm Drive= Ishiyama