Re: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted

Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Fri, 16 March 2007 19:50 UTC

Return-path: <isms-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSIRi-0005J8-Ii; Fri, 16 Mar 2007 15:50:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSIRh-0005J3-ST for isms@ietf.org; Fri, 16 Mar 2007 15:50:37 -0400
Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSIRg-0002lh-DW for isms@ietf.org; Fri, 16 Mar 2007 15:50:37 -0400
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6E6006DBFE; Fri, 16 Mar 2007 20:50:33 +0100 (CET)
Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28184-03; Fri, 16 Mar 2007 20:50:29 +0100 (CET)
Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id DE39B6DB2F; Fri, 16 Mar 2007 20:50:29 +0100 (CET)
Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id A7A681EAA4A; Fri, 16 Mar 2007 20:50:28 +0100 (CET)
Date: Fri, 16 Mar 2007 20:50:28 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Kaushik Narayan (kaushik)" <kaushik@cisco.com>
Subject: Re: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted
Message-ID: <20070316195028.GA3333@elstar.iuhb02.iu-bremen.de>
Mail-Followup-To: "Kaushik Narayan (kaushik)" <kaushik@cisco.com>, Eliot Lear <lear@cisco.com>, David Harrington <ietfdbh@comcast.net>, "David B. Nelson" <d.b.nelson@comcast.net>, isms@ietf.org
References: <20070316114102.GB991@elstar.iuhb02.iu-bremen.de> <618694EF0B657246A4D55A97E38274C3032CC8E7@xmb-sjc-22d.amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <618694EF0B657246A4D55A97E38274C3032CC8E7@xmb-sjc-22d.amer.cisco.com>
User-Agent: Mutt/1.5.14 (2007-02-12)
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@lists.ietf.org?subject=subscribe>
Errors-To: isms-bounces@lists.ietf.org

On Fri, Mar 16, 2007 at 11:53:44AM -0700, Kaushik Narayan (kaushik) wrote:
> Hi Juergen,
> 
> I think the question atleast in my mind is about not whether we would
> support local accounts but more about how to handle them in the context
> of the current RADIUS integration draft. As I suggested in my previous
> thread we have two options
> 
> 1. Leave to implementation specific approaches such as a Pluggable
> Authentication Module (PAM) framework.

As an implementor and system administrator, I like PAM because this is
used by many pieces of software...
 
> 2. Build the chaining of authentication methods into the security model,
> this would be required especially if we want build an access control
> model that is RADIUS specific.
> 
> It would be useful to get some discussion on this topic.

... and here I have no clue what this is supposed to be good for or
why things are needed in the security model; remember that access
control is done in the access control model (and all the security
processing including authentication exchanges happen in the secure
transport models, at least for SSH or TLS. Are you saying all the
work in the last months was heading in the wrong direction??

My understanding is that we have in principle two mappings:

a) authenticated principal -> securityName
b) securityName -> groupName

The first mapping a) happens in the security model (USM) or in the
transport mappings (TSM). The mapping b) happens in the access control
subsystem, that is VACM. We should not confuse these things (I think
section 3.3.2 in the RADIUS document is pretty unclear and potentially
confusing things, e.g. sentences such as

   The User-
   Based Security Method (USM) integrates with VACM, by mapping the user
   identity as defined in USM to access rights within VACM.

seem wrong since all USM provides is a securityName. Do you say this
is all wrong? Or is it about how to pass RADIUS attributes provided in
a) up to an access control mapping which does b) that you have in
mind?

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms