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

Eric Rescorla <ekr@networkresonance.com> Tue, 05 May 2009 17:08 UTC

Return-Path: <ekr@networkresonance.com>
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 85C323A692F; Tue, 5 May 2009 10:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level:
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 aruFlzNBwGrw; Tue, 5 May 2009 10:08:30 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 1449F3A6899; Tue, 5 May 2009 10:08:30 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8D40E50822; Tue, 5 May 2009 10:13:06 -0700 (PDT)
Date: Tue, 05 May 2009 10:13:06 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: secdir@ietf.org, iesg@ietf.org
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20090505171306.8D40E50822@romeo.rtfm.com>
Cc: isms-chairs@tools.ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org
Subject: [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: Tue, 05 May 2009 17:08:31 -0000

$Id: draft-ietf-isms-radius-usage-05-rev.txt,v 1.1 2009/05/05 16:12:55 ekr Exp $

This document is about the use of RADIUS servers with SNMP "transport
models" (security protocols such as SSH used with SNMP). As far as I
can tell, the idea is to explain how to outsource some of the
authorization decisions to RADIUS.

I found this document extremely difficult to read. I realize that
the intended audience is for people with a lot of RADIUS and
SNMP experience, but despite some familiarity with them, I had
to work fairly hard to figure out what it was trying to say
and I'm still not sure. This document would benefit very greatly
from a diagram explaining how the authors think things are supposed
to work.

My big question is how the user authentication decisions are
expected to be split between (e.g., SSH), and RADIUS. For
example:

- If the user has a password, who checks it the RADIUS server
  or the NAS? RADIUS certainly can do this.
- If the user is authenticating with SSH pubkey auth, who
  checks that? 

These seem like important architectural issues but I'm not getting
them out of the document, and they should in particular
be in the security considerations.

IMO, this document would benefit from a rewrite that makes it a
lot clearer to someone not enmeshed in the WG.



S 2.
I don't understand what the difference is between service authorization
and access control in this context.

S 2.3.
I don't get the SHOULDs here. If you're defining how code points are
set, why are these optional?