Re: [secdir] Review of draft-ietf-isms-radius-usage-05

"Dave Nelson" <d.b.nelson@comcast.net> Wed, 06 May 2009 14:07 UTC

Return-Path: <d.b.nelson@comcast.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9E23A6ED0 for <secdir@core3.amsl.com>; Wed, 6 May 2009 07:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.141
X-Spam-Level:
X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg9RwaRBAEbO for <secdir@core3.amsl.com>; Wed, 6 May 2009 07:07:08 -0700 (PDT)
Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 68BC03A6CAC for <secdir@ietf.org>; Wed, 6 May 2009 07:06:13 -0700 (PDT)
Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id oChE1b0050vp7WLABE6hnf; Wed, 06 May 2009 14:06:41 +0000
Received: from NEWTON603 ([71.232.143.198]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id oE6e1b00P4H2mdz8RE6ffH; Wed, 06 May 2009 14:06:41 +0000
From: Dave Nelson <d.b.nelson@comcast.net>
To: 'Eric Rescorla' <ekr@networkresonance.com>
References: <20090505171306.8D40E50822@romeo.rtfm.com><28137ED4FBEF49BBB99BCFF561806165@NEWTON603> <20090506132244.614751995AF@kilo.networkresonance.com>
Date: Wed, 06 May 2009 10:06:54 -0400
Message-ID: <B212DC53F37C4B76B360BF7D05FAB847@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20090506132244.614751995AF@kilo.networkresonance.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcnOTTyGRS+ySOasTp29YJuMjPwZxwABdjbg
Cc: isms-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-isms-radius-usage-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 06 May 2009 14:07:08 -0000

Eric Rescorla writes...

> so, this is what concerns me: architecturally these are pretty
> different--and challenge-response may be different yet. That
> seems like it deserves some analysis.

Perhaps some additional analysis and explanation of the "don't gets" would
be useful.  The draft clearly focuses on the "gets" and on describing a
particular use case involving SSH and password-based authentication.  There
are other SSH authentication methods that cannot be integrated with RADIUS.
Since they cannot be used, we don't spend any time discussing them.

In an operator has an existing deployment using SSH and public key
authentication, they may be able to use the transport-based security
features of SNMPv3 defined in the companion ISMS WG drafts, but they won't
be able to use RADIUS as part of that solution.