Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option

Masahiro =Rhythm Drive= Ishiyama <masahiro@isl.rdc.toshiba.co.jp> Mon, 02 July 2012 04:59 UTC

Return-Path: <masahiro@isl.rdc.toshiba.co.jp>
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 C25E311E8140 for <secdir@ietfa.amsl.com>; Sun, 1 Jul 2012 21:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level:
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 s8RXFpB6Dxk8 for <secdir@ietfa.amsl.com>; Sun, 1 Jul 2012 21:59:21 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 02AA411E8158 for <secdir@ietf.org>; Sun, 1 Jul 2012 21:59:15 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q624xJkD002606 for <secdir@ietf.org>; Mon, 2 Jul 2012 13:59:19 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id q624xJVV023254 for secdir@ietf.org; Mon, 2 Jul 2012 13:59:19 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id PAA23251; Mon, 2 Jul 2012 13:59:19 +0900
Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q624xIrR017494 for <secdir@ietf.org>; Mon, 2 Jul 2012 13:59:18 +0900 (JST)
Received: from snazzy.isl.rdc.toshiba.co.jp by toshiba.co.jp id q624xIfc014258; Mon, 2 Jul 2012 13:59:18 +0900 (JST)
Received: from maltesein.wide.toshiba.co.jp (unknown [202.249.10.100]) by snazzy.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id 2290E3FE67 for <secdir@ietf.org>; Mon, 2 Jul 2012 22:15:29 +0900 (JST)
Received: from malteseout.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by maltesein.wide.toshiba.co.jp (8.13.8/8.9.1) with ESMTP id q624xIYb011507 for <secdir@ietf.org>; Mon, 2 Jul 2012 13:59:18 +0900
Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by malteseout.wide.toshiba.co.jp (8.13.8/8.9.1) with ESMTP id q624xI7L031140 for <secdir@ietf.org>; Mon, 2 Jul 2012 13:59:18 +0900
Received: from localhost (localhost [127.0.0.1]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 5C3432E3F3 for <secdir@ietf.org>; Mon, 2 Jul 2012 13:59:18 +0900 (JST)
Received: from tsbgw.wide.toshiba.co.jp ([127.0.0.1]) by localhost (tsbgw.wide.toshiba.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lit8vJL7b+M for <secdir@ietf.org>; Mon, 2 Jul 2012 13:59:18 +0900 (JST)
Received: from grayswandir.isl.rdc.toshiba.co.jp (localhost [127.0.0.1]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 39A6F2E3F2 for <secdir@ietf.org>; Mon, 2 Jul 2012 13:59:18 +0900 (JST)
Date: Mon, 02 Jul 2012 13:59:16 +0900
Message-ID: <yd94npqbvx7.wl@grayswandir.isl.rdc.toshiba.co.jp>
From: Masahiro =Rhythm Drive= Ishiyama <masahiro@isl.rdc.toshiba.co.jp>
To: secdir@ietf.org
In-Reply-To: <tsl7gus37hu.fsf@mit.edu>
References: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org> <1337881837.3279.45.camel@destiny.pc.cs.cmu.edu> <004a01cd4562$b7b338e0$4001a8c0@gateway.2wire.net> <tsl7gus37hu.fsf@mit.edu>
User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) LIMIT/1.14.10 (Furuichi) APEL/10.7 Emacs/22.3 (i386-apple-darwin10.2.0) MULE/5.0 (SAKAKI)
Organization: Toshiba Corp. R&D Center.
Sender: Masahiro =Rhythm Drive= Ishiyama <masahiro@isl.rdc.toshiba.co.jp>
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 20100215(IM150)
Lines: 37
X-Mailman-Approved-At: Thu, 05 Jul 2012 08:05:11 -0700
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: Mon, 02 Jul 2012 04:59:22 -0000

	At first I thought that it might be good to leave section 4.1,
	but now I changed my mind. I think the order of the preference
	might depend on the running environment: some people prefer
	"secured" one, some people prefer DNS...  So I'd like to make
	the order configurable and move section 4.1 to appendix, as a
	hint for implementation.

masahiro

>>>>> On Wed, 27 Jun 2012 15:00:29 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:
 > 
>>>>> "t" == t p <daedulus@btconnect.com> writes:
t> Just to make public what I have hinted at privately, I think that steps
t> in section 4.1 may be somewhat underspecified.
 > 
t> A related issue is that section 4.1 prefers DNS to DHCP for Kerberos
t> information but the Security Considerations stress the weakness of
t> DHCP and recommend authenticating DHCP.  What if DHCP is secure
t> and DNS is not?  Should DNS still be preferred?
 > 
 > Yes probably.
 > DNS has been and will continue to be the dominant way to discover KDCs.
 > I see this as a specialized DHCP option for certain deployments, not
 > something you'll see in the enterprise for desktops or laptops as an
 > example.
 > I mean some people may deploy it, but I suspect that you won't see it in
 > most situations where DNS works well today.
 > So, basically in all cases, including preconfigured DNS servers, I'd
 > expect DNS to be preferred.
 > 
 > Note that choosing the right KDC does impact availability--if you have
 > the wrong KDC it won't work.
 > In general though, choosing the wrong KDC does not compromise
 > authentication. It's a bit more complex than that, but KDC location has
 > not generally been considered  security sensitive.
 >