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

t.p. <daedulus@btconnect.com> Sun, 10 June 2012 07:20 UTC

Return-Path: <daedulus@btconnect.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 6B01A21F8627; Sun, 10 Jun 2012 00:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4]
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 v2KO6Rc6vH-i; Sun, 10 Jun 2012 00:20:34 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8F57C21F8621; Sun, 10 Jun 2012 00:20:31 -0700 (PDT)
Received: from mail176-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Jun 2012 07:19:35 +0000
Received: from mail176-tx2 (localhost [127.0.0.1]) by mail176-tx2-R.bigfish.com (Postfix) with ESMTP id 5535B40132; Sun, 10 Jun 2012 07:19:35 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -27
X-BigFish: PS-27(zzbb2dI98dI9371I542M1432I1418I4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l)
Received: from mail176-tx2 (localhost.localdomain [127.0.0.1]) by mail176-tx2 (MessageSwitch) id 1339312773294535_4105; Sun, 10 Jun 2012 07:19:33 +0000 (UTC)
Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.240]) by mail176-tx2.bigfish.com (Postfix) with ESMTP id 44E7D100047; Sun, 10 Jun 2012 07:19:33 +0000 (UTC)
Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Jun 2012 07:19:31 +0000
Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.74.2; Sun, 10 Jun 2012 07:20:25 +0000
Message-ID: <005001cd46d9$10928de0$4001a8c0@gateway.2wire.net>
From: t.p. <daedulus@btconnect.com>
To: ssakane <ssakane@cisco.com>
References: <CBF8CDF4.6AEF%ssakane@cisco.com>
Date: Sun, 10 Jun 2012 08:17:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.240.133]
X-OriginatorOrg: btconnect.com
X-Mailman-Approved-At: Sun, 10 Jun 2012 16:04:44 -0700
Cc: draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, ietf <ietf@ietf.org>, secdir@ietf.org
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: Sun, 10 Jun 2012 07:20:36 -0000

---- Original Message -----
From: "ssakane" <ssakane@cisco.com>;
To: "t.p." <daedulus@btconnect.com>;
Cc: <draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org>;;
<secdir@ietf.org>;; "ietf" <ietf@ietf.org>;
Sent: Saturday, June 09, 2012 1:55 AM
> Removing the section 4.1 to an Appendix is nicer idea rather than just
> deleting it.

Yes, but for me it is definitely second best.

Arguably, following the steps in s 4.1 is necessary for
interoperability.

If DNS and DHCP produce the same KDC information, who cares what
procedure is followed?  It is only when they produce different results
that the procedure matters.

The dictum is that DNS information is preferred to DHCP information, but
as the procedure shows, it is not quite that simple.  It specifies that
DNS is accessed via DHCP, ie DNS is only accessed if DHCP provides
information about it.  Without this guidance, an implementer might
assume that eg preconfigured DNS information should be used to access
DNS for KDC information rather than first asking DHCP for what it knows,
in which case such an implementer would follow a different path to,
potentially, a different KDC.  So the client uses one KDC, the
application server a different KDC; result, protocol failure.

So you could see s 4.1 as necessary for the protocol to work.

And again, as I said before, s 4.1 says that DNS SHOULD be used, while
the Security Considerations say DHCP SHOULD be secured so given secure
DHCP and insecure DNS giving different results, which SHOULD wins?

Tom Petch
>
> Shoichi
>
>
> On 6/8/12 11:24 PM, "t.p." <daedulus@btconnect.com>; wrote:
>
> > ----- Original Message -----
> > From: "ssakane" <ssakane@cisco.com>;
> > To: "t.p." <daedulus@btconnect.com>;
> > Cc: <draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org>;;
> > <secdir@ietf.org>;; "ietf" <ietf@ietf.org>;
> > Sent: Friday, June 08, 2012 2:29 PM
> >> Hi Tom,
> >>
> >> Some reviewers suggested me to just remove the figure and its
> > description in
> >> 4.1 because it has ambiguity.  I think it would be better to leave
the
> > 1st
> >> paragraph in section 4.1, and I should remove the rest.  What do
you
> > think
> >> about this idea ?
> >
> > I would leave it in.
> >
> > The first paragraph on its own I would think underspecified and the
rest
> > of the section does cover a number of issues, issues that only
occurred
> > to me when I read the section carefully.  As I said in my last post,
I
> > then found I had further issues - how long to wait, should a secure
DHCP
> > trump an insecure DNS? - which may be worth exploring in addition.
> >
> > I do think that this kind of pseudocode helps a lot of developers to
> > understand the issues and would want a good reason to remove it; at
the
> > same time, others see it as an impurity that has no part in a
Standards
> > Track RFC.  One option would be to remove it to an Appendix which
> > implicitly makes it Informative and not Normative so it is there for
> > those who would benefit from it but will not upset those who
consider it
> > out of place.  But I would bounce this off the krb list to see what
> > reaction you get.
> >
> > Tom Petch
> >
> >> Thanks,
> >> Shoichi
> >>
> >> On 6/8/12 7:37 PM, "t.p." <daedulus@btconnect.com>; wrote:
> >>
> >>> Just to make public what I have hinted at privately, I think that
> > steps
> >>> in section 4.1 may be somewhat underspecified.
> >>>
> >>> They give the logic a client, one which supports both DHCP and
DNS,
> >>> should
> >>> follow in order to find a KDC, with DNS information being
preferred.
> >>> One scenario outlined in section 1 is of a user having entered
> > userid
> >>> and
> >>> passphrase and waiting to be authenticated.  The steps imply a
> > number of
> >>> timeouts in succession without specifying what balance to take of
> > how
> >>> long
> >>> to wait for a server to respond versus how long to keep the user
> >>> waiting.
> >>> I would find it difficult to know what balance to strike without
> >>> guidance.
> >>>
> >>> A related issue is that section 4.1 prefers DNS to DHCP for
Kerberos
> >>> information but the Security Considerations stress the weakness of
> >>> DHCP and recommend authenticating DHCP.  What if DHCP is secure
> >>> and DNS is not?  Should DNS still be preferred?
> >>>
> >>> Tom Petch
> >>>
> >>> ----- Original Message -----
> >>> From: "Jeffrey Hutzelman" <jhutz@cmu.edu>;
> >>> To: "Samuel Weiler" <weiler+secdir@watson.org>;
> >>> Cc: <draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org>;;
> >>> <secdir@ietf.org>;; <ietf@ietf.org>;; <jhutz@cmu.edu>;
> >>> Sent: Thursday, May 24, 2012 6:50 PM
> >>> Subject: Re: [secdir] secdir review of
> >>> draft-sakane-dhc-dhcpv6-kdc-option
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>