IETF Logo Mail Archive

Re: [radext] #148: Review of dynamic-discovery by Jim Schaad

Sam Hartman <hartmans@painless-security.com> Wed, 27 February 2013 15:47 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762FB21F87FB for <radext@ietfa.amsl.com>; Wed, 27 Feb 2013 07:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599]
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 8grOvyrihHk5 for <radext@ietfa.amsl.com>; Wed, 27 Feb 2013 07:47:50 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0621F87F6 for <radext@ietf.org>; Wed, 27 Feb 2013 07:47:50 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 3A07F20348; Wed, 27 Feb 2013 10:42:55 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 32A84447B; Wed, 27 Feb 2013 10:47:49 -0500 (EST)
From: Sam Hartman <hartmans@painless-security.com>
To: Stefan Winter <stefan.winter@restena.lu>
References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <tslip5dn5jb.fsf@mit.edu> <512E2846.5090702@restena.lu>
Date: Wed, 27 Feb 2013 10:47:49 -0500
In-Reply-To: <512E2846.5090702@restena.lu> (Stefan Winter's message of "Wed, 27 Feb 2013 16:37:42 +0100")
Message-ID: <tsl621dn4gq.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: radext@ietf.org
Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2013 15:47:51 -0000

>>>>> "Stefan" == Stefan Winter <stefan.winter@restena.lu> writes:


I strongly favor the first.  I agree that it means that you need to have
a field in the cert that contains the realm's name.
There are fairly obvious ways this can be done in a SAN.
RFc 4985 is an example of how microsoft does this.
My concern with the dnssec approach is that while it's easy to specify,

I'm concerned that dnssec APIs are not widely available enough at
userspace levels outside the resolver that I'd have confidence
radsecproxy or freeradius or other radsec implementations could actually
implement dnssec validation in the radius proxy right now.

v2.23.0 | Report a Bug | By Email