IETF Logo Mail Archive

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

"Kaushik Narayan \(kaushik\)" <kaushik@cisco.com> Fri, 16 March 2007 18:54 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 1HSHZE-00019g-NP; Fri, 16 Mar 2007 14:54:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHZD-00019W-Hs for isms@ietf.org; Fri, 16 Mar 2007 14:54:19 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSHZ4-0002IB-Fl for isms@ietf.org; Fri, 16 Mar 2007 14:54:19 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2007 11:54:10 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2GIs9N1027542; Fri, 16 Mar 2007 11:54:09 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2GIrfML003950; Fri, 16 Mar 2007 18:53:57 GMT
Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 11:53:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted
Date: Fri, 16 Mar 2007 11:53:44 -0700
Message-ID: <618694EF0B657246A4D55A97E38274C3032CC8E7@xmb-sjc-22d.amer.cisco.com>
In-Reply-To: <20070316114102.GB991@elstar.iuhb02.iu-bremen.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted
Thread-Index: AcdnwAA11bS+xE1kT1ODf42Tqspk5QAO3L3Q
From: "Kaushik Narayan (kaushik)" <kaushik@cisco.com>
To: j.schoenwaelder@iu-bremen.de, Eliot Lear <lear@cisco.com>
X-OriginalArrivalTime: 16 Mar 2007 18:53:49.0386 (UTC) FILETIME=[6EEE02A0:01C767FC]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2172; t=1174071249; x=1174935249; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20<kaushik@cisco.com> |Subject:=20RE=3A=20[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms- sshsm-radius-01.txt)submitted |Sender:=20; bh=m/3BnHvlrUZuyIGQtnG+j6YorNa9rNUS5Cyth2ANb5M=; b=OIuIYi/rr/5iSnqVrtdPO8YR78ERZ+lhyyJuQSMA/NkpqFWPlMBroYBnnE952jr+udpueIIi iB3dYsaw+5vYyj47tOo1MgWSBp5JHV1zyepWeSt50b5U7xHTb0uneoXRfXL/yZtFBUXTP4JlN4 hh9pFp6cND8TTB2bPtbOn59AE=;
Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

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.

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.

regards,
  kaushik!

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] 
Sent: Friday, March 16, 2007 4:41 AM
To: Eliot Lear
Cc: Kaushik Narayan (kaushik); David Harrington; David B. Nelson;
isms@ietf.org
Subject: Re:
[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt
)submitted

On Fri, Mar 16, 2007 at 12:26:08PM +0100, Eliot Lear wrote:
 
> And then Dave Harrington responded:
> 
> >So far, I have not seen any proposals, either written or just 
> >proposed verbally, that provides a secure transport with all the 
> >security characteristics of USM. A critical feature of USM, not 
> >provided by SSH or TLS or RADIUS proposals so far, is local 
> >authentication with NO ties to a third party authenticator.
> 
> Kaushik, Keith and I proposed a method last summer that would have 
> precisely addressed the 2nd sentence in that paragraph.  I believe 
> this leaves David Nelson's question somewhat unanswered.

Again, is a local password or key pair in the context of SSH not exactly
addressing the 2nd sentence above, namely "local authentication with NO
ties to a third party authenticator"? I remain in the confused state for
now.

/js

PS: Our implementation calls out to PAM and it actually does not
    matter whether you configure radius, something else, or local
    passwords if you like that.

-- 
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

v2.23.0 | Report a Bug | By Email